As a former (reformed?) non-coding architect, non-coding architects are a scourge on the industry. I know you didn't say "non-coding" but if it's a separate job, they're very likely not spending enough time coding.
Seniors should be able to build large, interconnected systems. IMO that's a basic skillset required to reach that level, and part of why I roll my eyes when I see people with 5, 4, 3 years of experience claiming to be seniors.
People can claim to be seniors because the gates for getting that title are pretty permissive. But even if you had the conviction to re-evaluate yourself ("do I deserve to be a senior engineer?"), you'll find tons of opinions on what it means to be senior, what knowledge they should know, and what they should bring to the table before claiming that. It's difficult to build yourself a widely accepted roadmap.
You have to watch out for people being too exclusionary though, almost getting into no-true-scotsman territory.
For instance: you can be a valuable contributor to a large, interconnected system, explain each part of it, but maybe not have the skills to build it from scratch. I would call that senior, but I wouldn't say architecting it from scratch is a basic skillset of this position. My opinion is if you could build large systems from scratch for a company, I'd say you probably need a title and pay higher than senior.
If you did want to roll architecture into a senior job, I'd imagine the pay is higher than non-architecting seniors, but it's hard to quantify the architecture contribution to the salary's bottom-line. If you took the non-coding architect's salary and added it to the senior's most of us would be clearing like 300k.
Personally, I'm pessimistic around job duties because you'll find so many companies looking for do-everything one-man armies at lower-end wages.
Architecture and coding are two distinct skillsets. I know that most senior developers haven't touched a book about architecture for a long time if ever but still feel competent about such topics - falling in the "You don't know what you don't know" trap. This is as problematic as the architect with rusty coding skills or who hasn't worked as a professional developer beforehand. Coding should be a small part of the architect role but this role is usually reserved for very complex systems where the majority of your work isn't anymore about coding because there is enough to fill a full time job otherwise there is no need for an architect at your company.
Why are books important? Senior engineers should be seeing design documents and code reviews that involve architecture and design patterns all the time.
Sure, there's room for external learning, especially at companies where software isn't the primary focus, but almost none of the best software architects I know spend much of their time reading about architecture.
Speaking personally, I've learned more about architecture from reading code and system design interview prep materials than I ever did from any book. The closest I found to a useful book was the "architecure of open source applications" series which is essentially reading code with a senior eng to walk you through it.
I hear the "Why are books important" pretty often when guiding developers. All of the best architects i know of spend much time honing their skills. That won't happen if all you see is just the company you're working at. The worst architects i've worked with stopped learning outside of their job tasks. It's also a step to understand that design patterns and system design are all within the core competency of the senior developer and that the role of the architect has many other responsibilities.
While I'm sure that the best employees make their entire lives about work skills, I just can't imagine that being a fulfilling life personally. If i have to spend my nights reading books about work, outside of work, then I don't want to be the best. I have other hobbies I'm more interested in than, "becoming a better employee".
Now, I do feel different about academia though. I could understand doing fundamental research and dedicating most of your living hours to those problems. But i guess I just feel like the research mission is infinitely more valuable than the corporate one. I say this having never had the chance to really contribute anything meaningful to any company I've worked for, and never having worked for a company who's mission felt personally fulfilling to me.
I'm glad that there are people who work their butts off for work in important places but I just can't imagine doing that myself and not just disintegrating with regret when I turned 65.
> I just can't imagine that being a fulfilling life personally. If i have to spend my nights reading books about work, outside of work, then I don't want to be the best. I have other hobbies I'm more interested in than, "becoming a better employee".
I'm the guy who reads books about my career (not about my work) outside of work (in my free-time) and during working hours as well. I love my career (computer science) and I love reading well-known tech/cs books. I don't do it to be the "best employee". I couldn't care less about what I do at work (I, like 99% of the people here, work for a totally useless tech company that nobody would care about if it disappeared tomorrow). What I do at work is stupid distributed systems in Go + Kafka + postgres + k8s (totally uninteresting stuff, but pays very well though). I genuinely enjoy readings books from Stevens, Kerrisk, Kleppmann, etc., just like I enjoy reading sci-fi/drama/etc. novels. I usually end up learning stuff that's actually useful at work, and once in a while I apply such knowledge at work, but I do it only for the raises and promotions.
There are people out there who doesn't give a fuck about tech companies, but care deeply about tech.
I somewhat take issue with this. (3+ decades of very hands on (read: coding) architecting, including some learning experiences in orbit. I've been coding code-doodling since teenage years.)
A lot of what non-coding architects traditionally brought to the table has been taken over by experts designing OSS protocols, data formats, etc. Take things like data frames that are now exploding in ML space. Seniors today, agreed, should be able to integrate (sub)systems and that may in fact be enough. But a competent systems architect (who have never touched code) should be able to also define data formats, patterns of movement of data between sub-systems (for say optimal performance), the actual computing platform considerations, etc. Also, sometimes when being too close to code, things degenerate to debates about tools, etc.
Naturally my points here gain more validity as system size (or its open-ness requirements) increase.
I always thought that non-coding architects still had at least some background in coding. What does the path of a never-had-coded architect looks like?
Possibly effective doodling in the design space of systems? I personally hacked at untold number of experiments with different approaches, and was doodling like mad over at least a decade. I have bookshelves full of notebooks covered with object graphs, system sketches, etc. It's not just coding.
The nice thing about it is that it scales to whatever level you need it to. We've had junior candidates with no real Ops experience diagram synthesizers that they've created. Then we ask questions to gauge their level of understanding. We have a general idea of what it means to be at each of the clearly delineated levels on the team and we ask questions to what seems like the appropriate level. We've had candidates come in to interview for senior positions and during the interview the team drilled down to what we felt like were lead candidate levels and we offered the candidate a lead role instead of a senior.
We call out in the pre-interview handout exactly what we are going to do and what we expect and we let the candidates bring what they think is best. For senior, lead, and staff candidates we call out that bringing something that the team is familiar with as well, will be beneficial to the candidate and to the team.
It's really allowed us to do our best evaluation of candidates in a reasonable amount of time. We have two technical exercises and they take ~1 hour total. We may still be getting false negatives, but we're not getting false positives. Hire hard, manage easy, right?
