Go Wide, Then Go Deep

An engineer just starting their career recently asked me what advice I’d give someone in their position. I didn’t have to think long: expose yourself to as many different things as you can. Stay curious, ask a lot of questions, and aim to be a T-shaped engineer, with a broad understanding of many topics and deep skill in one.

Why breadth first

Early in a career it’s tempting to pick a lane and optimize for it. Learn the framework your team uses, get fast at it, and ride that for as long as it lasts. Then the framework falls out of favor, or the hard problem in front of you turns out to live two layers below the code you know.

The specific technology you learn first matters less than it feels like it does. A lot of what you’ll use in ten years doesn’t exist yet. What carries over is the habit of picking up something unfamiliar and getting productive in it, and you only build that habit by doing it on purpose, over and over.

What the T looks like

The horizontal bar of the T is breadth. You know enough about a lot of areas to read the code and recognize what kind of problem you’re looking at. A backend engineer with some browser knowledge can tell a slow API apart from a page stuck behind a render-blocking script. Someone who has written a little SQL looks at a slow endpoint and suspects an N+1 query before reaching for a cache.

The vertical bar is depth. One area where you know the failure modes and why things are the way they are. That’s where you become the person other people ask.

You need both. Breadth with no depth lets you talk about everything and fix nothing hard. Depth with no breadth means you can only see the part of the system you know, so you end up solving problems in the wrong place.

Breadth compounds

This blog is a decent record of me following my own advice. It has posts about extracting constants in Ruby, Clojure protocols, nil values in Datomic, mocking Mixpanel in CoffeeScript, Docker Compose networking, and how BETWEEN treats dates in PostgreSQL. There’s also one about growing an avocado tree. I took “different things” fairly literally.

The payoff shows up when ideas cross over. My post on the Null Object pattern in Groovy came from writing RSpec tests at night while also working on a Grails application for a client. RSpec’s null object doubles were the inspiration for a small Groovy helper that cut out a pile of test setup. I wouldn’t have reached for that idea if I’d only known one ecosystem.

Different tools teach different lessons. Datomic refuses to store nil; to empty a value, you retract the fact. Working through why makes you think harder about what “empty” means in any database. Clojure protocols are another take on the interfaces you already know from Java. Each one gives you another way of looking at a problem, and the next problem might need exactly that view.

How to go wide on purpose

Curiosity is a good start, but it helps to have a plan. A few ways to get exposure early:

• Pick up the tickets nobody else on the team wants: the build pipeline, the flaky test, the CSS bug, the slow query. Those tend to be the parts of the system nobody understands, which makes them good places to learn.
• Learn a language that works differently from the one you use at work. If you write Java all day, try a Lisp. If you write Ruby, try something with a strict type checker. Bring back whatever ideas fit.
• Read code outside your own service, and read other teams’ incident write-ups.
• Join an on-call rotation or sit in on the support queue for a week. You’ll see how the system fails and what users do with it.
• Write down what you learn. A short “today I learned” post forces you to understand the thing well enough to explain it.

And ask questions, including the ones that feel obvious. Most senior engineers don’t mind. The ones who do are telling you something useful about where you work.

Breadth shows you where to dig

The other reason to go wide is that you probably don’t know yet what you’ll love. You won’t find out you care about databases until you’ve chased a slow query down to a missing index. You won’t find out you like developer tooling until you’ve fixed a build that’s been broken for a week and watched the whole team speed up.

Pay attention to the work that keeps pulling you back, and go deep there. The vertical bar can move over a career. The horizontal bar is what lets you move it without starting over.

That was my answer. Try a lot of things, notice which ones you can’t stop thinking about, and dig there.