Measuring progress as a developer

nickbenoit14 profile image Nick Benoit ・1 min read

Progress comes slowly, but still, if I think of where I was a year ago I am certain that I have come a long way. There are few days where I can close my laptop for the day without having learned something useful. Though I know I have picked up a lot of new skills, it is tough to quantify progress on one's journey to become a better developer.

So here is my question for the DEV community, how do you measure progress in your career as a developer?

My initial stab at answering this question is looking at the projects I lead at work. Early on, I mostly contributed small pieces to larger projects. In the past year the number and scope of things that I oversee has grown quite a bit.

Another approach is looking at skills. I have learned quite a bit about leveraging Redis and Mysql in the past year. Should I measure progress by looking at growing list of skills I could put on my resume?

Even in combination, these still don't seem to fully capture the idea of career progress to me. What do you think? How do you measure career growth?


Editor guide
jerielng profile image
Jeriel Ng

Couple of things I reflect on:

  • How’s my velocity compared to six months ago?
  • How many bugs am I producing as compared to before?
  • Am I challenging myself to learn how to implement new things every day or am I just implementing things I already know?

At the end of the day, it’s not a matter of how many functions/things you know how to implement in a given language or framework, but rather how much experience you’ve gained in seeing different problems and learning how to troubleshoot and solve them. Over time, the more types of these problems you learn to solve, the more you’ll come to realize they’re all so similar that you can draw from previous experiences to gain insight into solving a completely new problem you’ve never encountered before.

In addition, it’s really important to have 1-1 sessions with either your manager, a more senior developer, or both. If your team doesn’t have a structure for this, I recommend proposing it. This way, you can get feedback on your performance and growth.