Raspberry Jam Gets Thin in the Pool: Condense Your Programming Methods
Gerald Weinberg’s classic book The Secrets of Consulting continues to provide me with the nuggets of wisdom needed to sustain a long career. I reread the book every few years to remind me of the sometimes counterintuitive recommendations made within. But each time I’ve ignored Weinberg’s advice, it’s been at my own peril.
The more experience I gain (in other words, the older I get), the more I recognize that much of the advice is universal, not just relegated to consultants. Somewhere along the way, I realized that the crux of consulting is helping people solve their problems, not solving problems for them — they’ll never let that happen. This has allowed me to expand the applicability of Weinberg’s wisdom to many other arenas, such as my now 30-year marriage.
Further, some of the “secrets” aptly describe truisms unrelated to problem solving. One such truism is Weinberg’s Law of Raspberry Jam: The more you spread it, the thinner it gets.
Weinberg’s law speaks to your impact as a consultant. You’ll be most effective one-on-one, helping individuals through their struggles. Your ability to truly reach people, however, diminishes when you grow your sphere of influence — perhaps to a team, an organization, a conference audience, or tens of thousands with articles and books. The trade-off: The income potential generally increases as the audience size increases.
I also believe the raspberry jam metaphor can apply in a different way when it comes to talking about our worldwide pool of software developers. We are growing without bound but being spread ever thinner. By next year, ComputerWorld projects there will be 26.4 million developers worldwide, in contrast to 18.2 million in 2013. That’s a 45 percent increase in six years; or more than a million new developers per year.
Thinning Out
The abundance of new programmers represents a growing mass of inexperience. Based on the ComputerWorld statistics, we’re at about 25 million developers today, meaning that 7 million developers joined the pool in the past five years. Put another way, about a quarter of all programmers today have five or fewer years of experience. The implication is that the thinness of our collective wisdom is negatively impacting the quality of software development.
On the upside, programmers are generally intelligent beasts, because the complex nature of the job demands it. Programmers translate vaguely stated and often complex business interests into software plans, then translate these plans into solutions by using very picky, logically demanding computer languages. They also navigate a continually changing and growing landscape of similarly fussy software development tools.
Keeping up with the tools and languages is hard enough. To survive as a JavaScript programmer also requires continually updating an extremely wide toolset.
Unfortunately, survival mentalities may be one factor for why we have so many problems with software. New programmers struggle just to keep up with the toolset, and as a result, there’s little time left to learn a host of other important things, such as how to:
- Best organize code for sustainability and impact
- Demonstrate that the code behaves as intended
- Express code in a manner that minimizes maintenance costs
- Manage and document a large and growing codebase
In this blog post, I’ll primarily focus on how to better support these lessons. I’ll limit my comment on the tools to this: We’re wasting time focusing on the wrong things. The typical developer stack is unnecessarily complex and cobbled together. Seek simpler tooling so you can spend more time on the things that matter in the long run.
Waning Education
As a trainer who has taught and programmed with many hundreds of programmers across dozens of organizations, I’ve noted that fewer and fewer programmers over the years are what I’d consider to be well-read. Topics we used to consider essential are now weakly understood. Out of a group of twenty, perhaps one or two programmers can carry a deep conversation on things like refactoring, simple design, design patterns, UML, use cases, test-driven development, SOLID or code smells. The rest of the twenty barely have awareness of these topics.
Is knowledge of some of these topics passé? Sure, many of the aforementioned topics have been hyped as cure-alls, but that doesn’t dismiss the value that’s come out of their exploration.
For example, design patterns were all the craze in the second half of the 1990s, but they faded from glory perhaps ten years later as we realized they didn’t solve all problems. Yet they’re still useful for helping solve many problems. Also, reading about design patterns can spare you from relearning the hard-earned education of those faced with similar challenges.
The Internet answers many questions, so perhaps book knowledge isn’t as important. However, awareness is important: If you aren’t aware that something can be done better, it’s going to take a lot longer for you to figure that out (if ever).
The lack of education is a tough problem to crack, particularly given that a low bar grants entry to the software development career track. We can hope developers understand that it’s their job to continually seek how to improve their lot in life, as well as that of others. Beyond that, others have proposed myriad schemes, from the formal and mandated to the casual and altruistic: certification, mentorships, study groups, brown bags and so on.
We Don’t Need Any Disciplines!
How do programmers learn to craft software? A small number are taught, and some read books, but most probably learn by example from their codebases and from the internet. Good examples exist, but bad examples are widespread. The internet is rife with great resources such as StackOverflow, YouTube, and dozens or hundreds of articles on any given topic. These resources are usually technically correct but often lacking in code quality. Programmers, the majority of whom don’t know any better (they’re jam, remember?), ingest the “copypasta” into their systems, then mold it into a shape that works for their circumstance.
In other words, we don’t teach programmers how to incrementally craft and grow code so that it’s easily understood and maintainable. We value technical prowess more than we value building code that makes our life easier. This is an unfortunate historical legacy, one that derived from decades of legitimate concern over building “tight” code that fits into a constrained computer space. Obsession with tightness lends itself to extremely challenging code.
Today, tight code is still important in most cases, but we have easy techniques of building code that is both efficient and comprehensible. There’s no excuse for building code that makes no sense.
How do we get there? While not a panacea, test-driven development (TDD) provides a control mechanism for incrementally building code of high quality. It accommodates design thinking and supports continual attention to code cleanliness. With proper education, practitioners can use TDD to apply key design concepts, shaping their system as they go.
A Team Approach
Another legacy of our short history is that we practice professional software development as chiefly an individual activity. For various reasons, programming has attracted a seemingly larger contingent of folks who prefer to work alone. Programming can be a solo sport — nothing stops you from building your own apps and selling them in the marketplace — but most of us build software as part of a larger team. Sadly, somehow the bulk of us ended up toiling away in a cubicle farm, a shout away from our teammates and an earshot away from a lot of distracting conversations.
Frankly, the amount of time we waste trying to figure things out on our own is appalling. I know, because I’m personally guilty, and I’ve noted that plenty of other developers tend to spin wheels for a good while before mustering up the courage to ask others for their expertise. Sometimes I’ve spent hours searching about, struggling with various attempts at figuring out a problem, when the answer was five minutes and ten paces away at my teammate’s desk.
Equally disappointing, when I work alone in my cube, I receive no feedback from others when my code stinks or doesn’t make sense. As a result, we create messy masses of code that dramatically and permanently increase our cost of maintaining a system over the long haul.
Software development is a team activity because it requires collaboration. Software development requires collaboration because software is composed of millions of bits that must interact properly with each other. As individual professional programmers, we’re pretty good at producing isolated clumps of bits that correctly solve pieces of the jigsaw puzzle, but we often have a hard time when it comes to attaching those pieces to one another. Small deviations in the interlocking mechanisms between software make it seem as if the pieces fit snugly together, but in reality, the big picture hides countless little holes or defects. We must learn to work closely to ensure that we’ve negotiated how our pieces interlock.
Collaborative team practices are an essential part of succeeding long-term with software development. Learn to work as a team using pairing, mobbing or some other interactive technique. Minimize work in process, and experiment with what happens when the number of currently worked items approaches one. Find ways to communicate regularly about the code and better design techniques.
As a largely solo developer in the 1980s, it took me weeks to ramp up on each system I was challenged with. Wisdom about design and technique was hard-won through the school of hard knocks and painstaking research via manuals and bulletin board systems. Some of our gurus made it worse by treating knowledge as a treasure to be hidden and protected, presumably to help them retain their status as high priests. Thankfully, we’re now a couple generations removed from this insular behavior.
Thickening Up the Jam
As jam gets cooked down and spreads apart in a growing pool, it can’t help but get diluted. Our best hope of thriving with that dilution — our continually decreasing average experience — is to stick together, like chunks of fruit in a compote that doesn’t spread so easily. We must learn how to learn from each other, and we must seek better ways of working.
