Only people building software systems get to have opinions on how they get built
twitter.com
twitter.com
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.
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.
Or is this one of those convenient excuses people make, like "it's just a joke bro!"
“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.
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.
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.
One can totally skip reality checks in software, because there is more variety, more options, crazy amounts of money and general immaturity.
There's your problem.
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.
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.
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.
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.
A "software architect" is more like a building-code (hah, code!) designerm. But yes OP is toxic.
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.
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).
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.
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.
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:
https://charity.wtf/2020/03/03/observability-is-a-many-splen...
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:
https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...
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.
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.
So what exactly are you talking about?
> 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.
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....
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 feel like we have a good starter for a sitcom here.
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.
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.
You may like to consider: [1] The Winchester House, and [2] KRAZAM, Microservices
Just saying,
[1] https://en.wikipedia.org/wiki/Winchester_Mystery_House [2] https://www.youtube.com/watch?v=y8OnoxKotPQ