I was recently asked, by two different groups, two seemingly different questions, but I gave them both the same answer: Collaboration, Complication, and Continuity. Let’s mull that situation over.
Folks, this is a hard time for a person with my views about society. There is so much going wrong, in so many directions. I turn to geekery, as I often do, to be a kind of comfort food, for me, and maybe for you.
Stay safe, tho. And stay strong. Stay angry, too. Stay kind.
I spoke at a user group recently, on their choice of topic. They, ever so gently, pointed out that I’m old as dirt and have been a geek for forty years. And their question was how has programming changed since the caveman days of the ’80s?
In another part of the forest, I gave a university lecture last month, and because I was the industry expert, one of the speaking prompts they gave me was, my words not theirs: "What’s the difference between the pro game and the college game in the sport of geekery?"
Maybe to you those two questions seem obviously "the same", but to me they seemed very different. After all, I didn’t start out in geekery as a college student, but as a (weak but enthusiastic) pro. I didn’t graduate from college, and in any case didn’t study programming there.
So I was surprised when my answer to the two questions turned out to be the same. The big differences, college-to-pro and ’80s-to-now, are the astonishing increase in the significance of collaboration, of complication, of continuity.
Collaboration: as geeks, our ability to work well with others has gone from being a nice-to-have to being absolutely central to our basket of "things a geek must do".
Even in college programs that use team projects — a practice I strongly encourage — the teams are usually just three or four people. And in 1980, my whole first company was exactly 4 people, and only two of us were programmers. That was my team for two years!
But nowadays, a working developer routinely collaborates with between a half-dozen and two-dozen other people on a more-or-less daily basis. I had a client team last month that has standups every day with 25 people in attendance.
(Full disclosure: that’s not 25 programmers, it’s 10 of them, but also includes stakeholders, a PO, an SM, UX experts, deployment experts, and so on. Many of them are there to listen 99% of the time. But still. 25 people!)
There are still pro teams out there that have only 1 or 2 people in them, but they are increasingly rare, and even where they exist they generally aren’t the only software team in the house.
(As an aside: as you sit with that, if your heart has room, think kindly about how hard that is for the people who didn’t get into this game thinking it was going to be about human relationships, who even now still don’t understand it’s about that.)
Complication: the software systems a working geek operates in and around are multiple orders of magnitude more complicated than anything we did in the ’80s, and anything college students work with as they learn.
My favorite illustration of this is watching a cute cat video on Youtube. Call a "piece of software" anything that was made at a separate time by a separate team in a separate place. Now ask people how many pieces are involved in that heartwarming 45-second video on their screen.
Many naive computer users will puzzle for a second, and say, "Idunno, 7 or 8?". People with a little better sense of how computers work might say 70 or 80, or even something over a hundred.
The actual answer is on the order of 7 or 8 thousand.
That’s an awful lot of moving parts. And it’s the everyday experience of every geek anywhere who operates in a web development environment. When you npm your little project, hell, that alone is liable to include over a thousand modules, and that’s just one subsystem in your app.
I’m as impatient as the next biblical prophet, & I get so mad at the software when it isn’t working. But you know what? It is not a wonder that software often fails. It is an astonishing feat of engineering that it ever doesn’t fail, and the truth is software very often works.
The software I wrote in the ’80s had usually only a dozen parts in it, and I owned and wrote half of them. College projects are a little heavier than that, but not so very much. Real apps in the real world for real money are staggeringly complicated beasts.
Continuity: Modern geekery works primarily with applications that continue to be actively developed long after their initial release, in some cases on timescales measured in years.
The projects I worked in the ’80s "finished". What I mean is, however long we worked on them, they eventually released, and once they released they were done. There might be a skeleton crew left around for bug-fixes, but the bulk of us moved on.
Similarly, the majority of collegiate projects are one-off’s. You write an app — probably under the significant time pressure you created by not actually working on it until the last minute — and your professors give you a grade, and you move on to the next project.
Divide development into "G" greenfield (never been done), "R" replacement (been done but we’re re-writing it), and "B" brownfield (it’s in the field and we’re changing it). The relative proportions of these G:R:B are vastly different, in college-to-pro and in 80’s-to-now.
If I had to guess, I’d say it was 7:2:1 in 1980. Today, it’s likely 2:3:5. Modern software doesn’t "finish", it continues. We release it and we change it and we release it, over and over again, at times it seems ad infinitum, and it often seems ad nauseum.
Again, to be sure, there are niches that are still "one and done". But they’re niches, now, they’re not the mainstream of software development. The majority of modern development isn’t "building" anymore, it’s "changing".
So collaboration, complication, continuity, what do these dramatic differences, between the ’80s and the present, between the college game and the pro game, what do they add up to?
Well. Answering that question, or trying to, is at the center of all my activity these days.
What is our trade still holding on to from those early days? What can we do to adjust those old models to account for the new reality? How can we help our juniors get junior-experience that’s closer to the pro game?
That’s my thing.
Supporting GeePaw
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. You can also subscribe to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.