The most useless knowledge of all

There are things a programmer needs to know,  no excuses. There are things you can’t possibly all remember, so it’s fine to look them up when needed. There is the business domain the software touches on that you need to know. And then there’s knowing how to grapple with quirks that come from not doing things in a standard way; the most useless knowledge of all.

Throughout history humans have developed skills and then invented tools to perfect the execution of those skills. A lathe can make cuts straighter than any skilled carpenter could make with a hand saw but it doesn’t replace the carpenter. Meanwhile other innovations have made entire professions obsolete through competing technologies. The centuries-old craft of typesetting has been effectively killed off by word processing and laser printers; not by a typesetting robot. Mind you that the difficulty of mastering a craft says little about its likelihood to be mechanised into oblivion: there’s still plenty of vacancies for human dishwashers.

When mastery of go, the ultimate game of strategy, is no longer the exclusive domain of the human brain it’s time for traditional knowledge workers to re-evaluate what knowledge and skills will keep their jobs safe in the long term. We think of knowledge primarily as information, as data that can be memorised, transferred, looked up and ultimately processed by a computer. We think of skills as uniquely human, as capabilities that can only be acquired by effort and over time, like translating poetry while keeping all the subtleties of the source language intact. If we accept this clear and intuitive difference between knowledge and skill then this would make a knowledge worker in the literal sense of the word more likely to be automated, not less.

Software developers will be okay for a while, but that doesn’t mean the value and necessity of knowledge in the sense of memorisable bits of data isn’t changing dramatically. Tools for static analysis can already capture hundreds of best practices and common coding no-no’s that a seasoned developer will know but can’t possibly apply religiously all of the time. However just as automated testing can only warn you about the presence of bugs and not their absence, likewise static analysis tools can’t tell you whether your code is correct. There’s knowing about design patterns, and there’s the skill and judgement to apply them properly.

I have written about valuable (soft) skills for developers and you can’t overstress their importance. Yet neither can you carry out your daily job without hard knowledge. A thorough and up to date understanding of one or two (but not five) modern programming languages and general design principles is essential. Added to that you will encounter in every software project three types of what I like to call ‘lesser’ types of knowledge. I consider them so not because they are less important to doing your job, but because they are less transferable, less durable and often useless outside the particular project.

First there’s knowledge of common tools, libraries and frameworks. These come in many competing flavours, often highly overlapping in functionality. Some of these tools offer important support functions that take a one-time effort to set up and little work afterwards (build automation, source control). Hence they don’t constitute a skill that everybody on the team should have expert knowledge of. Secondly, most of the knowledge gaps you encounter as you use these tools can be efficiently looked up. Nobody trudges through the entire documentation of Spring or Hibernate to learn about features you may never have occasion to use. You want to do X with tool Y given circumstances Z? That’s specific enough to google. Thirdly, subsequent major versions of frameworks (especially web frameworks) can be nothing short of a complete rewrite. With so many competitors there’s bound to be winners and losers. You’d die from frustration and exhaustion if you want to become a guru in every hip flavour of the month framework.

Domain-specific knowledge has nothing to do with software. Rather, it’s what you need to know of the world in which the software will run in order to make correct assumptions and not write code that is spotlessly clean while completely wrong. When working for the port of Rotterdam I had to know the basic administrative procedures involved when a seagoing vessel visits the port. For another client I had to learn about seeds, seedlings, cuttings and the seasonality of different plant species. You cannot work on accounting software without knowing the basics of accounting and – let’s face it – enjoy it at least a little bit. There’s a reason so many open source software are tools for other developers. They get to stay in a domain that you enjoy and that you’re intimately familiar with.
When large enterprises commission bespoke software they probably have a sufficiently unique way of doing things to justify the outlay. This means that when you move between projects in the same industry not all of the acquired knowledge can be transferred, which is a bit of a shame. Hibernate 4 is hibernate 4 wherever you go, but nautical law isn’t the same in Rotterdam, Portsmouth and Shanghai. This brings us to the third type.

There is knowledge that is not domain knowledge and you will search stackoverflow in vain. I’m talking about the pesky and undocumented quirks you must internalise to grapple with any sufficiently large code base and which come largely from doing things in non-standard ways. It’s knowing that something is the way it is while realising that it shouldn’t be. The best definition of usability is when things work as you expect them to work and no explanation is needed. A door shouldn’t need a manual . The less usable a system, the more quirks knowledge is involved. You know the signs. When it takes a day to set up a new development machine you know you’re in trouble.

Knowledge about Spring and Docker doesn’t have a long shelf life, but it’s perfectly transferable between projects. Domain knowledge isn’t, but at least it has better longevity and it can be fun and enriching after a fashion outside you job, if not practically useful. Knowledge about the quirks of in-house developed software has none of these benefits. It may be essential while you’re on the job but is utterly useless after you leave. It’s a waste of effort that throws up an avoidable hurdle for new team members and takes time away they could have spent in becoming a better programmer or mastering the business domain. You should avoid having to learn it in the first place.