21 years at Microsoft led me to have great disdain for "Software Architects".
5 years at Amazon led me to fall in love with the concept of a community of Principal Engineers. The Amazon Principle Engineering tenets are amazeballs.
Exemplary Practitioner - Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implementations. Only by being close to the details can we earn the respect needed to be effective technical leaders.
Technically Fearless - Our company's startup culture does not admit the luxury of conservatism. Principal Engineers tackle intrinsically hard problems, venturing beyond comfortable approaches when necessary. We acquire expertise as needed, pioneer new spaces, and inspire others as to what’s possible.
Balanced and Pragmatic - Principal Engineers are pragmatic problem solvers. We apply judgment and experience to balance trade-offs between competing interests. We simplify processes and technologies while advocating a long-term view.
Illuminate and Clarify - Principal Engineers bring clarity to complexity and demonstrate smart ways to simplify. We frame each problem in its customer and business context and boil it down to its essence. We probe assumptions, illuminate pitfalls, and foster shared understanding. We accelerate progress by driving crisp and timely decisions.
Flexible in Approach - Principal Engineers adapt our approach to meet the needs of the team, project, and product. We solicit differing views and are willing to change our minds as we learn more. We recognize there are often many viable solutions, and that sometimes the best solution is to solve a different problem, or to not solve the problem at all.
Respect What Came Before - Principal Engineers are grateful to our predecessors. We appreciate the value of working systems and the lessons they embody. We understand that many problems are not essentially new.
Learn, Educate, and Advocate - Principal Engineers are constantly learning. We seek technical knowledge and educate the entire organization about trends, technologies, and approaches. We combine vision and discretion to drive fruitful and even game-changing technology choices.
Have Resounding Impact - “Deliver Results” is a low bar for a Principal Engineer. Without seeking the spotlight, Principal Engineers make a lasting impact that echoes through the technology, the product, and the company. We amplify our impact by aligning teams toward coherent architectural strategies.
It's typical of engineering organisations to come up with this kind of list, the main reason being that as an industry we're uncomfortable with experience, seniority and progression. We're collectively suspicious of it. We want to codify and clarify it, endlessly. We demand the right to define it but when given the chance we always set the bar unrealistically high.
To recognise someone as a Principal Engineer, they should be definitively and objectively exceptional in every way, right? Their depth of knowledge in all technical areas is unmatched, they deliver innovation, domain knowledge, expert teaching and mentoring, strategic vision. They're growth hackers and also they design and deliver timeless systems and ever-green architectures. They're research scientists, and also inspiring leaders who (with no formal seniority) are able to align large groups of engineers via respect alone. How else can they be deserving? I wonder, does any other discipline in the org require this?
Whenever we come close to settling on a sensible way of recognising the value that experienced engineers (that are well connected to the domain and the business) can bring, it takes only a few years before that route is smashed by a new iconoclastic bunch of thought-leaders.
The parts of the org that are outside engineering now just let us get on with sabotaging ourselves.
> as an industry we're uncomfortable with experience, seniority and progression. We're collectively suspicious of it. We want to codify and clarify it, endlessly.
Are we wrong to? We've all had the experience of being held back by poor decisions from a senior person who simply didn't have the skill. I watched a 200-person company full of smart people single-handedly destroyed by a "software architect" who just made a lot of, frankly, stupid choices that all of the freshly-graduated engineers could see were stupid.
Frankly I've found the vast majority of "experienced engineers" aren't actually any better at their jobs than fresh grads. There should be very high, objective standards before we allow one person to overrule the rest of the organisation.
Bear in mind, an Amazon Principal Engineer is intended to be a 1 in 100 engineers position. The pay is generally above 600k, with the max pay dependent on the position.
In a field where the spread of outcomes is as wide as software, it seems reasonable that the right tail of practitioners would be very impressive.
In practice, no company requires their equivalent of principal engineer to hit 100.00% of the defined marks, but rather a comfortable majority of them with no glaring weaknesses.
Principal engineer roles should be filled on ability and impact not seniority/experience.
I'm not familiar with Amazon, but the equivalent level at FB (according to levels.fyi) represents just 1% of engineering. So this isn't only "experience, seniority and progression", it represents something really unique.
It's hard to look at a list like this and say "oh I know what to do now", but it is useful as a rubric; is this person meeting most of the criteria? Just a few?
Principal at Amazon is the first level above senior software engineer, so closer to staff than principal at Google/Facebook. It isn't a particularly uncommon level to reach at Facebook or Google.
It's corporate mythos. Something that worked for someone long long ago was so successful that it became the corporate form of a folk song.
When we down near the bottom hear "lead by example", it's facile to find the nearly useless obvious veneer to it, but if we could attach the original odyssey that led that engineer to tell their story ... we might agree with the lesson. But retellings upon retellings compress, simplify and gloss the original story into a cliche.
Each thing in this list sounds obvious, but if one can picture the opposite of the advice to be false, that reflection might actually lead an individual to growth.
Principal engineers are expected to give talks about their experience, which are heavily attended in person and widely shared.
It’s not perfect, but it’s less abstract when one or two concepts at a time, they explain why those truism through their personal experience.
“Earn Trust” is a truism — but being able to search for talks by the keyword “earn trust” where a high level engineer discusses different situations from their career and how they handled them is useful.
Can you think of more concrete language that applies equally to all organizations? If so please do share.
Sure, there are the Dilbert PHB-esque abuses of trendy lingo through mindless cargo culting. But the bigger and broader your goals, the more abstractly you have to describe them lest you end up writing a full-on textbook.
Having said that, I have to disagree that your examples are buzzwords. Buzzwords are usually contextless, like saying "synergistic impact" without any hint of what that means.
As just one example, "Probe assumptions" is not a buzzword. It has a clear meaning within the context of software engineering. For example it is often assumed by new grads starting a company that a startup just has to use Kubernetes and microservices. But that is an assumption that is worth probing. Horizontal scaling only becomes a bottleneck long after the millions of users point. Microservices are meant to help giant engineering teams isolate the things different teams work on, but in a startup with only one team you don't have that bureaucratic overhead in your org, so you probably don't need it in your code.
> Microservices are meant to help giant engineering teams isolate the things different teams work on, but in a startup with only one team you don't have that bureaucratic overhead in your org, so you probably don't need it in your code.
We had these discussions many times on our team. Everyone understands that there are tradeoffs and "pitfalls" associated with any decision. Isn't this just normal rational thinking? Is your assumption that ppl that aren't principals don't consider pitfalls. Do non-principals employees really think that there are no pitfalls to using microservices.
> Everyone understands that there are tradeoffs and "pitfalls" associated with any decision.
I haven't seen this to be true. Especially as companies get larger.
Sometimes it's because they really believe option A is better in every dimension than option B. (But often are mistaken.)
Sometimes it's because option A means their team has more work and can hire more people.
Sometimes it's because they understand their own ideas really well but aren't understanding other people's arguments.
Sometimes it's because they just don't respect the other people in the room.
But assuming that everyone is going to rationally jump initially to the thing that's best for the long-term health of the organization isn't something I've been able to count on.
I've seen many engineers reach for a microservice architecture by default.
Why? Because they read HN, reddit and lots of blog posts, and thought that's how you do things now if you start from scratch, no legacy architecture to consider.
Not everyone thinks this way, but it's a frighteningly common thing.
Is your assumption that ppl that aren't principals don't consider pitfalls.
No such assumption on my part. But it might be safe to assume that the better you are at questioning assumptions, avoiding pitfalls, and thinking of the big picture (think breadth-first vs depth-first traversal of the problem space), the more likely you are to advance to higher levels of responsibility.
Another example. Suppose you are adding a new field to your payment processing system. You have considered engineering pitfalls. How will that change affect other teams? What about other departments? Will Accounts Receivable suddenly have a 10x workload of invoices to chase because that field change wasn't considered in their workflow in all cases?
There's nothing magical about what senior vs staff vs principal vs whatever engineers do, it's the same skills amplified and applied to the benefit of many people across an org, rather than limited in scope and awareness to a single project.
My experience is that people rationalize what they want. If they want microservices then you're going to get microservices.
It's not all nefarious, I think if many of them truly _UNDERSTOOD_ the difficulties of microservices it would give them pause (there's a difference between knowing and understanding), but they want what they want, they're optimistic, and they tend to back into the reasoning afterwards.
There was one key entry there, actually coding. Non-coding architects are rife with the possibility (but not certainty) of being too disconnected from the reality of the systems they are working on.
These seem like totally different roles. And the hours I've spent staring at the AWS console trying to figure whether I need "Elastic Beanball3" says to me that Amazon could use maybe just a little architecture. But I'm sure the Beanball Principal Engineer is quite proud of their resounding impact.
The console is a UX/UI issue, not a "architectural" one. Most "architects" nowadays are just mere users of what was built by the engineers and principal engineers of amazon.
AWS services don't mesh nice with each other, and the reason "software architecture" exists in the first place is so that disparate teams and technologies play nice with each other.
The disparity within AWS is the result of common inevitability that arises with managing technology built on over a decade of scaffolding. For sure there is a central planner within the company trying his best to put everything together into a cohesive whole. Technical debt is the most common name for this issue.
An "Architect" can't solve this problem anymore than an "Engineer" can fix the problem of technical debt because neither person can see the future. It's like pointing at everything wrong with a piece of technology and saying an "Architect" could've fixed that in hindsight.
"Architects" are not the solution to technical design and technical debt.
An engineering manager can place all engineers in a room and ask them to come up with an "architecture" that is the same if not better than anything a single "Architect" can come up with, and this "Architecture" will never solve the problem of technical debt for the same reason why we can't predict stock prices.
But you can. The separation is critical to the entire computing industry. The entire reason why higher level programming languages exist is to separate the form (assembly) from function.
Usually there are "costs" to doing this and much engineering work is done to reduce this cost as much as possible. Either way, what you say is categorically wrong. Separating form and function is not a "mistake" given that it is so fundamental to the entire industry.
Ah, but I would argue those are better described as form and function being part of the designs. Done wholistic, it is why the new apple hardware is able to take some very impressive gains.
You can argue that some interfaces are separate products from the services. I agree with that. But each has its design and each is targeted on form and function to something.
That is, you don't separate them. You make a new product, that has its own form and function.
UI can only show stuff in different place, with different colors and fonts, but it won't solve the problem. Explaining architectural purpose of a tool is an architectural job, neither UI designer nor salesman can do it, especially salesman.
There’s a concept in CS called an abstraction layer and the UI can literally change the thing underneath. I can create a UI with one button that when you press the button it triggers 50 actions to happen. It is not just about moving fonts and colors. This the exact same thing that a programming language does. A programming language abstracts away assembly language by having one programming expression execute several assembly commands. This is the job of abstraction layers and also the job of UI/UX.
Second explaining architecture is not solely an architectural job. It’s mainly the job of the person who writes documentation. The “architects” job is pretending he knows some “theory” of architecture more then the engineers actually coding the “architecture” when no such “theory” even exists.
Then architect should tell the purpose of the tool to the documentation writer, otherwise the documentation will read "press Ok button to install %toolname%" that tells nothing how to decide what the tool is and does and whether the user needs this tool. That's the problem at hand.
Agreed. Only Software Architects have the special ability of naming things. Engineers and managers don't have this special knowledge.
When I went to Standford to get my PhD is Software Architecture I was required to take at least 2 semesters of classes on the theory of naming things in software. The biggest point the class made was proving mathematically how one should never name anything after a plant, Greek/Roman god, gemstone, animal or molecular structure.
I hate with a passion services that have cute clever names. It makes it impossible guess what they do. It makes it easy to overload the service with things that don’t belong.... if the service was named “OrderService”, if somebody wanted to add a “spell check” endpoint people would start asking questions if that service was the right place. But since the service was named “CaptainCrunch”, who knows if spell check belongs...
Same goes for team names too... clever team names are obfuscation.
Naw. The term "mere" was to de-emphasize the importance of the term "architect" which doesn't apply to other AWS services.
The parent poster declared that AWS needed some "architects" which I think is kind of arrogant given the fact that most "architects" don't even have the ability to engineer the tools built by AWS. They are just "mere" users of the tools.
After many years at big tech companies, I am now working at my first that has "Architect" as a separate role. While many of my colleagues in that role are great people and very smart, after a few years of living with it, I strongly believe that it's an "org smell" and I will seek out companies without it in the future. It creates completely the wrong dynamic to have the hands-on engineers, no matter their seniority, not be fully empowered and expected to make these decisions. And no matter how experienced and smart the architects are, if they aren't working hands-on with the systems and code on a regular basis, they can't make the best decisions. Software architecture as a separate job from software engineer is bad for everyone involved.
It gets worse. The transition from "programmer" to "architect" results after a few years with the architect losing track of where the rubber meets the road. This results in worse architecture decisions that are made by a similarly experienced programmer.
This effect is so strong that if you're interviewing someone who became an architect, make them write code in the interview. If they don't do it really well, you don't want them in ANY role. Because now they can't program, they can't architect. All that they can do is sound smart while they make bad decisions.
I've worked with architects whose job was the result of taking courses in software architectry at college and then they took a job as one. Apparently there are organizations looking for these people.
"make them write code in the interview... Because now they can't program"
This comes across disrespectful and presumptious.
Firstly, do you believe that if you have not coded for 4-5 years you become useless just becauss you don't know the latest %fad% framework?
Secondly, the whole phrasing just conveys disrespect for cadidate, where the only responce to 'jump' is 'how high'.
If someone is interviewing for non-code postition they might tell you to take a hike.
The idea that a contrived 30 minute coding session tells you more about a candidate that studying code they've previously written or debugging together doesn't make awnce and is not supported by evidence
We don't ask surgeons: "since you can do heart surgery in 8 hours, surely you can reattach a toenail in 10 minutes during an interview"
I interviewed a very senior architect astronaut who literally couldn’t write code to compute the average of a list of numbers.
Wasn’t that they got hung up on the details of whether the average of ints should be an int, float, or double, or how to handle overflow, but just couldn’t get started at all.
After that, I stopped shying away from wanting to see code from even senior technical candidates.
(It was not a standard question for senior roles; I got a strong whiff of “this guy might be entirely full of it; let’s have a look-see”.)
i am very senior architect astronaut.
it will take me some effort to computer the average of a list of numbers in c/c++ as i didn't touch those languages in many years.
from the other side, while reviewing designs (not code) of various components I can spot locations where code handles sockets incorrectly or a couple of dozen of scenarios that system will fall apart under because engineers don't think that far.
value that I bring is not in averaging list of numbers. my value is 25 years of making mistakes, learning from them and knowing how to avoid them.
This "average of a list" is a red herring, because in practice one gets some variation of dynamic programming, trees, graphs, etc.
And for these kinds of more complex algorithms problems I would not expect most architects to be able to solve them, since they're utterly irrelevant for their jobs. Heck, a huge amount of software developers can't solve them and bitterly (and at least partly legitimately) complain about them to whoever will listen.
"make them write code in the interview... Because now they can't program"This comes across disrespectful and presumptious.
It is the interviewer's job to check the possible reasons to not hire someone and validate that the they aren't going to be problems. One of the possible reasons to not hire someone whose last job was "architect" is that they have lost contact with coding. If they have, then from experience I can tell you that they won't want to go back to coding, and their architectures are losing contact with reality. They are a liability.
This observation is not original to me. The first time that I saw it made explicit was when I took interviewing training while I was at Google. Google's experience is that a certain fraction of architects avoid coding. That fraction makes really bad hires. So they explicitly told people to look for that in the interview so that don't wind up accidentally hiring them.
But if someone's title is "architect" and they can code, then that isn't a concern. Companies do tend to promote good programmers to architect, and you don't want to miss out on those programmers.
Firstly, do you believe that if you have not coded for 4-5 years you become useless just becauss you don't know the latest %fad% framework?
This is a straw man argument. I said nothing about "latest fad framework". The exercise is to write some code, not write code in any particular framework or language. Go ahead and be offended at something that I didn't say, but please remember that I didn't say it.
Secondly, the whole phrasing just conveys disrespect for cadidate, where the only responce to 'jump' is 'how high'.
If an interviewee objects to writing code in the interview, how are they going to respond when they're asked to write code on the job? Seriously, if they get offended in the way that you just did, that's a good reason not to hire.
If someone is interviewing for non-code postition they might tell you to take a hike.
I do not want to work in an organization where "architect" is a non-coding position. Seen that, left in horror. So if I'm interviewing you, you are almost certainly being hired for a coding position.
The idea that a contrived 30 minute coding session tells you more about a candidate that studying code they've previously written or debugging together is idiotic.
It doesn't tell you more, but it tells you something different. In particular it tells the difference between someone who shows their own code versus shows someone else's code and lies about the source. (Yes, I have seen that.)
"Companies do tend to promote good programmers to architect, and you don't want to miss out on those programmers."
Everything in your responce sounds to me like in your view, architect is 'extra senior' developer, whereas I understand it to be a different job. Isn't what you are describing a principal engineer?
"In particular it tells the difference between someone who shows their own code versus shows someone else's code and lies about the source. (Yes, I have seen that.)"
To eliminate that possibility, you can ask questions about the code, how it was designed, etc. Presumably if they stole the code, they are not going to know it inside-out, like the author would.
I don’t buy this analysis. The principles of architecting code and system design are timeless. There are definitely people out there who don’t “code really well on command”, but can ask the right questions to design a solid system.
The principles of architecting code and system design are timeless.
That I emphatically agree with. Some of my favorite programming books are decades old.
There are definitely people out there who don’t “code really well on command”, but can ask the right questions to design a solid system.
There are?
I can't say that I've ever met one.
The problem is that people don't know what they don't know. A non-programmer can know exactly the business problem to solve and exactly how they want to solve it. But they can't tell the difference between what is easy for a programmer and what is hard.
They don't have to learn a ton of programming to fill that bit in. But if they never fill it in, that limitation will keep them from being able to be a good software architect.
It will be me. I am systems architect and last production code that I wrote was probably 10 years ago or so.
I am probably rather crappy programmer. I was crappy perl programmer, crappy php (starting with version 2), crappy in delphi, c, c++. Probably okay in Python, but mostly because Python allowed to concentrate on solving problem and not fighting the language.
Me been crappy was probably because I never really enjoyed to write code, as interesting part is figuring out solution to a problem. Rest is implementation details :) You can say if you want that I am simply too lazy to write code.
Me been crappy in writing code doesn't mean that i am bad in understanding code or understanding what is it to write code the easy way or the hard way.
In majority of cases when programmers come to me with design that will be easy for them to implement, turns out that they have a bunch of big problems that they missed, mostly due to lack of experience. Most of the time solutions that they come up with complicate things further and add even more problems.
And this is the point of time when I assist them to simplify whatever complex design they made to something much more simple and doable.
I saved many man/years of development time by showing programmers easy ways that they didn't know that they exists
Now I can't get the picture of Amazon employees in dark robes repeatedly reciting the tenets out of my head...
That being said, where's the proof that having PEs is better than having architects? If we look at results, I don't see any evidence that Amazon's creating better software than Microsoft on any quality axis.
In 2020, the Amazon Principal Engineer community added a ninth tenet. Much effort went into crafting the new tenet, as was the case with the others. The new tenet may be my favorite of them all.
LEAD WITH EMPATHY
Principal Engineers shape an inclusive engineering culture where others are heard, feel respected, and are empowered. We are conscious of how our words and demeanor impact others, especially those with less influence; we take responsibility for that impact, intentional or otherwise. Our work builds productive relationships across teams and disciplines, and across a wide range of life experiences.
This sound like a symptom of having too many smart people with too many diverging architectural ideas at the same place. How do the mgmt get them to march in the same direction? Easy, find the top 1% and create a mythological narrative around them. Then when a smart engineer in a team have a solid architectural idea he/she can defer to the Unicorn Principal that will "advocate" another "approach" that "balances tradeoffs" with "competing interests".
Sort of like the much hated ivory tower software architect.
That Amazon characterization of a Principal Engineer is great, and approximately how I've viewed the ideal role of the title.
Sometimes the title means being very highly skilled and experienced IC, or having deep historical knowledge of a particular system or organization, or being a niche technical expert. I like what Amazon's description adds to it expressly (which many have sometimes done unofficially), such as leading by example, engaging, and seeing humility as a quality of the role.
I share your disdain for "Software Architects." I'm curious on your reasoning though. Can you expand on why you hold disdain for "Software Architects"?
It really comes down to the tenets I posted above from Amazon. At MS there was a propensity for folks in these roles to just pontificate. We called them "Architecture Astronauts". As an example, they were rarely practitioners (they rarely wrote code).
As with other commenters, I feel like Software Architecture is a bit of an anti-pattern. Software just isn't like buildings in the end. The analogues of space and physics of materials etc are not solid enough in the software world that you can have someone disconnected from the "builders" lay out the whole building and then hand over the designs to be "built". As with agile approaches etc., there is a need for a far more incremental and iterative approach needed for most software projects and even if in practice that is how the architect role works, it is unhelpful to have it named in a way that implies a "waterfall" type process that you would see in building design.
I think most of the advice in the article is actually reflecting this sentiment and in my organisation I am deliberately not creating roles that bear "architect" in the title. The software industry should move on from this term, I think.
> that you can have someone disconnected from the "builders" lay out the whole building and then hand over the designs to be "built"
Agreed that this isn't going to work. I wouldn't write off the whole notion of having architecture and architects, though; I've known a handful of architects who absolutely improved the systems they worked on, but they were deeply involved in the whole process and part of their job was precisely to alter the system as needed.
Right, you just throw together angular, babel, webpack, bootstrap, typescript, spinners, redis, zeromq, recaptcha and nosql - and that's your blog's "architecture".
#2 is probably the most important. How you model the domain is the most foundational part of any software system. If everyone on your team looks at your domain model and thinks "yep that makes total sense", then it is very likely the rest of the project can be made to go smoothly. If the meaning of a Customer or User in your system is ambiguous, or has certain nuances privy only to the architecture team... this is where you run into massive problems on more complex systems.
Taking this a little bit further, having a clean model of the problem domain also makes other downstream aspects easier. Business analysts can start expecting certain types to have certain properties and you can leverage things like SQL to dramatically speed up projection of business facts without involving developers.
I agree. This is the classic “you don’t understand it if you can’t explain it” problem. If you don’t have the domain nailed down in plain speak, there are risks to productivity - especially if an entire team is involved. Business logic becomes open to interpretation at implementation time. That means a different solution for any developer who happens to implement it, and each one potentially incorrect and unable to interface with correct code in its own way.
I’ve set myself up for failure this way, essentially by assuming things would just fit into place as more of the project became clear. That’s a really bad way to work, haha. But you learn as you go.
I consistently have to argue with my brother about this, who started developing in the 90s and has a perfect memory for mapping terms to abstract objects.
He argues that at some level, every construct is just assembly that shuffles bits around, so nomenclature doesn't matter (he also grew up with Perl as a first language...). My argument is that it makes his code unreadable without a graph unraveler.
I once spent a long time trying to work through all of the complexities just for what "Customer" meant in one fairly large organisation. Pretty much all followed from one chap asking "if a customer consolidates it finance team from being at each of their 40 sites in one country to 1 shared service centre, do we lose 39 customers"?
Identifying bounded contexts is a critical part of organizing extremely complex systems. You might have a Customer model that supports all contexts of usage, but in a certain bounded context you could know that only certain things from that type are applicable. There are a lot of ways to model this explicitly, but sometimes just having a clear document that expresses what these contexts are and what is involved in each is sufficient.
This also alludes to the benefits around separating your functions from your data. If your domain model is just data and the functions live elsewhere (i.e. within a separate abstraction representing each bounded context), then you have tremendous amounts of flexibility with how the system is composed on top of the model.
People downplay software architects but I've found it's a critical role. You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality.
A lot of business logic ends up encoded in the software so you really want to isolate it as much as possible so that when change is needed you know where to look. That and you have to create a lot of documentation and train new developers and stakeholders. So it's really a job where you spend 95% of your time contextualizing, writing and communicating to others. It's a bit like doing continuous self reflection of a project.
It's kind of a thankless job, do your job well and it's like flowing water and nobody notices you. Do it badly and things dam up quickly.
> You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality
This is the Technical product managers job. The architects role is suppose to be an extreme high level view of purely the technical side of the business.
From my own anecdotal experience "architects" who try to fulfill the role to the definition end up being mostly useless.
I've had my worst experiences in teams where the Product and Engineering were completely siloed. Things go a lot more smoothly if there's a bit of overlap. Also, many orgs don't have a TPM role, so that falls on Staff/Principal engineers and engineering managers. In fact, roles should be fluid and slightly overlapping, as every team and every org will have different needs.
I'm biased, as an architect, but you can't be a good software architect if you don't know the domain very well - both the industry as a whole, and your company specifically.
I'm an old fart that is a programmer that now has a fancy "architect" title.
I think I can distill that 30 years into the following:
1. Nouns are more important then Verbs. (that's what DDD is about)
2. Everything is events (if your Nouns aren't doing anything, there's nothing to be done. When they do something, that's an event).
3. A Noun's state is the sum of all the events that occurred and the way the Noun responded to them.
All the rest, microservices, network partitions, RDBMS vs NoSQL, containers, etc etc is irrelevant to the business. If you don't get those 3 points right, then you don't deliver the business value and you've failed.
Architects are about translating the business into those Nouns and Verbs and explaining them back to the business and to the developers that are building the automated bit of that business.
And nothing about business needs and wants, working with stakeholders and all the rest? I’ve seen both newly minted and seasoned “architects” fail again and again because they think in terms of technology not business.
> 2. Don’t ignore the domain
It’s part of the role to become a domain expert. This knowledge can be used to act as an effective translator between business and engineering.
-shrugs- I don’t get that from that paragraph, but I guess it depends on how one thinks the author means “domain”.
I’m used to meeting “domain experts” who know all about the corner cases in the current implementation. Often they are the people who argue with the suits and it never ends well for them.
It's specific jargon in the Domain Driven Design community; "domain" == "business domain". Some of the links in that section of the OP give more detail.
I recommend DDD in particular, it's a great architectural framework, though it's a bit dense and hard to approach.
Nah sounds like a seasoned architect. The first thing I had to unlearn was that I had any say over my architecture.
Maybe the problem with software architects is that they only exist in bureaucratically hellish companies, and exist as a scapegoat for bad management decisions?
Your experience matches mine. I can think of twice where I stood my ground and argued with a more senior person. Both times I was shown to be right technically but that came at a big cost to my career. I would have been much better off letting the project crash and burn.
I think there are senior people that are different. Hell, there might be companies full of them. But I'd need to see first hand proof of it before doing anything harder than gentle pushback.
If you're arguing with your boss's boss's boss, who has worked at the company for five years and the industry for two decades, and you think you've unraveled their entire argument by reading a few blog posts, you're wrong approaching 100% of the time. Best case scenario is that you've missed something specific to your company, or industry, or the current technical implementation, or some obscure contract the previous CTO signed that they're still trying to get out of.
In pc86's scenario, though, it's much more likely that you're the one with the ego, thinking that reading a few blog posts makes you more informed than a 20-year industry vet.
In my experience it's rarely (read: never) that clear, is my point. When it's that "obviously" wrong, there's almost certainly something you don't understand.
Maybe what you mean is “everyone has a plan until they get punched in the face” ? All good architecture starts with that idea in mind, so you optimize for making things as decoupled and changeable as possible.
When I'm managing junior folks, I generally advise them there are three main paths:
1. Keep focusing on IC/software work. You keep growing and having larger impact, capping off with an architect type role.
2. Lean into project management, full stack, and business a bit. Become a tech lead for increasing large/important projects. This is a great general path that still lets you be pretty close to the code.
3. Focus on business & people. Gain experience mentoring teammates, then interns, then become a people manager. At some point you're going to be trading cutting edge coding skills for mid level management skills. You can branch off to focusing on CTO or engineering leadership from here.
There are definitely a lot of other paths, but that above three are the most "well worn" and achievable in my experience.
Do you still want to live close to SV when you're not working there anymore?
Your burn-down rate for your retirement fund is predicated pretty substantially by the standard of living you maintain after you retire. If a lot of your day to day activities become indefensible once you can't justify it based on work concerns, then your costs may be lower.
Look, for instance, at all the fancy cars that real estate agents have to drive to exude competence. They end up leasing a high end car, when maybe all they want is a 2013 Subaru Outback for activities and half a closet of clothes from Duluth and Patagonia that last forever. Once you pull on that thread, then moving to an exurb might make sense too.
I would say that something you need to know about yourself by the time you reach your FIRE goals is what you want to do with the extra 10 hours a day once it's not working for a boss. Even if that means adding a couple years onto your plan.
Because if you know the answer to that question, many of those answers don't require a tier 1 market. And since you're doing it late in life, it might occur to you that if you move to the mecca of beer making or kayak building, you'll be competing with people who are way, way more experienced than you are. Maybe you want to live in a 'rising star' city of a 200-600 thousand people, where your relationship with the community can be more reciprocal, but you can still find a decent turkish coffee and bulgogi tacos. That place is going to be tons cheaper than where you are now.
I don't know what the author has in mind, but I plainly disagree when stated as a general rule like this.
Examples:
Try to get every server on the same OS by default, same packages, standardized networks, health check at the same path, prefer the same port, deployed with standard jenkins jobs, use a standard versioning scheme, use the standard branching model, standardize logging, standardize error-handling, standardize datastores, use standard login/security.
That’s “Dev Ops” consistency, not architectural consistency.
Insisting on architectural consistency might mean every service needs to use a relational database, and have an exposed API. But a pub/sub or map reduce, may not fit neatly into that architectural model.
I've been in software architect roles on and off during my career (currently I'm on) and I feel like I've read similar discussions to the ones in the comments many times over the years.
But no matter how you cut it, you can't escape software architecture when doing software development. One may call the architects principal engineers, gremlins or senior developers, the role may be covered by one person or multiple and the end result may be better or worse, documented or undocumented - in the end someone worked on the software architecture.
Depending on the organization and its needs, the role may be strongly focused on technical aspects or straddling engineering and product management. A company with very specialized roles will want architects to take care of the architecture, whereas one with more flexibility might require that they also work on requirements, talk to customers, mentor developers, manage a product, etc. Some of these combinations are less than ideal.
Every time I did application architecture I was also writing code, but that's not easy and may be an anti-pattern. Typically architecture tasks (especially the documentation) are neglected under time pressure and the people revert to doing what they know best, which is coding.
Application architects should be very familiar with their application domain, applicable algorithms, idoms and patterns, etc because they're essentially part of the development team.
Now I'm closer to the "architect that doesn't code" stereotype, doing systems architecture. And indeed, I do not write any code besides small applications I use to validate my assumptions or evaluate and analyze solutions. I don't remember writing one line of production code in the past years and this is neither unusual nor problematic.
I work with several development teams, ensuring that their components stay technically coherent and fulfill the requirements of the system. I start by translating business requirements into technical requirements and then work together with each team observing their progress, iterating over our solutions until we are feature complete. Specifically this involves intra-component interface design, software design (in my case - how components behave and interact with each-other and the platform), architecture documentation, application architecture review, code review, etc. And meetings, tons and tons of meetings with development teams, POs, project managers, testers, lead architects, etc.
I do find that working close to the metal grounds you as an architect. Whenever I do too much diagramming and abstract concept design I feel like I'm losing something important and this is where testing your concepts comes in.
But there's no general rule about what developers expect from architects. I've had teams in the same projects expect a finished concept while others were happy to implement something by themselves with minimal to no input from me as long as the external preconditions were being met.
Software architecture is a critical responsibility.
There is more than one way to get that taken care of, and it tends to work better when the people who are responsible still have their hands in the code.
I've seen too many pure architects spout off about how the system works and not notice the meaningful glances among everyone else at the table. That's how you wanted it to work. We couldn't make that work (possibly because Information Theory or physics) so we did something else.
5 years at Amazon led me to fall in love with the concept of a community of Principal Engineers. The Amazon Principle Engineering tenets are amazeballs.
Exemplary Practitioner - Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implementations. Only by being close to the details can we earn the respect needed to be effective technical leaders.
Technically Fearless - Our company's startup culture does not admit the luxury of conservatism. Principal Engineers tackle intrinsically hard problems, venturing beyond comfortable approaches when necessary. We acquire expertise as needed, pioneer new spaces, and inspire others as to what’s possible.
Balanced and Pragmatic - Principal Engineers are pragmatic problem solvers. We apply judgment and experience to balance trade-offs between competing interests. We simplify processes and technologies while advocating a long-term view.
Illuminate and Clarify - Principal Engineers bring clarity to complexity and demonstrate smart ways to simplify. We frame each problem in its customer and business context and boil it down to its essence. We probe assumptions, illuminate pitfalls, and foster shared understanding. We accelerate progress by driving crisp and timely decisions.
Flexible in Approach - Principal Engineers adapt our approach to meet the needs of the team, project, and product. We solicit differing views and are willing to change our minds as we learn more. We recognize there are often many viable solutions, and that sometimes the best solution is to solve a different problem, or to not solve the problem at all.
Respect What Came Before - Principal Engineers are grateful to our predecessors. We appreciate the value of working systems and the lessons they embody. We understand that many problems are not essentially new.
Learn, Educate, and Advocate - Principal Engineers are constantly learning. We seek technical knowledge and educate the entire organization about trends, technologies, and approaches. We combine vision and discretion to drive fruitful and even game-changing technology choices.
Have Resounding Impact - “Deliver Results” is a low bar for a Principal Engineer. Without seeking the spotlight, Principal Engineers make a lasting impact that echoes through the technology, the product, and the company. We amplify our impact by aligning teams toward coherent architectural strategies.