Coding vs. Software Engineering

2025-10-27

Welcome to the first post in a series of "What they don't teach you when you're getting a CS degree".

Software Engineering is more than Coding. You might think that the best professional Software Engineers code a ton, and some of them do, but many of them don't.

In Computer Science degrees at a university like mine, the name gives away that what you're learning is Science. How to write code to perform experiments, write papers, and complete assignments. Code being optimal might be about the order notation of the solution, or about implementing an algorithm without bugs, or adhering to some basic style rules like "no global variables".

In professional Software Engineering, the code is the record of the decisions made by the organization. It's the source of truth for what the computers do, yes, but mostly it's the result of tradeoffs made, priorities ordered, and alignment gained. In large software enterprises, the lowest-level employees actually type the code into the computer, but they don't make the big decisions about what code should be written and why.

For example, when I worked at NASA 10 years ago, the flight control software (which I didn't work on) was "written" by interns only. The permanent flight control software engineers wrote the "code" in flowcharts of excruciating detail that, when read aloud, sounded like "If this variable is greater than 10, set the value of this variable to 0.2". The "code" was "written" by interns, whose job it was to precisely translate the flowcharts into some more standard programming language that the computer could execute. Because it was critical flight software at NASA, I'm sure it was quintuple-checked to be correct.

This also explains why AI being powerful at coding hasn't replaced software engineers yet, as people keep discovering. Current usage of LLMs for coding makes micro-decisions about what code to write in what style, but larger decisions are provided by a human who sets up the context and the prompts. Note that I don't think this means that LLMs could never replace the non-coding parts of software engineering, but that they need to do more than just code to do so.

So what else do Software Engineers do besides code? I mentioned making decisions, but what decisions, and how are those made? Depending on the organization, project, and other context, it could be like:

  • "What do the users want to do?"
  • "What can we cut from this design to do it in two weeks instead of two months?"
  • "What's the abstraction that most cleanly balances the current requirements and possible future changes?"
  • "What isn't this design doc mentioning?"
  • "Who could we bring in to help speed up this urgent project?"
  • "What factors contributed to the incident we had in production?"
  • "How long will it take to implement this feature?"
  • "Are there race conditions in this code?"
  • "How sure are we that the code works as intended?"
  • "What are colleague X's strengths & weaknesses?"
  • "What's the simplest way to solve this problem?"
  • "What priorities do we really care about?"
  • "How should we break up this problem into smaller chunks?"
  • "How maintainable is this code? What tech debt do we take on by doing this implementation?"
  • etc