A programmer rightly condemns the code-first approach to programming:
There are two kinds of programmers, generally speaking. There are programmers who care more about code, and there are programmers who care more about product. The former – I’ll call them “code-first” programmers – are obsessed with how code is architected, what tools, libraries and languages are used, how much test coverage there is – stuff like that. Code-first programmers are psyched when they check in the perfect abstraction, when they get to use the latest language-feature, when they delete dead code. That is, they love the code they write – the code is the thing.
The product-first programmer cares about that stuff too, kind of, but only as a means to an end. For product-first programmers, the code is the scaffolding, the support, the steel beams in the building, but not the end product. The end product is, well, the product, not the code, and what matters to them is how well that product actually solves the underlying problem. Does the building stay upright? Do the elevators work? Is the A/C functioning? Do people like being there? Product-first programmers love building and launching and seeing users use what they’ve built. The product is the thing.
Anyone who has worked at a place like Google has met plenty of code-first programmers. They are the teammates who are always refactoring code and nit-picking spelling in your function comments. They are in the micro-kitchen complaining about “spaghetti code,” “technical debt,” and the lack of rigor in other teams’ code review processes. They are probably not fixing bugs or launching features. You can probably tell I’m not a huge fan of the code-first approach.
When I interview programmers I’m always amazed at how many of them seem to think the code-first approach is what I’m looking for. Trying to impress me, they ask: “What’s your unit test coverage like?” Pretty close to zero; this is a startup. “Do you guys use hot new technology X.” Not yet, no, how would that help us build the right thing faster? “Is there a lot of technical debt?” We will have to rewrite everything at some point, but it doesn’t matter right now because we haven’t even figured out the right thing to build.
They have an understandable but fundamental misconception of what programming is all about. Programming is about building products that solve problems for users not about writing beautiful code for its own sake.
It can be remarkable how difficult it is to convince people, in a wide variety of activities and occupations, that it is the ends, and not the means, that are the actual objective. Whether it is businessmen planning new ventures, people getting involved in politics, or sports teams taking the field, the confusion of means with ends and process with results almost inevitably results in eventual failure.
Process is important, but only with the context of achieving the desired results. It is not important in and of itself.