Thinking Like A Software Engineer

Near the end of their two years with me, some of my students start to imagine themselves working in the software industry, but they’re not sure if that’s something they want to commit to. “What does a software engineer actually do? Is it just programming?”

As our codebases grow, so do the invisible systems that keep them running — data hierarchies that keep information organized, build and deployment tools that get our code onto the live production systems, the people responsible for them, and the processes they apply daily. Software engineering is the art of making complexity sustainable.

Thinking In Systems

What happens when we apply computational thinking and operations research to our own thinking and programming processes? We get the field of software engineering, which applies engineering principles to the design, development, testing, and maintenance of software systems.

A city planner thinks not just about individual buildings, but neighborhoods, districts, transportation networks, and utilities. A well-designed city allows for efficient movement of people and goods, while a poorly designed city leads to congestion and inefficiency. Similarly, a well-designed software system allows for efficient development, testing, and maintenance, while a poorly designed system leads to frustration as it grows in technical debt that will eventually need to be paid off with even more attention and effort.

As systems grow, structuring code isn’t enough; we must also structure how we think about code. Paradigms provide the lenses through which engineers reason about complex problems.

Thinking In Paradigms

Once code organization becomes second nature, new challenges emerge — different ways of structuring thought itself. Some think in math, some think in data, some think in objects. Yet others may prefer to write code that describes rather than code that prescribes. Some strictly require that every variable be declared with a type, while others prefer letting variable types be inferred automatically.

Code written in an unfamiliar paradigm can be a shock to the uninitiated: the language syntax may be the same, but why does this read like an alien-authored story? These different paradigms are like different lenses through which we can view and approach programming. Each paradigm has its own strengths and weaknesses, and may be more or less suitable for different kinds of problems. Through some of these paradigms, engineers create processes — version control, code reviews, automated testing — that synchronize team thinking and maintain reliability over time.

Conclusion

Software engineering isn’t just about building things; it’s about keeping them working as complexity grows. Building on computational thinking and abstractions from programming, software engineers scale these principles across teams and systems. Reliability emerges from their structured thinking, well-chosen paradigms, and disciplined processes.