There's No Should in Software!

or, Can’t Help Lovin’ that Tool of Mine

Imagine you are awesome at mazes and find yourself in a hedgerow maze with clues along the way that help you get out.

You’re moving along, piecing things together to get through the maze, when suddenly your foot gets caught under some root.  You have to stop thinking about the clues and extricate yourself.  You deal with the root, and now, you recall the clues you had before, reconstruct your strategy and move forward three steps, only to have some dude step out of a hedge and block your path.  Now, you need to stash away the clues in your memory and deal with this guy.  Okay, so you’re done with him, you get your head back in maze-solving mode, go around a couple turns, get your momentum going — and around a turn, part of the hedge is on fire.  Great.  Okay, stop maze-solving and figure out how to get around the fire safely. You can’t figure it out, so you call a friend; she tells you the undocumented way to get past the fire and you do; you then let your adrenaline level off and try to remember all the clues and get back into maze-solving mode.  Your foot gets caught in another root; how did you solve that root problem before?  Oh, yeah.  Okay, solved quickly.  Back to maze-management…

Four hours have passed and you’ve gone about 30 feet. 

I have always heard developers I’ve worked with express their passion about the tools they are and aren’t using, and training that they are or aren’t getting.  And as a two-decade-tenured leader in software engineering, I have received innumerable requests for tools and training.  I have been sympathetic to these issues, and have always tried to get my people the tools and training they say they need to get their job done.  I have not, I must admit, often actively sought out what they needed to make their jobs better or make them more effective.  And, when a developer has said, “I’m making Tool X work for me; don’t worry about it”, I have been satisfied to let the status quo remain intact.  That changed for me a while back.

Back in 2017, I had the opportunity to step into a straight-up IC role at a new company (part of the rite of passage for taking on the manager job for which I was hired).  Not having coded with any regularity for about nine years, I had a variety of rust to shake off and a lot to learn.  Today, I am writing about the unexpected lesson I learned from that experience — any disconnect between the engineer and the tools he/she has to do the job will create impedance that is orders of magnitude worse than I ever thought. Note: I did not say “can create”; I said “will create”.   

To start me off, I was given a non-trivial, but reasonable first project (thanks, Russel!).  It was in a familiar language, the code was very clear and self-documenting, and there was already an architectural pattern established. What would take me 2-1/2 weeks to accomplish this task was setting up my machine, learning tools my teams had been using for some time (but I had never personally used) and learning “how we do things here”.  I probably spent a cumulative total of three days on solving the actual business problem, and the other ten figuring out how to test, build, test, code review, test, merge, test, deploy, test, and — the context switching in between. 

The company had a very good tool chain for developers (most of it commercial, some of it home-grown) and several teams actively working to continually improve it.  The issue for me was that I hadn’t used *any* tools in forever.  Now, in my case, the issue was that I was (as stated above) inexperienced, period.  But, still – there was a disconnect.

The major time sink wasn’t even the differential in time it took to solve the problem vs execute the solution — it was that I repeatedly had to interrupt my execution on the business problem with tool difficulties.  I would repeatedly get into flow for a couple hours and then hit some tool knowledge barrier that had to be overcome.  It was slow-going.  And, it was frustrating — I really wanted to solve this business problem, but I couldn’t get to it because I had to repeatedly context switch between solution mode and tool-learning mode. 

Again, In my case, the situation was that the tools are great, but the engineer (me) was inexperienced with them (I am happy to say that my second task, which was larger in scope, took about half the time 😃 ). But it illuminated something for that, when extrapolated out, showed me a problem that even the most experienced developers face.

The same experience is encountered by seasoned developers who are saddled with inferior, or lack of, tools and training.  They spend their time working through problems they shouldn’t have to tackle, and doing things that, frankly, we don’t interview them for (think about it – have you ever asked a developer to talk about getting her code into production?  I haven’t).

When this disconnect occurs, we must solve it, and fast.  The cost of NOT doing so is HUGE.

There is a mythology that pervades our industry — we think we can’t afford to take the time or spend the money on training and tools because it takes away from productivity.  The reality is that we can’t afford not to invest in this way, and that a lack of such investment is actually sabotaging the very productivity we claim to be preserving. 

If you don’t believe me, think about context switching and flow.  We all agree that context switching is expensive, right?  Joel Spolsky offers this very helpful explanation as to why:

The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code.

Reggie, one of the most insightful engineers I’ve ever worked with, would talk about how developers need time to be in flow.  It’s not about the cumulative hours spent coding, he explained, it’s about the contiguous time the brain could be in the problem and solution.

So, we try to minimize interruptions — we set up constructs like meeting-free days, on-call rotations, and blocked-out “work” hours; we try to minimize the number of meetings for our engineers, and allow them to work from home when they need to focus.  All agreed?  Good.

But these are only the external interruptions.  We are missing the internal interruptions – tool doesn’t work right, I have to work around a tool deficiency, I have to look up how-to articles to get this language / package / technology to do what I need.  These internal interruptions are as counter-productive as the external ones, and they can lead to greater frustration because they happen silently and thus with no decent outlet for that frustration energy.  Tools that work well and don’t interrupt flow, and training on the technology in use such that engineers are proficient in them, drastically improve productivity and job satisfaction.

The maze is in front of our people, and they have the skills and desire to get through it.  After this experience, I became committed to preventing the distractions that keep them from solving it.  Are you?