When I see this kind of attitude I know that this person is burned out and needs to find something new to do.
The reality is that software is complex and maintaining and running it is also complex. Making sure it continues to work 24/7 is not trivial. And the beeper that goes off when it stops working most likely belongs to a different person than wrote the code.
So, no offense, but get the fuck over yourself or find a new job.
I am a Software Architect by title, but most of my work is finding the right people and pulling the right strings to get the job done.
I force myself into coding at least 25% of time because I do not want to become one of those non-coding architects that everyone including themselves despises.
You really can't just draw diagrams, write Software Architecture Documents and assume that what you do makes sense.
Our minds have a tendency to wander off and need constant reality checks to operate properly.
All comparisons to construction business are flawed, because Architects in the construction business have to navigate an entangled reality of regulatory work, client desires, supply chain considerations and all other real-world constraints.
In contrast, Software Architects mostly work in a digital world where almost everything is possible. Their perception of reality drifts unless they fight the sensory deprivation with hands-on coding.
You seem to contradict yourself. You start off by noting all the non-technical constraints on a software architect and then say it's nothing like a construction architect by noting all their non-technical constraints.
They seem to be very similar - balancing client desires vs. real-world constraints, because no, it is not the case that everything is possible with regards to software architecture. Software architects have to contend with processing constraints, memory constraints, networking constraints, process management and coordination constraints, and organizational constraints. Depending on the industry vertical you're in you may even have to contend with regulatory constraints.
Then you should be quite aware she doesn’t believe half the random shit she spouts on twitter, including this. It’s greatly exaggerated for clout chasing.
Nuance doesn’t work on twitter. It’s part of the game. She’s on there to get clicks to spread her personal and company brand.
“I take you more seriously on matters of architecture if you’re committing code on a regular basis and on the pager duty rotation. Some architects are really good and many are bad or detrimental.”
Is not a take that gets quote tweeted or posted on hacker news.
This more or less describes a lot of how I view software industry Twitter.
Tweet threads on topics like this are rarely deep and thoughtfully considered, and when they are, an article or blog post would always be a better format.
> When I see this kind of attitude I know that this person is burned out and needs to find something new to do.
When I see this kind of absolutist statement - where someone presumes to have a complete picture of someone & have absolute certainty about what it means - from a brief snapshot like this - I know better than to trust the claims or take them seriously.
> So, no offense, but get the fuck over yourself or find a new job.
Counterproposal: ease the fuck up. Step back. Couch your terms in at some least modicum of hesitancy & humility, that you maybe don't know 100% everything & might not be 100% accurate & correct. You're having their own reaction here: it has only somewhat to do with the post.
One thing I think is kinda strange about software development as a craft is how a large portion of the industry seems to believe that the end goal of spending 10-20 years becoming a highly skilled coder is to one day stop coding. You're either supposed to become a manager, an architect, or spend 100% of your time mentoring and reviewing work for junior developers.
Personally, I like coding. I don't want to be a manager. I don't want to be an architect. I don't mind mentoring, but only if it's a minority of my time. If I wanted to be a teacher, I'd have chosen that as a career. I understand that many people do want to transition those roles, but I don't like the feeling that transitioning around the age of 40 is considered the default.
This is like saying only carpenters should be able to design houses. Sure there are some excellent carpenters that are also good architects, but most are not. There obviously needs to be good communication between the carpenters and the architect but these are distinctly separate functions.
The Twitter OP sounds like someone that’s a bit full of themselves and struggles to see other perspectives—-a core skill to be a broadly respected leader.
I’ve seen the persona they’re referring to materialize, but that’s just someone that’s a bad architect. I’ve equally seen plenty of “know-it-all get outta my way” developers that say they don’t want others around but create terrible productions systems that end up failing because of bigger picture design items the developer missed.
Building excellent production systems at scale is a hard job that requires strong collaboration from diverse teams.
It is like saying only carpenters should be able to design houses, but it's also not exactly that. Why? Because house construction and building is a proper engineering discipline, but very little software is built like that.
We are just starting to understand how software can be designed with such rigor, and maybe we will never be able to because of market forces.
> This is like saying only carpenters should be able to design houses
No, it's really not. For that analogy to work, architecture (house design) would have to be a skill best learnt via carpentry (i.e. hands-on house building), when there's pretty clearly minimal connection. If there were, we'd see many successful architects who'd started in the building trades, just as we DO see many developers rise up through the ranks to become seasoned veterans capable of architecting complex systems.
The thing is, most software system requirements could be translated into many proposed alternate architectures (decompositions, inter-module interface definitions, technology choices, etc, etc). They may all look viable on the white board, but it takes years of experience to understand what works and what doesn't - what the consequences of those design choices are, and how they will impact development, debugging, operational support, future changes/extensions, etc.
I don't know that op chooses her words super carefully, but I read it as being like only carpenters should be able to choose how they build houses. That's pretty reasonable, especially when you consider there's also housing codes (something software engineering probably needs to work on).
> This is like saying only carpenters should be able to design houses. Sure there are some excellent carpenters that are also good architects, but most are not. There obviously needs to be good communication between the carpenters and the architect but these are distinctly separate functions.
The carpenter is more like the compiler in this analogy: it merely follows the blueprints.
The structural engineer is in charge of said blueprints. The architect can mock and draw whatever he wants; if it's not structurally sound it's simply not getting the engineer's signature and seal.
I've worked with great software architects (most of who wouldn't use the tittle seriously) and all of them had one thing in common: a solid engineering background and a track record of solid design.
> I genuinely wonder if an actual house designed by carpenters for carpenters wouldn’t be better? Maybe not more attractive, but better built?
Maybe if they really over-build it, but I don't think carpenters know how to calculate stuff like structural load requirements. I know the building code have some rules of thumb, but I kinda doubt those cover all the situations you'd need to design a home (e.g. how strong does this wall need to be based on all the stuff above supported by it).
If "what the user wants" violates 5 building codes and will fall down within a decade, then I would say yes?
The problem is rarely the average user, who just wants stuff to work, and probably would be just fine with what a carpenter would design. It's the ones who think they deserve something extra-special, and know better than you what you're doing.
I've read a lot of Charity Majors' stuff, and in some ways this opinion is typical of her, and in some ways it is not.
Obviously, she's a big proponent of engineers taking full ownership of their work. That's core to observability, which is what her day job is all about:
Yet one of the pieces she's well known for is "The Engineer/Manager Pendulum," where she argues that some of the best managers and some of the best ICs are people who have gone back and forth between the two roles:
In one sense, that is consistent with her opinion about architects being a BS position, sort of analogous to calling out useless middle managers.
But one of my takeaways from her pendulum opinion is that those senior ICs who have pendulumed are better off precisely because they bring a management skillset to IC work and an IC skillset to management work.
And a high enough level, that manager's eye might involve recognizing that helping other engineers design their systems is imparting more engineering influence than whatever any one person can do at the code level. And in these cases, I'd argue you're still delivering engineering value rather than just project-management value.
Charity knows a lot of these senior ICs, and so it's not as if she's dismissing their potential value out of ignorance. So I'm a little surprised that she's throwing the baby out with the bathwater and arguing not that there are a lot of architects who aren't delivering the value they should be, but that the role itself is inherently not valuable.
On balance, the role might be net-negative. Like PMs. There are _good people_ doing _hard jobs_, at most orgs. However, a role where you're not responsible for the systems you create is one where the feedback loops are too large to add value beyond random chance.
There’s many kinds of responsibility. You can just as easily tell the inverse story, where you need architects and PMs to be in charge because engineers aren’t responsible for the business value of the systems they create.
Ideally, an architect's job performance is measured in terms of revenue or attributed cost savings for the products they architect. A good architect will produce streamlined designs that make lots of money with little development effort; a bad architect will produce convoluted designs that require more effort to produce less money.
How often are architects actually measured that way? I'm not sure, in the areas I work in these days it's not a trendy title to have. I've heard the same horror stories you have of "architecture astronauts", who design pointless frameworks and then get evaluated based on how many people they can bully into adopting the framework. But I know people doing valuable work in similar roles, so I can't get behind the idea that it's illegitimate in some fundamental way.
I really wish I could see the reactions to this tweet in a parallel universe where it was not written by a woman with died hairs. I have a hunch that the disagreement wouldn't come with personal attacks and judgments on OP's character.
Maybe I don't know how Twitter works, but I didn't manage to find a single personal attack or judgement on her character from the Tweet replies or from the comments here. The responses were rather on the contrary, enforcing her view with some anecdotal testimonies etc. This is a bit surprising given the provoking nature of her initial comment (calling peoples engineering roles bullshit)..
I'm sorry you couldn't find them. Here are some comments with personal attacks and judgements that I found on this very comment section here on HN:
> Have some humility with your cheap box dye, ugh
> When I see this kind of attitude I know that this person is burned out and needs to find something new to do.
> So, no offense, but get the fuck over yourself or find a new job.
> Yeah, when you start to describe your daily work with words like "burden", you're usually not in a good mental state.
> The Twitter OP sounds like someone that’s a bit full of themselves and struggles to see other perspectives—-a core skill to be a broadly respected leader.
> Toxic attitude. I hope to hell to not work with someone like that.
These are either attacks or judgements of her character, based on a single statement (or opinion if they actually went to read the entire thread).
One thing is to say "you are wrong" and another is to say "you are wrong and burned out/mentally unstable/full of yourself/unable to be a leader/toxic".
Again, I would be very curious if I would find these kind of remarks in a parallel universe where this thread was not posted by a woman with dyed hairs. Bias is a real thing and the fact that she's actually wrong in this instance doesn't make bias justified or less problematic.
Why go to a parallel universe? I thought it was an uninteresting stale rant and didn't know it was written by a woman nor that she had dyed hair until you just told me.
It would have been more interesting if any of the comments had brought up Christopher Alexander's observations from, I think it was, the timeless way of building....
I agree with the "out of tune with reality" but in my experience it can also be a chasing after the next big thing to the detriment of the current reality. That rests on a belief that computer systems are not an end in themselves except where you are selling them to not be an end in themselves.
"Architects are not real engineers/their opinion doesn't matter" is just a rephrased version of "the real developer starts at exactly my level of knowledge, but anything above is already 'incredibly good'" which I've seen, well, everywhere & all the time. IT culture has a big problem with repressed aggression and some weird & frankly speaking pretty useless type of competitiveness which leads to this type of behavior.
This is just a rant on Architects who don't know what they're doing.
At face value, it's like saying only players with current season court-time should be coaches.
It would have been much more insightful and productive to present this as being hands-off for too long leads to a detrimental disconnect, and seek solutions to close that gap.
If the tweet was motivated by a specific incident, perhaps that would be a more interesting read.
I really love the people at my job they never write any code anymore, except for the quick POC's to test out every new shiny thing that comes along, and then unilaterally decree that from now on everything must be written that way, or with that new tool or on that new platform.
Can they be joined by the agile project manager who insists that producing work on time is "not agile"? In fact, being asked to do anything is "not agile".
I feel like we have a good starter for a sitcom here.
I've never worked in a company large enough to have an architect who didn't write code. My current role as a manager/bizdev/ex-CTO person, I still write code. Though, it's always janitorial type stuff so my team can do the fun/challenging things.
Yeah. Or the owner of the company who has done a little coding (R scrips, etc.) who knows exactly how you need to implement that feature, or design that database, etc.. lol
When Richard Hipp of SQLite was setting up his foundation to manage the project, Mitchell Baker of Mozilla advised him to ensure only developers got the final say, and that was excellent advice (Baker is a lawyer herself by training).
We all know Architecture Astronauts who have been so long out of the field their recommendations are completely disconnected from reality. Back when I worked at a Fortune Global 500, we were invited by IBM to a lunch with Grady Booch, and seldom have I been as unimpressed by the torrent of meaningless platitudes he spewed during that event.
Agreed, the people building should ideally have the decision (which every now and then I think they are also liable to be overruled on).
But this seems to say they should be the only voice in the room too, which seems not right. It's not easy creating an environment where it's clear whose decision it is, and where teams feel ok brushing off other people's opinion. But I do think dialog & discourse are an important thing to maintain, and I am having a hard time seeing how that factors into this assertion.
It's not perfect but I like having the org use the RAPID framework at my last job, as it established some framing/roles for secision making & was clear who had what roles: R, recommender, gathers input - makes a formal recommemdation. A, agree, optional, people signing off on recommendation. P, perform, the team doing the work. I, input, provide info/advice t o recommemder. D, decide, the decider who commits org to task, based on recommendation & it's gathered inputs.
Often teams would be recommender, decider, & performer, but being clear on that was a nice positive.
Quite sad reading such a statement from a CTO. This attitude would tell me that a hypothetical candidate lacks likely fundamental skills in software architecture and has also either never worked or grasped the business need in complex organizations for such roles. I've seen this attitude many times over and it always boiled down to a fundamental misunderstanding of what software architecture is about
Depends entirely on your company. At big Orgs (hundreds of teams) it's usually consulting and being compliant with the goals of the overall enterprise architecture. What it's certainly not about if the architect is actually worth their salt - dictating other teams what to do.
That "way of operating" has gone horribly wrong in pretty much every domain it's ever been attempted. It's obviously "wrong", insofar as opinions can be "wrong", conflating different skills, authorities, responsibilities. All the counters appear to already be known and obvious, sooooo, trolling for fun and profit? Attention economy for the win? Here I am posting comments about it. Tsk.
You can't attack others like this on HN, no matter how wrong they are or you feel they are. We have to ban accounts that do, in order to prevent the community from destroying itself, so please don't do it again.
If you don't want to be banned on Hacker News, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
Agreed. And I say that when my role is "building software systems"
People with different roles in an organization will have different perspectives and goals. Ultimately the software system being built will have to be a compromise of those perspectives and goals.
Everyone has "skin in the game" to a degree, even if they don't "carry a pager".
The reality is that software is complex and maintaining and running it is also complex. Making sure it continues to work 24/7 is not trivial. And the beeper that goes off when it stops working most likely belongs to a different person than wrote the code.
So, no offense, but get the fuck over yourself or find a new job.