Drive

I took a decision some time ago to try to change my role at work to be able to spend more time working actively with software again.

I don't mean only programming, but learning more about software and code quality, frameworks, patterns, languages, algorithms and data structures, operating systems, trends and so on. And yes, programming too.

I believe I used to be a good programmer before that point in time, but the way things had developed at the company I found myself in roles where I did a lot of coordination and management-like work for a couple of years, gradually losing engineering competence from not doing enough of the technical stuff.

You know, the fun stuff.

The thing is, if a tech company would be a racing team, I think of the software engineer as the race car driver. Even though the outcome of course depends on a large group of people in the team, all with different roles, it's arguably the driver that has the most exciting job. And it's the driver that brings the car over the finish line. Although I appreciate skilled people in any role, it's the talented driver that earns my highest respect. I want to be the driver.

Yet after driving some races usually your company will want you to move on to do other stuff, like watching races and giving feedback to the new younger racers. And write documents about driving processes. And help driver A communicate with driver B in another country. And so on. Perhaps the company might even outsource all the racing! What's up with that?

Getting older, people around you may look up to you as an awesome driver, a driver with tons of racing experience. Yet you may not have driven any race in years. The thing is, maintaining skills as a driver requires that you actually keep driving now and then. Otherwise, as time passes by, one day you'll have forgotten how to do it.

My plan was two-folded: try to change my work role so that I would do less administrative tasks and spend more time doing hands-on technical work, and also to set off time at home during evenings and weekends to learn new things, by reading articles and doing experimental software projects as a hobby.

And the winnings I imagined would also be two-folded: I would have more fun, and I would be better prepared for change because I would be technically stronger.

It's good to be prepared for change. Even if you don't have a plan to change jobs anytime soon, the fact is you don't have absolute control over the company you're working for - no-one does - and so you really don't know whether you might be forced to change. And if you need to change, be it for internal or external reasons, most likely you'll need to go to interviews. Are you prepared to go on an interview and explain in detail what you have been doing the last two years and which parts of product X you have contributed to, and how? Later being asked to write source code on a whiteboard to solve a technical problem, in case it is a software engineering position. I went to an interview and failed, realizing far too late that I had fallen behind technically. Not from not taking work seriously at my workplace, but because I had done exactly everything my company asked me to do, and not all of those things were strengthening my profile to prepare me for other roles in other companies. Actually several of the things I had been working hard on were rather counter-productive, distancing me from the profile I wanted to maintain. And I had failed to see that I needed to compensate for this by spending free time to actually stay up to date and skilled.

This was a late realization for me, that I needed to reflect more actively on where I was going and whether I was ok with the direction, and whether I felt I was learning enough. Not to mention whether I was having fun or not. Work is supposed to be fun. And learning should be fun.

Shortly thereafter, with my new approach, I felt joy again. Joy to learn new things. Joy to relearn things I had been studying or practicing long before. And most of all, joy to do what got me interested in computers in the first place: creating cool things with software.

I also changed the way I see "gaps" in my knowledge. Whereas before I would find a gap and be disappointed that there was something I didn't know, I decided to appreciate gaps as they are opportunities to learn something new and improve my skills. Moreover I started seeking out gaps, trying to track down things I felt I ought to know about but yet didn't. It's much better to find gaps on your own in a controlled environment than in a future job interview. And it's fun to feel how you are progressing and becoming better at something. I had almost forgotten that.

So, be prepared, and get behind the wheel and drive now and then. If not in the sense of doing hands-on software engineering, in case that's not your cup of tea, then in the sense of having control over where you are heading and your self development. And enjoy the ride!