In software development there is a tension between obsessing about a single line of code, and shipping. Focus too much on the perfect code and you will never ship a product, but ship without caring about the underlying code and its structure introduces the risk of poor product quality (bugs, inefficiencies) and building up long-term technical debt. This tension is not specific to software development; the tension equally well applies to other kinds of creative work like writing a paper or a book.

In the end, shipping becomes most important, because otherwise the value of all your efforts are to some extent squandered.1

Perfect is the enemy of good.

Not every line or block of code has to be perfect, but there is great value in consistency. I believe consistency is a highly valuable trait in a programmer. What do I mean by consistency? Consistency can mean many different things, ranging from coding style to the choice of libraries and architectural designs.

Here are a few examples of poor stylistic (syntactical) decisions:

  • Sometimes indent you code with tabs and sometimes with spaces, or if using spaces, sometimes using 2 spaces and sometimes 4
  • Sometimes write if(var==2){ and sometimes if (var == 2) {, or any combination in between
  • If semi-colons are optional at end of statements, sometimes include them and sometimes not
  • If braces are optional for single-statement blocks, sometimes include use them and sometimes not2
  • Sometimes horizontally align variables and sometimes not3

You get the point. But why does it matter you say? It’s not going to effect the running code. Am I just being pedantic? Perhaps, but I strongly believe in syntactical and stylistic consistency. It’s important for readability, which is important for maintainability, which in turn is important for evolving and improving the code in the long run. Readability is more than just avoiding writing “too smart” code, it’s also about style.

Examples of consistency in library choices (unless there are specific needs) include avoiding using two different libraries for handling JSON in the same program, or using two different libraries for making HTTP requests. Sometimes a language, or framework, comes with built-in capabilities to make HTTP requests. If the built-in library is used in some situations but an external library is used in others, it requires programmers to be familiar with the quirks of both libraries. Be pragmatic, but think twice before adding a second way to make HTTP requests, or for anything else.

Examples of architectural decisions can for example be as simple as having consistent API designs with common formats and structures for handling errors and providing error messages.

To me consistency in programming and software development is just common sense, but I’m surprised how many programmers don’t seem to care about it.

To be consistent, you have to be detail-oriented. It’s impossible to be consistent if you pay no attention to details.

The kind of detail-orientation I’ve given examples of above are not necessarily requirements in deciding whether a person can, for example, design scalable and effective software architectures. However, I do believe attention to detail is somewhat of a canary in the coal mine to determine if a developer will be able to effectively develop, organize and maintain large-scale code-bases and architectures.

The need for attention to details is not only for the code itself, but also for the documentation, the issue tracking, the tests, and the deployments and orchestration scripts.

Douglas Rushkoff writes in The New York Times about grammar and clear thinking:

[A]n employee who can write properly is far more valuable and promotable than one whose ambiguous text is likely to create confusion, legal liability and embarrassment. Moreover, a thinking citizen deserves the basic skills required to make sense through language, and to parse the sense and nonsense of others.

Writing has to be clear, otherwise it causes confusion. This also applies to software development and architectural design, choice of tools and libraries, and, yes, the style of a single line of code.

  1. However, there is also inherent value in the work itself because you always learn something along the way.

  2. I’m looking at you Java.

  3. Actually, never align your variables horizontally