Do software architects code?

Sidestep the critical path; be a force multiplier.

How much do software architects code? How much should they code? Consider the following if you want to collaborate better with architects or seek a role with architectural responsibilities.

Spotting architecture roles

Not all job descriptions have a title with "architect" in it.

Many job titles may fulfill an architecture role. "Software Architect" is the obvious one. Architecture roles with clear names include Enterprise Architect, Solutions Architect, and Application Architect. These roles differ slightly in responsibility – mainly at the abstraction level.

Principal Engineer and Distinguished Engineer are often, at least partially, architect roles. The more senior an engineering role, the more likely its responsibilities overlap with those of an architect.

How a Principal Engineer is an architect

A role labeled Principal Engineer will usually have the responsibilities of an architect. They can differ from one labeled Architect because they typically state requirements for more hands-on work. For example, it may indicate you will spend 20-30% of your time coding. A pure architect role will likely not require coding time in the job description. But, as we'll see later, it does not mean you should expect to avoid coding.

Different companies use different labels for their roles. I've seen roles such as "Senior Software Engineer" or "Staff Engineer" have the responsibilities of a software architect. 

The oneliner for each resume job position signals to interviewers your responsibilities at a particular job. For your career growth, resume titles should reflect the role's duties rather than just the job title. One way to do this is to put the job title and the role together in the description, for example: "Principal Software Engineer/Architect."

How much coding should an architect do?

While an architecture role might not require coding, continuing to code aids architects. An architect’s other responsibilities require an up-to-date understanding of the code developed by the team. 

For example, architects often review code. Code reviews are one of the ways an architect can mentor other engineers and promote best practices and standards. Architects are often called upon to debug problems or troubleshoot cross-cutting issues. These tasks can involve deep diving into the code to figure out a complex bug or performance bottleneck.

Proof of concept work is another opportunity for an architect to be involved with coding. Engineers create proofs of concept to understand a new technology or a new way of using it. This work may be delegated, especially if it's in an unfamiliar language or time constraints demand it. 

However, architects should do proof of concept work directly. It gives them a much greater understanding of how the technology works. Also, it provides a better insight into how other developers will work with it. Two responsibilities of an architect are improving code quality and enhancing the productivity of engineers. To do this, architects need to understand how developers use various technologies.

Architects who don't code

The exception to the coding rule may be Enterprise or Solution architects. These higher-level roles focus on system design: the infrastructure and interactions between components. High-level architects may not be involved in any aspects of programming, including non-coding tasks like setting best coding practices or doing code reviews.

Chief Architects and similar leadership architecture roles focus more on business and technical strategy than implementation details. Their time spent with programming is indirect.

Of course, there are exceptions to this as well. Early-stage startups or small companies may lean on high-level architect roles to do implementation work in the early phases. This early implementation allows these experienced engineers to set the stage and define a clear path for software development at the company. As the team scales up and the product matures, these engineers focus more on business and technical strategy and decouple from day-to-day programming.

Sidestep the critical path; be a force multiplier.

Whether spending 0% or 50% of their time coding, architects should avoid being on the critical path of implementation. The other responsibilities of an architect make it challenging to spend significant time doing feature implementation work on a predictable schedule. If feature delivery time is unpredictable, it will delay additional dependent work. 

Architects provide the most benefit performing higher-level responsibilities like research, mentoring, and strategy. If an employer leans too much on architects to implement features, they hamper a force-multiplying influence. Force multiplication increases the overall capabilities of the entire team and company.

Productive but singular efforts:

• Implementing a simple customer request

• Fixing a typical bug

• Designing a feature

• Reviewing code to get it out the door

• Churning on the backlog

Force multiplying efforts:

• Framework or library development

• Debugging a complex problem that is blocking other developers

• Mentoring others with their design or reviewing designs

• Reviewing code to teach

• Grooming the backlog

• Research and developing proofs of concept

• Defining best practices

• Improving performance

• Refactoring to illustrate best practices

Pro tip: You can multiply force even more if you do these tasks indirectly by pairing with others to do them. Those you pair will learn to be force multipliers themselves.

However, sometimes the most impactful thing an architect can do at the moment may be to get a critical feature out the door. Only sacrifice tomorrow's architecture for today's top priority if tomorrow depends on today's top priority.

Deceptive architecture roles

Avoid job descriptions that say you will be a crucial implementor with lots of coding and, at the same time, take on the responsibilities of architecture roles. Either they aren't architecture roles, or the employer has unrealistic expectations of people's time. Suppose the employer focuses on short-term feature delivery rather than process, strategy, or technical improvements. In that case, they are not interested in architecture. Architecture is a long game.

However, it can still be a good fit if they are up-front about expectations. Many startups are at a stage where they are unable to utilize an architect full-time. Still, they need someone thinking about architecture so they can scale up. A role like this may start with a lot of implementation work. The benefit is that an experienced engineer that can scale the architecture and team from zero does the implementation.

An architect can be valuable at early-stage startups if they can design a clean architecture in pragmatic steps that tradeoff correctness for immediate business value. But while doing so, they set up rails that make it easy for the other engineers to do the right thing and hard to do the wrong thing. It allows the company to avoid the many pitfalls that come with organic development with only the near future in sight. In short, this architect will be a force multiplier.

Coding is still key

As a software architect, it's essential to have a strong understanding of coding and how developers work with the code. It helps architects improve code quality and increase the team's productivity — they will be a force multiplier. However, the amount of hands-on coding they do depends on the specific role and the company. While some higher-level architects focus more on business strategy, it's still essential to have a solid grasp of coding to be an effective architect. Keep in mind that job titles may not accurately reflect an architecture role's responsibilities, so if you're considering a software architecture role, carefully review the duties and requirements.