July 3, 2020
In a couple of earlier posts, I pointed to some problems with the software development ecosystem, and the way these problems have prevented us from reaching the place I had hoped for thirty years ago. The sources of these problems are well beyond what we can address as individuals; what we can improve is what we produce individually.
At least six traits are required to be a good programmer:
Sitzfleisch is a German word that means the ability to sits still for as long as it takes to get the job done; literally, sitting meat. The equivalent in colloquial English is to say that a person has a cast-iron ass. Doing anything well requires a certain amount of sitzfleisch, and programming requires it to an unusual degree. Different frameworks and scenarios consume sitzfleisch in different ways. Web development requires beating through a thicket of uninteresting special cases; certain aspects of Java involve tedious boilerplate; assembler requires slow careful work. All of these take sitzfleisch.
Focus is a little different than sitzfleisch. It's the ability to internalize a mass of complicated relationships and hold it in your head so that you can express your ideas. The ability to focus is a double-edged sword. Too often people use their ability to focus as a way of compensating for lack in other areas – I certainly have; there's a glaring, and slightly embarassing, example on a page of this site. The result is code that works (sort of), but that no one ever wants to look at due to poor (or incorrect!) comments, global variables sprinkled liberally, oodles of special cases, strange data structures, etc. The list of possible offenses is almost endless. Things that seem clever during a period of intense focus often are not, even if they get the job done...for the time being.
Too many programmers confuse focus with good practice. The ability to focus, in itself, does not make you a good programmer. Just because you can focus and produce complicated code doesn't make you smart or even competent. More bluntly: such programmers are incompetent in the worst possible way since they won't admit they're using focus as a crutch, probably aren't even aware of it, and often think of themselves as geniuses.
Training and experience are the easiest things to observe objectively. With enough experience, prior training with particular tools becomes less relevant, although it depends on the job at hand. To work on NASA's flight control software, some knoweledge of physics seems necessary; if I don't even know calculus, then that job is out of reach. On the other hand, a person with 10 years of experience as an embedded systems programmer should be able to figure out how to use SQL pretty easily.
Intelligence and aptitude are the most intangible, and it's often possible to compensate by relying on other traits. Sitzfleisch and focus are the great equalizers, particularly when coupled with training and experience.
What about the elusive "10X engineer?" They exist, but being a 10X engineer is rarely a permanent state of affairs for an individual. The circumstances, personal and work-related, have to be right for a person with 10X potential to fully reach that potential. There can't be any draining distractions in his or her personal life, relationships at work need to be congenial and supportive, there can be no time-wasting requirements from management, and the problem being addressed needs to align with the person's interests. 10X engineers often have a vision regarding certain problems, bordering on obsession. When they're tasked with something outside their vision, or contrary to it, then 10X engineers can become worse than ordinary.
Obviously, we don't want to work as hard! This means different things for each of the six traits given above. Everyone wants an opportunity to exercise their intelligence and make use of their aptitudes. Ideally, there should be more of that. One hopes that less training and experience will be needed too – but let's not get greedy.
It's in the areas of sitzfleisch and focus that we want the world to change. Focusing means sinking into a world of thought, and that can be enjoyable for its own sake, but there's a difference between mentally juggling the possible interactions of a dozen global variables and special cases versus gaining insight into a problem or contemplating the perfect data structure. Coming up with an ideal data structure involves a great deal of aptitude, perhaps informed by experience, and that kind of focus is what programmers live for. Bad focus is like staring at the ceiling of the dentist's office to block out the fact that your tooth is being drilled; good focus is like contemplating the face of a loved one.
Ideally, avoiding bad focus is a choice. For some people bad focus is a habit that needs to be broken. For others, the need for bad focus is forced on them because they work with code produced by inexperienced or mismanaged programmers. In a case like this, the only choice may be to change jobs. If you can possibly quit such a job, then go for it. Don't waste your time and talents on junk.
Sitzfleisch will always be needed, but nobody wants to spend hours banging out boring stuff like a trained monkey. Most languages, environments and frameworks are pretty good at avoiding boilerplate and tedious housekeeping. Repetative work is where computers excel so that automating this stuff comes naturally. But the meaning of "boilerplate" has a gray area. The first time you implement something like Bresenham's line-drawing algorithm, it's rewarding and interesting; by the third time it's become an irritation.
This is a place where we can make a difference as individuals. Changing a broken culture at a particular workplace is difficult, and changing the system of rewards and the relative importance of various stakeholders in the broader software ecosystem is even harder. As individual programmers and teams, what we can do is choose to write software for the ages.
Some tasks don't rise to this level of attention, and the right thing to do is to bang something out and move on. And I'm not advocating a world in which easy problems require that we trundle out a huge clanking machine – we have plenty of situations like that already. Software must always get the job done, but that's not enough. "Software for the ages" is written with two additional goals in mind: first, and most importantly, the source code must facilitate understanding; second, it should be reusable.
The obvious thing that facilitates understanding is high-quality documentation, but what is "high-quality documentation?" In the 1980s, Donald Knuth came up with literate programming as a way to allow code and documentation to be written together, but it never really caught on. We need a new approach, that I call compelling programming. Whereas literate programming is defined by the use of certain tools, compelling programming is defined by the outcome and is agnostic about the tools. When source code is compelling, it will be used throughout the software ecosystem because it's so obviously the best and easist thing to do.
This is hardly a novel goal. Every programmer dreams of writing code that the world accepts as the best and most useful, and pretty much every open-source software project has this as an underlying motivation, even if it's unstated. Part of the reason this goal is difficult to reach is that it's hard work. But there must be more to it than that.