I'm a Software Architect who made a progressive move to that role after being a Sr. Software Engineer for almost a decade. I see the distinction as pretty simple. We do the same things, but, we specialize in terms of time spent and breadth of awareness and contact in the business.

As far as skills go I expect to maintain my coding skills and as far as what I know more about than other SE's is not about skill as much as it is about practicality of time spent. We need the devs to be writing code/implementing every day and the architects spend more time on the, well, architecture as well as business interfacing and planning side.

So that's basically it, the difference is where we spend our time and focus. It's more about roles and needs of the group than about the skill set. At least, that's what I'd hope. Anyone thinking they are a Senior level engineer who can't understand the concepts of software architecture needs to rethink their position and maybe broaden their skill set a bit, imho.

Good Software Architects can make a huge positive impact over time. But, people often fail to live up to the role.

The most common issue in my experience is Software Architects who don’t spend ~10 to 25% of their time actually working with the code base are largely ignored. You get things like two layers that are both 100% 1:1 mappings of the layer below them.

It’s not about coding skills, but software is complex enough people quickly lose touch without regular feedback. Resulting in people spending a lot of time solving non problems.

I think "architect" is code for manager who is slightly technical enough to make high level decisions about a system.

You get layers that are 1 to 1 mappings from engineers? Gee only software architects have the innate ability to notice an issue like that. An isomorphic layer more than likely exists as a translation layer to make composition with another layer easier even though entities are bijective.

So you think an engineer is unable to comprehend anything about a layer that is basically an identity morphism in disguise? Wow. Please tell me about some other architect things that an engineer is unable to comprehend. I would like to learn more from great architects who have super powers like "big picture thinking"

To clarify, someone with a PHD and architect title came up with a system that had 8 layers server side. The actual programmers coded up two of them on top of each other as simple 1:1 mappings using objects with different prefixes, and a third layer on top of that which was usually 1:1, but occasionally not. They did plenty of other odd stuff like stored all values as a string rather than using any database data types on the off chance they would port or a different database.

Anyway, I worked for the same company and very occasionally helped some friends on the team, but was not really directly involved day to day or even most months.

A PHD does not make you an "architect." There's no formal design theory around "layers" "patterns" or "software architecture" so a person with a PHD does not have a definitive answer to good design or bad design. It is unlikely that anything he studied in school is relevant because such a science or theory doesn't even exist. His answer could be just as good or just as terrible as an engineer. Every architecture or pattern you here about is NOT theory OR Science, it is opinion and opinion only.

I don't have context on what those programmers did, nor do I know whether the 8 layer server side design was good. But I do know that how good a design is, is not influenced by a PHD or a software architect title.

That being said, an 8 layer design points to 8 things that want to be re-used. Typically you just need 3 layers (letters represent types, arrows represent a conversion process from one type to another.):

   IO input -> A
   A -> B
   B -> IO output

I have rarely seen a business case that necessitated 8 layers:

   IO input -> A
   A -> B
   B -> C
   C -> D
   D -> E
   E -> F
   F -> G
   G -> IO output

From my experience those 8 layers are probably garbage and unnecessary. You just need A -> G. You might break A -> G into several components but 8 is overkill.

Likely the architect and the software engineers both don't know what they are doing.

I'll go further to say that no architect will ever reason about "layers" the way I just did because my break down of the design layers above isn't some science. I made it all up, it's basically my opinion and most architects you meet will have either canned opinions from some book or have their own made up reasoning on how it all goes together. An engineer can easily come up with his own opinions and read an "architecture" book as well (which is again basically reading someones opinion). The "architect" title is a BS title that implies an "architect's" "opinions" are better than an engineers. It's not and from what I've seen in the industry an architect rarely has better design chops then an engineer. It's all relatively equal.

That being said there is some formal theory on network topology and graph theory that can say something definitive like this graph has faster output than another graph but rarely is it used or applicable in most web apps.

I was specifically using this guy as an example of someone with a job title that said “Architect” going through the motions that was terrible at his job.

