Developer, Engineer, Architect Oh My

Titles in the Software Programming Landscape

For obvious reasons, I have been thinking about what title to put on my resume. Since it has been almost ten years since I last looked at the programming job market I thought another look around made some sense. With over thirty years experience there are many titles that might apply to me. While trying to understand how each title is used I have come across a couple of articles that discuss the titles and in some cases argue why they are not necessary or helpful. I have found that the arguments offered are a
little myopic and decided I would add my insights from my time as a developer. But first here is a summary of the argument that I have found.

Definition of Terms

Software Programmer/Developer Someone who writes code in a programming language may be involved in design and testing as well. Usually a junior to a mid-level individual.

Software Engineer A person who designs writes and tests software. Typically mid to Senior level individual.

Software Architect Someone who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. Typically a Senior level individual.

Developer Rather Than Programmer

So let’s start with my use of the term developer rather than programmer. I prefer the term developer because my experience is that programming (the act of writing code) is a fairly small part of my job. Software development is about design, problem-solving and sleuthing root causes of defects. (I am open to a better word than sleuthing for the work of finding a defects root cause.) I was once asked if I wanted to be a coder for the rest of my life? This leads me to wonder about that term. I believe programmer is more like coder and I do not believe that any developer can last long as a coder. In fact, it is never your job to write code. Not sure you agree? Have you ever removed code? I know that I have had the experience of removing a great deal of code and considering the day a productive one. Have you ever spent a day on finding the root cause of a defect? Did you consider that a productive day? This is why KLOCs is not as good a metric as it sounds like it should be because it is not our job to write code, but to develop reliable functionality that is available to the user. If you can improve the functionality to the user by writing less code, then you are being productive. Therefore I call my self a developer.

Set Aside Your Experience

The articles that I have read about the lack of need for these distinctions often center around people who have been developing software for a while and find that they have no need for people to occupy these different roles. Essentially the argument goes, I have been developing software for a while now, I often work on the full stack (backend to front end). I make all the decisions (tools, platform, design, implementation), so there is no distinction between these roles. Still, that same person is likely also handling the project management, quality assurance, and quality control roles. Obviously, these are not the same as developer responsibilities. The mistake here is the idea that different roles require different people to fill them. If you are skilled enough and the project is small enough you will likely carry the whole show yourself. This means you are wearing many hats, not that the hats do not exist. The reason we talk about these different roles is to express both the responsibilities and the skills that are necessary for the roles. If you are covering the quality and development roles for your project, that is fine. If you are simply ignoring the quality role you can likely get away with it for a while, but eventually, this will bite you. Architecture is similar. You can code a solution to a problem (if it is straightforward enough), but as that code base is asked to change over time, eventually the lack of architecture will become costly. So you see the fact that you are filling each role does not take away the fact that there are separate roles.

A Presumed Progression

There is a progression implied in these definitions that I believe is false. It is implied that a developer eventually learns enough to be an engineer and then after more experience one becomes an architect. The issue I have with this is that these are different skill sets. The architect needs to think in terms of design goals, flexibility, and reliability. These are concerns for developers as well, but more tactical rather than strategic. Attention to the dependency inversion principle or interface segregation principle is not necessary for many developers. Meanwhile, developers must be focused on details and algorithms. Developers have to watch encapsulation, must understand the intention of various code segments. They have to dig into the details to understand why code is not behaving in the way expected by the user and ultimately if that is a bug or if the user misunderstands how the software is intended to work. These are clearly different focus at least. I propose that they are different skill sets altogether. So let us consider a new set of definitions.

Software Architect

A software architect is responsible for design of software at a component level. They are responsible for being careful with dependencies, understanding how data will flow through different parts of the software. They are responsible for creating a solution that not only achieves the desired functionality, but also will allow the flexibility to adapt to changes
in the future, which will come.

Software Developer

A software developer is responsible for design and implementation of software at a unit level. They are responsible for being careful with data and code implementation, coupling and encapsulation. They are responsible for understanding the performance implications of their decisions. Finally, they need to be able to identify and detect defects in the implementation, especially when changing the functionality of existing code.

