Whom we Write Code for

As developers whom do we write code for?

This is one of the questions that I like to throw at beginning developers at my workplace. It is a question open enough to get even shy people involved in a discussion, yet relevant and tangible enough to yield answers that can guide us in our daily work.

Whom, then, do we developers write code for?

Simple answer: Computers

Obviously, we write code for computers, be it compilers or interpreters (in most cases). Clearly, this can't be a wrong answer. And it is not. For what is code worth that doesn't even compile and can't be interpreted?

Then again, pseudo code is something that can hold a lot of educational value, yet doesn't need compiling or interpreting. Though, pseudo code is not what pays our bills (not as developers, at least, as instructors maybe).

So, is the machine all we write code for? No, it is not. If that were the case, there wouldn't be a need for high-level languages such as C#, Java, Swift and the like. We could happily type away in assembly or machine code instead, and for sure only few of us would enjoy that (I certainly wouldn't).

So, whom or what else do we write code for?

Next try: Our Clients!

We write code for whomever pays us writing it. Another crystal clear answer that is absolutely true and yet entirely false. Yes, we get paid by our clients to write code for them that they couldn't (in some cases, wouldn't) write themselves. It is them who tell us what our product is supposed to do, so we have to write code that satisfies their business needs.

And yet, the functional criterion here is only one of many criteria. There are nonfunctional aspects to consider when writing code. To put it simple, we can write code that satisfies all business needs and yet delivers a product that fails spectacularly (indeed, this happens more frequently than beginning devs might think).

So, if we do not write code solely for machines, and not solely for our clients, whom else could we write it for?

Final one: All our code are belong to us!

At the end of the day, writing code is first and foremost something that we do for ourselves. We write code for ourselves because we have to maintain it tomorrow. We write code for our colleagues because they will have to use our work, fix some bug, or add a new feature. We write code for every human being who comes across it.

This is as trivial as it is important: code is written not for a machine, not for a client, not for anything else but fellow human beings. And we should not forget that those people touching our code are very likely to be under a lot of pressure. They are probably not keen on deciphering hieroglyphs or fishing in the dark. They would most certainly appreciate code that reveals itself upon them and guides them through its peculiarities in good faith.

So it is up to each and every one of us to take good care of our code, to communicate our intent clearly, to let our code tell a story that our fellow developers will be happy to engage in.

Let us write code and pretend we would have all forgotten about it the next moment. Would we be happy to touch it the next day and fix a bug or add some features? Would we enjoy reading our code, working in it? If we answer "no" to any of these questions, we are not writing the code that our fellow developers (or even we ourselves) deserve.

We should never forget that every single line that gets written once, is read ten times or more. Bottom line, code generally must be optimized for reading, not for writing (performance aspects and the like put aside, those may be rare exceptions). And that in itself is far more difficult than it may sound.

We can rest assured that everyone of us is grateful to someone who cared enough to write clear and intention-revealing code. Let us be that someone!