Article summary
Computer Scientists often use the phrase “premature optimization” to describe effort wasted on making code better or faster when it hasn’t been demonstrated to be a bottleneck in the software’s run time or the development team’s process. Implementing a super-fast-access data structure for a list of just ten things would qualify, as would spending eight hours reducing the runtime of a monthly script from thirty seconds to ten.
Premature optimization is a bad idea both because we’re distracting ourselves from more important tasks and also because the problem we’re trying to fix might change — or may not even exist — in the future. We try hard to not do this with code, but I’m afraid we often inadvertently do it with people.
Turn Up that Fire Hose!
I frequently see well-meaning senior developers suggesting that new hires rebind their text editor’s shortcuts, switch to Vim, get a window manager, get a clipboard manager, try zshell, and learn C-x M-c M-butterfly in their first week working together, all the while suggesting they “read the docs” for every language, framework, and tool on the project.
Eager and enthusiastic young developers frantically scribble notes on these things (as well as command-line incantations, IDE workflows, and other inane tasks) while still making mistakes like writing imperatively in a declarative codebase.
The reason that we often recommend these small process tweaks is because they’re very easy to spot. Every developer knows the agony of watching a beginner fumble around their favorite development tool for the first time. There are a million things they need to learn before you can watch them work without wincing. So how can we decide what to teach in that moment?
To keep myself from trying to optimize a junior developer’s workflow, I take inspiration from the three questions you should ask yourself before you speak.
1. Does it need to be optimized?
There’s a natural inclination, when watching another person use tools we’re intimately familiar with, to share all of our own hard-earned tips and tricks.
- On a good day, this kind of knowledge sharing might come out as: “Can I show you a neat trick?” – Fine, but possibly distracting from the task at hand.
- On an okay day, it might come out as: “Why are you doing it that way?” – Can put your pair on the defensive.
- On a bad day, it will come out as: “You’re doing that wrong.” – Oof. Relationship damage territory.
Before giving this kind of feedback, sit back and watch to see if the inefficiencies you’re seeing in your pair’s workflow are actually reducing their effectiveness, or if they just feel a little clumsy to you.
As their mentor, it’s your job to help them spot high-value places where they can focus their self-improvement efforts. Look for these areas of improvement in the same way you would evaluate code for quality and efficiency. Start by getting [the code/the developer] working, then search for ways to improve [runtime/effectiveness] on especially [hot loops/critical skills], and save improving the little-used corners of the [codebase/skillset] for a rainy day.
2. Does it need to be optimized by your pair?
One of the big benefits of pair programming is the ability of pairs to fill in one another’s skill gaps. If you’re able to do some of the lifting by crushing through grunt code or backing them up on syntax details in the moment, you can give your junior pair space to focus on learning the conceptual paradigms of the stack.
To do this without robbing your pair of learning opportunities, provide them with some guidance on where to focus their energies instead. Clear directives will tighten up the first-few-months firehose and help newbies maintain a sustainable learning pace. Having someone else explicitly say, “Focus on X, and don’t worry about Y right now,” protects against the urge to spend one’s evenings frantically combing documentation, or worse, feeling guilty about not having the energy to comb documentation after burning hot by learning new things all day.
3. Does it need to be optimized by your pair right now?
Good code can be written in an IDE, on an OS you don’t like, and even without great command-line skills. Good code can be written slowly. While using a mouse. In Notepad.
Good code can not be written without a strong foundation in the important concepts of the language and framework. There is a limit to the number of skills that one can learn simultaneously, so it’s important to tackle the highest-value skills first. There will be time enough for speed drills later.
The Thinking/Writing Inflection Point
No matter how many typing games someone played in grade school, there’s going to be a period in everyone’s career where they think (i.e., have idiomatic, efficient code assemble itself in their mind’s eye) slower than they type.
When physically writing code is not the bottleneck, efficiency gains from ultra-high-speed text editing and slick workflow optimizations are going to be minimal. Instead, look for areas of understanding where your pair gets stuck, and help them learn to think faster before you remap their caps-lock key.
P.S. for Junior Developers
You don’t have to implement all of the process changes suggested by your more senior pair right away. It’s okay to say, “Thanks for the feedback, but I’m focusing on a different skill right now.” Get comfortable setting boundaries and owning your own learning process.