Most software engineers are facing an identity crisis bordering on depression.
As CTOs aggressively evangelize tokenmaxxing, a class divide ensues.
The lazy. The lazy push code. They don't write it. They don't manually test it. They don't even read it. They're on autopilot. See Jira ticket, prompt for task, submit code. Many of them are barely on their computer the whole day. A comment on the PR asking why they did this? The lazy ask AI. A Slack message? The lazy ask AI. Need to prepare for standup? The lazy ask AI. As long as it sounds enough like them and isn't detected. Some of the lazy are even overemployed, and work multiple jobs. The lazy smart ones get away with this, and even rewarded. After all, software engineering for the lazy is just a dance to convince your colleagues you're smart and hard working.
The craftsmen. The craftsmen are tired. Very tired. 15 PRs in queue. Slack blowing up. The entire burden of review falls on the craftsman. The burden of understanding. They try. They work their way through the code, thoughtfully commenting to improve what ships. The response? A lazy: "That's a clever idea! You're absolutely right." with an incorrect change. It's fine, the craftsman says. I can fix them. They write a doc urging his colleagues to be better. The next day? 20,000 line PR to review. Day after day, their workload grows. Bugs seep into production. No one seems to care. Another round of AI is thrown at it. Their animosity to their colleagues rises. Eventually, they give up. It's just not what it used to be. The craft they loved is dead. They eventually wake up, a lazy.
This isn't all companies. Many companies are genuinely more productive, adopt the right set of principles and practices around AI development and have highly talented teams that trust each other. It tends to happen in bigger companies that are 10+yrs old with a higher talent variance. But it happens. A lot.
Several years ago I heard of "Real men create their own drivers", but this takes it a step further: "Real men create their own CPUs." https://t.co/DBFN1ce3jK
Somewhere right now, a software engineer is staring at a Jira board during a 9:00 AM standup, telling six people what she did yesterday.
Three of them aren't listening. Two are on Slack...
https://t.co/8QW1j5Xq39
"Shopify loves the five-person team. We increase to eight sometimes, but we think the best team size is one, because a single author can do things that is impossible to do for teams, and hit high notes that are unreachable.
Most projects worth doing need to be done in teams. There's a magic number at five. It's sort of what military ends up figuring out too. They test these things and come to the same conclusions.
You can temporarily go up, but at some point, you have to split teams and parcel out the tasks. Each of these gradations is like a 10x loss of productivity.
Our R&D team is three and a half thousand people. It's really lots and lots and lots of small teams."
—@tobi
Greatest modern-era software engineers (last ~30 years) - the people shaping how we build today.
1. Graydon Hoare
Creator of Rust. Made memory safety, fearless concurrency, and correctness mainstream without sacrificing performance.
2. Andrew Kelley
Creator of Zig. Radical simplicity, explicit control, and a rethink of C/C++ ergonomics for modern systems.
3. Rob Pike
Co-creator of Go, UTF-8, Plan 9. Influenced cloud-native software more than almost anyone alive.
4. Russ Cox
Go toolchain, module system, regex engine, networking stacks. Turned Go into a production-grade systems language.
5. Brendan Eich
Created JavaScript in 10 days, then fixed it for decades. Also co-founded Mozilla and Brave.
6. Rich Hickey
Creator of Clojure. Changed how engineers think about immutability, state, and simplicity in distributed systems.
7. Leslie Lamport
Paxos, logical clocks, distributed systems correctness. If you design distributed systems, you’re standing on his work.
8. Martin Kleppmann
Author of Designing Data-Intensive Applications. Defined how modern engineers reason about data systems.
9. Jeff Dean
Google-scale systems: MapReduce, Bigtable, Spanner, TensorFlow. Planetary-scale engineering.
10. Sanjay Ghemawat
Co-creator of Bigtable, MapReduce, Spanner. Quietly shaped modern distributed storage.
11. Ben Treynor Sloss
Founded Google SRE. Changed ops from firefighting to engineering.
12. Mitchell Hashimoto
HashiCorp (Terraform, Vault, Consul). Infrastructure as code became normal because of him.
13. Solomon Hykes
Creator of Docker. Containers went from niche to default.
14. Kelsey Hightower
Kubernetes educator-in-chief. Made distributed systems understandable to normal humans.
15. Fabrice Bellard
QEMU, FFmpeg, TinyCC, QuickJS. One of the most productive engineers in history.
16. John Ousterhout
Tcl, Raft, Redis influence, system design philosophy (A Philosophy of Software Design).
17. Theo de Raadt
OpenBSD. Security-first systems engineering done uncompromisingly right.
18. Evan You
Creator of Vue.js. Developer experience done with taste and restraint.
19. Chris Lattner
LLVM, Clang, Swift. Compiler infrastructure that powers half the industry.
20. Bjarne Stroustrup (still relevant)
C++ evolution in the modern era. Performance engineering at scale never left.
---
Pattern you’ll notice:
Modern greats don’t just write code - they change how engineers think: about safety, scale, simplicity, correctness, and leverage.
If you’re aiming for Staff+ in 2026 and beyond, study their ideas, not just their tools.
Anthropic in the last 10 days: built Claude Cowork
Me in last 10 days: chased a production bug until I discovered the "fix" was a single minor version bump in a closed source Java dependency
The company hired me to lead their "Agile Transformation."
I don't know what Agile means.
Nobody does.
That's why it works.
I make $425,000 a year.
To move sticky notes.
From left to right.
On a board.
The board is digital now.
The sticky notes cost $80,000 in Jira licenses.
Progress.
Day one, I said "we need to break down silos."
Everyone nodded.
Silos are bad.
I don't know why.
But destroying them is a career.
My career.
I introduced "squads."
Squads are teams.
But disrupted.
We disrupted the teams into teams.
Different names.
Same people.
Same problems.
But Agile problems now.
Agile problems are strategic.
A senior engineer asked what we're actually changing.
I said, "The mindset."
He asked what that means.
I said, "It's a journey."
He asked where we're going.
I said, "Toward agility."
He asked what agility means.
I pointed at the sticky notes.
They were moving left to right.
That's velocity.
We have velocity now.
The VP of Engineering said two-week sprints don't fit their work.
I said, "That's waterfall thinking."
Waterfall is bad.
Like silos.
I don't know what waterfall is.
But I know it's bad.
She stopped talking.
Waterfall accusations end conversations.
We had a retrospective.
In the retro, we discussed what went wrong.
Everything went wrong.
We put it on sticky notes.
Then we moved the sticky notes.
Into a column called "Parking Lot."
The Parking Lot is where problems go to die.
It's full.
We don't look at it.
That's agile.
Velocity is up 40%.
I defined velocity.
I also defined the points.
I also defined the stories.
We're crushing it.
At the things I made up.
To measure.
Ourselves.
The CEO asked for ROI.
I showed a chart.
The chart went up.
Charts should go up.
This one did.
I didn't label the Y-axis.
Nobody asked.
Leadership is confidence.
We do standups now.
Every day.
We stand.
For 45 minutes.
Standing is agile.
Sitting is waterfall.
My legs hurt.
But we're transforming.
The transformation is now "Phase 3."
Phase 1 was assessment.
Phase 2 was implementation.
Phase 3 is "continuous improvement."
Continuous means forever.
Forever means job security.
I'm very secure.
My contract was extended.
Three more years.
For "cultural impact."
The culture is confused.
But impacted.
Agile transformation isn't about being agile.
It's about transforming.
Continuously.
Toward more transformation.
The destination is the journey.
The journey is billable.
Unless leadership has an engineering background, the value of the technical debt work likely needs to be quantified and shown as business value. Most Technical Problems Are Really People Problems https://t.co/5gdt27BdPB
Last quarter I rolled out Microsoft Copilot to 4,000 employees.
$30 per seat per month.
$1.4 million annually.
I called it "digital transformation."
The board loved that phrase.
They approved it in eleven minutes.
No one asked what it would actually do.
Including me.
I told everyone it would "10x productivity."
That's not a real number.
But it sounds like one.
HR asked how we'd measure the 10x.
I said we'd "leverage analytics dashboards."
They stopped asking.
Three months later I checked the usage reports.
47 people had opened it.
12 had used it more than once.
One of them was me.
I used it to summarize an email I could have read in 30 seconds.
It took 45 seconds.
Plus the time it took to fix the hallucinations.
But I called it a "pilot success."
Success means the pilot didn't visibly fail.
The CFO asked about ROI.
I showed him a graph.
The graph went up and to the right.
It measured "AI enablement."
I made that metric up.
He nodded approvingly.
We're "AI-enabled" now.
I don't know what that means.
But it's in our investor deck.
A senior developer asked why we didn't use Claude or ChatGPT.
I said we needed "enterprise-grade security."
He asked what that meant.
I said "compliance."
He asked which compliance.
I said "all of them."
He looked skeptical.
I scheduled him for a "career development conversation."
He stopped asking questions.
Microsoft sent a case study team.
They wanted to feature us as a success story.
I told them we "saved 40,000 hours."
I calculated that number by multiplying employees by a number I made up.
They didn't verify it.
They never do.
Now we're on Microsoft's website.
"Global enterprise achieves 40,000 hours of productivity gains with Copilot."
The CEO shared it on LinkedIn.
He got 3,000 likes.
He's never used Copilot.
None of the executives have.
We have an exemption.
"Strategic focus requires minimal digital distraction."
I wrote that policy.
The licenses renew next month.
I'm requesting an expansion.
5,000 more seats.
We haven't used the first 4,000.
But this time we'll "drive adoption."
Adoption means mandatory training.
Training means a 45-minute webinar no one watches.
But completion will be tracked.
Completion is a metric.
Metrics go in dashboards.
Dashboards go in board presentations.
Board presentations get me promoted.
I'll be SVP by Q3.
I still don't know what Copilot does.
But I know what it's for.
It's for showing we're "investing in AI."
Investment means spending.
Spending means commitment.
Commitment means we're serious about the future.
The future is whatever I say it is.
As long as the graph goes up and to the right.
Microservices is the software industry’s most successful confidence scam. It convinces small teams that they are “thinking big” while systematically destroying their ability to move at all. It flatters ambition by weaponizing insecurity: if you’re not running a constellation of services, are you even a real company? Never mind that this architecture was invented to cope with organizational dysfunction at planetary scale. Now it’s being prescribed to teams that still share a Slack channel and a lunch table.
Small teams run on shared context. That is their superpower. Everyone can reason end-to-end. Everyone can change anything. Microservices vaporize that advantage on contact. They replace shared understanding with distributed ignorance. No one owns the whole anymore. Everyone owns a shard. The system becomes something that merely happens to the team, rather than something the team actively understands. This isn’t sophistication. It’s abdication.
Then comes the operational farce. Each service demands its own pipeline, secrets, alerts, metrics, dashboards, permissions, backups, and rituals of appeasement. You don’t “deploy” anymore—you synchronize a fleet. One bug now requires a multi-service autopsy. A feature release becomes a coordination exercise across artificial borders you invented for no reason. You didn’t simplify your system. You shattered it and called the debris “architecture.”
Microservices also lock incompetence in amber. You are forced to define APIs before you understand your own business. Guesses become contracts. Bad ideas become permanent dependencies. Every early mistake metastasizes through the network. In a monolith, wrong thinking is corrected with a refactor. In microservices, wrong thinking becomes infrastructure. You don’t just regret it—you host it, version it, and monitor it.
The claim that monoliths don’t scale is one of the dumbest lies in modern engineering folklore. What doesn’t scale is chaos. What doesn’t scale is process cosplay. What doesn’t scale is pretending you’re Netflix while shipping a glorified CRUD app. Monoliths scale just fine when teams have discipline, tests, and restraint. But restraint isn’t fashionable, and boring doesn’t make conference talks.
Microservices for small teams is not a technical mistake—it is a philosophical failure. It announces, loudly, that the team does not trust itself to understand its own system. It replaces accountability with protocol and momentum with middleware. You don’t get “future proofing.” You get permanent drag. And by the time you finally earn the scale that might justify this circus, your speed, your clarity, and your product instincts will already be gone.
The biggest drain on your team isn't the impossible challenges. It's the people who turn simple tasks into complex ones.
Keep the simplifiers. Avoid the complicators.
It's not easy to spot, often the complicators are seen as having a great attention to detail & high care.
But it's not that. It's inability to self-regulate on the right detail, the right problems, and the right effort. And their blast radius is hard to contain.
WOW
Oracle Layoffs are intense.
Entire orgs are getting blindsided.
Cloud, Comms/Marketing, Engineering, Ops, Sales
Directors, ICs, even SVPs - all levels.
Remote and in-office. Top performers. Doesn’t matter.
People with 7, 13, 18, 20+ years at Oracle… gone!!
I was told- If you got the email for saying 'Project Updates' - that’s the bait.
You join the call.
An HR rep read a statement.
Access cut within 5 minutes.
Laptop wiped. That’s it.
- Some management didn’t even know.
- RIF decisions weren’t made by your manager.
- Not even your manager’s manager.
People found out their reports were laid off AFTER the fact... then they got cut next.
SaaS execs were reportedly told:
“Cut 10–12% of workforce by end of year.”
And yes, I'm being told some H-1B workers are being impacted as well.
This morning:
- SVPs laid off
- Longtime employees ghosted by leadership
- 1/3 of some teams already gone
- One Oracle vet: “I just got traded in for a GPU.”
Make no mistake: this isn’t just Oracle. This is Corporate America 2025.
Shopify CEO Tobi Lutke explains Goodhart’s law and why he doesn’t like KPIs or OKRs
“Goodhart’s law is real. The moment a metric becomes a goal, it’s no longer a useful metric… No metric by itself is a complete heuristic for a complex business. There’s a million different tensions in a company, and you can’t keep all of them in harmony by optimizing for one thing.”
For this reason, Shopify doesn’t use KPIs or OKRs. But as Tobi explains, this doesn’t mean they don’t value data and metrics.
“We are extremely data informed. We have invested enormous amounts of money and time into systems that give us basically everything at our fingertips… But what Shopify attempts to do is just not over-fit for what’s quantifiable.”
People love optimizing for highly-quantifiable things because there’s immediate gratification that comes from seeing a number go up. But Tobi thinks that the most important aspects of a product are rarely quantifiable:
“The overlap of the most valuable things you can do with a product and the things that happen to be fully quantifiable are like maybe 20%. Which leaves 80% of a value space unaddressable by the people who only look at quantifiable things.”
He continues:
“Shopify is comfortable with unquantifiable things like taste, quality, passion, love, hate… The sort of deep satisfaction that a craftsperson feels when they’ve done a job well is actually a better proxy if you allow it to be.”
They then have robust analytics systems that tell the company if something’s wrong or a new rollout breaks something.
“We think about it as a cockpit for a pilot. The decisions are still made by pilots, and we think this leads to better results… I think there needs to be more acceptance in business of unquantifiable things… And then metrics take a support function.”
Video source: @lennysan (2025)