Know Where to Polish
Software engineers are typically drawn to the ideals of craftsmanship. Many books and blogs praise caring deeply about code in a similar way to an artisanal woodworker caring about every detail of the wood they shape.
This story about Steve Jobs comes to mind for me:
Fifty years later the fence still surrounds the back and side yards of the house in Mountain View. As Jobs showed it off to me, he caressed the stockade panels and recalled a lesson that his father implanted deeply in him. It was important, his father said, to craft the backs of cabinets and fences properly, even though they were hidden. ‘He loved doing things right. He even cared about the look of the parts you couldn’t see.’
Paint the part of the fence that no one else can see but you.
Intermediate Stages versus the Final Piece
There is an important distinction though about where we should focus our energy. For example, music and film share similar intermediate stages with software in that listeners don’t see your audio tracks or GarageBand project. Viewers don’t see your Final Cut Pro timeline organization or clip naming. Code is hopefully never seen by the people who use it. What listeners, viewers, and users care about is the piece they experience. When it’s done beautifully we call it art.
Schematics
We should view source code as something more like a GarageBand file, Final Cut Pro project, or hand drawn plan by a craftsman – it’s a schematic not the final thing itself.
Am I suggesting we leave wood scraps and saw dust all over the work area? No.
But some of the best video editors I’ve worked with leave horrific messes while working. They focus relentlessly though on every moment in the final edit being exactly how they want. The names of the tracks? The folders where things are stored? The versions of the project file name? Chaotic to an outside observer. It can be hard to collaborate and work along side folks like that, but their completed work speaks for itself.
Given the ideal option we all want to be great at every step along the way. But your music, film, and code don’t matter if the final thing that people experience is not good. Perfectly organizing and endlessly debating parts of the intermediate stage, anything that doesn’t affect the final product, is missing the big picture.
Most of Apple’s sample iOS code wouldn’t pass the corporate code review gauntlets at the large places I’ve worked. Yet many engineers I know aspire to work at Apple, where only the best engineers make it through the hiring process. Apple’s sample code is a teaching tool not the final product. Engineers want to work there because we respect what they ship. Not the sample code. They know what they’re doing.
Know what you’re building and which stage in the process you are focusing on. Polish the thing that people will use, yes even the parts they can’t see, but don’t fight about the intermediate stages along the way. Save your fire and fury for the final product.