About the Developer Profession #1: How Many Decisions Do You Make in Real Time?

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

In this series of articles, I’ll be discussing the developer profession from different angles. The common denominator is that all articles will, in one way or another, be about professionalism. This first article is about the different factors and decisions behind every single line of code.

Notes snd Equations

A while ago I spoke to a friend who is pretty much a professional singer. He explained singing to me in a very passionate way, saying that singing is like solving multiple parallel equations in real time. He told me that it’s quite obvious that every singer has to follow notes. What’s less obvious is that the singer also takes a multitude of micro decisions during every second of his/hers singing. He told me about tempo, intensity, interpretation of the composer, matching the expectations of the audience, synchronization with other singers, following the Kapellmeister, and a bunch of other factors. I was quite impressed.

A second later it struck me that this goes for programming as well, and I started to list all the equations a developer must solve while writing a single line of code. Here it is!

Syntactic correctness: will this line of code compile?

Coding conventions: does this line of code follow the company’s or some other coding conventions?

Formatting and spatiality: is this line of code formatted and is it arranged vertically in a way that makes reading easy?

Logical belonging: does this line of code belong in this context (class/file/module/system)? Or is it a surprise hack?

Recommended best practices/pattern: is this line of code part of an implementation of a design pattern or best practice?

Language/framework idioms: different languages and frameworks have their own idioms. Does this line of code follow them?

Adherence to design and architecture: does this line of code support the current architecture/design?

Testability: is this line of code testable, or does it contain constructs that make testing harder?

Simplicity: is this line of code simple and minimal while readable at the same time?

Performance: premature optimization is the root of evil, but there’s no reward for writing particularly inefficient code. Is this line of code reasonably efficient?

Security: is this line of code resilient to the most common attacks?

Deployability: does this line of code contribute to making the deployment of the system easier or harder?

Alignment with current task: does this line of code bring us closer to completing the current task? Can we move a sticky on the whiteboard?

Alignment with business goals: does this line of code support the way our company makes money? Or does it become a cost as soon as it’s written?

Delighting the users: does this line of code help us win our users’ hearts?

I came up with this list quite spontaneously. I bet it’s far from complete, but that’s beside the point. I’ve managed to come up with 15 questions developers can ask themselves while writing every single line of code. Now where does professionalism come in? In my experience more is better here! Look at this list again and think back at your junior developer time or your observations of less skilled developers in action. How many of these questions were being asked? I argue that more professional developers take more of these (and other) factors into account. This, in a way, makes them slower at churning out code, but the result is better and saves time and money in a wider time frame.

How many equations are you solving in real time?

One comment

  • 1
    Nick
    2014-09-03 - 04:35 | Permalink

    Sure – I see this in other developers and sometimes I fall in a trap of laziness and expediency – but I hope that is rare 🙂 When I’m developing, experience has taught me these things and I do them automatically but try and reflect on it later as well.

    By not doing some of these practices implies selfishness to me. Sometimes, it’s driven by project managers inflicting their desires – they usually aren’t from a development background.

    Sometimes it just an unwillingness to improve on the developer’s part. Getting comfortable with challenging oneself is a root cause. Unwillingness to adapt, to admit faults.

    Coaching for willingness, a coalition of the willing if you will. Adopting humility and minimizing hubris is a way to go.

    Good things to take into life.

  • Leave a Reply

    Your email address will not be published. Required fields are marked *