Mentoring junior programmers: What I tell them is job number one

I’ve mentored, coached, managed, and reviewed many software developers throughout the years. There are many different areas one can discuss, but my most importance advice for engineers early in their career has never changed.

Your first years are critical

The first few years in any developer’s career are critical. Perhaps the first ten, but definitely the first five.

Why is this?

Because these are the years during which you build the fundamental technical expertise you rely on for the rest of your career. And — most importantly — it’s when you have the most time to do so.

During this time nobody more senior is really expecting anything else from you. You just need to show you can learn, and build expertise as fast and effectively as possible. You’re not expected to lead teams, go into management, or deal with product questions. Of course if you can do all that too, great, but don’t lose sight of the what you must do from year zero to year five.

You must gain as much technical knowledge as you can.

Knowing this can bring great clarity to your career during those early years. Because if you wonder “what should I be doing?” the answer is clear. You should be learning about computers and software, as deeply as possible.

Setting up a virtuous circle

During the early years, you must set up a virtuous circle. You must gain deep technical knowledge, apply it, which then shows you’re a capable programmer. As a result you get the opportunity to do more good work, learning even more technically as a result, which shows you to be even more capable than before.

Breaking a vicious cycle

The flip side of this cycle is obvious. You don’t get exposed to interesting and challenging work, don’t get a chance to learn deeply, and don’t build a record of success. So how to break a bad cycle?

Through your own agency. If you’re in bad cycle it’s up to you to break it.

Set up pattern of learning

Take note of anything new you come across, anything you don’t understand. Spend five minutes reading about it. Don’t really know what TCP is? Spend a few minutes reading about it. Write a small TCP server.

Gaining even a small amount of practical experience with something new to is a huge improvement over no knowledge at all.

Look for the learning opportunity in every role

Once I was asked to write a performance-measurement system for a set of MPEG encoders. It was going to be written in C, for Microsoft Windows — an operating system I didn’t want to learn anything about. It made me cringe at the time. But then I made a conscious decision to treat it as a learning opportunity.

It was exactly the right attitude. I ended up learning about PSNR, MPEG encoding, and system calls on the Windows platform. And when I applied for my next job — at TiVo — it was exactly my MPEG analysis work that stood out! And at TiVo was where I got my first Technical Lead role. The virtuous cycle had kicked in — all thanks to attitude.

Work in the area you want to learn

If you’re interested in a particular area of software, start working in it. I don’t mean get a new job in that area — without experience it may be difficult to get that job — I mean start writing your own software in your own time.

Very early in my career I wanted to learn about Linux device drivers — really learn about them. But I was only doing very low-level embedded software. So I wrote a device driver for the MPEG encoder I was working on, and didn’t stop until it was fully functional.

It’s very important to choose your project wisely however — and dedicate yourself to it. If I had just worked through some Linux device driver examples on the web, and then added Linux Device Drivers to my resume, it wouldn’t have been real — and any experienced Linux programmer would have spotted it in a minute. Instead I was able to say I wrote a Linux device driver for this hardware module and it does this. This is much more impressive — and shows real learning.

Learn about widely-used technology that most folks don’t really understand

Another area to study — to work on — if you want to stand out is your source control system. Most developers rarely develop more than a surface understanding of their source control system, but doing so can be quite powerful. Teams often encounter issues with their source control system (particularly self-hosted systems) and don’t know how to resolve them. Showing expertise in industry tooling makes you stand out.

There are many other examples of widely deployed technologies in our industry that most people have only a shallow understanding of — compilers are another example. It’s early in your career when you have the best chance to develop those understandings.

You have one job

Early in your software career your goal is clear. Learn as much technically as you can, and all else will flow from that.


3 thoughts on “Mentoring junior programmers: What I tell them is job number one”

  1. Very minor nit-pick for the author:

    It’s a ‘Vicious Cycle’ – ‘vicious’ meaning bad, nasty.

    ‘Viscous’ means ‘thick’ or ‘slow-moving’, as in ‘a viscous liquid like honey’

Leave a Reply

Your email address will not be published. Required fields are marked *