I feel managers, directors, etc. who cannot code should not be managing, either.

You have two classes: management and individual contributors, when there shouldn’t be. Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.

This depends on the size and context of the organization. I'd argue that front-line managers should handle trivial, low-priority, low-glamour development, but not more than a small fraction of their time (say between 10% - 30%). If they're doing development work that is more sophisticated or requires more of their time, they aren't going to be able to do their more important job: managing. Managing, by the way, is more than just having 1:1s every week and filling in the budget spreadsheets--it's negotiating for priority, fighting for direct reports' career needs (e.g. fighting to get the team assigned the projects that ICs will be able to use in their performance reviews) and balancing that against the needs of the business, etc.

Mmm, what I was arguing for is that a manager ought to have sufficient experience that they can substitute for and work as any individual under them.

I understand that many large institutions are constructed in a mechanism you describe. In many cases, these managers are technical enough that they can substitute any individual working under them. There are also many cases where they are not sufficiently technical.

Nonetheless, if a manager’s purpose tailored towards prioritizing, fighting for projects, and assisting ICs career growth, I am not convinced that that manager is necessary as I am not seeing his value. Prioritization ought to be intrinsic for everyone and is more a collaborative choice, no? Why does a single individual (manager) decide priority?

Because direct collaboration scales as O(N^2) in terms of person-to-person interactions which becomes rather big as N grows. Having everyone spend 80 hours a week in meetings and still only understanding 1% of the business seems a silly use of time and rather inefficient in actually getting things done. Thus you get managers who are the ones in meeting with other managers which leads to a smaller N.

Understood. Apologies, I didn’t understand what was being prioritized previously. Previous replier clarified. Agree that otherwise this reduces to a handshake problem.

Prioritization is a collaboration in many parts: between members of a team including the manager, and between managers, their managers, etc.

Often ICs don't have the context necessary to contribute much to the conversation once it leaves the sphere of influence of the team they're on--and more importantly most of them don't want to acquire that context, often because they view it as inferior work that is beneath them. They don't see value in management because they can't see past their own egos and myopia.

Got it— prioritization of say features vs prioritization of tasks in the backlog, as an example. Management is necessary— I don’t think management’s function to a company can be discounted. I am advocating for certain traits I think a manager ought to possess, one of which being they have full ownership of everything happening under their umbrella. :-) Not saying they have to code, but saying if necessary they can be a substitute for anyone under them (given some minor startup cost).

The problem is that the world is not filled with superman. People who can code, lead, manage down, manage up, do product and so on are very rare. Ones who can do all those well are even rarer. By focusing on coding you get people, who to be blunt, can't manage or lead well. Which leads to more conflicts and issues than it fixes in my experience. Even if you find such people you get into the problem of them stepping on toes because they or others don't realize which hat they're wearing at a moment (ie: are they talking as an IC or as a manager).

Plus, at the end of the data, a good manager should aim to hire people smarter and better than them. If they can step in for those people quickly then they're not hiring better or smarter people which is a problem. A first line manager should understand what people do but that is different from being able to do their job to the same level.

"I feel managers, directors, etc. who cannot code should not be managing, either."

It works if they know they are out of touch and trust their people. On the other hand if they try to give input but haven't coded in 10 years it's bad,. Last year I had a fight with a manager who insisted that we use JSON for everything. I pointed out that this is a minor decision and really not very relevant. Another guy agreed and was almost kicked out of the project.

I'm in this situation now and it's not bad. It's really important for everyone to have a nothing-personal policy about being like "Hey, this is my area and not yours, let me take over." (And it goes both ways).

It does lead to a lot of "Black Triangle" [0] situations though. Where you spend a long time with no "real" actionable results to show management, and then after an annoyingly long amount of time present what looks like an insignificant joke to a non-programmer.

[0] https://rampantgames.com/blog/?p=7745

> I feel managers, directors, etc. who cannot code should not be managing, either.

