Assumptions software engineers make about production networks that are often wrong:
- Network requests always succeed
- Networks are reliable
- Bandwidth is infinite
- Latency is zero
- The network is secure
- Topology doesn't change
- Nothing is shared
- The administrator is trustworthy
- Transport cost is zero
- The network is homogeneous
- Clocks are synchronized
These assumptions, known as the "Fallacies of Distributed Computing," lead to fragile systems that break in production.
Lies programmers believe about scaling:
- if 1 process can handle X requests, then 2 processes can handle 2x requests
- well, 2x requests with 2 processes is possible if there's more than 1 CPU core
- 2x reqs with 2 procs is possible with more than 1 CPU core and plenty of RAM
- uh...and there's plenty of disk space?
- oh, oh, right, and if there's no shared services
- something, something Kubernetes
- ...this can't be this hard
- I'll have time to figure it out later
Maslow's Hammer: If all you have is a hammer, everything looks like a nail.
In software engineering:
- If you only know SQL, every data problem looks like a database problem
- If you only know REST, every API looks like a CRUD interface
- If you only know React, every UI problem looks like a component problem
- If you only know microservices, every system looks like it needs to be distributed
The solution is expanding your toolkit and learning when different tools are appropriate.
Moved my blog from Substack to self managed:
https://robertroskam.com/blog/
I flipped the switch in the past hour or so.
I expect it’s still going to be bare bones for a bit.
Enjoy!
Aaaaand a few hours later I have 100s across the index page.
Moved my blog from Substack to self managed:
https://robertroskam.com/blog/
I flipped the switch in the past hour or so.
I expect it’s still going to be bare bones for a bit.
Enjoy!
For software engineers, how much of your week to you spend writing documentation?
Things no one will mention at your funeral:
- participated in standups
- increased to shareholder value
- got in expense report on time all the time
- had 90% code coverage on all PRs
- clocked your time on time all the time
This is not an exhaustive list by any means.
Imma having nachos
Vibe coders are in for a shock. Writing code was never that hard.
Figuring out what people need and determining what to try to solve it. Now that's the hard part.
AI just takes the direction it's given. Sure, you can go faster in a particular direction. If you're going in the right direction, you'll get there faster. If you're going in the wrong direction, you'll also get there faster.
You still need the judgement to know if it's the right or the wrong direction.
If you want to be a 10x engineer:
- Share your ideas freely with little concern for credit
- Default to openness
- Hear another team member all the way out, especially when you disagree
- Fail together, not alone—no one learns if you keep it secret
- Message where you're going as much as current location
The 10x engineer lifts up their team to get 10x things done.
Robert Roskam