Life of a Stoic Programmer

Becoming stoic as you do the job you love?

Markus is a stoic programmer. He is constantly in search of the original teachings of the great Roman philosophers like Seneca, Epictetus, Marcus (strangely very similar to his name). It’s been around ten years that he has been following the path of the stoic programmer and has striven to become the stoic sage.

Always have a plan

He sits at his workstation and takes note of the things that need to be done on that day. Of course, he needs to be rational in his account of things.

The marks of a rational person page

Markus considers himself as a rational man. Programming is an art, it’s a craft and exercising this craft hinges greatly on his ability to be rational. As he was thinking this, he started listing down the three main characteristics of being rational.

He needs to look inwards for all things.
He needs to hold himself to the highest standards and be the most critical of himself.
He needs to make his own decisions, independent of any popular notions.

Opinions

This makes him thoughtful as to what are popular notions and to put it otherwise, what are opinions. Nothing is good or bad by itself; it is perspective which differentiates between good and bad. The feelings that he has towards something are only the product of his thoughts and hence, the code that the junior programmer has written is not bad in itself. He is on the road to development and is in need of some guidance. Markus makes a mental note to have a word with the developer and understand how he can help the person out.

Don’t let this go to your head

Markus is again at his work station. He opens up his inbox to see if there is anything important that he should be looking at with priority. But, he sees his inbox filled up with appreciation email on a recent code critical bug fix that he had done. He glances over the email and sends a ‘thank you’ as a reply. This doesn’t register with him. He is happy with the work that he delivers every day and only delivers the work when he is happy with it. Yes, he was happy with the bug fix when he was able to find the bug. This did take a considerable amount of hard work, but, he is not motivated by the appreciation alone. Any appreciation depends on the whims of the management which he does not control. He is only able to control how he delivers and if they are happy with him, well and good; else it’s okay.

Trust but verify

Markus works with developers whom he trusts and respects as highly talented and hardworking individuals. But, he does not give them any leeway and is very meticulous about unit-tests. Markus trusts the code that is written by the developers but is always the first one to raise the question when the code coverage is less than 100%. On his part, he takes extra hours to ensure that not only is the code coverage 100% but all the edge cases are covered as well.

Don’t impress

Markus takes pains to make the code as simple and readable as possible. He understands reading code is difficult and therefore, he tries to make the files as small as possible, putting extra efforts to keep them within 250 lines. You will never find any function that has multiple ‘if’ statements or more than 20 lines. Being a true stoic, he does not go into introducing esoteric libraries and patterns in the code, to show off his capabilities.

The definition of insanity

The whole point of programming is that the same actions should always give the same result. If this were not the case, the whole vocation of programming would not be there. Markus understands this and so, he also apprehends the corollary. If some program doesn’t work, then it will not work the next time it is run. If it somehow executes perfectly, then it’s a cause of worry, as the obvious conclusion is that the program is dependent on some state changes and hence, a risk.

Dealing with loss

Till recently Markus was a dot net programmer building windows desktop apps, but the company he was working for suddenly decided not to build desktop apps anymore. Instead of letting the developers know of the change in the direction of the company beforehand and asking them to re-skill in a relevant technology of choice, all the dot net developers were fired. Other developers who were working with Markus were angry. They came to him and expressed their angry and disappointed. But Markus calmly told them that such bad things happen. Worse things happen. They should get over it and focus on the next thing.

Then Markus collected his stuff, came home and started looking at various languages and tech stack that he has been working for a long time.

Antifragility

Markus is a champion of anti-fragility. What is anti-fragility in the programming context? It’s when a code is easy to be changed and maintained. He looks at the SOLID principles with a high degree of suspicion. The whole concept of SOLID is that the code is only open to some changes while it is closed in general. This makes the code highly fragile. This doesn’t mean that the principles are useless. It means that specific use case must be carefully examined before implementing this. Again being a true Stoic, Markus doesn’t do anything out of habit but evaluated each use case and conditions minutely before deciding.

Training

As a stoic, it is essential for Markus to keep some time apart for his daily training on various topics. And he is not at all apologetic about it. He doesn’t look forward to learning everything. He is not a fast learner but focuses more on learning deeply. Recently, after learning the basics of Principal Component Analysis, which is a way of thinking in the field of machine learning, he went and talked to the data scientists in his project. The reason for this discussion was to see if some models could benefit from this analysis. After collaborating, they found that they could increase the performance in around 60% of the models that were there in production. Thus, he not only learns something but applies it as well.

Review and retrospect

Then, at the end of it all, there is the review and retrospection that comes. Markus is happy that code reviews have become the standard in the software industry but he knows that as with all good things, it must be guarded and constantly championed for. Else, it is very easy for people to become complacent and give it a pass. In fact, he had watched with horror, when during hours of high pressure and pressing deadlines the whole activity of code reviews was dropped. So, he reminds himself that he needs to push for better reviews and retrospection on the work that gets done and delivered.