To follow up on a previous post and answer a question I get surprisingly often - how I manage to get so much done - I want to share a loose collection of ideas that I've found particularly helpful. Software engineering in 2026 comes with a uniquely demanding lifestyle, and learning to sustain that lifestyle long-term is part of succeeding in the field.
Time Efficiency
Software engineering is not something you can excel at with half measures. You get out of it what you put in. That doesn't mean you need to be at your computer for 10+ hours/day to get the best results; on the contrary, I'm convinced it is more a matter of mental discipline. The ten-minute drive to the grocery store? You can use it to plan your next move on a project. Waiting on the bus? Instead of looking at memes on your phone, write some notes on potential features you might implement later.
By virtue of being a fundamentally creative domain, software development benefits greatly from your willingness to dedicate additional thought to it. The trick is to create and maintain mental discipline such that, when you do sit down to write code, it flows from your fingertips. This is the key to overcoming executive burden as a developer - being able to answer "what do I do next?" without much thought. Understanding the shape of a solution is the hard part. Creative thought processes are energy-intensive and require sustained effort, but you need not be at your computer to engage in them.
Depending on how you define productivity, your most productive hours might not even be those spent in front of a keyboard. Sometimes the solution will come to you in the shower, sometimes it's when you're lying down to sleep at night. Occasionally, even a sleepless night produces something useful. Like other creative endeavors, the best results usually arrive when you manage to "channel" your ideas, and you often can't force this process.
On Cumulative Stress
This is something that software has in common with some medical specialties. In a lot of careers, you're able to just clock out at the end of the day and enjoy your free time outside of work. Emergency medicine at least has a relatively hard boundary when the shift ends. Internal medicine often doesn't: large caseloads, multimorbidity, and ownership of unresolved problems create cognitive residue that follows you home.
Software is a lot like this. Going back to what it means to be time efficient, clocking out mentally is easier said than done. There is an obvious danger here. The same habit that makes you extraordinarily productive can also make you extraordinarily bad at resting. Learning when to keep a problem loaded in your head and when to deliberately evict it is one of the harder skills in a long software career. I've found myself thinking about projects throughout an entire two-week vacation. I'll be enjoying an expensive dinner when an architectural idea too juicy to ignore hits me out of nowhere. By the time I get back to work, it can feel as if I never left. We hit this month's deadline, and then we're immediately sprinting to the next. Feature after feature, release after release. It never stops. This is what cumulative stress looks like.
Being stress tolerant is not enough. Though I've always fancied myself as stress tolerant, I've come to appreciate the difficulty in managing cumulative stress, as doing so requires significant effort. Burnout doesn't occur overnight; it's a slow boil, and when it reaches a breaking point, simply going to the gym or having a night out with friends is too little too late. I firmly believe that my experience managing cumulative stress in my career is why I've had little difficulty managing the stress of medical school compared to my peers. Eight hours a day of lectures and labs with weekly quizzes and monthly block exams, pace-wise, isn't much different from a demanding, full-time software job.
The key takeaway is that stress management is not something you can do passively in a software career. Viewing stress as part of life's background noise can lead you straight to burnout. Managing cumulative stress requires proactive daily efforts. If you let your routines slip for a couple days, you're going to feel it for a week (or longer!)
On Burnout
I've often joked my secret is that I burnt out years ago and I manage to keep going through sheer discipline and force of will. While discipline is undoubtedly part of the equation, forcing yourself to work through burnout can carry potentially life-altering consequences. Indeed, there have been times when I've done as much. Sometimes circumstances leave you little choice in the short term. However, I often come out the other end ready to do something other than write code for the foreseeable future. This really isn't a viable, long-term strategy.
When a project is starting to cause you stress, it's a hint that something could be wrong. If it's a personal project, it may mean that you're misdirecting your creative energy. If it's a project for your employer, you need to question if you're actually solving the problem in a principled way. Sometimes you really do need to just knuckle down and do the work, but it should feel good after it's done.
So what practical advice is there when you're at the point of burnout? Firstly, treat burnout as evidence that something in your system failed. Maybe you ignored warning signs, maybe your workload was unsustainable, or maybe circumstances simply overwhelmed the safeguards you had. Either way, getting better without understanding what broke is an invitation to repeat it. You need time to spend doing nothing of consequence - e.g. vegging out and watching movies - while you reflect and rebuild your behaviors to avoid a depressive slump. The objective is always to understand what put you there well enough that you don't rebuild the same machine.
On Psychoactive Substances
My advice is to avoid recreational drugs and use alcohol rarely, if at all. Consistency matters enormously when your work depends on sustained attention, motivation, and creative energy. I've never found chemically borrowing from one state of mind to be worth what it costs afterward. As enjoyable as it may be to drink beers while plotting your next move on a project, later you might be wondering why you lack the energy and motivation to keep up the pace. The key is consistency, and that notably doesn't involve constantly poking and prodding at your chemistry.
Software engineering has certain lifestyle associations that distinguish it from other engineering disciplines. Notable among them are musicianship and substance use. What do software, musicianship, and substance use all have in common? They all appeal to the aesthetic and experiential tastes of creative types. Both software and music entail molding layer-upon-layer of creative abstraction into an elegant and harmonious gestalt. For some of the same reasons substance use has long been associated with creative subcultures, software development can attract similar patterns. The idea that states of consciousness conducive to divergent thinking can be reliably conjured via substances is naturally attractive to both musicians and software engineers alike. Additionally, the "cumulative stress" component of software encourages the use of substances to manage stress, mood, and sleep.
It is imperative to avoid this pitfall.
In my experience, and for reasons that seem obvious enough, professional engineers are more tight-lipped about addiction than professional musicians. In private discussion, the parallels in character arc are often remarkable: whatever short-term creative benefit drug use seems to offer is easily outweighed by the obstacles it can create. The idea that you need substances to sustain your creative process - or that you even benefit from them at all - is a demonic lie. Failure to heed this warning is a remarkably common way to derail your career.
Learn from the mistakes of others. You can understand this perfectly well on an intellectual level, but translating it into real-world behavior is a perfect example of wisdom.
On Future Shock
The acceleration brought by AI has instilled a powerful sense of FOMO among developers. Software engineering in 2026 is moving crazy fast. Have a cool idea for a product? There are already three other VC-backed companies that meaningfully overlap with your offering. You'd better make it to market before they do!
I suspect nearly all of us are experiencing future shock to some extent. If I had a nickel for every time my fiancée patiently waited for me to dispatch one last prompt before we eat, I'd have, well, many nickels. We recently watched the entire X-Files TV series, during which I was babysitting an agent more often than not. I'm blessed that she understands my work and supports it, but it often occurs to me how much I'd be sacrificing if my attention were similarly diverted with children in the picture.
Timelines are collapsing. Technology's pace cares not for the life unfolding in front of you. Your competitors would love nothing more than for you to choose family and friends over your project. The cruel part is that choosing the project will likely be the decision you regret. You can understand all of this and none of it becomes easier.
Nobody knows what the future holds. Perhaps the AI bubble pops and the technology becomes impossibly expensive. In any case, you'll be glad you prioritized the people in your life over whatever silly project is vying for your attention. It's not a binary choice; we negotiate it over and over. The danger is that you will always have a compelling reason to make the sacrifice this one time. Eventually, those one-time sacrifices become your life.
-Tom