In the book the Unicorn Project, the main character Maxine is held up as a positive role model, when she's actually part of the problem.
Let me explain.
Maxine works late nights, volunteers for Thursday evening deployments, volunteers for weekend store training, then goes home and writes a 12-page report while her family plays with the puppies, and checks in her laptop while she's sick.
1/
Tech culture often celebrates engineers like Maxine. Theyโre brilliant people who work nights and weekends because they "love" it.
This isn't what good culture looks like. Sure, every once in a while this is necessary when it's a real emergency. But if "real emergencies" happen every weekend and evening week after week for months on end, it's not actual an emergency; it's just a poorly managed organization.
2/
In the book the Unicorn Project, the main character Maxine is held up as a positive role model, when she's actually part of the problem.
Let me explain.
Maxine works late nights, volunteers for Thursday evening deployments, volunteers for weekend store training, then goes home and writes a 12-page report while her family plays with the puppies, and checks in her laptop while she's sick.
1/
Vibe coders are learning. Writing code was never that hard.
For sure, coding starts hard, but it's a hard that gets easier with exercise, like any other exercise.
Figuring out what people need & solving that need. Now that's hard. Irreducibly hard. It never really gets that much easier.
Your favorite LLM, though, can't exercise anything. It doesn't even really know anything. At least not in the sense of the way we say that we know things. Does
1/
An LLM just goes in the direction you point it. It is as deep as you are in understanding something.
Sure, you can go faster in a particular direction with it. 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. That's valuable.
But knowing if it's the right or the wrong direction, that's on you.
2/
Vibe coders are learning. Writing code was never that hard.
For sure, coding starts hard, but it's a hard that gets easier with exercise, like any other exercise.
Figuring out what people need & solving that need. Now that's hard. Irreducibly hard. It never really gets that much easier.
Your favorite LLM, though, can't exercise anything. It doesn't even really know anything. At least not in the sense of the way we say that we know things. Does
1/
Parkinson's Law will at your roadmap alive, if you let it.
"Work expands so as to fill the time available for its completion."
Setting time expectations for how long something ๐ฎ๐ช๐จ๐ฉ๐ต take tends to make it how long it ๐ด๐ฉ๐ฐ๐ถ๐ญ๐ฅ take.
I bet you've experienced this:
- meetings that expand to fill the scheduled duration regardless of agenda or need
- features always somehow take the full sprint when given two weeks
- projects scoped to take place during Q2 mysteriously require the entire quarter
I submit there are likely many major mental models that people actually useโ consciously or unconsciously for how they're doing the work:
- Academia - getting to the answer
- Artisan - making a high quality parts
- Assembly Line - making the whole sequentially
- Construction - making the whole in layers with different crews
- Restaurant - different stations to assemble something
2/
Additionally, there are several mental models for what they're making:
- Factory - a thing that makes other things
- Residential building - an thing for someone to use directly
- Roads and bridges - a thing for someone to use indirectly
- Supply chain - a thing to move other things
Having a sufficiently accurate mental model helps you (1) explain to yourself what's going on, (2) explain it to others, and (3) effectively target it for change.
3/
More software engineering leaders have poorly formed mental models for their work.
Mental models are metaphors for how something works, a simplification of the thing to make it easier to understand it. A few examples from physics would be things like:
- electricity is the flow of positive charge
- gravity is like a spring in reverse
- a black hole sucks everything in
These mental models aren't strictly accurate. So you must be careful when building upon them.
1/
I submit there are likely many major mental models that people actually useโ consciously or unconsciously for how they're doing the work:
- Academia - getting to the answer
- Artisan - making a high quality parts
- Assembly Line - making the whole sequentially
- Construction - making the whole in layers with different crews
- Restaurant - different stations to assemble something
2/
More software engineering leaders have poorly formed mental models for their work.
Mental models are metaphors for how something works, a simplification of the thing to make it easier to understand it. A few examples from physics would be things like:
- electricity is the flow of positive charge
- gravity is like a spring in reverse
- a black hole sucks everything in
These mental models aren't strictly accurate. So you must be careful when building upon them.
1/
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
Robert Roskam