Principal Software Engineer vs Architect | How to Differ Them?
There is no rulebook for job titles in the IT industry. We sometimes use them interchangeably, but it’s good to be specific, so let’s examine the differences in detail.
One thing is for sure:
Titles might not be the most important thing, but they can make a difference.
Our job titles define how others see us, they’re a big part of our first impression, and they convey what we do.
For managers in technological companies, it’s important to know who does what. Proper titles can even improve teamwork. It’s easier to ask for help when you’re aware of your teammates’ responsibilities.
One of the most mysterious titles is the Software Architect. How is this job different from software engineering? First we’ll look at the “soft” side of things, and we’ll get more technical in the second part.
The Mysterious Software Architect
In a (very tiny) nutshell, software engineering is more on the technical side, and software architecture is a bit more on the business side.
It’s important to bear in mind that in private companies and SMBs, these titles won’t always mean the same thing. The corporate environment is a bit more structured and requires detailed job titles, whereas smaller teams have a bit more leeway.
So in smaller companies you might find a Principal Software Architect whose job, in reality, is limited to Engineering.
Why limited? Because the Architect usually covers a wider range of responsibilities. To put it simply, in a normal team hierarchy, the head of engineering would be tasked with building a product that fits the senior architect’s vision.
From an education perspective, Software Engineers with college education know about software architecture. Realistically, then, these titles are interchangeable. At least to a certain degree.
When Engineers choose a job at a tech company, they can specialize in producing high-quality software, or planning and managing that production. This would lead to either a senior Engineer, or senior Architect title as they became more specialized and gained more experience.
Lots of people like building start-ups because it allows them to take on many roles at once. In the archetypical two-person start-up, there’s the business partner and the technology partner. The tech partner does the architecture, planning, engineering, testing, bug-fixing, from the backend to the frontend.
As the software project grows, the tech partner becomes the technological manager, and then – principal software engineer or architect. Whichever he prefers, and thinks describes his job best. In reality, and in accordance with the definition (which you’ll see in a bit), he was the architect from the start anyway.
Now, a different situation. Manager needs to gather a team for a big project with specific requirements, budget, and a deadline. Should she specifically look for a software architect?
Not necessarily! A senior software engineer with relevant experience would most likely be able to take on the role of the senior architect.
One of the crucial aspects of the Architect role is that sometimes the architect isn’t a programmer. Architects don’t always code.
But, as Anthony Langsworth (and many professional software developers) would argue, a good architect should be able to write code, because it:
- “Verifies the code written by developers matches the design and identifies deviations.
- Helps the architect learn about changes or new features. […]
- Allows the architect to write a proof of concepts or prototype. […]
- Provides another pair of capable hands during the project crunch periods.
- Makes the architect more forgiving of bugs because the architect has likely made similar mistakes in the past.”
Which brings us back to the fact that a senior software Architect on some teams can in fact be an Engineer, despite their title. Anybody who designs a product or a system can be called an Architect if the role isn’t clearly defined.
Titles can mean different things from project to project. On the technical side, however, things are a lot more clear.
Software Architecture and Engineering – technical side
Borrowing from Simon Brown, the job of a software architect is to:
“[…] figure out what the requirements are and design a system that satisfies them.”
To put it another way, architecture entails planning how to put together different software components so that the finished product will fulfill its purpose.
There is a clear deliverable – the required characteristics and features of the product combined into an applicable (buildable) model of working software. It doesn’t have to be a revolutionary system, as there are many different types of commonly used architecture patterns, like Serverless, Event-Driven, or based on Microservices.
After taking care of the model, the architect is responsible throughout the project for making sure that the product meets all the requirements of its architecture. That means not just making sure that the development team is doing everything right technically, but also supporting the team, and upholding the role of the leader in the production process.
The software development engineer’s job involves less dealing with people, and more dealing with code. As Samer Buna nicely put it:
“The act of engineering software is about designing, writing, testing, and maintaining computer programs with the purpose of solving problems for many users. It is about creating robust and safe solutions that will withstand the test of time and will work for some of the unknown problems around the original obvious ones.”
Sounds kind of similar to the architect role, doesn’t it? To understand the difference, it helps to see the architect as more of a high-level role, focused on the big picture. The software engineer is more focused on the nuts-and-bolts of the product.
The deliverables for the engineer are different. For example it’s clean, usable code, understandable and thorough documentation, and working features.
The engineer delivers the parts that make up the components of the product’s architecture.
If confused — ask about responsibilities and deliverables
In a real life project management situation, there is no time for ambiguity and confusion. My advice is: when in doubt, ask about responsibilities and deliverables.
If you’re not sure of what someone’s job title means, ask about what they’re responsibilities are, and what are the tangible results of their work.
This will help you bypass the title, and really understand if you’re talking to a software architect, a software engineer, or a different specialist altogether.