Doing good engineering vs. getting shit done
By good engineering I mean following good engineering practices and writing maintainable code. It includes, but is not limited to doing Test Driven Development, writing tests, using the CI and CD, implementing a design pattern, religiously doing code reviews.
By getting shit done I mean doing whatever little is needed to implement the feature. Just mark the jira ticket to done without doing any of the things mentioned above. This will invariably lead to bugs.
Some incidents at work prompted me to post on reddit: Writing high quality maintainable code v/s getting shit done? I felt like I’m forever stuck in this dilemma and I wanted to know what other people in the industry (especially senior people) felt. To my surprise, this post got a lot of attention and it was really nice going through all the comments. Most of the people agreed with the topmost comment:
I have a “tech debt dial” which goes from 0% to 100%.
If I dial it down to 0% that means the team should be in full on hack mode. Fuck tests, fuck good coding standards just get it done.
If I dial it up to 100% that means the team only works on code quality (refactoring) and tooling (e.g. tests / CI infrastructure).
Ultimately on a normal day we leave it at 30%
Many others gave their own version of the above. But then I came across:
There’s a false dichotomy between “beautiful code” and code that is “fast to write”.
Writing beautiful code does not take longer than writing messy code. What takes long time is to learn how to write maintainable code.
What a revelation! “What takes long time is to learn how to write maintainable code.”
It took sometime, and some arguments both at work and on reddit, for me to agree with that. But once I did, I was totally on board with it. I decided I will stop hacking up stuff and actually do good engineering. This prompted me to write another post: Learn to write maintainable code instead of getting shit done. To my utter surprise this post got even more attention. Seems like a lot of developers agreed with me.
I don’t want to get into the mindset of there’s a tradeoff between speed and good engineering. There is no tradeoff. Rather, the mindset I want to be in is I take time do it right- that’s because I have a lot left to learn. This is a much better place to be in.
However, doing good engineering is easier said than done. It becomes an order of magnitude harder when people you work with do not see the importance of it. Not only do you have to spend extra time and effort to learn how to do it, you also have to explain to the manager why this feature will take you a week instead of 1 day that it’ll take the other developer to do.
But I have decided. I will stick to my guns and not give in. Even if my job is on the line. In any case, I wouldn’t want to work at a place that doesn’t understand the importance of good engineering.
Bad engineering only gives a perception of speed. Take 1 day to build a feature, take another week to debug and fix bugs. Groups of people and entire companies fall into this trap. I do not want to fuel such a culture.
I don’t write software for money, I do it for the love of engineering. I get a dopamine rush when I solve problems. It doesn’t happen everyday. It happens when I learn something new. It happened when I first did TDD. It happened when I understood dependency injection.
I have to do good engineering. I owe it to the software engineering community- the one that gives me answers on Stack Overflow and on the internet search, the one that made the linux kernel that powers my MacBook, android and iOS, the one that is fighting back tyranny of governments and federal banks by developing bitcoin and ethereum. A free and open community that I am deeply humbled and proud to be a part of.