Overcoming boredom in a Software Engineering career

At many times in my career, I’ve struggled with an overwhelming sense of boredom¹ that affects my day-to-day ability to do my job. How can this happen given what an infinitely deep subject computing is? I find it usually derives from the following causes:

Causes of Boredom

• The sense the work you’re doing isn’t societally relevant, that you’re merely a cog in a giant military/capitalist water-works
• The work you’re asked to do is tedious and unchallenging, merely a repetition of the same things you’ve done many times before
• The work you’re doing is challenging, but the challenge is beyond your skill level and you don’t have mentors who can point you in the right direction

Potential solutions

Of the above causes, I think the least tractable is the moral/ethical one, and has led me to the greatest dissatisfaction, including at times trying alternate career paths. Despite the amazing achievements of the past half-century, it’s hard to ignore the way they’re often shaped to less-than-positive societal outcomes. From social media addiction to the collapse of the music industry, the unintended consequences go hand-in-hand with the oft-praised ‘disruption’. Rather than attempting to ignore this impact, any sensitive engineer should be confronting these issues directly. At the dawn of the computing age, Norbert Wiener had this to say in Cybernetics²:

Those of us who have contributed to the new science of cybernetics thus stand in a moral position which is, to say the least, not very comfortable. We have contributed to the initiation of a new science which, as I have said, embraces technical developments with great possibilities for good and for evil. We can only hand it over into the world that exists about us, and this is the world of Belsen and Hiroshima. We do not even have the choice of suppressing these new technical developments. They belong to the age, and the most any of us can do by suppression is to put the development of the subject into the hands of the most irresponsible and most venal of our engineers. The best we can do is to see that a large public understands the trend and the bearing of the present work, and to confine our personal efforts to those fields, such as physiology and psychology, most remote from war and exploitation.

So there you have it– if you are working for the war machine, just quit!³. Most of us, though, occupy a moral gray area– our product provides some service which is useful but not exciting, and the fact that we’re decently paid but not solving the biggest problems of our age induces a kind of malaise. If you have the opportunity to go solve one of those problems, stop reading & just go do it! But if you’re considering a career change or change of environment out of disillusionment or boredom, are new in your career & haven’t grown to the skill level where you could solve those problems, try these instead:

Take ownership

If your company is flexible enough that you can take more ownership of your work-streams and still provide value where expected, take the opportunity. Being directly responsible for a whole product or feature will let you have more impact on the company & consequently society as a whole. You’ll have the authority to call out dark patterns and potential forms of abuse, as well as prioritize accessibility, all while keeping the bottom-line in mind.

Learn from the past

The essays curated in The New Media Reader by people like Ted Nelson, Douglas Engelbart, Alan Kay, Adele Goldberg, and others inspired me early in my career, and I recommend reading their works if you haven’t already. In NY, Jack Rusher introduced me to more artifacts of our unfinished future, such as Emacs & Lisp Machines, and he’s consistently a source of insight in this direction. I find mining this history valuable because it helps to become aware that every aspect of modern computing was a choice between trade-offs among factors which could be changing. The awareness of a time when no prior art to copy existed makes it easier to re-imagine from the ground up what our field is all about. Recent startups such as Notion and Roam Research are taking inspiration from pioneering work on Hypertext, re-imagined for modern platforms.

Imagine the future

“The best way to predict the future is to invent it” - Alan Kay

Kay and the other folks at Xerox Parc were constantly experimenting, building prototypes, and using the learnings from that prototype to build the next prototype. You could be doing that too! A small hobby project to experiment with a new UI techniques, data structure, or algorithm is just the thing. On many occasions I’ve found that something I was working on in my spare time has direct application, months later, to something on the critical path at work. Use these opportunities to sell your managers on carving out a little time to work on a developer tool that enhances everyones productivity or makes visible parts of the system that you would otherwise be imagining in your head. Follow the Future of Coding community to get inspired by how other developers are re-imagining how we work.

Connect with fellow engineers

As an introvert with frequent social anxiety, establishing a network of folks I can learn from and mentor has been challenging, but I’ve been helped by many wonderful people along the way. A few introductions can have an outsized impact on your success. Early in my career, I was overwhelmed by a set of performance problems we had to solve and the lack of tooling available to solve them. My manager introduced me to a colleague at the company who was working on similar problems in a different department, and the cross-team advocacy group that he was leading became instrumental to the success of my own team.

If you’re in a similar position, ask your peers and managers if they know of anyone who is working in a related problem space. Ask senior engineers if they would be willing to mentor you, or to at least give special attention to your pull requests. Offer to mentor junior engineers. Read biographies and interviews– people’s mental habits and shortcuts are not often visible in their code. Volunteer at a conference or meetup. Most people want to help, and engineers especially are usually flattered to find someone interested in their niche.

Read research papers

This David Nolen talk makes the point better than I can, but there is a lot of academic research that can be directly applied to solving real problems. Ask your company for a subscription to the ACM library– it’s a tiny expenditure. Or work your way thru the Papers We Love repository. If, like me, you didn’t get a computer science or mathematics degree, don’t be intimidated by the sometimes obscure notation in these papers. For one, you can get a general shape of the system even without digging into the notation, which is still valuable. For another, the notation is sometimes a creation of the author, as tho you were reading a programming language they invented just for the paper. A crash course on common notations can take you far.

Open up the black boxes

I recommend this especially if you’re writing your 400th React component or SQL query. It’s easy to get bored if you’re taking for granted the 10k layers underneath the layer you’re working on– but a programmer like you had to write them too! If you’re a UI dev, study the React Fiber architecture or the Inferno source. Write your own Redux middleware or read the Redux source (it’s tiny.) Fire up a profiler and find the hotspots in your most critical codepaths, or optimize your SQL from their query plans. All of these activities will force you to climb down the ladder of abstraction, which opens up a host of interesting patterns you wouldn’t normally be exposed to.

I hope you find some of these recommendations valuable. Please share yours with me!