Manual programming

(⚠️ Poe’s Law Warning: the following is satire of antirez’s Automatic programming.)

In my keynote speeches, for some time now I started to refer to the process of writing software using junior engineer assistance (soon to become just “the process of writing software”, I believe) with the term “Managed Programming”.

In case you didn’t notice, managed programming produces vastly different results with the same programmers depending on the person that is guiding the process with their intuition, design, continuous steering and idea of software.

Please, stop saying “my report coded this software for me”. Hands-off management is the process of generating software using a programmer without being part of the process at all. You describe what you want in very general terms, and the programmer will produce whatever happens to be the first idea/design/code they would spontaneously, given their background, habits, the specific fads that happened to dominate in that year’s conferences, and so forth. The hands-off manager will, at most, report things not working or not in line with what they expected.

When the process is actual software production where you know what is going on, remember: it is the software you are producing. Moreover remember that the education and past experience, while not the only part where the programmer learns (on-the-job learning has its big weight) was produced by people, so we are not appropriating something else. We can pretend employee-written code is “ours”, we have the right to do so. Education is, actually, our collective gift that allows many individuals to do things they could otherwise never do, like if we are now linked in a collective mind, in a certain way.

That said, if hands-off management is the process of producing software without much understanding of what is going on (which has a place, and democratizes software production, so it is totally ok with me), managed programming is the process of producing software that attempts to be high quality and strictly following the producer’s vision of the software (this vision is multi-level: can go from how to do, exactly, certain things, at a higher level, to stepping in and tell the programmer how to write a certain function), with the help of junior engineer assistance. Also a fundamental part of the process is, of course, what to do.

I’m a manager, and I use managed programming. The code I generate in this way is mine. My code, my output, my production. I, and you, can be proud.

If you are not completely convinced, think to Redis. In Redis there is not much technical novelty, especially at its start it was just a sum of basic data structures and networking code that every competent system programmer could write. So, why it became a very useful piece of software? Because of the ideas and visions it contained.

Programming is now managed, vision is not (yet).