Brief (reductionist) notes on accelerating the pace of software development

These are some quick notes. Maybe they should have been a string of tweets, or maybe I should have waited until they were more fully formed before sharing… but I’m still trying to figure out the right kind of content for this medium.

There are two main levers when it comes to accelerating “software eating the world”.

  1. We can make it easier to build software

  2. We can make it easier to learn how to build software.

In other words, we can treat this as a software problem or a human problem.

Low-code/no-code tools and the wide body of dev tooling are attempts of the first variety: they provide new abstractions for software development. They make software easier to manipulate.

The second variety traditionally has looked a lot like coding education. How do we make it easier for people to learn new technologies? The answer has manifested as bootcamps, moocs, codecademy, pluralsight etc…. These approaches make us better at coding and even turn non-coders into coders.

But the “human problem”, if we can call it that, extends beyond the territory generally ascribed to education and stretches into a wilderness of communication problems. Such problems cover varying use cases from reading a new code base to composing/interpreting documentation to discussing architecture proposals. We’ve made very little progress on this class of problem.

Which brings me to an aphorism of sorts I frequently come back to: teaching is good communication and good communication is teaching. The challenge is the same: can you move knowledge from one person to another. When it comes to communicating technical knowledge, I think we are executing well beneath our potential and I think that has something to do with not recognizing technical communication as a kind of teaching problem.