In 2004, I graduated from University with a degree in Computer Science and a graduate job at a large investment bank. In the years since, I have worked as a technologist in some of the world’s biggest banks and as of 2017, at a startup in London.
I have had many titles: business analyst, project manager, team lead; but I have always written code.
Earlier this week, I came across this thread on Hacker News. It is an “Ask HN” thread: “What habits make a programmer great?”. Go ahead and read it, it has some great advice.
It got me thinking about what I could add to that discussion. I am not a great programmer, but I get things done and I have had many years of mistakes to learn from.
So here are my 2p..
You will get frustrated, and it’s OK
Our field worships productivity. We hear about amazing applications built over a weekend. There is always someone who gets things done faster.
The truth is that programming is hard, sometimes lonely and often frustrating. Some of us work long hours, face challenging deadlines and difficult clients. Getting stuff done can be a long and arduous grind.
Getting angry and frustrated is perfectly normal. However, if not managed properly, it will lead to burnout and disillusionment.
Find out what coping strategies works best for you. When I feel like things are getting a bit too much for me, I go for a walk. Others grab a coffee and vent to a friend, some even talk to rubber ducks..
Be kind to yourself. Programming is mentally taxing, and your effectiveness depends on a number of factors that may be outside your control. Some days will suck, and you will feel like you got nothing done. It’s OK.
Know and love your tools
Our field moves fast, and every day there is a new tool, package manager or framework that will solve all your problems and make you a 10X programmer. This is a trap.
Take IDEs for example. I use IntellIJ IDEA for Java, Python, and JavaScript development. It is probably the most complicated application on my computer. It has taken me years to just get to the point where I can navigate the interface, understand the capabilities and am productive using the IDE. If I switched to something else, my productivity would plummet immediately.
You have already sunk hours into learning the tools you are using currently. Think of the return on investment (ROI) for all the time you have spent before moving on. Learn and love the tools that you use, and strive for max ROI.
Tools and frameworks come and go, but time moves only in one direction.
Don’t dive right in
I am biased towards action. Given a choice between just getting started on doing something (anything..) or spending a few minutes thinking and planning, I tend to choose action over contemplation. I see this same tendency in many other programmers.
Diving right in feels good, feels productive, however I have learnt that this is merely an illusion. This approach has let me to dead ends, wasted time and frustration.
When faced with a feature to build or a problem to solve, I ask myself these questions:
- What is the goal?
- Will doing this move things (the product, project or company) forward?
- How does this problem relate to what I know already? Do I know enough?
Once I have processed the problem, I work on outlining a solution. This can be a doodle, a user story or sometimes just a bunch of comments in an IDE. This exercise makes writing code the easy part of the whole process.
“Start projects by measuring the current state of the world. This goes against our engineering instincts to start fixing things. But when you measure the baseline, you will actually know whether you are fixing things.”
Kent Beck
Refactor vs rewrite is a false dilemma
Everyone comes across a codebase that is so convoluted, so messy, so gnarly that the first instinct is to just want to bin it and start all over again. In some cases, this may be the right thing to do, for example if your client is willing to pay for a feature that would not be possible to implement given the current codebase.
However, in most cases looking at ways to clean up the legacy codebase by refactoring it is the more productive approach. Modern IDEs and code coverage tools make it easy to refactor a large codebase. This combined with a pragmatic approach to unit testing will take you a long way towards quickly and safely delivering value.
Refactor vs. rewrite is not a binary choice. It is a continuum that is heavily biased towards refactoring.
I have and have been a team member of numerous projects that were ground up rewrites. Most were abject failures. We spent weeks (sometime months) delivering functionality that already existed. By the time we got to adding value, the projects was behind schedule and over budget.
Don’t ignore the context
Nobody wants to write terrible code. The messy codebase you inherited is the result of battles wons and lessons learnt. It may give you a headache, but there is always something to learn.
It is worth spending some time to understand what problems the codebase is trying to solve and why it ended up the way it did. In most cases, it is the legacy codebase that is being actively used by your customers and paying your salary.
By ignoring the “why” and focusing on “how”, we are doomed to repeat the mistakes of the past. If the codebase is messy and broken, try to understand what caused that situation and try not to repeat the same mistakes or adopt the same patterns.
In conclusion
I have been part of more projects that have been qualified successes and unqualified disasters than those that have been unqualified successes. I am a mediocre programmer, but I keep striving to learn from my mistakes and make small improvements everyday.
What have you learnt from your mistakes?