You have to know what to wish for

Summary

you have to know what to wish for Last month, someone high up at $dayjob said that we should treat any line of code written by hand as a failure. This hit me like a ton of bricks, to be honest. What does it mean to be a software engineer without writing code? Is this the end of software engineering? Let’s define terms. Programming is theory building, as Peter Naur remarked. The job of the programmer is to build and maintain a mental model of the problem space the system they develop is written against. There’s a feedback loop there in the small: the programmer writes a program to solve a problem, and learns more about the program and its environment when they run the program. Change, edit, crash, swear, learn, repeat. With luck, eventually the program does what the programmer intended. The programmer walks away changed from the experience. They know avenues not to explore, patterns to match on that let them skip steps, maybe something interesting about their tools. Writing the code changed their mental model of the program. This understanding, not the code, is the thing of value. The programmer could write documentation about the program, but their exact understanding at that moment cannot be captured in full. This is what Naur is talking about: the programmer has a theory of the system, developed in concert with that system. That theory is a mental model, a map of the system, problem space, and how it might react to changes in the future. Software Engineering is the act of building a socio-technical system that promulgates that theory to a group of people – “engineering is programming integrated over time” . This is to say, the goal of software engineering as an organizational capability is to model the problem domain and current solution, keep multiple people in alignment on that definition, and use that understanding to integrate changes from the business. Just as programmers anneal their theory of the system by changing programs to understand the effect of their...