Older developers miss being able to focus; younger ones think focus is antisocial
I started writing software for pay in 1988. A year later, I was at Microsoft and that first year, around the end of 1991, was probably the best time of my career.
In 2008 at Microsoft, my sixth contract-based job there - my manager told me about this new thing called “Test-Driven Development”, and I turned around to make sure I had a clear path to the door because I was talking to a lunatic.
It isn’t just that new methodologies have been introduced; wisdom has been lost. The modern software industry is in thrall to practices that are impediments to good work and productivity, and there seems to be almost no recognition of this.
I will come at this from many angles, but they are all spokes on a wheel whose hub is enabling uninterrupted concentration. We used to call this Flow, and it is in this condition that developers and others do their best work.
Then and Now: Comparison
Thirty Years Ago
- Insulating developers from interruptions was management’s Prime Directive. Companies recognized and embraced the idea that we who were allowed to concentrate would do better work and more of it. I cannot emphasize this enough. This was the source of Microsoft’s long-lost greatness, and the abandonment of this recognition is the reason for the industry’s floundering in wasteful management fads.
- The goal of software development was software development, not writing unit tests, not team cohesion, not ceremonial meetings.
- Projects were planned and designed. We had documents we were expected to read.
- Learning was part of the job. Nobody was expected to come to a new position either as a blank slate or already having every single skill he might use. We were expected to acquire new skills quickly and on the fly, and we did not yet have Stack Overflow nor even Google to do this for us.
- QA was other people. Testers were experienced and had insights into testing code. I worked very closely with them and often spent almost as much time in my tester’s office as in my own. We had a good rapport and often kept the company out of the loop; he would find a bug, I would fix it, he’d verify, and we’d keep no records. Because often, my fix went live within the hour.
Now
- Interruptions are constant. A typical day has at least two regularly scheduled meetings, each of which breaks concentration for the day; these meetings are never canceled if there is nothing to talk about, nor do they let out early. A Microsoft developer told me recently that he spends about twenty hours a week in recurring meetings alone. Get back to your office, and your mind is numb, details are forgotten.
- Methodologies add extra layers of work. If a developer is working on a feature that will take months, he has to routinely rewrite his schedule because the project is artificially divided into two-week “sprints” with planning meetings, daily status meetings, and a paralytically wasteful retrospective at the end. For all intents and purposes, methodologies are nothing but meetings.
- The goal of software development is testing. Since people who are not allowed to concentrate write buggy code, testing is regarded as more important than coding. And since managers impose preposterous deadlines and schedules, developers are forced to cut corners, but they cut those corners in the code, not in the unit tests because testing is viewed as more important.
- Working alone is antisocial. Traditional developers who expect to stay focused are regarded as “not team players,” possibly mentally ill. Ideas like pair programming and mob programming go squarely against what worked so well in the past; communication and concentration are incompatible, yet concentration is deeply deprecated. And this is astonishing because the centrality of focus in good software development was core wisdom not all that long ago. Any developer who can concentrate will have it beaten out of him with constant interruptions.
- Design documents are constraining and obsolete. The unit tests are the design. Uh, what?!? Kids don’t like to read.
Unchanged
- Code reviews are jokes. Hardly anyone takes them seriously or does any analytical work. They are mostly formatting quibbles. And they are more important than ever.
- Code is illegible. Taking the trouble to make one’s code easy for others to read is regarded as effete, and still, there are many who go as far as they can in the other direction, coming up with bizarre reversals of the conventions of written language and saying with straight faces that they “find it to be more readable.” In thirty years, this has only gotten worse.
Misconceptions and Lies
Ask anyone under 35 or so about the early days of software development. You will hear a lot of lies, and nearly everyone will use exactly the same words.
- We followed the Waterfall methodology. Well, I never heard of waterfall except for advocates of “agile” or “scrum” who are detracting it. I think the idea was that we worked in stages, with one stage only beginning when the previous one was completely finished—something like that. I have no recollection of ever working at all like that.
- We were silos. Individual developers had huge responsibilities (true) which they did not share with anyone else (false). Instead of distributing projects between “teams” (sorry, that word makes me think of sports, we were “groups” back then), we gave developers full responsibility for important features, so if those developers left, the company lost that feature. This is a lot of crap.
- We didn’t do testing. This is a slanderous and contemptible lie. It is an invention to sell more books for Kent Beck. Of course, we did testing. Anyone who handed work over to QA only to have them find bugs in core functionality in a few minutes had egg on his face, and repeated work like that would get us fired.
- Writing tests after coding doesn’t work. This makes me glad that software “engineers” don’t design cars; if they did, we would be driving face-down and feet-first. Test-driven development is asinine in so many ways; even with the greatest rigor in design, we make discoveries once we start coding that we did not anticipate, and so pre-written tests must be constantly revisited.
- Developers are their own testers. Just … wow. I and everyone I have ever talked to about testing has had the same experience; we write a new feature, test the hell out of it, can’t find anything wrong; ask a coworker to take a crack at it, and he finds a major bug in under a minute. The password is blind spots, and we all have them. And if we didn’t think of some case in development, we are not going to think of it in testing. That’s why we had separate QA departments.
- Programming is fundamentally a social activity. No, it’s not. Social activity means communication, and communication is immiscible with concentration, which is the most important consideration in writing good code.
One way the latter misconception shows up most vividly is in attitudes toward the abhorrent practices of Extreme Programming; you will find very few who are indifferent to pair programming; most anyone who experienced the halcyon days of private offices and uninterrupted work regards pairing as a monstrous indignity while anyone else regards it as a potentially valuable collaborative tool. I have not worked onsite in over ten years but were I told to pair program, I would demand the order be rescinded, or I would resign on the spot. The one time I did it at Microsoft in January 2009, I resigned the next morning, and in a job market that was not very favorable. I found it to be ghastly, sitting closer to a coworker I detested than I lay next to my own spouse in bed. I could smell him.
What We Can Do
Not a lot of points are necessary here; I said at the beginning what was the most important way to do good work, and that is to go back to enabling concentration, prolonged and unbroken concentration.
How We Do That
It really could not be simpler: go back to what worked before.
-
Remove interruptions. Instead of a morning “standup,” send a status email.
-
Eliminate recurring meetings except maybe a solitary weekly meeting devoted mostly to dependency management. B depends on the completion of A’s work; A is behind.
- Keep offices as quiet as libraries used to be
- Dump the methodologies; since really they are little more than ceremonial meetings anyway, this is implicit.
- Minimize process; nobody needs to work with a dozen different pieces of third-party software nor with layers and layers of the procedure. For example, there should be one modality for communications within groups, not four or six, and Slack is not the right choice.
Some People Won’t Be Able To
My generation grew up reading books. We did not have Twitter. We did not have cell phones with games that we tapped at all day. We didn’t watch a few seconds of a TV show and then click a remote and watch a few seconds of another. We didn’t write “ur” for “you are” and we didn’t learn from short videos.
We could concentrate, and we did it a lot. I fear that for many younger people, these skills have not been developed, and they may be forever lost.
Conclusion
Writing software used to be a joy. We were at our desks late into the night because we loved our work, and we loved how we were treated, not because we were terrified of our next review or we had preposterous deadlines to meet.
It would be possible to bring back that joy, but it means letting go of a lot of bullshit.
Here’s a way to start. Open up your work calendar. Select all meetings. Hit Delete.
Check out our podcast on game development.