Software engineering career roadmap in 5 degrees of DRYness.

Are you a new freelancer with 10+ YOE trying to justify your rate over an offshore junior developer?

Perhaps you are are senior developer struggling to "sell your skills" in the context of a job interview?

Or maybe you are currently a junior looking to make the jump and you aren't sure whether you are ready for a senior role.

If you are reading this blog, you already know the importance of constantly improving your software development skills. You know years of experience correlates with salary but not ability, that plateauing as a developer and coasting in your current role is all too common.

Personally, I wish someone gave me a 'Software Development and You' handbook when I first started containing a roadmap of how I can improve as a programmer. Not just improvements in the next 1 or 2 years, but a decade into the future.

This is my stab at doing so with one narrow area of software development, the application of generally agreed-upon software development principles. I will list my stops on the roadmap and provide some action items for improving as a software developer and communicating its virtues with others.

The exemplary principle at hand is 'Don't repeat yourself!', often short-handed to just DRY, a software development principle which states you should reduce repetition of software whenever possible, generally through the use of an abstraction.

Here are the stages:

Level 1

This is also where I started, and likely also where most fresh college graduates or junior developers start, where you may know the existence of GASPs (Generally Accepted Software Principles), but you do not know what they are. So you write code that gets copied and pasted all over the codebase, leading to brittle, bug-prone software that's expensive to maintain and update.

Level 2

At some point, your pull request/merge request got a comment on how something you wrote should be 'kept DRY', or you read about 'The Pragmatic Programmer' in one of the programming watering-holes you frequent and decide to get a copy. You start to practice keeping your code DRY, as well as a lookout for opportunities to improve others' code quality by the DRY principle when doing code reviews.

Level 3

After practicing DRY for a few weeks to a few months, you are getting hang of learning when to apply the principle in practice, from the simple function extraction to developing higher levels of abstraction to be reused via modules, inheritance, and perhaps even creating DSLs instead of writing slightly modified function each time. By now you have also been bitten by premature abstractions a few times, maybe you've even read Sani Metz's great blog post on the cost of creating the wrong abstraction in order to 'stay DRY'.

Level 4

After being bitten by the early DRY bug a few too many times, you no longer follow the principle as closely as you did when you first learned of it. You have developed a pretty good gut feeling on the kind of code that is likely to change in the future, and when the two different use cases of the same piece of code in your codebase are likely to diverge in the future. Maybe you've even adopted the rule of three and use it with DRY selectively. In your code reviews, you regularly debate with your teammates on when it is appropriate to only selectively apply DRY.

Level 5

After many debates about the relative merits of the DRY principle, you've honed your gut sense into some general guidelines on when it should be applied in your current project. Perhaps some controller code should not be refactored before they've seen regular production traffic, or that certain modules change so often they should stay more or less 'experimental'. This is also when you move from discussions to creating rules of thumb that can be written down, documented, and shared with others in your group. You may even decide to write about the criteria you use to decide when to apply DRY on your blog or give a presentation about it at your local tech meetup.

'Don't repeat yourself' seems like a fairly simple principle at first glance, but like most principles, its correct application often requires considering tradeoffs and experience measured in hours spent debugging. Not all software developers will hit all 5 stages with DRY, just like not all software developers keep a blog or present at meetups and conferences.

Similarly, these are simply the 5 stages that I have seen so far in my software career, there could definitely be more / different stages that are outside of my lived experience.

Here's what I hope you will take away from this post:

For the junior software developers/college students reading this, I hope the stages can provide you with a rough idea of where the road ahead will take you.

For the more experienced developers reading this, I want to point out that moving from level 1 to 2 is a step-wise efficiency improvement, but moving from level 2 to 3 and from level 3 to 4 means you are improving your entire team via code reviews and discussions. Lastly, moving from level 4 to 5 is a multiplicative improvement based on the size of the software team, not to mention any codebase guidelines/style guides you create can generate value for the company even if your tenure has ended.

If you liked this article, you may also enjoy my tips on creating better front-end documentation or how to write code review comments that don't get pushed back.

Happy Coding!