Somewhere, in a different forum there is a bunch of managers discussing an article where a project has completely failed because some completely naive engineers made a bunch of rookie management mistakes, pissed off half their employees and crashed the whole project.

And they are busy saying "Engineers who don't know anything about management shouldn't be managing stuff..."

:-) I am not convinced engineers cannot be trained to also be great managers. A lot of managers were devs in the past choosing to take management roles to increase salary and forsake programming to satisfy rules implemented in their environment. Forsaking dev work is a mistake.

Management is not something complex. Almost all of management is expectations management.

Some directors may have dozens, if not hundreds or even thousands, of people under them directly or indirectly. This rapidly grows beyond the scale where the director can jump in for anyone in the tree beneath them.

Your comment probably applies for a team lead with a half dozen IC reports. Add in one other layer (i.e., a half dozen team lead reports) and it might still apply in some cases. But double that number or add in another layer and things are probably far beyond the scale you were imagining. The manager’s job now requires a vastly different toolset that most developers know nothing about, have no experience with, and generally wouldn’t even know how to think about.

You don't have to do it recursively, a director should be able to substitute his reports but not necessarily their reports.

Right. I wasn’t clear above. I do not mean recursive. For example, I don’t expect a CEO to do dev work: different skillset.

> Management ought to be able to solve any problem people they serve (i.e., their underlings) are facing, given certain amount of time to familiarize.

I disagree with that.

If your manager has the best technical skills of anyone on the team, then they are probably a poor manager who can't hire/retain good technical people (by far the most important job of a manager).

this is how it works in finance - but doesn't carry over into tech for some reason

What is the reason though? Was there some survey done that analyzes why this strategy is used (in large tech firms)? I am going to start looking into past research to see if any have delved into this question.

i think its because tech is seen as a trade (like plumbing) and not a profession (like finance).

Could not agree more about coding. These days I am doing more architecting and code reviews with coding as time permits and the less coding I do the less I’m able to stay ahead of pathologies developing in the codebase as the codebase scales. Right now I’m trying to get the engineers I lead to be more self sufficient on code reviews among themselves and self directed in terms of what to do next so I can spend enough time coding. It’s hard to do if the team is growing and the number of inbounds demanding your attention grows.

API and system design is usually technique agnostic - but I think the biggest reason to have someone designing the system close to those doing the work is both motivation and buy in. As people get more senior they tend to code less frequently, but that’s usually okay - a doc describing all aspects of a system is very much a coding exercise.

Some places call this a "Principal Developer." Believe it is largely the same thing, i.e. software/system designer.

In my time at $bigCorp, I saw the title “principal engineer” used to describe two positions simultaneously, and sometimes both in the same org;

- the good, hands-on, full-of-wisdom senior engineers, whose relevant experience and strong vision enable an entire floor of developers to build the right stuff and quickly. These guys made commits to high and low level code, from network debugging to interpreter design. Really inspiring people.

- The toxic “ideas guy” “architects” who believe it is their job to write white-papers on how everything should be, without providing any guidance on how to actually get there. They believe that all problems would be solved if only we had the right perspective, even though perspective can’t be executed on x86 architecture. These guys constantly made me wonder why they were there and what they did all day.

Sometimes the architecture is not designed by a single person. Sometimes it is a group. Sometimes it evolves from every-developer-does-it. Sometimes the role switches quickly from person to person. I don't know scientific studies to compare the approaches. Usually everbody just agrees that ideally one person should do it all.

It is usually easy to identify architectural decisions. You can then find out who made that decision and thus figure out who is the architect.

For example, in a web project: Who decided to build microservices vs a monolith? Who chose the database technology (PostgreSQL vs MySQL vs MongoDB vs ...)? Who chose the cloud platform? Who introduces external SaaS products? Who split up the big thing into pieces for different teams?

Your last sentence reminds me of https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

this was a great read thanks!

"They may even be the worst way."

I'm interested in whether you think this could be the case even when compared with say a development team designing the architecture as they go.