The Difference is Focus

The job of Software Architect and Software Developer are similar but have a different focus. The Architect is typically working at a higher abstraction level. Often talking about sub-systems or modules and how they interact. The developer spends most of their time at the unit of code level. Very close to the details, not thinking so much about how the application as a whole is working.

You Can Do Both

Most people will be asked to fill both roles at some point in their career. Many people always assume both roles. Small teams, short deadlines mean that each team member must wear different hats, often simultaneously. So if you typically work on short projects with small teams then you likely act as both a developer and architect. If you work on longer projects, more functionality, typically larger teams then it is more likely that one (or more) people on your team will be assigned the role of an architect. Sometimes one person is assigned to each module, other times there will be one or two architects for the whole application. These people pay attention to the big picture to free the rest of the team to pay attention to the details. I have found that people tend to be better at one role or the other. Again this does not mean those good architects are bad developers, but it does mean that typically your best developers will not make good architects. This is another
reason to dismiss the false idea that there is a progression to these roles.

Software Engineer

According to the Institute of Electrical and Electronics Engineers, the definition of Software Engineer is “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.” This is sometimes referred to as formal methods. The things to take away from this is “systematic, disciplined and quantifiable approach”. Software Engineers apply known techniques and track metrics to know if they are working. Software Engineers plan, test and verify what they do. It is probably occurring to you that this is time-consuming and therefore expensive. On the other hand, they tend to get pretty good results. Aircraft control systems, satellites, planetary rovers, military system these types of systems not only benefit from engineering but require this level of discipline.

Why Not Engineer Everything?

The reality of the world that we live in is that cost matters. There are software projects that would never be started if they faced the cost structure of engineering. Many projects are accomplished with more ad hock approaches. This is not to say that these are “bad” pieces of software, but they do not require the level of rigor that engineering brings to the table. To look at it another way, we do not engineer cabinets, tables, chairs, etc. This is not to say that these things do not have value, but the value they have is sufficient to justify engineering costs. Also, they work just fine without engineering them. Carpentry is a craft, not engineering. There is more artistry than science in a great deal of software developing.

The Take-Away

Software development is a relatively new discipline, both in terms of engineering and craft. We are all still trying to figure this stuff out. So we should all keep an open mind. We should continue to be open to adjusting our methods and vocabulary. Fine tuning how we approach problems. Software development is going to move toward specialization just like other industries. It is already impossible to be “good” at all aspects of software development. Developer, DevOps, Architect, and Engineer are just a few of the many titles I believe we will end up using in this field.

What is a Practical Programmer?

A programmer, in this case, is someone who creates value by writing or modifying programming code. Thinking like a programmer starts with curiosity.  Wondering how things work.  Why they work that way?  Figuring out what makes them work that way and how you could change them to work a different way.  Thinking about software is thinking about systems.  This curiosity leads to investigating how things work and investigating how changing parts of the system changes the outcome.

Programmers are willing to put in the time to make things easy or automatic.  They are often frustrated by having to do repetitive tasks. They want things to “just work”. Beyond wanting it, they are willing to spend the time and effort to create the automation to make them work.

Programming is often a solo effort. Yes, programmers work in teams, but a great deal of what we do is done by ourselves in front of our computer. There is something called the zone.  This is when all the distractions (including other people) fade into the background and you just “see” the solutions to the problems you are working on. When this happens you get a lot done. You also do not want your manager or teammates coming by to ask questions. So some of the most productive time you have as a programmer is spent alone.

A Practical Programmer is someone who gets the job done.  Programming is full of distractions and interesting problems.  It is easy to research the algorithms and historical solutions that exist for hours, or days in some cases. One of the challenges for programmers is balancing the time spent researching to avoid reinventing the wheel with movement toward a solution that can be used.  We need to be open to what is out there, while still focusing on moving forward.

This blog will be a series of articles that cover thinking like a Practical Programmer.