We’ve all been there. Staring at a piece of legacy code that makes your eyes water. Or perhaps feeling stuck, like your skills aren’t growing as fast as the tech landscape is changing. Being a “good” developer is a great start, but the journey doesn’t end there. The real growth – and often the most rewarding challenges – lie in transformation of good to better. Are you ready to unlock that next level?
After spending many years as software developer I came up with this theory, of how to evolve from a good developer to a better developer. Due to my love for the programming I was always a good developer. It took me a long time to transform into a better developer. It took me a long time to understand what it means to become a better developer. I understood only when I landed up in a situation that demanded me to become better at what I was doing.
I believe the transformation from good to better is all about acquiring some specific traits & qualities and practicing them on a regular basis. There is a simple recipe that one can practice to develop the desired traits of a better programmer. It’s a self transformation journey.
Here we only have good developers and better developers but, there are no best developer. Designing and developing software is all about trade-offs. As no single solution can meet every needs, similarly there is nothing called best developer. It’s like how we are shying away from the term best practice and replacing with sensible defaults. These sensible developers are the better developers. These better developers need not be Dennis Ritchie or Bjarne Stroustrup or Richard Stallman, but they are our next door daily heroes. Every team must have few better developers, they catapult the team towards heroic successes.
My journey to become a better developer started when I suddenly became one of the most experienced developer surrounded by junior developers. My work changed from writing codes to more of reviewing codes, working with devs doing peer programming and pushing people to adopt best practices for a code base. Slowly my days turned out to be all about thinking how to improve the system and strategizing how to bring in those changes. I was no longer proud of developing complex features in the most concise way, but became proud of writing the most simplest, readable and maintainable code. In short this marked the start of my quest for clean code.
Continuous learning is a key to get better at this. Invest a lot of time in learning and trying out new things. My exploration in ML lead to applying regression model in forecasting usage patterns and building lasting systems. My readings on evolutionary architecture and large data centric applications, helped me develop new features and products over the years. Even learning other languages expand our mind, one we develop appreciation for a different programming language or paradigm and sometime bring techniques learnt elsewhere into your current system. I have personally developed high appreciation for functional programming when I learnt Scala.
My learning journey always comprises of learning, understanding through experiments, and finally by writing about it or giving a session on the same. Not only you help the team, but by writing blogs or giving talks (even internally), you start to create a personal brand for yourself.
This continuous learning also lead me to build multiple small developer tools and utilities to improve efficiency. They were mostly inspired from my readings and our attempts to simplify our daily life or crisis situations through automation. Some got used more than others.
By constantly peer programming, and reviewing others code I improved my debugging skills. I figured that being a good programmer I was bad at debugging. One who makes less mistakes often don’t know the errors compiler throws on faulty codes. Working with other developers helped me develop this skill.
Peer programming and helping devs write their codes helped me understand each dev team members strengths and weaknesses. Not only that I got a grasp of multiple areas of the code very fast, this made me the de facto owner of the system as I knew about all the changes and how they have been implemented. Peer programming helped us reduce bugs in general. I got a first hand experience of its benefits. It also improved developer’s skills faster than anyone not practicing peer programming.
As I was getting involved with every code change, we opted for peer reviews. The dev responsible for the code present their changes to me and to one more (if available). Code reviews became like a critical ceremony for every feature that we were developing. Sadly today, I see many team members raise a pull request (PR) and another dev do the review in silo. I strongly feel this is ineffective.
My early stints oscillated between developer job, production support and business analyst (BA). This helped me grow a sense of responsibility towards people in production support. What to log and what not to became an important point during my reviews. This is another trait I picked up over the years. Today in many of systems logging turns out to be a tech debt. Over the years applications accumulates a lot of unnecessary logs, and later cleaning up becomes a separate tasks. Specially with FinOps coming in this kind of tech debts are surfacing out more and more.
The journey from good developer to a better one is not a destination, but a continuous process of learning, refinement and contribution. By focusing on these key areas, you are block your potential and make great impact. What one step you will take today to become a better developer?