Programming is Easy, Software Engineering is Hard

Over the years I've been programming and people ask me what I do for a living, I try to explain to them as best I can. Inevitably, they respond with something along the lines of "that sounds very hard and complicated". To someone without programming skills, this sure sounds hard. To me, performing open heart surgery sounds hard, but to a seasoned surgeon, I am sure it is like riding a bike. Sure, there may be challenges in the middle of these tasks that need to be addressed, but the training acquired should be enough to work through those challenges.

Anyone with the proper skills can:

These are varying degrees of difficulty based on skill level, but at the end of the day, programming by itself is largely an easy thing for most of us to do. We are good at it and we educated ourselves by learning new techniques, languages, and concepts to solve these complex problems. If left to our own devices, we all could build a very stable and successful solution. However, programming does not become stressful, frustrating, and downright hard until we factor in two more variables...time and other people.

"Software engineering is what happens to programming when you add time and other programmers." -Russ Cox on "What is Software Engineering?"

Russ hit the nail on the head when he was using this to explain the reason why Go needed module support, but this also holds true in the larger context of what we all do day in and day out.

I would like to amend that quote to be:

Software engineering is what happens to programming when you add time and other PEOPLE.

The people I am referring to here are managers, stakeholders, investors, SCRUM masters, sales people, marketing people, the list goes on. So now, we should circle back and address the solutions above. We can take into account the plethora of other people involved who impose time constraints on problems of which they do not have complete understanding. Not only are we no longer just programming, we are engineering software systems that need to fit neatly within an arbitrary box, that was not chosen by us even if we may be able to influence that box size. 9 times out 10, our influence over those constraints will not help if we are up against another agenda driven by time, other people, and money.

Can you create a websocket service to accept 1 million concurrent connections to broker messages to multiple internal services? I am sure you can, but now consider doing it within 3 weeks and having to sit in on 5 hours of meetings per week over those same 3 weeks.

Can you get a 50 node Kubernetes cluster up and running on bare metal? Sure, but how about you also do sprint planning and retro meetings every 2 weeks while also onboarding a new hire that joined your team?

What we do now is no longer focused on technical problems, which we know fully well how to solve, but now there are other non-deterministic and uncontrollable factors mixed into that task. Now things are stressful, frustrating, and downright hard. The daily juggling of context switching, meetings, cost/benefit analysis, personality differences, time constraints, priority changes, and anything not involved in programming is what makes what we do hard. The sooner everyone involved (not just programmers) understand this, the better off we all will be.