Recently I’ve been reading a lot of articles about two topics:
Both topics are very related and reading about them has given me a better understanding of the bigger picture. This post will focus on the second point, though I imagine a future post will discuss the first.
I want to be up front about what I’m about to discuss. This article isn’t about being just a “good” developer, it’s about being the absolute best developer you can be. There are many people out there who just do development as a way to pay the bills or just want to put in their eight hours a day. That’s fine, but this article isn’t for them. I got lucky that I get paid to do my hobby every day. I work on development outside of work because it’s what I’m passionate about.
The expectation of anyone who is getting paid to develop software, regardless of if they like it or not, is for them to work hard, solve problems, and keep up to date with their given technology. Those are the table stakes. If you’re not already excelling at those then stop reading this and do what needs to be done. Going above and beyond doesn’t count if you’re not meeting basic expectations, you’re just not doing your job.
The core of becoming and staying a great developer is discipline. This comes in many forms (as Coding Horror describes so well) from maintaining consistent code styling to rigorous evaluation of new tools before jumping on the bandwagon. Discipline is you putting in the work before and after performing too, not just during. And I don’t mean you have to learn a bunch of things outside of work (though that usually helps), I mean taking the time to evaluate yourself.
It’s critical to stick your head up above water every once in a while to make sure that you are doing everything as well as you can, or, more likely, to identify your own process to find what you should work on. A phrase I’ve heard is those who make it look easy are the ones who put in the most work.
This one was a big mental shift for me: you are not the best developer you could be. Originally I was going to put “you suck at development”, but that’s not necessarily the case. You could be a great developer, but you’re not as good as you could be. This should be your driver. Assuming you want to become the best developer you can (which if you made it past Table Stakes I’m assuming you do) you should be seeking out ways to become better. The critical word in the last sentence is seeking: how to become a better developer won’t find you, you have to find it. This means read articles, read other people’s code, fix other people’s code, write code, write a ton more code, and seek out feedback.
The different mindsets of someone who has accepted the above and someone who hasn’t is best shown through an example. Everyone knows that pair programming and code reviews are great, so let’s say someone just reviewed your Pull Request and gave you some feedback. You could have one of two reactions:
How dare you suggest that I didn’t write the code in the best way? Have you been working on this module for the past three weeks? Then how do you know what’s best for it? And who cares that you can’t understand the logic? It’s definitely not because it’s unmaintainable, it’s probably because you aren’t a good developer.
Or:
Awesome, thanks. I didn’t realize that the code wasn’t readable, thanks for letting me know. How could it be better? What parts were tough to read? Let’s have a discussion to find out what the best solution is.
Ok, so maybe I went a little overboard with the negative reaction, but can you think of someone (even yourself in a past life) who would react like that?
The first reaction has all sorts of issues with it, so I rather focus on the positive reaction. Your reaction to feedback about your code, style, process, or anything else should pretty much be Awesome, thanks for the feedback. And I don’t mean this in a “be polite and professional” sort of way. I mean this in a “thank you for giving me another perspective on how I as a developer write code and participate as a member of the team”. If someone says your code is hard to read, is it? Did they suggest a better way of writing that module? That’s friggen awesome, thanks for teaching me something. Your whole goal is to become a better developer, right? Isn’t a huge part of being a developer recognizing how you best fit within the team?
So you got some feedback from a coworker or an article you read. This is where the “before and after” work I mentioned above comes in. Many of these action items require actual work like practicing a different coding style, reading about best practices, and refactoring your code. Sometimes the work is more reflective by asking yourself where your own weaknesses are, how you can improve them, and how you can best use your strengths to help the team. These are all supplementary, i.e. you could still probably do your job without them, but these are what actually make you a better developer.
An example of how this is important is in the disparity between “years of experience” and how good of a developer you actually are. One could do the exact same bad development for ten years yet be woefully unqualified for a job when someone with one year of self-aware experience and be far more qualified. I care much more about the quality of someone’s experience than the quantity of it. Make sure that the experience you are gaining actually improves you as a developer instead of just piles up on your resume.
So finally we get down to the phrase “by any means necessary”. This is the phrase that I think best describes how you should become a better developer. I want to become the best developer I can be by any means necessary. Do I need to put in work outside of work? Do I need to step out of my comfort zone and work on things I’m not an expert in? Do I need to shine the light on my own weaknesses and work on them? Do I need to accept that I know far from everything and that there are lots of people out there I can learn from? A resounding yes to all of those. I can’t get defensive about feedback. My job as a developer is to provide as much business value to the customer(s) through software as possible, so I will do whatever it takes to make sure I am the best developer I can be, by any means necessary.