The career path of a developer is a tricky one. On the one hand, you have pressure to advance into positions with more responsibility and authority. On the other hand, there is continuous pressure to maintain a technical edge.
This can be a difficult road to navigate: many developers fear that a move into management will weaken their developer skills, while others fear that staying too close to the code will limit their careers. Both are correct. The way to stay on top of the game will be different for every person, but I offer here a few lessons I’ve learned as I’ve tried to balance this in my own life.
Insist on code reviews.
Code reviews are part of establishing proper code architecture, keeping technical debt low, and shipping quality software. Like all quality activities, some stakeholders are quick to let code reviews slack when time or budgets become constrained. Other than quality, development team leads have another, more personal, reason for insisting on proper code reviews: it keeps your brain in the code, thinking like a developer, and using your expertise to help make others sharper, as well.
Follow the commits.
As your own time for work becomes constrained by team leadership tasks (mostly meetings), it’s easy to stop paying attention to the finite details of what’s going on in your code base. Similar to code reviews, watching the source control commit stream to see where and how changes are being made can be a helpful way to stay connected to the details of your project without having to read every line of code. Train your team on proper commit messages. Follow the messages and the list of files that have been changed. When something looks curious, dig in and find out what’s happening before the formal review happens.
Schedule small tasks for yourself.
There are plenty of tasks on any project. The small and uninteresting ones usually aren’t thought to be the best use of a team lead’s time as conventional wisdom dictates that a highly experienced developer should focus on difficult or high level problems like system architecture. However, small tasks present an easy way to stay connected to a codebase without having to commit to large development time periods or block other developers. By scheduling yourself for the small tasks, you’ll at least keep some part of your coding brain exercised and your developer skills sharp. It might not be the most fun or interesting problems to solve, but it might be the best way to make an impact without using too much of your time. And speaking of time….
Guard your time.
Development team leads are often put in the position of needing to “buffer” their team from outside meetings. Stakeholders want to discuss some element of the project, or more likely its deadline. Other disciplines (design, project management) want to coordinate their activities with development. There are an endless number of people trying to eat your time, and the meetings will continue expanding for as long as you let them. Don’t let them. Block an entire day off on your calendar each week and refuse to accept meetings on that day for anything that isn’t 100 percent mission critical. Reject meetings that don’t have a well-defined objective and agenda. This may be difficult to do at first in a business culture that instills a fear of conflict and under-communication. But after a few weeks of holding the line you’ll find that many of your coworkers and stakeholders will respect you more for this ability.
At the end of the day there’s no simple solution for keeping your developer skills strong while also growing as a team leader. If it were easy, everyone would do it. Exceptional developers learn to find their own way to balance these competing tensions. It will be difficult, but it will be worth it.