I don't really code anymore.

Once you start being responsible for more and more people and for ensuring that multiple streams of work are being delivered, direct programming contributions tend to fall by the wayside pretty quickly.

Moving from solving immediate problems with the power of code to solving problems indirectly through the power of people is challenging. Its far more nebulous than direct contribution and it becomes harder to conclusively tell if you're making a difference.

So sometimes I miss coding. I miss the clarity of having a problem and then crafting something that clearly solves that problem. I miss the rush of satisfaction that I get when a piece of code finally works. When all the pieces click into place and the thing happens.

That seems like a relatively safe high to chase, right?

That Unpleasant Feeling

Minimizing the pleasure seeking aspect of my brain for a moment (as loud as it might be) there are more benefits to maintaining development skills than just feeling good when you make the computer do a thing.

When you are responsible for the well being and professional growth of engineers and need to ensure that the work that they are delivering is valuable, its beneficial to have a solid understanding of the technical details. You're never going to be as good as someone who literally builds things on a day to day basis, but that's okay.

Direct contribution skills atrophy quickly. Much quicker than you think they do. Indirect contribution skills (like technical concepts and good engineering patterns and practices) atrophy much more slowly, which is nice, because it means you don't have to be constantly coding in order to be able to contribute to the technical success of the team.

Still, there is something to be said for being able to look at, understand and possibly suggest changes to (or make changes to) a piece of code. It helps keep you connected to the people you're responsible for, because you can understand what they go through to get things delivered.

Bringing it back to my own experiences, the hard truth is that the only reason I'm not programming every single day is that I haven't made time for it. I could easily go and create a project of my own or contribute to open source or any other number of things that involve direct contribution.

But that requires time and time is scarce. I like to use the free time outside of my daily responsibilities to either learn how to be better at those daily things or to relax. You know, to avoid exhaustion.

If only there was a way I could flex that programming muscle without having to invest a ton of time...

Getting It Moving

The good news is that there are a bunch of ways to flex, which shouldn't be surprising, because this is the internet after all.

For example, I've started using HackerRank as a sort of code kata. If you're unfamiliar with the concept of kata, its where you practice patterns repeatedly until you've internalized them to such a degree that you don't even have to think about it anymore.

Overall, HackerRank seems pretty good, featuring an embedded development environment with support for multiple languages and a wide variety of pre-configured programming challenges, ranging from the basics through to exhaustive interview preparation kits.

In the last few weeks, I've completed 30 Days of Code (which was pretty straightforward but had some challenging bits in it) and Basic Problem Solving (which was surprisingly difficult). I found that I could easily dedicate half an hour at a time to get something done when working on the 30 Days of Code problems, but had to dedicate an uninterrupted block of an hour in order to do the Basic Problem Solving stuff.

I plan to continue this pattern, weaving some coding into the beautiful tapestry that is my professional development backlog, to keep myself at least a little bit on the tools.

Even if its a poor facsimile of actual development.

The Aftermath

To expand on that last point, doing small isolated coding problems in a sandboxed environment is not really software development.

Don't get me wrong, its great to just write a bit of code to do a thing, but its a very different experience compared to developing a piece of software that needs to do something.

For one, its tiny. Even a small application that has to do things for real has much more going on than the largest of coding problems. Said application probably has multiple layers for interacting with different things (data stores, logging, maybe a user interface). Its just...more stuff, all of which has to work together in order to produce the desired outcome.

The second thing is that the delivery process is trivially simple. Write some code, push a button, someone else's tests get run and you get ticks or crosses as appropriate. Real software development involves figuring out how you're going to get your awesome application to your users on a regular basis and how you're going to ensure that it continues to work as expected while said users ruin it in ways you never anticipated.

The last thing, which is probably the most important, is that you don't need to pay the price of bad design decisions. Or even mediocre design decisions. You cut a piece of code for a problem and if it works, you walk away. In real software development, building on top of an existing body of work is probably the thing you do the most.

Conclusion

Still, despite that entire section whining about how doing programming problems is not "real software development", I'm still finding it valuable.

I like being able to sit down for an hour or two and focus on actually accomplishing something with code. I like that I don't have to think about all the other stuff. I like getting that little burst of satisfaction and then being able to walk away.

It doesn't make me a software engineer though. Not anymore.