Professional Corner-Cutting (2016)
Balancing craftsmanship with pragmatism in software engineering provokes strong views: some argue professionals should cut corners strategically to ship on time, while others see “corner-cutting” as a euphemism for poor quality and burnout-inducing practices. Commenters contrast Steve Jobs–style obsessive attention to unseen details with real-world pressures like deadlines, management incentives, and technical debt, debating who should decide which shortcuts are acceptable and how to weigh long-term maintainability against short-term business needs. Many conclude that true expertise lies in knowing which corners can safely be cut—and when doing so simply shifts hidden costs to the future.
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.