An Unnamed Programmer in Peopleware is One of my Heroes

I read Peopleware early in my career and revisit it every few years. Yesterday I wrote about what they meant about 10x programmers, and while doing that, I looked for this excerpt, which I think about all of the time (emphasis mine).

One of the upper managers buttonholed me to request that I assess […] his project staff. He was particularly curious about one woman. It was obvious he had his doubts about her: “I don’t quite see what she adds to a project; she’s not a great developer or tester or much of anything.”

With a little investigation, I turned up this intriguing fact: During her 12 years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn’t obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them.

Peopleware

They go on to say “The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who just do work.”

I don’t know who she was, but this programmer was one of the most influential role models of my career. I constantly ask myself what would she do. My post about How Senior Software Developers Think is my take on it, but it’s much more than that. Coding is certainly an important part of being a software engineer, but most projects can technically be done by a wide range of coders. The other skills, the work that makes the project succeed, are a lot more rare in my experience.

How to Become a 10x Programmer

The idea of the 10x programmer probably originated with Peopleware. The authors ran pairs of developers from the same organization through a “coding wars” exercise. They collected data from many organizations over several years and measured that the best coders did about 10x better than the worst and about 2.5x better than the median ones.

But, probably everything you have heard about what that means is wrong.

For one, even though the pairs did not work together at all, their results were highly correlated with each other. Secondly, the participants in the exercise worked at their desks in their normal working environment. Finally, there wasn’t a correlation to experience level or technology used.

The authors conclude that the organizational environment and culture is a major factor in the effectiveness of its programmers.

The bald fact is that many companies provide developers with a workplace that is so crowded, noisy, and interruptive as to fill their days with frustration. That alone could explain reduced efficiency as well as a tendency for good people to migrate elsewhere.

So, how do you become a 10x programmer? By changing jobs to an organization that provides an environment where you can be effective.

Recommendation: Digital Zettelkasten by David Kadavy

I just bought and finished reading Digital Zettelkasten by David Kadavy. It’s a quick read and a good companion to How to Take Smart Notes, which I talked about in Write While True Episode 2: Small Bits of Writing and Write While True Episode 3: First Drafts.

Like David, I think of note-taking as primarily about writing and is the starting point of my original writing. His book covers his workflow, which is a lot like mine. I got a few new tips, but it was mostly a reinforcement of how I think of note-taking.

As I covered in my podcast, I “read” by writing. At the end of reading a book, I have generated bits of writing in Obsidian and flash cards for Anki (covered in Write While True Episode 14: Spaced Repetition). This has helped me retain the information I have read, have new ideas, and develop them into new writing.

If you write, but don’t currently have a note-taking practice and would like to see how one writer does it (in detail), this book is worth your time.

June 2021 Blog Roundup

I took a few weeks off to travel, see friends and family, and get some rest.

WWDC was in the beginning of June, so I wrote about that:

I also wrote about software process and testing

I also took a break from podcasting, but made these in June:

I expect to have an episode Monday on taking breaks.

Put Aggravation (and Joy!) in the Spreadsheet

When I am trying to figure out if something is worth the cost or how to charge for something, I might build a little model in a spreadsheet. All the things that can be expressed as a number probably end up in it. What usually makes the difference though, is when I force myself to express my mental costs and benefits as a number too.

For example, I like my apartment, but sometimes I think of moving. Maybe get a condo instead of renting. But, when I put the numbers together, if I make line items about my “feelings”, I see that I can’t justify the cost difference. I just don’t value what I’d get and I personally find some parts of home-ownership very aggravating.

The same kind of line items also show up when I am trying to price my consulting services. I price in my feelings. I want to be neutral to the customer’s choice. It’s the standard “say no with a number” advice, but this is how I get to that number.

Write While True Episode 15: Combine Identities

I made this podcast, but I wanted to self-host, so I learned how to do that with s3 and wrote my own way to get analytics. So, Podcasting leads to programming. And then I wrote up a blog about that program (so it led back to writing) and now I am telling you about it on this podcast. Round and round it goes.

The more times I go around the circle, the easier it becomes to write or podcast or program about one of the other things I’m doing. The content for this podcast is mostly taken from a blog post I made in February. Back then I just said that I should come up with some way to combine programming and writing more. This podcast was the result of that thinking.

Transcript

Waterfall is a Myth

I think everyone who programs has heard the story of the failure of the waterfall process.

Back in the olden days, to build software someone would first write up a document with all of the requirements. Then, the software architects would design a system and produce a document with that. And, then, I guess there would be some kind of implementation plan and that would be completed. Then, the programmers would code it up. And finally, the testers would test it. Then, you ship it.

It looked like this:

I’m going to say that I think this never happened in real life. I doubt anyone seriously tried it for anything big. Or, if they did, I hope they failed super-fast and started over.

This diagram comes from a 1970 paper called Managing the Development of Large Software Systems by Dr. Winston Royce. Right after this figure, he says: “I believe in this concept, but the implementation described above is risky and invites failure.”

Then he goes through a bunch of fixes to the process and ends up with:

The process as described seems completely reasonable to me (see the original paper) . It features

  • Code review
  • Automated tests
  • DevOps manuals
  • The idea of a spike implementation to learn and de-risk the real one
  • Including Customers in the process (every circle icon in the figure)

So, even in 1970, it was known that waterfall could never work, and the term was only coined later to describe Royce’s first diagram, which he had immediately rejected.

I think waterfall only really existed as a concept to immediately reject and fix, not a serious suggestion for what to do for a large software project.

Green, Refactor, Red

I’ve been doing more TDD lately (which is why I’ve been watching TDD debates), and one thing that’s been good is to not do Red, Green, Refactor, but instead do Green, Refactor, Red and end the day on Red.

That way, when I start the day, I can warm up quickly by fixing that test and before I know it, I’m done.

I do end the PR on the Green though.

Confession: I Estimate Using Time

I know, I know. I’m supposed to be estimating using Fibonacci story points, and like Whose Line, the points don’t mean anything, but I have tried it, and I don’t get it.

For one, regular people just translate that to some notion of time anyway, and in that regard, I am very regular. If you are going to take some random number I provide and assign a date to it, I’d much rather I do the translation for you.

Also, I feel like a wrong point estimate is never acknowledged as wrong. It’s just that we didn’t do as many points this sprint as we thought we would. A time estimate is more checkable and less subjective. You can track it using normal means. When I work for two hours on something, that’s two hours. How many points did I just work?

If I say it takes 8 hours and after 4 hours, I say that there’s 6 hours left, I have good feedback on my estimate. If I say something takes 8 points and at the end of the day, I think I’m halfway done, was I right? I don’t think you can make any inferences about the correctness of point estimates without some kind of translation to time, and if you do that, then just use time.

If you love and use story points, that’s great. My only strongly held belief is that people should do what works for them. But, it’s not how I think of how long things take.

Write While True is a Prompt not a Companion

In March, I wrote this about the idea of a “companion” podcast that could be listened to while doing something (or learning something) related to what you were listening to:

This kind of podcast could not just be played in your regular playlists though—you need to be at your computer ready to listen. It could guide you in a vague way, so that you have to think in order to do the tasks, not just listen while you exercise.

At the time I was thinking about a programming podcast, and that somehow you listened while you were doing tasks it described.

But this ultimately turned into Write While True, which is a podcast that ends with a writing-related exercise that you do right after it’s over. So, not exactly what I thought it would be, but more of a prompt. I do believe in hacking your behavior via prompts, so this is good with me.