Take Pride In What You Do
I’ve been in software development since somewhere around 1997 or 1998, I can’t remember when exactly. I did not actually do a computer science education, but taught myself to program. After starting it as a hobby, I quickly got my first professional job as a developer. The job market was quite easy for a PHP developer, so my skills were not even that important. The fact that I could develop websites that worked was more important.
Despite doing PHP for such a long time already, it wasn’t until somewhere in 2005 that I actually learned to do true programming. Looking back at the time before that, I was mostly “scripting things together”. In 2005, I landed a developer job at TomTom. And the lead developer of my team, Ivo Kendra, taught me the most important lesson of my development career so far.
Pride
I’ve been in a lot of jobs over the time, both before and after my job at TomTom. Several of those jobs were at companies where “it works” was good enough. Because of that, I never even considered code quality; as long as the code worked, I was quite happy. Unit tests? Not important. If I click on the page and fill in the form, it ends up in the database, so it’s good, right?
NO
There are a lot of things you can do to ensure a good code quality. Lots of tools that check the code, pair programming, peer reviews, you name it, but the most important thing to get high quality code is your own mindset. All the tools that are available for ensuring a good code quality are nice, but they only check your work after it has been done. If you have a good mindset, they will never warn you about anything, because you’ve simply done a good job.
The lead developer at TomTom taught me to take pride in the work I do. Every single line of code you write should be good enough to feel good about. It should not just work, but should also make you proud you wrote that line of code. This is the first and foremost step to good code, because as soon as you feel good about the line of code, that means you’ve done your utmost to ensure the code is good. More than that is impossible.
Does that mean you always write perfect code? No, because no developer is able to write perfect code. It also doesn’t guarantee that your unit tests will always pass, or that your code inspection tools will never complain. A developer will always make mistakes, there will always be bugs in your code, and you also have to accept that you never know everything there is about development. There’s always something new to learn.
Safety Nets
You still need your safety nets. Your continuous integration server that checks whether your tests still run, and that do analysis of your codebase to see if anything smells of bad code. Having a tester (or even more than one) functionally testing all changes is also a good safety net. But in the end, it should be a safety net. Your focus should be to write code that does not need to be caught by any of these safety nets.
I don’t regret having done the “scripting”, the “if it works, it’s fine” stuff, because it taught me to be pragmatic. I learned back then that shortcuts work. And yes, there are situations where shortcuts are OK. But what I didn’t do back then, and what I do now, is that I make a very concious choice of when to abandon my pride and take a shortcut because it is needed in the project. Perhaps I only regret it took me such a long time to get to the point where I took real pride in my work.
Pragmatism vs Pride
The problem of pride is that it can turn into arrogance. This is something that you need to be careful about. There is, as far as I’ve experienced, not a single project where you can be proud of every single line of code. Whether it is because of legacy code, time or budget constraints or any other reason, but sometimes you have to set aside your pride and simply be pragmatic. Make sure that you recognize the situations where you need to be pragmatic. There are no rules or easy checklists for when you need to take which approach; this is a matter of experience. Don’t be afraid to make a mistake. You’ll find out sooner or later whether the chosen approach is right or wrong. But make sure you don’t become arrogant. Recognize mistakes and learn from them - it will only make you a better developer.
Beyond Development
The great thing is: You can apply this mindset to more than just development. Take it with you for everything you do, starting with your work, through your friendships to raising children. And remember that software development should never be 100% of your life anyway.
About Me
I’m a self-taught software developer, running my own company called Ingewikkeld (Dutch for “complex” or “complicated”, the way I like my projects) and speaking worldwide at conferences on a variety of topics. Quality has been a important part of my projects since 2005.
Tweet