The Generational Divide in Software Developers

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 “ ”, and I turned around to make sure I had a clear path to the door because I was talking to a lunatic. Test-Driven Development It isn’t just that new methodologies have been introduced; . 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. wisdom has been lost I will come at this from many angles, but they are all spokes on a wheel whose hub is enabling . We used to call this , and it is in this condition that developers and others do their best work. uninterrupted concentration Flow Then and Now: Comparison Thirty Years Ago 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. Insulating developers from interruptions not writing unit tests, not team cohesion, not ceremonial meetings. The goal of software development was software development, Projects were planned and designed. . We had documents we were expected to read . 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. Learning was part of the job . 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. QA was other people Now . 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 meetings alone. Get back to your office, and your mind is numb, details are forgotten. Interruptions are constant recurring . 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. Methodologies add extra layers of work 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. The goal of software development is testing. . 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. Working alone is antisocial . The unit tests are the design. Uh, what?!? Kids don’t like to read. Design documents are constraining and obsolete Unchanged . Hardly anyone takes them seriously or does any analytical work. They are mostly formatting quibbles. And they are more important than ever. Code reviews are jokes . 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. Code is illegible 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 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. Waterfall We were . 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. silos . This is a slanderous and contemptible lie. It is an invention to sell more books for Kent Beck. . 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. We didn’t do testing Of course, we did testing . 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. Writing tests after coding doesn’t work . 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 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. Developers are their own testers blind spots, . No, it’s not. Social activity means communication, and communication is immiscible with concentration, which is the most important consideration in writing good code. Programming is fundamentally a social activity One way the latter misconception shows up most vividly is in attitudes toward the abhorrent practices of ; 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 him. Extreme Programming smell 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. . Instead of a morning “standup,” send a status email. Remove interruptions except maybe a solitary weekly meeting devoted mostly to dependency management. B depends on the completion of A’s work; A is behind. Eliminate recurring meetings Keep offices as used to be quiet as libraries ; since really they are little more than ceremonial meetings anyway, this is implicit. Dump the methodologies ; 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 within groups, not four or six, and Slack is not the right choice. Minimize process one modality for communications 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 . 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. Writing software used to be a joy It would be possible to , but it means letting go of a lot of bullshit. bring back that joy Here’s a way to start. Open up your work calendar. Select all meetings. Hit Delete. Check out our podcast on game development. https://www.youtube.com/watch?v=zgEokLt-Tlo