Why Software Engineers Make So Much

Getting Started

Software engineers get started on projects in two ways: starting one from scratch or continuing development on one. Both ways require those engineers to know the project's technologies. This is called the tech stack. Off the top of my head, engineers are required to know:

• the tech stack;
• the tech stack's dependencies (third-party software);
• what security risks are inherent with the tech stack and its dependencies;
• what platforms are supported (computer, phone, tablet, etc.);
• how to deploy/release the project (how is it released out into the wild)

Tech Stack

Let's say we're building a new application. We want to build a marketplace like Amazon.com (simplified though). We need a few things to start the project:

• A domain name (like simplezon.com)
• A cloud service (like Amazon Web Services aka AWS or Azure for back-end processing)
• A web framework that supports our needs (Express, Spring, Django, something else)
• A database (to store account details, stuff in people's cart, etc.)

Like I said, this is to start the project. I haven't mentioned how to make this project quick, secure, highly available, or nicely displayed to users. I haven't mentioned how to get this thing out into the wild so users can view simplezon.com and see the marketplace.

If you don't know much about building software and are building something from scratch, you might ask yourself these questions: So, where do we get the domain name? How do we sign up for a cloud service? Which one is best for the project? How do we connect the domain name to the cloud service? How do we download a web framework? How do we decide which web framework is best? Do we use a Java framework? Do we use a JavaScript framework? Do we use a Go framework? How do we develop it on our computers/laptops? How do we take what we've developed and push it to the cloud service so the cloud service can run it? How do we get the cloud service to run it? How does the database fit into all of this? How do we know which database is best? Do we use relational or non-relational?

The point I'm trying to emphasize here is there's a lot that goes into starting a software project. Questions, nuances, development, and maintenance add to the complexity of the project. Let's move on and see how dependencies play a role in all of this.

Dependencies

A lot of software is a combination of other pieces of software. They're combined together to make more useful packages or products. These products are used in bigger pieces of software (e.g., iPhone apps, Netflix, Amazon.com). Let's say we wanted to build a web server. It will receive HTTP requests and respond to those requests.

To simplify things, let's say we're going to use Express for our server. At the surface, we're only pulling in one piece of software: Express. Under the hood, we're pulling in more than just Express. We're pulling in its dependencies as well. That is, those other pieces of software that are combined to make Express, which is one whole product.

The point here is software engineers need to know how to use their main technology (Express in this case) while staying familiar with its dependencies. As of this writing, Express has 28 dependencies (see screenshot below). This means software engineers need some knowledge (working or familiarity) of 28 other technologies to quickly address security vulnerablities, compatibility issues, or any type of required patching.

Let's say a few months pass by and some security updates are needed for our server. Security updates could come in the form of updating one or more dependencies, or updating Express to a later version. Security updates to a single dependency sounds easy: you update the dependency and your Express server is good to go. In a perfect world, that's how a lot of software would work. However, updating a single dependency could break the server. This is because all code has to be compatible with one other to run smoothly. Pinpointing issues like this are side quests no software engineer loves to take on. At the end of the day, we just want to innovate and build really cool shit. The nuances of fixing software incompatibilities can be cumbersome and demoralizing. If there aren't any unit tests in place to future-proof the software, then there already two side quests: the side quest itself and the side quest of addressing tech debt.

As a software engineer, I know using AI speeds up our debugging processes, but we still have to validate and verify what it gives us. Sometimes it gives us the wrong solution a few times before it gives us one that works. Rarely, it will give us one that works that's written with best practices and in the style that fits the project we're working on.

So far we've covered the tech stack and dependencies. Cue Billy Mays: But wait, there's more. And it brings us back to the question.

Security

Every technology and dependency choice made when building software either reduces risk or introduces a security vulnerability. Security should never be an afterthought, so software engineers must build software on a foundation of security to prevent critical vulnerabilities from being baked in, minimizing the attack surface and avoiding costly fixes. This rule applies to the entire tech stack (dependencies included).

I don't think security needs further discussion. You either want your application secure, somewhat secure, or not secure; and the level of security you want/expect directly ties to what you're willing to pay.

Supported Platforms

To expand on the Express server above, let's say we want it accessible from desktops and laptops. Specifically, we want it accessible at simplezon.com because this is the framework that will power some of simplezon.com. Users should be able to visit simplezon.com in their browser and see a nice, responsive site. This requires front-end engineering skills.

I'd consider front-end engineering for large screens (desktop and laptop displays) a baseline skill for software engineers, ensuring apps are at least usable and accessible. Projects needing support across smaller screens (e.g., your iPhone 16, your friend's Pixel, your other friend's iPhone 17 Pro Max, etc.) demand advanced responsive design expertise to handle the varying device sizes effectively.

For each device a project should support...

I say usable and accessible above because they directly tie into WAVE, WCAG, Section 508, and more. I won't discuss these here, but keep these in mind because they apply to the above question. A fact about me: I'm partially color blind, so I have to keep colors and screen brightness/contrast top of mind if I don't directly work with a UI/UX designer.

Deploying/Releasing

Software has to be deployed and released somehow. In some cases, one team handles the deployment and another team handles the release. For enterprise projects, this could involve 50-125 people in an Agile Release Train (ART). If you require enterprise-grade talent, but can't hire 50-125 people, here's this again:

There are engineers who possess enterprise-grade talent and can match the output of 50-125 people in an ART. I've worked with engineers at Cisco who can do this (big ups to Derek, Rob, and Chris!). Also, my colleague and I did this for LUMA. Imagine finding a few full-stack engineers who can replicate an entire ART's capacity through top-tier automation and continuous delivery. Again:

Even without the enterprise-grade talent, the above question still applies. Software engineers need to know how to get projects deployed and released out into the wild. Without that knowledge, all of the development work beforehand is pointless.

The paragraphs below are a bit nerdy, so skip to the end if you don't care much about AWS Elastic Beanstalk, AWS Amplify, or IaC.

There is no single, correct way to deploy software. Reason is because there are so many variables at play that determine the deployment flow for a project. Taking the Express server above, we could see how it can be deployed using AWS Elastic Beanstalk or AWS Amplify. This assumes AWS is the best fit for the project.

AWS Elastic Beanstalk

Instructions for deploying an Express server to Elastic Beanstalk can be found on AWS' documentation pages. If you take a look through the documentation, you'll see there are some prerequisites before thinking about deployment:

• Node.js
• npm
• Elastic Beanstalk Command Line Interface

The documentation pages state "EB CLI" after it says "Elastic Beanstalk Command Line Interface" which assumes the reader isn't familiar with a CLI. If I see "CLI" in any documentation page, I already know to have my terminal open. You read further and it mentions commands like eb init, eb create, and eb open. You might ask yourself, "What in the fuggg does that even mean?" Experienced software engineers recognize these commands and know to use the --help flag for quick refreshers if needed and know where to go for more in-depth learning. Again...

Those CLI commands don't even cover most of the documentation, so the question above can be asked multiple times throughout the documentation. You read further and there's a .ebextensions directory mentioned. Specific configurations for your applications require creating .config files and storing them in your .ebextensions directory.

For example, if you're running into a performance issue with static images, you can follow these instructions to create a .config file to improve performance. These instructions mention setting up paths and there's a nuance here that could go overlooked: experienced software engineers know leading/trailing slashes in path concatenation can make or break your application.

Btw.. You might be reading this on your phone noticing text flowing outside of the yellow box above. This is called a text overflow bug. It's intentional and is one that requires front-end engineering skills to fix.

In general, path handling is such a nuanced issue that programming languages like C#, Java, JavaScript (Node.js, Deno), Python, and more have built-ins to ensure developers don't run into path handling issues (we just want to build really cool shit remember?).

We can discuss the complexities around Elastic Beanstalk for days, but let's move on to the next subject: AWS Amplify.

AWS Amplify

Just like Elastic Beanstalk, you can deploy an Express server to AWS using AWS Amplify. Detailed instructions are available on AWS' documentation pages. So now we have two options to deploy and release an Express server out into the wild. Which one do we go with? Which one is best suited for the job? Again, there are many variables at play just in thinking about a deployment and release cycle. Also, I lied about having two options. We could go with a more low-level DevOps option: IaC.

IaC

IaC is short for Infrastructure as Code. A popular IaC product is Terraform. It has its own configuration language and ecosystem. Big tech like Microsoft and Amazon have dedicated documentation pages on Terraform's site. Those pages go over how to use Terraform to deploy to Azure and AWS. Since we've been talking about AWS, you can see that Terraform has AWS tutorials published. On this same note, AWS has their own IaC product called AWS CloudFormation.

So... what option do you go with!? And...

Knowledge Doesn’t Stop There

Think about everything discussed thus far and really question how much that knowledge is worth. That knowledge doesn't stop there though. Software engineering isn't a "learn once, done forever" role. Technology and people are always changing and there's always a demand for ongoing adaptation.

Why do software engineers make so much? This.