So what is software engineering?

Software engineering

Is the process of building and running technology to suit business needs. The software is often delivered in the form of a web application or an executable binary file which users run on the device of their choice. In return for producing software to suit the business needs, people often called software engineers (or developers) are typically compensated. They then leverage that compensation to do things like obtain shelter, nutrition, and try to be happy. Hooray for humanity.

At least, that was my impression coming into this career.

What I’ve come to appreciate over the years is that software engineering is a craft. Your output is software, but you will spend most of your time improving your mastery of tools, techniques, and their application in some business context.

Learn, build, test, learn

Software engineering is often mistaken for an innovative or creative process. It typically isn’t. There are innovative technologies and the people who create them were often inspired, but the vast majority of us simply aren’t doing that.

Instead, it is an iterative process. We take existing technologies, study their application and trade-offs, and build connectors between them to serve a business purpose. “Connectors” are usually computer programs written in a language which is usually pretty arbitrarily chosen.

Making technology choices and balancing trade-offs happens many times throughout a program’s life. Things once thought unimportant to the user may turn out to be very important. The tool may become very important and widely used and it may need to run faster. Or maybe more flexibly. Or on more data. Or maybe at once. So we iterate and improve the robustness of the software. Because software is so easy to distribute in this modern age, it’s easier to yield predictable quality by making incremental changes and solicit feedback from users than to extensively plan beforehand.

Side note -> Even many foundational technologies are built in a similar fashion, iteratively composing other existing technologies, specifications, or academic discoveries into workable specifications and code for all to enjoy:

Hooray for humanity.

Learn, build, fail, learn

Our competency as software engineers is not only dictated by our ability to parse business requirements and write code, but also how well we are able to cater to the psychology of our product’s users and deliver it in a robust way. Don’t get me wrong, those are business requirements, but often times they are overlooked.

Confusing and unreliable tools don’t typically last long. Even the reputation of unreliability can be fatal. It is important to continually improve our understanding of the user and evolve the software along with it. Delivering incrementally allows us the opportunity to minimize the penalty paid for missteps made as our understanding evolves.

Fortunately, there are countless resources, references, and communities devoted to improving our craft. And I guess I’m planning on writing future blogs to serve as a resource as well since I’ve been in the industry for ~6 years and feel like I’m already forgetting some of the lessons I’ve learned along the way.

Also…

There is a whole debate about software “engineers” vs software “developers”. You can find all sorts of definitions on the internet that involve hair splitting. My opinion is that the difference is semantic. There are plenty of other titles as well. I think the most convincing argument against engineer is that “engineer” has a protected meaning in some industries. I like that so I tend to say I’m a developer. But people will still use engineer or individual contributor or member of technical staff to refer to the same job and that’s fine. Hooray for humanity.