Note: This one has two weeks worth of notes since I forgot last week.
For those of you who are subscribers but not signed up with Substack, here is a compilation of some notes that I’ve been sharing lately online. Notes are my way of making media suggestions, sharing experiences, and trying out the goofy ideas bouncing around in my head. If you are on Substack already, you may have seen a lot of these in your feed. You can safely disregard this email.
If you want to see comments or reactions to an individual note, click on the time-date stamp at the top of the entry. This link is also useful if you wish to share a specific item.
I think it is always going to be true that a person who manages programmers should not expect it to be predictable.
-- Donald Knuth (Coders at Work)
Amen to that! If only the world would listen.
I tend to code this way as well. I need to see something running, then “it starts telling you what it is.”
In the spectrum of implementers, I probably err on the side of just making things happen. A lot of that is because I get so much of a thrill bringing things to life that it doesn't even matter if it's wrong at first. The point is, that as soon as it comes to life it starts telling you what it is.
-- Dan Ingalls (Coders at Work)
Organizations find ways to say unpleasant things with vague and indirect language. It makes hard things more comfortable, but it obscures the simple truth.
Reduction in Force instead of Layoff
Performance Improvement Plan instead of Probation
One that I particularly hate is Alignment. It's a euphemism for forced compliance.
"aligning the organization."
"driving alignment"
"alignment vs autonomy"
"we need to align"
Alignment is never about coming to a common understanding or meeting in the middle. There is always a corporate standard to align with.
Align simply means "fall in line" and march to the beat of the same drum.
To founders.
It's beyond frustrating to know, as a programmer, that what your manager subjects you to would never fly with the founders. But because the barricades erected between you and the founders are so thick, you can never get a message through. Like Bob Dylan says in Maggie's Farm,
Bricks line their windows, and the national guard is posted outside their front door.
Even in the rare instance you can get a message through the armaments, the assumption is always that you must be a disgruntled employee and it's best not to engage.
If you care about culture, you have to follow Paul Graham's advice, and go full "founder mode." You can't let your middle managers be black boxes. You have to care what your individual contributors tell you, and believe them, and protect them. You have to get your hands dirty and being willing to take out the garbage.
Where was “founder mode” when I needed it?
Great historical information on how we got to where we are with Agile and Scrum.
https://x.com/allenholub/status/1846275670483128563
aristocracy, government by a relatively small privileged class or by a minority consisting of those presumed to be best qualified to rule.
--britannica.com/topic/aristocracy
In a corporation, they call it management.
Here are four core elements of Scrum, straight from the Scrum Guide—the official document from scrum.org—that often cause problems in software teams. No one can say, “you’re doing it wrong,” because these are the very pillars every Scrum practice rests on. If Jeff Sutherland and Ken Schwaber don’t already have these principles tattooed somewhere, they’re probably getting matching back pieces right now.
But there’s a problem, every one of these items is not just wrong—they’re crippling software teams everywhere.
Sprints constantly repeat, with fixed lengths and no breaks: rethinkingsoftware.substack.com/p/why-s…
Stand-ups are everyday: rethinkingsoftware.substack.com/p/the-d…
Scrum depends on estimates (a.k.a. sizing): rethinkingsoftware.substack.com/p/how-t…
The product owner has full control over the product backlog.: rethinkingsoftware.substack.com/p/scrum…
Click on the link that goes with each to see why they’re causing so much trouble.
This is one of the best write-ups I have seen on the pitfalls of Agile and it comes completely from ChatGPT reading
’s awesome collection of developer lamentations. AI gets it! Now why can't management?!medium.com/@agilekillskittens/chatgpt-t…
So much to glean from this excellent piece. One passage struck me as particularly relevant to the problems engineers continue to face in the Agile movement. Seeing how Scrum and other formalized Agile implementations have been so easily co-opted to serve traditional top-down management, perhaps that was the fundamental flaw--the fact that they were formalized and written down. The Agile Manifesto was vague enough to serve the same purpose as Arizmendiarrieta’s without mandating any specifics. We should have just left it at that and let engineering teams self-organize.
The most important takeaway, however, is that programmers need to start forming worker-owned organizations, where exploitative practices can't take root in the first place.
Arizmendiarrieta’s manifesto is not done, and perhaps that’s why it could never be penned down on paper. “We should not live cooperativism as if what is accepted and decided at a given moment were something unchangeable,” he said. “Rather, we should admit it as a process of experience in which it is possible and may be necessary to adapt as many modifications as can contribute to cooperativism.”
Chapter 17 of the Tao Te Ching is a masterclass in leadership.
The best leaders are those the people hardly know exist. The next best is a leader who is loved and praised. Next comes the one who is feared. The worst one is the leader that is despised.
If you don’t trust the people, they will become untrustworthy.
The best leaders value their words, and use them sparingly. When she has accomplished her task, the people say, “Amazing: we did it, all by ourselves!”
tao-in-you.com/lao-tzu-tao-te-ching-cha…
Employee prediction markets have successfully been used to harness the wisdom of the crowd for predicting corporate outcomes. I wonder if they could be used to accurately predict product releases. I would much rather do that than story points and velocities…
Some corporations have harnessed internal predictive markets for decisions and forecasts. In these cases, employees can use virtual currency to bet on what they think will happen for this company in the future. The most accurate guesser will win a money prize as payoff. For example, Best Buy once experimented on using the predictive market to predict whether a Shanghai store can be open on time.[19] The virtual dollar drop in the market successfully forecasted the lateness of the business and prevented the company from extra money loss.
Nature has a few things to teach us about self-organizing, leaderless teams. Turns out, honeybees have developed an effective algorithm for making decisions without deferring to authority. If you find this podcast interesting, Seeley has also written a book, Honeybee Democracy, with more details about his research.
Over millions of years, honeybees have evolved to act as a collective. Together, they identify and deliberate new nest locations and then navigate there as a swarm. Thomas Seeley loves honey bees, and he knows a lot about them. But there's one thing that remains a mystery to him: how do bees know when to swarm? As he searches for the answer, Seeley's learning what these insects can teach humans about making decisions.
google.com/amp/s/radiowest.kuer.org/hea…
Goodhart's law
"When a measure becomes a target, it ceases to be a good measure"
Oh so true. Especially in software development.
en.wikipedia.org/wiki/Goodhart%27s_law
I recently listened to Coders at Work on audible. It had a TON of great of advice for programmers. I highly recommend it.
oreilly.com/library/view/coders-at-work…
I read Erik Dietrich’s excellent book Developer Hegemony some time ago, but just recently discovered his online blog. I am excited to dig in!
Wonderful conversation with Kent Beck on the Refactoring YouTube channel. They hit:
How power structures continue to co-opt engineering processes.
How to eliminate the extremely inefficient bottle-necking around PR based code reviews.
Working with AI as a programmer.
Junior Programmer: What's Scrum. I didn't learn that in college.
Senior Programmer: Oh, that's nothing. It's just slang we use around here for when you throw up a little in your mouth and have to swallow it back down.
Junior Programmer: (puzzled look on face)
[Later in Scrum planning meeting]
Scrum Master: Everyone have your poker cards ready? How many points should this story be? Pick the right card, and on the count of three, hold it up. One, Two, ..
Junior Programmer: (looks nauseous)
Senior Programmer: (whispers to junior programmer) Dude, you ok? You look like you're going to Scrum.
Enjoy your week!