I’ve received a lot of feedback over the past couple of weeks regarding my last two blog posts. The overwhelming majority seem to really like them. There are some, however, that have raised some interesting questions. Questions that deserve a bit more exploration than a simple blog comment provides. For instance, some seem to be drawing a distinction between web developers and software engineers based on the ability to complete some sort of task. Whether someone is capable of implementing quicksort from memory or setting up a server on their own or implementing a neural network for predictive analysis shouldn’t be the measure of whether someone is a software engineer or not.

As I stated before, a software engineer is simply someone who writes code for a living. That’s it. How do you know if your primary job is actually writing code? It’s actually quite formulaic.

Software engineering functions

There are two primary functions of a software engineer: development and maintenance. Development is the fun part, the part where you get to create new things or augment existing things with new functionality. Development is the breath of a software engineer – it’s what we live for. There’s nothing more exciting than creating something new. And every software engineer wants to be doing this as much as possible. Unfortunately, that only lasts for so long.

The second function, maintenance, is what many software engineers dread. This is otherwise known as fixing bugs. When it follows development pretty closely, people generally don’t mind. But when you’re maintaining code somebody else wrote, especially if it was written a long time ago, this quickly turns into the part that many engineers hate. Everyone is always looking for a way to get back into development, even though maintenance is a nice mental break from the hurried development cycle.

Almost all software engineers begin their careers doing maintenance. It’s very common for interns or other junior engineers to simply start by fixing bugs. In fact, some companies do that with more experienced engineers, too. The reason behind this is because figuring out what’s wrong helps you to learn about the software as a whole. Debugging is an excellent way to get acclimated to a new code base. There is nothing as revealing as stepping through code that you’ve never seen before to figure out why something is happening.

Engineers move on to real development, creating something from scratch, when they’re good enough at the maintenance tasks that they know their way around the software.

Software engineering focus areas

All software engineers perform functions in one of two focus areas. The first focus area is components. Almost all software engineers start out working on components, which are just pieces of some larger system. You’ll work on a single piece of something within a specific framework so that you can get the job done easily. The majority of software engineers remain component-based for most of their careers.

The second focus area is systems. These are usually software engineers who started out working on components and became fascinated with how the larger framework and ecosystem worked. Understanding systems is a very different skill set from understanding components because you need to think about relationships. Components within the system have relationships with other components within that same system (and potentially with other systems). Dealing with systems is frequently called software architecture, and the practitioners are called architects.

While all software engineers will work on components at some point in their career, not all software engineers will work with systems. Understanding systems is a very different skillset than understanding components. It’s the difference between knowing how to recognize and replace a broken screw versus putting together an engine from its component parts. Without a high-level understanding of how the system works, there is no way to complete the task.

On any given team, you typically find the lead is the one who is working at a systems level while everyone else is working at component level. Software architects live almost completely in the realm of systems, something that the best architects struggle with because the component builders that have all the fun (read: get to actually code!).

What’s not important

Notice to this point I haven’t actually talked about programming languages at all. As I’ve stated before, the programming language that you use is inconsequential. Whether you’re working with C, Java, HTML, CSS, or JavaScript, your role will still fall into line with what I’ve discussed above. You will be a maintainer of the component or system or you’ll be a developer of a component or a system. The actual tools that you use for the job depend very much on the component and on the system.

Those who say that all software engineers should be able to implement quicksort from memory or be able to set up a server on their own are completely misguided. These are tasks based very much on the role that the engineer is filling, which in turn is based on the components and systems that she works with. It has absolutely nothing to do with whether she is a software engineer or not.

I also heard from some people that you shouldn’t be considered a software engineer and unless you had formal training in computer science. I disagree with this assessment. First and foremost, colleges and universities teach only the very basics. Perhaps with the exception of those in postgraduate or PhD programs, the things that you learn in a computer science program are not the things that you end up using on the job in your career. Further, there are a large number of skills that are very important for software engineers that are still not yet taught in colleges.

HTML, CSS, and JavaScript are rarely taught in college. NoSQL databases are never taught. Web application architecture is never taught. In my career, I’ve used very little of what I learned in my college computer science program. The skills for which I have been hired are things that I taught myself over the years. A lot of front-end engineers are in the exact same boat. Because the skills that we possess aren’t taught in school, we have to teach ourselves. That doesn’t make us any less software engineers than anyone else. It just makes us different.

Conclusion

Software engineers are those people who are paid to write code. The two main functions of the software engineer are maintenance and development, and both of those can take place within components or systems. The nature of those components and systems is what defines the type of software engineer one is. It doesn’t matter what sort of tools are programming languages you use, as long as you are fulfilling these roles and writing code, you are a software engineer.