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.
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.
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.
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.
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.
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.
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.
I’ve been doing more TDD lately (which is why I’ve been watching TDDdebates), 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 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.
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.