A little while back two things happened to me that made me wonder how I was doing as a software developer.
- I’d taken part in a coding challenge that was meant to be simple, but I’d done pretty poorly.
- I started noticing that the code I was writing was exactly the type of code I encouraged others not to write earlier in my career.
I started wondering…
Am I a good software developer?
Am I getting better?
The Bike Shed is a podcast cast about software development, and it’s one of my favorite podcasts. The hosts Chris and Steph do an incredible job of having interesting things to talk about each week. And, as luck would have it, they were asking for listener questions.
I wrote to them.
How do you know you’re improving as developers? Is your improvement consistent? Are there regressions? I find myself having very different views about code than I did even a year ago. In some cases, I write code now in a way that I would have criticized not too long ago. For example, I started writing a lot more comments. I used to think a well-named variable obviated the need for comments. While it feels like I’m improving, I have no way of measuring the improvement. It’s only a gut feeling. Thanks. Love the show.
On May 25th, 2021, they read my question on the podcast and shared their thoughts. I was blown away by the level of thought that went into their responses. I decided to summarize their ideas and am presenting it here for my own use, but hopefully for yours, too. I’m combining both Chris and Steph’s ideas as there is a lot of agreement between the two.
Here’s a link to the episode. I recommend listening to it because my summary doesn’t capture everything.
A Quick Note About Me
The way I understand Chris and Steph’s advice is coloured by my own experiences.
I am a 39 years old, but I only have 4 years of experience in the software development. I switched careers from teaching English to software development at the age of 35. I’ve only ever worked at one company. I write software for the web. I’m a self taught (or blog internet-taught) developer.
How Do You Know If You’re Improving
I’ve bolded ideas that I found particularly useful.
- You are becoming more comfortable with, and faster at, the work that you’re doing.
- Your time estimates are becoming more accurate.
- People are more often coming to you for help. (Tom note: I really like this way of measuring your skill level. If no one asks for your help, it might be an indication that they don’t see you as knowledgeable. It might also mean they think you’re a jerk. More on that later.)
- You are given more responsibilities.
- You write robust code that doesn’t need to be tweaked to handle cases you hadn’t thought about, and doesn’t introduce bugs. (Tom note: This was interesting to think about. There’s a lot of code that I’ve written that I never go back to because it just works. But because I never have to revisit it, I forget how well it’s working. It might be worthwhile to keep a list of things I’ve built that just keep on working.)
- When developers have to work with your code months after you wrote it, they find it easy to read, change, and extend.
- You feel confident taking on features that are outside of your comfort zone. (Tom note: It can be a challenge getting assigned tasks that are outside your comfort zone because you have never build anything like it before. Definitely worth talking to your manager about.)
- You are able to unblock yourself. (Tom note: A manager once told me that a sign of a senior developer is that when they can’t get a library to work, they look at the library code to see how it works. This feels like the same idea. Knowing what to do to get yourself unblocked.)
- You are able to balance code quality and speed, and determine what features should be part of an MVP, and what can come later.
- You are able to translate business requirements to technical requirements, and to help the product team understand the trade-offs in different approaches. (Tom note: I found this surprisingly difficult in my first couple years as a developer. I just wasn’t comfortable enough with the technical concepts to be able explain trade-offs.)
- You get better at determining what should be public and what should be private when building an API. You understand why these things matter when other developers will interact with them.
- You write better, more important tests because you know what’s important to test.
- You look back at code you wrote months ago and see that you’ve improved. But, hopefully, as you progress in your career you aren’t as unhappy with the code you wrote a few months earlier.
- Ask your manager if you are improving. (Tom note: This is good advice, but there are reasons people might not follow it. There were times at my company when we had very few developers. We were an early-stage start up. At that time it didn’t feel like it made sense to have formal meetings with my manager. I also know developers who do not want to ask their manager if they are improving because they are afraid they’ll find out that the manger thinks they are not improving.)
How To Improve
- Explore different languages and frameworks. (Tom note: TypeScript has had a huge impact on my PHP code. Go has made me reconsider so much I thought I new about programming.)
- Teach others how to code. Even if it’s just a lunch and learn.
- Pair program. (Tom note: Early in my career I had a bad experience with pair programming. It really soured me to the idea. But I think it’s time to revisit it.)
- Don’t be afraid to write code quickly and get feedback on it. The first draft doesn’t have to be perfect. The sooner you get eyes on it, the sooner you can improve it.
- Decide on how you want to improve, and figure out way to get there that you can measure.
Should We Wrap Up
It was amazing listening to Chris and Steph’s thoughts on my question. Their advice for measuring improvement is split between ways of becoming a better “coder” and ways of becoming a more useful team member (sort of a hard skill vs soft skills split). I really like this. I have a tendency to focus strictly on the technical aspects of becoming a better developer, but as I progress in my career it’s becoming obvious that I’ll need to spend time developing leadership skills, too.