Cutting Paths

What high leverage work for senior engineers should look like.

For a few summers in my teens, I worked on a landscape construction crew run by a family friend. The work was honest, hard, and paid better than most summer jobs that one could find in the tourist town I grew up in. As the youngest crew member (usually by a decade or 2), I knew hardly any of the “tricks of the trade” that the professional crew regularly employed to get work done quicker and with less labor.

This knowledge gap impacted how productive I could be at work. If left to my own to complete a new (to me) task, it might take me 3 hours finish what a seasoned vet would have knocked out in 30 minutes. A 6x “rookie tax” might sound extreme, but really I think this is pretty conservative, especially when we superimpose this idea onto software engineering.

I found myself most productive when some “heavy hitter” from the crew would take a few minutes to do “setup work”, to get me up and running. If tasked with planting a row of 4 shrubs for example, perhaps the landscape architect could mark where each shrub should go, then maybe the excavator operator swings by and digs crude starter holes with his machine.

These are small, but high leverage tasks for the experienced folk. They unblock me on multiple fronts that are beyond my current skillset. Instead of fretting over placement, or digging holes by hand, I’m now focused on the things that I’m proficient at while pushing the task forward.

Hand finishing the holes to proper depth, cutting the burlap off the root balls, fertilizing, planting, cleaning up the top soil, laying down a bit of mulch. All right up my alley, and critical to getting the job done.

We should think of building software like this. Throwing a junior engineer at a new problem with no context is doomed to, in the best case, take longer and be more painful than it needed to. The job of a senior engineer is to find the setup work that frames the tasks of others properly. Stubbing out 3 pseudo functions in the right parts of the code, writing a script to run something locally, coming up with a mock json response for a new API endpoint.

This stuff is easy and doesn’t require much time investment, but it serves as a critical guide wire for someone less familiar with the task. And best of all, it’s not infantilizing. You’re offering a fuzzy glimpse at what the solution looks like, and most importantly, you’re letting them know the kind of things they need to learn to level up themselves. And if they are any good, they will.