It seems like we’ve come full circle, doesn’t it? We published our first issue on hype. Now here’s an issue on books, blogs, podcasts, conference talks…this is the same thing, yes?
Yes.
Knowledge-sharing activities in the software industry have a financial model that follows a long-tail distribution. Almost every software podcast you listen to costs its presenters money in bandwidth fees. A few of them make revenue from advertising. Most of the software podcasts that exist, though, are the ones you don’t listen to, and probably haven’t even heard of.
Almost every software book you read took months of full-time effort to write (either in lieu of, or addition to, a “day job”) and made a small amount of money as an advance on sales. A few of them break into profitability. Most of the software books that exist, though, are the ones you haven’t read, and probably haven’t even heard of.
Almost every software conference talk you have seen was delivered for free, perhaps with some honorarium to cover expenses. A very few speakers break into the world of the paid keynote speaker, and a small fraction of those give the same talk often enough to amortise the preparation costs and make money from the talk. Most of the software talks that exist, though, are the ones you haven’t seen, and probably haven’t even heard of.
And of course those talks are given at conferences. Almost every software conference you have seen cost the organisers money, even where you were paying to attend. A few manage to break even, usually with sponsorship. A few of them break into profitability. Most of the software conferences that exist, though, are the ones you haven’t attended, and probably haven’t even heard of.
To recap, most of this activity, certainly the “at-scale” activity, pertaining to sharing knowledge and experience in the world of software development, comes at a cost to those who perform it. Presumably, then, the people involved have another reason for putting time and other resources into this work. Often, that’s promotion.
A consultant can give a prospective client a business card that says they can help with some business activity. It’s much more impressive to give that prospect a book about the topic, with the consultant’s name on the cover. Life gets even better if you don’t have to pursue the prospect at all, and they come to you after listening to your podcast or watching your talk at a conference.
What about salaried staff who write books, give talks, present podcasts? Some are hyping themselves, playing the long game of boosting their profile so that future opportunities, interviews, or promotions come easier. Others work for their marketing teams, hyping their employers, who are banking on a little evangelism going a long way in either promoting their product or their workplace. MongoDB famously had a successful sponsored “grass-roots” evangelist network long before they had a working database.
Much of the software world is written for money, so where we don’t see money we naturally look for economic externalities. With knowledge-sharing work, the externality is self-promotion.
No.
Helpfulness is also an externality. De Programmatica Ipsum exists because Adrian and I wanted it to exist. We wanted to read it. We wanted you to read it. You could not read it if nobody created it, so we created it. People write blogs because they found out things that were interesting, or would have been helpful to know. You read them because they are interesting, or it is helpful to know what was written. Plenty of people who write or speak do so because they want to help their community. In a way, this also defines and shapes the community. A blog written for mobile app testers defines its readers as mobile app testers, or people who are interested in mobile app testing. That’s more restrictive than, say, software testers. It’s less restrictive than, say, Flutter app testers. The blogger has defined the size of the group, and who is within or without that group.
Another externality is enjoyment. Some people enjoy writing, or podcasting, or preparing and giving conference talks, and do it despite the cost in the way that other people play music, cycle around town, or compete at football, without expecting to profit from it. Indeed, some combination of all four motivators we’ve identified so far – money, promotion, helpfuless, and enjoyment – with different “weights”, led to the creation of each talk you’ve watched, each book or article you’ve read, and each podcast episode to which you’ve listened.
Software Engineer, Disrupt Thyself
Knowledge sharing is, in a knowledge economy, unsurprisingly very useful. But, surprisingly, not particularly economical. As I have argued here, the activities that define our communities and through which we disseminate information are not ones that will make you money. A programmer can improve through training, education, study, and a connection to a community of practice and expertise. Many of the artifacts of training, education, study, and the community of practice are loss-making and very few are sustained through point-of-use payment.
The software craftsmanship movement claims to be “raising the bar” by “helping others to learn the craft”. Towards this end, their manifesto says that craftsmanship means valuing “a community of professionals” and “productive partnerships”. There is no evidence in the further reading for the manifesto that this idea of value includes any monetary definition. This is unsurprising: software professionals also make heavy use of free and open source software without contributing to its creators. If it’s hard to get software businesses to value software, how would we get them to value things that only indirectly become software?
Difficult though it may be, I believe it to be necessary. There are many dimensions along which software construction could improve: access, diversity, usability, quality, fairness, reliability; these are all areas in which we have industry-level problems. If we want industry-level solutions we must be able to pool our collective resources, and build sustainable ways of “uncovering better ways of developing software by doing it and helping others do it”. For it to be sustainable, it cannot just be the hobby of some interested individual or a sideshow a consultant uses to drum up business. There must be a way to fund the improvement of our industry.
There is plenty of innovation in the world of documentation tools. The OpenAPI initiative defines a specification for formatting web service documentation. IDEs like lighttable and project jupyter allow deeper integration between code and its documentation than before. Publishers have been on a journey from TeX through OpenDoc, LaTeX, and Markdown, making it easier for an author to type a book in to a computer. Much less has changed in the practice or perception of documentation, training, and knowledge sharing. People have misinterpreted “we have come to value working software over comprehensive documentation” to mean “we do not value documentation, or documenters, at all”.
Question-and-answer sites like project-specific forums, Stack Overflow and Quora give people a great opportunity to find the answer to the questions that are blocking them today. As with personal blogs and podcasts, the creators who answer questions on these sites do not get paid: indeed they are digital sharecroppers whose work makes money for the site owners.
Collectively, the (small-u) union of software professionals has come to rely more on these landlords and their q-and-a sites than on other forms of knowledge sharing. Unix command-line tools, Alexa skills, and IDE plugins all let us ask questions on Stack Overflow without disrupting the flow. It’s become so easy to solve the problem I have today that there is no need for me to level up so that I can have newer, higher level questions tomorrow. Where will the better ways of developing software come from if we all get accustomed to the idea that the existing ways will work, given enough time and enough upvotes?
A Solution?
At the outset of this article, I noted that the “content generation” side of the knowledge advancement industry is long-tailed. For every “Learning Python” there are a hundred “Teach Yourself C++ in 21 Days”, ten thousand “Get Started with Erlang and Kubernetes” and one million “Advanced Mathematical Computing in Postscript” titles. The reason is that the readership is the inverse of this: for everybody who wants to read an “Advanced Mathematical Computing in Postscript” book, there are one million who will read “Learning Python”.
Unsurprisingly, then, you can look to any publishing house (any that remains in business) to see how we might run an organisation dedicated to knowledge-sharing in the software industry. They have a business model that is tailored to the long tail. Think of the mass market publishers Penguin Random House, who missed a trick by not adopting the name “Randy Penguin” upon their merger. They publish Sir Terry Pratchett’s Discworld series and E. L. James’s Fifty Shades of Grey, and the money from those titles lets them take risks on publishing titles into the longer tails like esoteric literary fiction.
Or indeed a software-focussed publishing house like O’Reilly. Their “Learning React” book is much more likely to pay for itself than “Decentralized Applications”, but the fact is that “Learning React” probably paid for both.
So the long tail market model of a publishing company fits well the long-tail model of knowledge sharing (obviously: as nonfiction books are representations of knowledge). Our long-tail model is one of industry improvement. Plenty of people want to become programmers, software testers, sysadmins, penetration testers, SaaS marketers, or take on other roles in the software industry. Some fraction of those want to be better at those roles. Some fraction of those want to become experts at those roles. And some fraction of those want to transcend those roles, and redefine computing.
The publisher model also has its problems, otherwise books wouldn’t have appeared at the start of this article. Publishers seem to have high enough overheads that the (absolute) revenue going to creators in the long tail is tiny. The distribution is probably entirely equitable: all authors are offered an advance, followed by a percentage of revenue. But that means that no matter how important the topics in the long tail, creating for that market is not going to pay well. In academia, the model is even reversed, with authors being charged to publish their articles in Open Access journals, in return for the article being freely available to all. In that world, the authors can write their costs into their funding requests. The problem to be solved back in the software world is that there isn’t a magic pot of money for content creation.
The combination of a long tail (more novices than juniors than seniors than architects than…) and the increased influence of the individuals out in the tail leads to the conclusion that versioned pricing can address this problem. Beginner material can be cheap, because it will be sold in volume, and then you have the benefit that beginner material becomes accessible to those of lesser means. Expert material becomes expensive, which takes advantage of the fact that experts get paid more so can put more in, and provides for the fact that there are fewer people who can credibly share expert knowledge with experts, so their skills are rare and deserve recompense.
By the way, this money doesn’t need to come from individuals, their employers should be responsible for their development too. In many places I’ve worked, the stated budget for training has been much larger than the amount that’s actually spent by employees. So something you can do right now to improve your own career and the availability of high-quality knowledge-sharing resources is ask your employer how much they set aside for professional development, then go out and spend that money.
As it happens that question, and also the response to your attempts to use the money, are great for finding out to what extent your employer walks the walk when they say that they only hire the best. Someone, somewhere, must be hiring the mediocre and below-average developers, and it’s probably the people who turn out not to have a training budget.
Cover photo by Miguel Henriques on Unsplash.
