Leveling Up

When you look at job ads for programmers invariably they mention “years of experience”. There’s a general assumption that someone with 7 years under their belt will write better code than someone with only 4 years. That they will be able to work faster, perform more difficult tasks, and produce higher quality work.

Experience obviously matters, no one is born an expert. We work in a sprawling and complicated field, it’s hard to imagine someone becoming a truly stellar and well-rounded developer without putting in the proverbial ten-thousand hours. But not all experience is equal, and it can happen quite easily that one reaches a stage after a number of years where they stop progressing. Once you are able to meet the demands of the job, to hack your way towards a solution for any given task, it’s easy to get a little too comfortable. This is the curse of the Advanced Beginner.

In this newsletter I want to give some suggestions for how to avoid stagnating in your development. How do make sure you continue to level up, once you feel your learning is starting to plateau?

Read, read, read

Probably the most effective strategy is to read other people’s code. Lots of it. But which code should you read? In my opinion the best code to read is the code you are calling. Using a library? See what it does. Using Clojure (or any other language)? See how it’s implemented.

This achieves two things, it shows you how other people have approached a problem. Popular libraries tend to be popular because they are well written and do a good job. They tend to be written by experienced people, who took the time to understand a hard problem so you don’t have to. Do you understand how they did it? Do you understand why?

This tends to be code that’s at least one level more advanced than what you would write yourself. It also makes you familiar with the next layer of the system. Having an understanding of how things work on the next one or two levels below your code helps to write good and efficient code at the level you are at.

This is why I consider “jump to definition” such an important editor feature, both to jump to code within the project you are working on, and to jump to library code. When calling a function you want to be able to get to its definition in an instant, scan it to get a sense of how it does its job, and what the shape of its arguments is, before jumping back.

Intermission

Now would be a good time to mention: my team and I are for hire! We are half a dozen developers with over half a century of experience between us. Our expertise is in developer tooling, BI and analytics, web standards, and data driven systems. We are available for training, consulting, coaching and mentoring, interim tech lead positions, product development, and team augmentation.

Slow down to Speed up

As programmers we are obsessed with speed and efficiency. We love to tweak our editors and set up terminal shortcuts so we can do things with three keystrokes instead of five. This however is superficial speed, since typing is rarely the bottleneck.

The most time consuming part of coding is observing the behavior of your code within a running system. It’s what happens in between each change you make. The best way to boost your productivity is to improve the speed and quality of your feedback cycles.

There are many ways to get feedback about what your code is really doing. You can use a REPL to evaluate isolated snippets, or rely on tests to validate a wide range of inputs in one go. You could be using browser devtools to inspect the DOM, or use breakpoints in a debugger. You could be scanning logfile output to observe a multi-stage process, or use data inspection tools like Portal to pore over application state. Or maybe you just run the program top to bottom until it crashes. Rinse, repeat.

These are all ways to gather feedback. You’ve written the code, you assume it does a certain thing, now you get to validate and challenge those assumptions. At this point it pays off to slow down, take a step back, and consider both the speed and quality of the feedback you are getting. How long does each iteration take, and is it providing you with quality insight?

Fast but low quality iterations lead to brute force programming. Try this… doesn’t work. How about this? Hmmm… still not. Try swapping the arguments? Maybe it should be a collection instead?

Your iterations may be fast, but how many do you need to debug an issue? Say you’re inserting some print statements, you put a few into the code where you think the issue arises. Hmmm, it’s a null, where is it coming from? Put in some more print statements, and repeat. Each iteration may be fast, but it’s still slow going.

This is why it pays to slow down early in a task or project, and figure out how to get better feedback. Sometimes that means better tools. Tools that let you interactively explore data are great, for instance. Sometimes that means improving the structure of the code itself, so it’s easier to run bits of it in isolation, or to simplify data setup. Work smarter, not (necessarily) faster.

The Lost Art of Reading the Docs

Finally, learn to take the time to read technical documentation. Brew a cup of your preferred hot beverage (I can recommend a sencha Japanese green tea), sit down with a reference document, RFC, or other in depth explainer, and then… read!

We’ve all learned to read, or else you wouldn’t be reading this. But reading dense technical writing is a separate skill. It will challenge your power of concentration. You need to stay attentive, keep your wits about you. Be aware when your mind starts wandering, and gently bring it back to the text. Question yourself as you go to make sure the material is seeping in.

In today’s high-paced media environment it can feel strange and uncomfortable to spend several hours with a single text. It might feel like you’re not being productive. How do you explain at standup that all you did yesterday afternoon was read? It might feel like it’s not part of the job, and as a freelancer or contractor you may find it hard to bill for those hours. “They’re not paying me to read.”

But of course employers and clients have to understand that it is part of the job. In a field so broad and large, that evolves so fast, study has to be a regular practice, rather than a fringe activity or afterthought. Envisioning quality solutions takes understanding as well as experience. The coding is just what’s left doing after everything else has become clear.