The future of software engineering is SRE | Swizec Tellerswizec.comScaling Fast BookWhat happens when your startup hits hypergrowth?Learn moreSenior Mindset BookGet promoted, earn a bigger salary, work for top companiesLearn moreThe future of software engineering is SREWhen code gets cheap operational excellence wins. Anyone can build a greenfield demo, but it takes engineering to run a service.
You may be wondering: With all the hype about agentic coding, will we even need software engineers anymore? Yes! We'll need more.
SRE about to become the most hired job in engineeringEverybody wants to write a greenfield demo. Nobody wants to run a service. https://t.co/THl9rBJ9rk— Swizec Teller (@Swizec) January 13, 2026
Writing code was always the easy part of this job. The hard part was keeping your code running for the long time. Software engineering is programming over time. It's about how systems change.
Lessons from the no-code and spreadsheets era
Let's take no-code and spreadsheets as an example of the kind of software people say is the future – custom-built, throwaway, built by non-experts to solve specific problems.
Joe Schmoe from accounting takes 10 hours to do a thing. He's does this every week and it feels repetitive, mechanical, and boring. Joe could do the work in his sleep.
But he can't get engineering resources to build a tool. The engineers are busy building the product. No worries, Joe is a smart dude. With a little Googling, a few no-code tools, and good old spreadsheet macros he builds a tool.
Amazing.
Joe's tool is a little janky but his 10 hour weekly task now takes 1 hour! 🎉 Sure, he finds a new edge case every every week and there's constant tinkering, but he's having a lot more fun.

Time passes, the business changes, accounting rules are in constant flux, and let's never talk about timezones or daylight savings ever again. Joe is sick of this bullshit.
All he wanted was to make his job easier and now he's shackled to this stupid system. He can't go on vacation, he can't train anyone else to run this thing successfully, and it never fucking works right.
Joe can't remember the last time running his code didn't fill him with dread. He spends hours carefully making sure it all worked.
The computer disease
Feynman called this the computer disease.
Feynman called this The Computer Disease pic.twitter.com/Zv4Bu4ftv1— Swizec Teller (@Swizec) December 26, 2025
The problem with computers is that you tinker. Automating things is fun! You might forget you don't need to 😆
The part that's not fun is running things. Providing a service. Reliably, at scale, for years on end. A service that people will hire to do their jobs.
Why operational excellence is the future
People don't buy software, they hire a service.
You don't care how iCloud works, you just want your photos to magically show up across devices every time. You don't care about Word or Notion or gDocs, you just want to write what's on your mind, share it with others, and see their changes. And you definitely don't care how a payments network point of sale terminal and your bank talk to each other, you just want your $7 matcha latte to get you through the week.
Good software is invisible.
And that takes work. A lot of work. Because the first 90% to get a working demo is easy. It's the other 190% that matters.

What's your uptime?
Defect rate?
How quickly do you recover from defects?
Do I have to reach out or will you know before me?
Can you own upstream dependencies?
When a vendor misbehaves, will you notice or wait until your users complain?
When users share ideas, how long does it take?
How do you keep engineers from breaking each other's systems?
Do you have systems to keep engineers moving without turning your app into a disjointed mess?
Can you build software bigger than fits in 1 person's brain?
When I'm in a 12 hour different timezone, your engineers are asleep, and there's a big issue ... will it be fixed before I give up?
Can you recover from failures, yours and upstream, or does important data get lost?
Are you keeping up with security updates?
Will you leak all my data?
Do I trust you?
Can I rely on you?
How can you be so sure?
Will you sign a legally binding guarantee that your software works when I need it? 😉

Those are the ~~fun~~ hard engineering challenges. Writing code is easy.
Cheers,
~SwizecPublished on January 24th, 2026 in Software Engineering, SRE, DevOps, Scaling Fast BookDid you enjoy this article?👎👍Scaling Fast book free preview

Enter your email to receive a sample chapter of Scaling Fast: Software Engineering Through the Hockeystick and learn how to navigate hypergrowth without burning out your team.Your NameYour EmailYour AddressGet my free chapter 💌Join 16K+ engineers learning lessons from my "raw and honest from the heart" emails.Senior Mindset BookGet promoted, earn a bigger salary, work for top companiesLearn more
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉
ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand
with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️Created by Swizec with ❤️ArticlesInterviewsCollectionsBooksCoursesWorkshopsTestimonialsAbout

Swizec Teller’s analysis presents a critical shift in the future of software engineering, moving away from the immediate focus on building functional demos towards the sustained operational excellence required for reliable, scalable services. The core argument revolves around the increasing demand for services—like cloud storage or payment processing—rather than simply software applications.

Teller emphasizes that while the initial 90% of building a working demo is relatively straightforward, the remaining 190% – encompassing reliability, scalability, and continuous operation — represents the true engineering challenge. He frames this challenge as “The Computer Disease,” highlighting the tendency to tinker and automate, often without considering the long-term operational demands.

A key element of this shift is the focus on service-level agreements (SLAs) and operational questions that are frequently overlooked during the initial development phase. Concerns such as uptime, defect rates, recovery times, upstream dependency management, security, and data integrity become paramount when delivering a service that users come to rely on, particularly as operations scale to different timezones.

Teller’s argument underscores a fundamental change in the role of the software engineer. Moving beyond simply writing code, the future engineer must prioritize operational excellence, proactively anticipating and mitigating potential issues, and ensuring the service functions reliably, securely, and at scale.

The piece advocates for a proactive approach, urging consideration of long-term operational implications, rather than solely focusing on the initial “greenfield demo” phase. This reflects a recognition that the true value of software lies in its ability to consistently deliver value to users over extended periods.