Code Gets Better
Some codebases are crappy — actually, quite a lot of them are — but it’s distinguishably common to hear sharp criticism of code written even by decent engineering teams. Often this takes the form of complaining how the existing codebase is riddled with things-not-done-the-right-way. It’s typical when a small team of hackers grows to a bigger company and hires more programmers.
From an idealistic viewpoint, it’s warranted one. Proper Unit Testing, Continuous Integration, Uniform Coding Style, and Good Code is something that all engineer teams should strive for. But frequently, these complaints carry smugness in one’s own superior abilities and subtle belittlement of others.
It’s easier to carry that out while not thinking critically why that might have happened —
- Maybe cutting corners was imperative to ship the product on time.
- Maybe people were inexperienced when the code was written but have improved their craft since then.
- Maybe the team wasn’t aware about some obvious best practices in terms of security, development and deployment.
- Maybe the team acknowledges the kludge and is in the process of slowly replacing the old code.
- Maybe some of the best practices didn’t make sense in the scenario.
The most obvious thing to miss is that the code works. Yes, it needs to be better but it can be done piece by piece. Practices can be added when they make more sense. There is no point in branching out for small bug fixes when the team is small and product has hardly any users. Unit testing can be incorporated when team grows and codebase acquires a certain level of stability.
I remember browsing PHPMyAdmin’s source few years back thinking how it was a archetypical example of global variables abuse, but ever since has grown to a cleaner namespaced codebase. The code improved gradually while still solving the problem it needs to solve.
Programmers learn fitter ways of thinking about programs and consequently, codebases get better. There are always superior ways in building software, but it’s absurd to demand the absolute best (there probably isn’t any).
Few years back, Heather Arthur wrote about a heartfelt account of disparagement she had to face about her small node.js project which got significant attention on Hacker News. In one of the tweets she responded to the ridicule —
@coreyhaines I wrote that code 2 years ago. If I wrote it today it’d be a lot simpler, not node’s fault.
— Heather Arthur (@harthvader) January 22, 2013
Update: Tweet was deleted. So there’s no link.
Of course, it would be whole lot simpler because she has shipped enough stuff in two years to know better. Unfortunately, it’s far more customary to mock than to accept the natural course of anyone’s growth cycle. The result? Team members who don’t hold each other in high regard. Worse — a toxic work culture.
I am not asserting that one shouldn’t be candid about giving feedback but it should come with gentle nudging towards the (possibly) correct way. Arrogance and stubbornness about it is anything but detrimental. Maybe using a build system would help. Discuss it with the team about its benefits and how it’s a good time to introduce one. But don’t assume that anyone’s a nitwit not to use one.
When you get hired, you are not chosen to be one-off star to fix everything bad, you’re chosen to be part of a team. So when you’re confronted with a code you dislike, the thoughtful path is to suggest, discuss, and improve rather than disdainful about the perfect way — does it even exist?.