Stay Close to the Code
July 18, 2022
Photo by Laura Chouette on Unsplash
Everyone wants to progress in their careers. To go from junior to senior; from associate to partner. Maybe you want to move into management.
It’s a noble pursuit, and for most of us, with enough work and skill, we will get there.
And as we do, there is a phenomenon that happens: we spend less time doing and more time deciding. As Ryan Holiday writes in his book Ego is the Enemy:
As you become successful in your field, your responsbilities may begin to change. Days become less about doing and more and more abouthing making decisions. Such is the nature of leadership.
As a senior engineer, I can attest that this is true for engineers as well. As we progress, we find ourselves reviewing documents, thinking about long-term strategy, and maybe even starting to look at those dreaded budgets.
And while this is good and important to our career development, we often stop paying attention to the very thing that helped us progress in the first place: the code. We aren’t “getting our hands dirty” as we once did. We become distant from our codebases, not understanding the nuances or gotchas of the code our teammates are working on most of the time.
I think this is a pattern to change. We have to stay close to the code as long as we can before our responsibilities truly dictate we move away from day-to-day coding entirely. Here are some of my reasons why and ways you can stay close.
Most Mentorship Involves Coding
As a senior engineer, part of your role is helping level up the other engineers on your team. We often call this mentorship.
And what are the ways you are most likely to help your team immediately improve? By helping them grow as a coder. Why? Well, quite simply, this is what consumes the majority of their time. They were hired to code.
Yes, you can help them learn to make better architectural decisions. Yes, you can help them improve their communication skills. But often, these are areas they can improve on with less direct mentorship. For instance, there are many great resources on how to grow as a writer, speaker, and even non-verbal communicator. But when you look at the resources for learning to code, they are often focused on who? The beginner. And for good reason: coding is hard!
Coding requires lots of mental energy. It requires a deep technical understanding of how systems work. It requires persistence to push through bugs that don’t make sense.
To offer the best mentorship and guidance on how to improve as a coder, you have to have a deep understanding of the code your team works with on a day-to-day basis. Otherwise, you might give poor guidance that leads to confusion or even frustration.
For many seniors, this frequently happens in the form of code reviews. And while that is important, we can do better. We can keep taking tickets or issues and writing new code every sprint, and we can pair-program alongside our team. We can ask questions to provoke deep thinking about how to achieve a new feature without incurring loads of technical debt.
But we can’t do any of that if we aren’t close to the code.
An Incorrect Understanding of the Code Lead to Bad Decisions
When you are far from the code, you might be leading your team off of a cliff. And you would have no idea.
There is a deep connection between our code and the rest of the technical decisions we make in our organizations. Every codebase contains a set of tradeoffs. Some features or needs will be easy to modify or change or maintain, and others will be more difficult. However, you can’t know which is which if you don’t work with the code.
Only reading the code isn’t much better either. We have to be part of writing it. For example, many people think they could play just about any sport better than a professional when watching on the sidelines. It isn’t until they suit up and play in a game that they realize how hard it is.
To avoid bad architectural or product decisions within our teams, we need to make sure we know what it is like on the field.
You Can Always Get Better at Coding
Pride can be tough to recognize, but I bet many of us coders have a bit of pride once we reach senior. We might think, “I can write any code I need to.” It might even be true.
But that truth only lasts as long as we are willing to keep our skills up. And the best way to keep those skills up is by aiming to get better. We have to work towards improvement; if you aren’t growing, you are dying.
No matter how good you are at coding, you can always get better. The best athletes in the world are still training to get better every day. The best writers are still writing constantly to make their next book better than their last. We need to do the same as coders.
Until you move into management, keep coding as often as your role allows. If you find the day-to-day code your team maintains to be somewhat simple, tools like LeetCode or Hackerrank offer problems to keep your skills sharp continually. I’ve recently started trying one problem every other week, and it has helped me get back in touch with algorithmic thinking, writing understandable code, and how to break down problems.
Ways to Stay Close
Depending on your team size and your role, your ability to code day-to-day might not be possible. I know of several senior engineers who spent most of their time reviewing architecture docs than writing - or even reviewing - code. How do you stay close to your team’s code in this position?
First, consider if you need to discuss with your manager the need to spend more time in the codebase. It might be your manager doesn’t realize how detached you might feel from the codebase and will work with you to find a way to write more code.
Another great way to stay close to the code is to participate in pair programming. Pair programming is often the next step beyond asynchronous code reviews (which are still helpful, by the way!). Work with your fellow engineers to understand the tradeoffs, the tricky spots in the code, and what can be improved. You’ll also learn how you can help your other engineers most effectively in real-time.
Lastly, find unstructured time to mess with the code. I’ve learned so much from code design and patterns by simply trying to move a function from one package to another just for fun. Having unstructured time gives you the space to think creatively about better designs and identify gaps that need to be addressed. Just like play is critical to child development, “playing around” in the code is critical to developer development.
All this to say: find ways to stay close to the code. You’ll be a better mentor, a better engineer, and make better technical decisions.
This might change if you move into being a manager or potentially even a staff level engineer. Those roles have different responsibilities and a wider breadth than that of a senior engineer dedicated to one team.
But until then…
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.