“Oh Cool!” Moments
Increasing the frequency of the moments that drive software development
The Moment
How do you know if becoming a software engineer is the right career for you? Over the past 30 years of writing software, leading engineering teams and talking with people at all stages of their careers in the field, I’ve discovered an interesting indicator of job satisfaction for software engineers. Anyone who has written a fair amount of code will instantly recognize it though they may never have noticed it before. I call it the “Oh Cool!” moment.
The moment happens when you’ve been working on some idea, you run your latest bit of code — and it works! Maybe you’ve been working on a bug fix, trying to track down some undesirable behavior when the correct solution finally appears, you run your tests and they all pass. Oh Cool! These moments happen whenever something that didn’t work before, now works. You have pulled successful, functioning code out of your own mind — you have created something new and it is all working the way you’d anticipated. These moments are like a little endorphin rush and are surprisingly satisfying.
When I talk with students who are just starting out writing code and describe this, I frequently see them smile with familiarity with these moments. “If you get those feelings when you make something work, you’re in the right place.” I tell them. “If you don’t, you might want to look for another career.” Aggressive ship schedules, constantly changing frameworks and languages, legacy tools and codebases and highly competitive work environments can all make software engineering a very stressful career, but these Oh Cool! Moments can make it all worthwhile — if they happen frequently enough.
Mean Time To “Oh Cool!”
The frequency of these moments is crucial to individual and team happiness and job satisfaction. I use the phrase “Mean Time to Oh Cool” (MTTOC) to describe the relative frequency of experiencing these moments. The lower the MTTOC, the higher the satisfaction for the engineer and this directly correlates to more productive and effective teams because more frequent Oh Cool moments means more problems are being solved and more new code is working.
The challenge is that there are a lot of things that are working to drive up the MTTOC. Meetings are a big killer of engineering productivity not just because engineers are usually not coding during them, but the timing of a meeting (even a quick question from someone stopping by their desk) in the middle of their most productive coding time can break their concentration.
Slow or unreliable build systems or test suites are also big contributors to increasing MTTOC. When I was working at Microsoft in the early 2000’s, I was writing code on the Windows Shell team for the release that became Windows XP. This is the team that creates most of the default user experiences in Windows including the file organization windows, the task bar and a lot of the common controls like buttons and menus that all Windows applications use. Because that code is so central to the way that Windows works, changing it involved a lengthy process of building Windows (which could take anywhere from 10 minutes to 20 hours depending on how much you needed to build), copying the output of your build to a different test machine, rebooting that machine, hooking up low level debuggers and then, finally, stepping through the code I just wrote to see if it solved the problem. Even the smallest change could take more than an hour to go from writing it to seeing if it worked and, if it didn’t, the whole process started over again. Combine this onerous process with the rest of the daily interruptions and it could be days between Oh Cool moments. Not surprisingly, this period was one of the low points in my career for job satisfaction even though the features I was working on were hugely visible and impactful from an industry perspective.
In the years since, I have worked on many technologies including mobile apps and web services where the tools and processes enabled incredibly fast turnaround from writing the code to seeing the results of that code and the very low MTTOC made those exhilarating times. When the iOS App Store first opened to developers in 2008, I shipped an app that was connected to a web service to help golfers track their scores and share their rounds with friends. Being in full control of both the front-end and the back-end for those services, and building on tools that let me crank features out far faster than the app store approval process let me ship them, I would see several Oh Cool moments each hour I was coding and being able to get customer feedback on these changes led to new types of Oh Cool moments as they shared their experiences with the app.
Projects with significant tech debt, serious quality or reliability problems, poor or non-existent test coverage, office layouts that encourage distractions, bad team dynamics or poor processes can all lead to increased MTTOC as engineers spend significant time moving from interrupt to interrupt. In these cases, the Oh Cool moments can be drowned out by a constant incoming load of new problems and this can become one of the most destructive patterns for job satisfaction and productivity.
When the tools, process, product clarity and team dynamics all come together, though, the results can be extraordinary. The pace of delivery and innovation accelerate, job satisfaction is high, recruiting new talent to the team is easy and retention numbers are high even in the most competitive of environments.
Reducing MTTOC
Our job as engineering leaders, from the team lead level to the executive level, is to focus on decreasing MTTOC. Remove the barriers to low MTTOC. Look at the tools and processes you have in place and figure out if they are impacting the engineering team’s MTTOC and, if so, address those problems quickly. Fixing long or unreliable build processes may not seem to deliver customer value in the short term but resolving that problem quickly will pay for itself in a sprint or two and the efficiency and satisfaction improve as these problems slow down every engineer on the team.
Similarly, tuning your team processes to enable clear times and mechanisms for communication and collaboration while reserving and jealously guarding dedicated “heads down” coding time will make it easier for engineers who need to get into the zone to do their best work to focus on their code and hit more of those Oh Cool moments, more frequently. Agile processes can be very helpful here since a well-run scrum process reserves specific times for the sprint rituals and that makes it easier for the team to have a reliable schedule. Encouraging fast turnaround (or at least reliable response windows) for code reviews also helps keep the code flowing and unblock movement on to the next feature and the many Oh Cool moments that it may enable.
The “Oh Cool! Moment” is a powerful and positive source of energy for software developers. With proper focus on increasing the frequency of those moments, by reducing the Mean Time to Oh Cool, we can expect to see a significant improvement of team productivity and, far more importantly, in the satisfaction, engagement and happiness of the engineers themselves.
