Professional Corner-Cutting (2016)

Steve Jobs, cabinets, and hidden craftsmanship

• Several commenters recall the “beautiful back of the cabinet” story and debate whether Jobs advocated never cutting corners or doing so selectively.
• Some argue the metaphor is technically off: plywood backs can be superior for stability and cost, and even historical furniture often has plain, unfinished backs.
• Others stress the point was aesthetic and identity-driven: quality even where unseen, as a source of pride and marketing to people who identify with craftsmanship.
• Apple’s “beautiful internals” are cited as aligning with this ethos, though some feel Apple’s software and repairability don’t always match the myth.

Corner‑cutting vs. professionalism

• Broad agreement that trade‑offs are inevitable; the “professional” skill is knowing which corners matter to users and future maintenance.
• Tension between doing fewer features well vs. many features poorly; many favor the former.
• “Perfectionism” is described as both a necessary defense of quality and a term weaponized to shut down legitimate risk and quality concerns.
• Some emphasize down‑scoping and choosing simpler solutions (Firebase, UI libraries) as distinct from doing shoddy work.

Technical debt and “we’ll fix it later”

• Disagreement over whether “fix it later” is usually a lie or sometimes a rational business choice, even for serious issues.
• Many say technical debt is inevitable, often emerging from formerly good decisions as context changes (e.g., dependencies).
• Some advocate silently baking refactoring and debt repayment into estimates rather than asking permission, since “later” rarely comes.
• Others insist business leadership must explicitly weigh trade‑offs, not engineers unilaterally.
• The “tech debt” metaphor itself is criticized as misleading; its “interest” is unpredictable and unstructured.

Managers, incentives, and autonomy

• Experiences diverge: some report managers who happily approve extra time for quality; others describe cultures where speed, ticket count, and deadlines dominate.
• Many note that organizational incentives (scrum, metrics, career pressure) often discourage craft and long‑term thinking, pushing developers toward assembly‑line behavior.
• Burnout is linked to caring about quality beyond what the company structurally supports.

Ethics and broader impact

• Discussion extends to ethical codes that prioritize public safety, privacy, and welfare.
• One view: working on platforms that amplify harm can conflict with such codes, so ethical engineers would avoid them entirely.
• Counterview: ethics mostly means not breaking laws or directly implementing harmful shortcuts; platforms also have positive uses, and regulation is a state responsibility.

Predictability, overengineering, and YAGNI

• Some argue good engineers anticipate common future needs (e.g., UTF‑8, scalable abstractions) at near‑zero extra cost.
• Others warn this easily slides into overgeneralization and slowed delivery; the right balance is contextual and subtle.

Limits of the cabinet analogy for software

• Multiple comments note software differs: unknown future uses, hostile environments, many stakeholders, and multi‑customer products.
• This makes “what the customer cares about” and “when quality matters” far harder to judge than for a single physical cabinet.