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.
“Our new Jira ticket machines have finally arrived! Just grab your next task as you come in, find a seat, and get to work. Don’t forget to punch your ticket if you take a bathroom break, so we can track your time. Happy programming!”
"I heard you telling your brother that a chore point is 15 minutes. I know it’s confusing, but you know we don’t measure chores like that in this house, right? Chore points aren’t about time."
Engineering Manager: There's nothing I can do. We have to do it this way; it's required by law for SOC 2 compliance.
Programmer: Didn’t you choose what would be required for our SOC 2 compliance? The auditors just check to see if we're following our own rules.
Engineering Manager: I don’t know what you’re talking about... (slowly backing out of the conference room door)
Scrum Master: Story points mean nothing. You have to remember that! They are not hours or days; they're just numbers. Actually you could pick barn yard animals if you want. Should we do that? Is this story a chicken or goat? Maybe not quite as big as goat ... should we say it's a pygmy goat?
Programmers: (with laptops open, pretending to listen, quietly updating their resumes.)
Great article (and book) by Cal Newport about the benefits of Slow Productivity:
A philosophy for organizing knowledge work efforts in a sustainable and meaningful manner, based on the following three principles:
Do fewer things.
Work at a natural pace.
Obsess over quality.
This philosophy rejects busyness, seeing overload as an obstacle to producing results that matter, not a badge of pride. It also posits that professional efforts should unfold at a more varied and humane pace, with hard periods counterbalanced by relaxation at many different timescales, and that a focus on impressive quality, not performative activity, should underpin everything. The philosophy’s core principles include, providing both theoretical justification for why they’re right and concrete advice on how to take action on them in your specific professional life, regardless of whether you run your own company or work under the close supervision of a boss.
https://behavioralscientist.org/a-new-philosophy-of-productivity/
Everybody wants to be a unicorn: a billion dollar business. But, what I want to see is a billion dollar employee owned business -- that makes a thousand millionaires. That would the hallmark of a new and better age of capitalism. That's where I want to work.
I arrived at work one day to find someone sitting in my chair. It turns out, that person was my replacement. In fact, my entire team was being replaced. An engineer, hired just two days earlier, had been promoted to CTO, and his first official action was to call us, one by one, into a conference room and terminate us immediately—while his friends, the replacement crew, sat at our desks.
The next day, a friend who hadn’t been fired told me the CEO was claiming we had all quit.
You can’t make this stuff up.
Programmers are pawns in a corporate game where others hold all the cards. Freelancing or starting our own companies seems to be the only viable way out of this madness.
This has been my experience as well. The “programmers as technicians” mentality is pervasive.
When Yahoo bought Viaweb, they asked me what I wanted to do. I had never liked the business side very much, and said that I just wanted to hack. When I got to Yahoo, I found that what hacking meant to them was implementing software, not designing it. Programmers were seen as technicians who translated the visions (if that is the word) of product managers into code.
Paul Graham, Hackers and Painters
Most companies do the exact opposite of this, to their detriment.
Don't listen to marketing people or designers or product managers just because of their job titles. If they have good ideas, use them, but it's up to you to decide; software has to be designed by hackers who understand design, not designers who know a little about software.
Paul Graham, The Other Road Ahead
Greatest Hits from Before Sep 8
Since this is my first weekly notes email, I have included some greatest hits from earlier weeks.
After my freshman year of college, I did a summer internship as a computer programmer. My assignment during those four summer months was to complete a considerably large project using technology I had scarcely used before. There were many unknowns, and I had no idea if I could succeed. However, after much effort, I surpassed my own expectations. By the end of the summer, I had not only completed my project but also finished several others. I planned, designed, researched, asked questions, wrote documentation, and presented my work. It was a full engineering experience.
Sadly, almost 30 years later, as a much more senior engineer, I rarely have such opportunities. No engineer I know is ever trusted with a project of that size or given that much time to focus on one thing. About fifteen years ago, the industry began its massive shift toward Scrum-like processes. With that shift, software engineers effectively became assembly-line workers, merely taking one task after another from the hopper. Each task takes no longer than a couple of days. No time is allotted for design or research. A day without a commit to version control is considered a wasted day by most managers. Unfortunately, we now have to content ourselves with daily software errands that are scarcely more interesting than making the morning coffee or fetching the boss’s dry cleaning.
Scrum had its chance; now let’s move on to something better!
I once got called into my boss's office to get grilled for not putting in overtime to hit a deadline.
"Don't you care?" he asked.
"No," I said. "Why would I? You don't pay me what I'm worth, and I don't have any equity."
His face turned red. "Maybe this isn't working out," he said.
The next day, he gave me a pay raise and made me team lead.
Moral of the story? I have no idea, except that our industry is nuts.
I asked Chat-GPT to, “write a poem about how pointless it is to estimate software tasks”
The Estimator's Lament
We gather 'round with charts and tools,
To guess the time, like well-trained fools.
We break it down, piece by piece,
Hoping the chaos somehow will cease.
But numbers lie, and plans deceive,
What once seemed clear, we now misbelieve.
For in the code, where logic twists,
Our estimates fade like morning mists.
We say "a day," but weeks go by,
"Just a sprint," we softly lie.
The hours stretch, the tasks expand,
Beyond the reach of our careful hand.
Why do we pretend to know the end,
When each new bug's a curve to bend?
In software’s wild, uncharted sea,
No map or time can guarantee.
So let us code, let flow the mind,
Leave the clocks and charts behind.
For in this dance of ones and zeros,
No one can count the unsung heroes.
To estimate is to chase the wind,
A futile game we never win.
Embrace the journey, trust the flow,
And where it leads, we’ll never know.
Chat-GPT knows what I am talking about.
I once received a bad peer review at work because my story estimates were "always bigger than the rest of the team."
What's funny is that no one ever bothered to check how accurate those estimates actually were. If they had, they would have seen that I was right a lot of the time.
Estimation is usually just theater. If I estimate low, it signals to everyone that I'm a hotshot programmer. I gain street cred. The business folks say, "Yeah, he's a go-getter. I like him." But no one ever checks to see if the estimates are correct.
If the goal is to get accurate estimates, the motivations are all wrong.
To those who say, “Yeah, yeah, Scrum sucks, but show me something better,” here is one of the many promising alternatives.
The software development company Basecamp uses a system that is decidedly non-Scrum-like. Their process is well-documented in an online book. Here are some quotes to give you an idea of how it works:
Six Week Cycles
Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks. Our focus is at a higher level. We say to ourselves: “If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.” Then we commit the six weeks and leave the team alone to get it done.
Defining Projects
Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite.
Delegation
Third, we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers.
Check out basecamp.com/shapeup to get more details. Contrary to popular belief, Scrum is NOT the only game in town!
Adventures of Scrum Dad
Son: Dad! I finished with the leaves!
Scrum Dad: Great job!
Son: I emptied the trash too.
Scrum Dad: What?
Son: I emptied the trash too.
Scrum Dad: You did? I don’t remember that being on the list I gave you.
Son: (with a confused look) But it was full!
Scrum Dad: Yes, I understand that. But we never groomed that task. There might have been something more important for you to do with that time.
Son: But it... was... full.
Scrum Dad: Yes, I know that, but I am the customer, not you. It’s not up to you to decide what I need. You should have brought this to my attention first. Then we could have decided what comes next. We will never get that time back, and who knows what important thing was neglected.
Son: (walks away mumbling to himself) But it was full.
The Adventures of Scrum Dad
Scrum Dad: Son, we need to get the leaves raked. If you had to do that, how long would it take you?
Son: Hmm... I don't know, I’ve never done it before.
Scrum Dad: But haven’t you thought about doing it? Maybe you and I can break it down into tasks?
Son: Tasks? Like what? Rake a few leaves, then put them in a bag? I’d rather just go do it.
Scrum Dad: No! You don't have permission to do it until I know how long it will take. There could be higher-priority chores that will fit into your time better. We need to groom our backlog.
Let’s see if Mom would rather have you do the dishes. How long does it take you to do the dishes?
Son: It depends on how many dishes we have.
Scrum Dad: Maybe you can talk to your mother and see what she is cooking tonight, and how many dishes she plans on using.
Son: Dad, can't I just go rake the leaves?!
Scrum Dad: No, I don't know if that's what you should do yet. Will you just get your mother!
Son: Mom! Dad wants to know how many dishes there will be tonight!
Mom: How the heck should I know! Tell Dad he needs to stop doing Scrum; work is over.
Scrum Dad: Scrum isn’t just for work.
Mom: If you don’t want to sleep on the couch, it is.
Question of the Day:
If Scrum is so great—if it really lets you do “twice the work in half the time,” as Jeff Sutherland’s book proclaims—then why doesn’t everyone use it?
Why don’t your CEO, CTO, or COO put all their tasks into JIRA?
Why aren’t there Scrum Masters all over the organization, running meetings for accounting, marketing, HR, product development, finance, legal, and sales?
Why aren’t your managers—the very people who are convinced that this is the only reasonable way to manage and track engineers—putting their tasks into backlogs, doing weekly grooming meetings, and holding daily morning stand-ups?
Answer:
They don’t want to be micro-managed.
They want the autonomy to work on projects, not just errands.
They want to be trusted to accomplish big things without being checked up on every step of the way.
They want input into the vision and direction of their work.
They want the freedom to work in ways that work best for them.
Is it unreasonable for software engineers to want the same freedom as everyone else?
Scrum is dumb!
Remote-only work requires different collaboration skills than what most programmers are used to. While in-person collaboration is about talking, remote collaboration is about writing. We have some learning to do about how to effectively communicate in writing and we also need some better tools. Here are some places to start:
Literate Programming (invented by Donald Knuth). A way to make code comments first class citizens in your source files — and keep them in sync with code changes.
Internal Reddit clones: an asynchronous way to make decisions and have discussions around specific topics, as opposed to chat software where items scroll off the screen and get lost in daily chatter.
Alternatives to task hopper management software (ex. Jira, TFS, Pivotal, Linear) We need systems that focus on recording roles, projects and relationships -- not automated to-do lists. Because remote workers have less frequent interaction, they need much broader responsibilities than they get from Agile stories. Our current software systems are not equipped to handle that.
Wiki systems that aren't graveyards of immediately outdated information. We need systems that foster more aggressive individual ownership over areas of documentation. We need to gamify wiki. Wikipedia works, and we can make work-place wikis work too.
One of the best passages from one of the best software engineering books of all time:
If you’re the manager, of course you’re going to feel that your judgment is better than that of people under you. You have more experience and perhaps a higher standard of excellence than they have; that’s how you got to be the manager. At any point in the project where you don’t interpose your own judgment, your people are more likely to make a mistake. So what? Let them make some mistakes. That doesn’t mean you can’t override a decision (very occasionally) or give specific direction to the project. But if the staff comes to believe it’s not allowed to make any errors of its own, the message that you don’t trust them comes through loud and clear. There is no message you can send that will better inhibit team formation.
Most managers give themselves excellent grades on knowing when to trust their people and when not to. But in our experience, too many managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager’s eyes or in your government’s eyes) is irrelevant; it’s only the right to be wrong that makes you free.
— Peopleware by Tom DeMarco and Timothy Lister
My Dad, a software developer in his younger years, liked to tell me his version of the Heisenberg Uncertainty Principle, except his applied to software development:
If you know what's in it, you don't know when it'll ship. If you know when it'll ship, you don't know what's in it.
As a programmer myself, I haven't found many exceptions to this rule. Whether you ship once a day or once a year, there is too much uncertainty in building software to make good predictions about when things will be done.
Yet most existing software processes ignore this rule and resort to constraining feature sets and delivery dates (ex. sprints) — which creates dysfunction. What if we took this rule seriously and built a process around it? Instead of wishing it wasn't true? What would that process look like?
Enjoy your week!