We used to see them all the time, before we knew the signs and started to avoid them. Engineers who had moved into management, turned architect, been CTOs and VPs for so long they didn’t know how to program any more. Long-time technical managers. Directors of engineering. And then, of course, at some point you look in the mirror and realize you’re writing blog posts on status reports.

I manage a couple of teams now, and I don’t get a lot of opportunities to code at work. Dress it up however you like, throwing together a report with a quick and dirty Python script isn’t really programming, even if it is fun. There comes a point at which every time you open an IDE you’re not doing your job – and fighting against it is only going to extend the awkward interregnum between when your role fundamentally changed, and when you started doing your new job.

Managing and Coding

There are typically two different career paths for engineers – the first is the alpha nerd role, in which you stay an individual contributor, become a technical lead, principal engineer, software architect, CTO. The second is the managerial route, in which you go more and more toward a completely administrative position, as exemplified by the VP of Engineering role. There are all sorts of hybrid roles, especially when you’re first moving into a management position – there are technical leads who have some managerial responsibilities, and managers who continue to code until their teams get to be too large. As I’ve mentioned elsewhere, managing and coding are almost diametrically opposed activities, and the larger the team, the more substantial the management responsibilities, the more difficult it is to balance:

Engineers need long periods of uninterrupted time; managers are interrupt-driven. Engineers write code, which is a pretty concrete accomplishment; managers attend meetings, write reports, assign tasks, and do many other things that can feel very insubstantial. Engineers can get away with being extremely introverted; a manager’s success is highly correlated with her ability to work with and organize other people.

At some point, it becomes impossible to reconcile the two, and you have to choose one or the other. This essay is about what happens when you go over to the dark side and no longer code actively at work.

Why Bother?

Does it even matter if you stay technical? If your role is so different, shouldn’t you be focusing on your new core competencies, instead of continuing to develop the old, obsolete ones? Given the title of this essay, I clearly think the answer to that is yes, it matters a great deal. There are a couple of reasons:

• Respect

It shouldn’t come as a surprise that coders respect those who have mastered the craft they love. If you don’t know the code base, can’t write a script, can’t grep the logs or write a SQL query, then you’re helpless. It’s even worse than if you didn’t have a technical background to start with. Conversely, if you’re in an entirely non-technical role and can program, you’ll immediately gain the respect of the engineers. It’s like they’re speakers of some obscure language, and suddenly discover that you took the time and effort to learn their bizarrely difficult mother tongue. Of course they’re going to be positively inclined toward you.

• Management responsibilities

Many of your day-to-day duties will require some level of technical skill. Grepping logs for errors, doing database queries, writing scripts to send out automated reports, doing technical interviews, performing code reviews, evaluating new technologies, mediating disputes about different technical approaches, managing risk – all of these will require your technical skills to be in working order.

• Looking ahead

Very few people in tech stay at the same job for their entire careers. Whether in one year or twenty, at some point you’re almost certainly going to be looking for a new job. Keeping your skills fresh, staying up to date on new technologies, and being able to demonstrate strong coding and problem solving skills will make you more desirable, even for pure management positions. As an example, manager candidates at TripAdvisor have to go through the same technical evaluation as individual contributors.

Staying Technical

You aren’t going to be able to maintain a reasonable level of ability if you aren’t constantly exercising your skills. And you aren’t going to be able to grow unless you’re constantly being challenged in new ways. This is true of any expertise – language, sports, musical instruments, whatever. Even if you’re in a partial coding role, you’re typically not going to be taking the most challenging projects, both because you should be giving your team the “cool” stuff, and because you have less time than they do. Here are some ways I’ve found for continuing to exercise my skills at work, though they’re of admittedly limited effectiveness:

• Interviews

Strange though it may sound, interviews (i.e., where you’re the interviewer) can be good opportunities for learning new things. Of course, you should never ask questions that you wouldn’t be able to answer yourself – however, you can construct a question around a new concept and give the interviewee enough info to remove unfamiliarity as an impediment. As an example, if you don’t remember how min-heaps work, you can give interviewees some introductory info, then have them implement basic operations. After a couple dozen interviews, you’ll know all the ways these functions can be written, and all the most common mistakes.

• Scripting

Automating reporting is almost always a win. And making it into an opportunity to learn a new scripting language is doubly so.

• Learning new command line utilities

As with scripting, you should always be picking up new command line tools and fitting them into your arsenal. You’ll have to have the discipline to use them instead of similar commands you already know. But, for instance, if you already know cut, try using sed. If you can do some basic sed tasks, start adding in awk. Learn to use find with xargs. Know sort and uniq. Work your way through the Bash Cookbook. There are a tremendous number of tools out there – commit to learning (and over-using) one new command line utility every week.

• Book groups

Choose a book on data structures, concurrency, a new programming language, big data processing, machine learning… Anything. Get your team to read the book, and stay one chapter ahead. As a more general rule, any time you want to learn something, getting everyone else on your team to also learn it is a good way to simultaneously develop them, and provide an incentive for yourself to keep up.

• Code reviews

There are many levels at which you can do a code review. The simplest is looking for coding standard violations and missing documentation. Next up is checking for whatever your language’s version of null pointer dereferencing looks like. Then come logic errors. And lastly come the big design issues. Ideally, the architectural issues have been handled up front, before you get to a formal code review. Likewise, your developers shouldn’t be wasting people’s time with coding standard violations. The middle two, then are the sweet spot, and also where you should be spending your time, really trying to understand what the code is doing.

To some extent, though, these are chump change. In order to maintain your skills, and certainly to develop new ones, you’re going to have to be doing significant programming, whether at work or on the side. Maybe this means developing a mobile app, or installing Hadoop and setting up some MapReduce jobs. You could set up a site in (properly patched) Rails, or Scala, or Erlang. You could get involved in Linux kernel development. You could compete in online coding competitions. There are an infinity of projects you could do, but the most important thing is that you do something.

You have a life outside of work. You have lots of demands on your time. If you have kids, you have a painfully detailed understanding of exactly how much “free time” exists each night between when they go to sleep and when you collapse into bed. Tradeoffs need to be made, and believe me, I know – there’s no easy way out. If you want to stay technical, you’re going to have to use some of this time to code. The key thing, as usual, is to set yourself up for success. Choose something you’re excited about (e.g., iOS/Android development), come up with some achievable, concrete short term goals, and go for it.

Good luck!