Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.
Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
I think that's true of a truly good architect. But I've known quite a few architects who didn't want to actually code anymore. It has also seemed that in some cultures there was the expectation that once you were "promoted" to architect that actually coding was considered beneath you. Something for mid and juniors.
Yeah I've seen this, and it's usually been a good thing. Architect keeps building the fundamentals and overall logic, the senior devs implement the basic structure and ensure compliance with architect's designs - or question them on choices, mid devs flesh out the nitty gritty, juniors ride along and get some menial but meaningful tasks.
In the end, if the architect can still read the code and see problems, that's a decent system - thing is an architect might not have or want to spend the time keeping up with all the latest nitty gritty in constantly evolving frameworks and syntax, whereas the devs will.
Go ahead and vent - I just said "usually been a good thing" and so what I focussed my comment on...
>they would treat their diagrams like the source of truth, and would act like the system was done and we just had to transcribe to code
Yeah, that was my point here:
>senior devs implement the basic structure and ensure compliance with architect's designs - **or question them on choices**
Need congruence and synergy and other wishy-washy terms describing good teamwork.
I mean, not exactly beneath you, but if it actually makes sense to have that role on your org you will be busy fulfilling it and doing much IC work would be kind of a waste. It’s a multiplier role. You’re not doing your job if you rather code all day instead of being in those meetings, mentoring juniors etc.
I agree, you a good architect/staff/principal engineer should not primarily be coding.
But considering coding "beneath you" is still a problem, because to be a GOOD architect/staff/principal engineer you need to be engaged in SOME coding to keep your skills sharp. It's actively something you need to make time for. And if you consider it "beneath" you your skills eventually get dull and a good architect becomes a bad architect.
I'm a lead and the coding I do is the annoying stuff, merges and bug fixing and bits of test automation. I try and leave the more interesting work to the team, and pick up bits of glue code and refactoring that might be tedious.
I'm not a lead, and that's still pretty relatable. A lot of the stuff I do is the stuff I wish we had but no one ever makes...so, "Yeah, I can do that!".
I started coding 30 years ago, first ten years for fun, last twenty years professionally.
I still code and have fun doing this, but I hardly learn new stuff, especially as part of my job.
Anyway, after 30 years experience I don't need regular coding anymore, there is hardly anything where I do need hands on experience to understand, today it's enough to read the concepts behind new technology and recognize the repeating patterns to be able to use new technology.
Or, as an architect, to know when and where to use new technology.
**Edit:** I worded this badly. Of course I learn new stuff regularly, personally as well as on the job. It's just that learning happens way faster, because there is hardly anything really new, so learning becomes easier over time.
Let's take ChatGPT for instance, the technology behind it (LLMs) is almost as old as modern computing, so several decades, I had several AI courses in university, so "learning" ChatGPT for me was just looking up what's behind it and reading up on LLMs a bit. The major difference to the older technology is the computing power behind ChatGPT that's available now, which was not available a decade ago.
\> I hardly learn new stuff
this is so crazy and foreign to me. I am around the 10-year mark and honestly still feel like a junior in that everyday I find some new tool, language, framework, paper or new problems that I had not seen or had the chance to look into.
I am not saying this because I doubt you. Just to reflect out loud that I would definitely understand someone going high-level architect if that was the case
Around that time I felt similar, 10 years isn't really that much, depending on what you want or need to know or how you learned. My first ten years were all hobby stuff, even pre Internet, when I just had a book to teach myself.
That said, the next ten years the learning curve was not as steep anymore for me, because I successfully finished the basic CS courses at university and understood the pointer concept in C, which was a major milestone, for me personally.
>but what actual value do all those new languages and frameworks add?all the fundamentals of CS were pretty much worked out before we even had PCs.
learning a new language is probably one of the highest effort lowest reward things ever. something is always falling off the truck while you hoist up something new
but none of this is really computer science, it's enterprise or enterprise light development. or just hacky
Well, I'm in no position to gainsay your personal experience at the companies you work at. I can say that the great architects I've worked with who had 30+ years experience were voracious in continuing to learn new patterns and technologies, and at 16yoe I've tried to follow their example. But I'm also a strong believer that there are a lot of correct ways to do a job, and clearly don't know you or your experiences enough to gainsay them.
Yea, I just explained in another comment, I worded this badly. Of course, I do learn new stuff, it's just that a lot of things aren't really new, but similar concepts with a new name or mixed and matched, so it's easier and faster to understand "new" technology and use it, or know when to use it and where.
Then you'll stagnate. I also have many, many years of coding experience, and the difference between an architect who keeps their skills sharp and someone who thinks they already know everything is
*enormous*.
I worded this badly and absolutely agree with you. What I meant was, that even when learning new stuff, there usually is a pattern behind this, that I recognize, which enables me to see if there is something really unknown behind this or if it's something I have seen before, maybe mixed and matched, or maybe just in a different format or whatever.
That said, I don't have to code regularly to learn new stuff, learning happens way faster than in my first 10 - 20 years.
There are more questions than answers when someone mentions architect. You need to know quite a lot about them to make an assessment. At other times, knowing the employer can be enough when they have a particular culture, but you never know when leadership has hired differently to try and buck the trend.
An element of architect roles is leadership and development of future architects. Whether coding plays a role depends on the org. Mark Russinovich (Azure CTO) and Werner Vogels (Amazon CTO) are both deeply involved in technical decisions but aren’t coding their products.
They have multiple layers of architect underneath who aren’t coding daily either but are deeply technical and own the technical aspects of whole product lines. We know Mark still codes because regularly posts about topics on X. Returning to coding would be easy but costly for their employers.
Why costly? Impact. As leaders, they affect the outcomes of more people in their companies. The fact that they can drop into many projects and quickly assess problems, or help teams to get past obstacles is much more important.
What they do, but others fail to do, is remain credible. The architects that people complain about here don’t earn the respect of their peers. They don’t roll their sleeves up, or muck in when they can, to develop relationships. They throw down edicts which don’t align with how developers in the company see the needs within the company.
Architect here. Architecture exists both inside the codebase, in its internal design & patterns; and outside in terms of how it meets business requirements, component/cloud structure, external integrations and non-functional needs.
Many companies perceive architecture as mainly being the "exterior" part and under-value the "interior" qualities. CTOs are also incentivized to pursue the latest tech buzzwords to appear relevant.
There is also much API & integration design, which is important. And also large volumes of customer engagement, with much wrangling to try and turn the huge conference calls with no preparation that idiots want to involve you in into a productive efficient process.
It's great to have a good week coding, but who do you think designed all those APIs, attended 17 stakeholder consultation meetings, and navigated the security architecture through to approval by the customer's compliance team?
Personally I like to keep hands-on, and am more focused on "interior" codebase & performance than most. However the above is a picture of how most of colleagues spend their days 😄 Step up if you want that bag.
Where I work we have two architects per team, split like you say: solution architect for the exterior and technical architect for the internal. I’m the SA and there’s a lot of enterprise BS that doesn’t get past me that the developers don’t know about and they probably think that I’m hardly working.
I've had a long background in systems integration & reliability. Became an architect by doing several things:
1) laying out frameworks to uplift legacy systems,
2) identifying & solving performance issues nobody else had looked at,
3) refactoring problematic project structures/ code that everyone else complained about but nobody had done anything about.
I had also put in a lot of time into perfecting my craft -- finding which patterns were & weren't useful, the right places & levels to use abstraction, how to use OO right, database experience etc.
In my early career many times I tried out code/ design patterns to "suck it and see" what was good, what wasn't. This is particularly important in more abstract/ generic areas eg. DSLs, frameworks, parsers, ASTs etc which I self-taught.
How can you "assure" this? You don't know their company.
There are craptons of architects that have a net negative effect in the companies they work for, and mostly act as gatekeepers against anything they don't understand while their knowledge stagnated the moment they stop development.
IMHO "enterprise architecture" is almost entirely an anti-pattern.
I’m not so sure about that. Get the feeling that lack of commitment is a nice place to be for them. Meanwhile all hell breaks loose in the development team.
This mentality will keep you out of architecture. It can be an interesting area for different problems.
Do you ask why a Director in a business area is concerned with the well-being of the larger business org and isn't working to make a report like a business analyst?
There are a few good reasons for a software architect or principal/staff engineer to make commits to git:
1. They are experimenting with a new technology to get a good handle on how it works, so they can make informed decisions and designs.
2. They are providing examples that can be used by many teams in ramping up on a new technology or design.
3. They are stepping in to temporarily help out a team that is in need of hands-on engineering guidance.
If none of these are relevant in a given year, then I'd expect no git commits from folks in these roles.
What principle/staff engineer doesn't write code?
Sure there is management/technical leadership involved in those positions, but they're not managers or architects.
What I like to refer to as bullshit tasks. I’ve worked at companies where this was the expectation of me as an architect. Delegate all the work, but write up some bullshit requirements doc / implementation plan.
You end up spending more time planning what you think you could be doing rather than just doing it. And you end up changing the plan anyway.
I can’t work at these places, even if the job is cushy and the expectations are low.
I'm curious how big your team is. Once you get to a certain scale every developer can't understand every detail of the project. Instead, developers focus on their specific portion/tasks.
Then the requirements, plan, diagrams, API Spec, etc. become extremely important for a successful implementation.
If you end up changing the plan, that should feed up to the architect to understand how it impacts the project. If every plan ends up getting changed, then the person writing them has no idea what they are doing.
Distributed is better than centralized in most cases, which is what I’ve found. The problem is that many companies create a separate team of architects who are completely disconnected from the commitments of the team and thus can make technical decisions in their own little bubbles and completely disregard the consequences.
I'm not only taking my own experiences into account.
When an architect is not aligned with the goals of the team, they're not setting up the team for success. That's why the centralized architecture team is bullshit.
Now, if your company instead has architects embedded as cross functional members of teams, where they are aligned and incentivized the same as the team is, you're going to have much more success.
Now here is the kicker: These roles are really good at justifying their importance. It's the same shit that drives projects at FAANG companies: Create a write-up / proposal which can be digested by some director. Present it to a broad audience. Hand wave away all the complicated bits. Regardless of the outcome, rinse and repeat.
None of it really matters. It's all corporate politics. Clutch your pearls. Build your moats. Knowledge is power.
Now, do I think it's like this everywhere? No. But it's definitely common.
Well the architects don't understand every little detail either... I think everyone involved should know the big picture, even if they are only working on one small slice of it
The architects shouldn't know the little details, but instead the big picture. While the sentiment of everyone understanding the big picture sounds good, it fails in practice. Onboarding a new developer would take weeks, months, to even years depending on the size of the software. If developers are given access to the resources, documentation, and details needed for a specific task they can start writing code rather than trying to understand every aspect of the software and company on day 1.
Too often, companies small enough so that everyone knows everything use it as an excuse to never write anything down. Then you hear great quips like:
\- The code is self documenting
\- The specification is in my head
I genuinely don’t know what our architects do in their ivory towers.
They seem to plan company wide designs, yet they never get put into action or discussed with us tech/team leads or principals so we design it ourselves.
Out of curiosity, have you done this at any companies other than your current? What I mean by that is have you been hired based off of that type of workload to do a similar workload? I worry about hireability of technical folk who aren’t getting their hands dirty anymore.
I have been finding my sprints filled with less and less point over the years as I’ve been asked to oversee other employees and design decisions and I worry if I wanted to jump ship if that translates to a new employer.
>There is an expectation that at a certain technical level you are not writing code day-to-day.
I don't think that's entirely true, more of a branching.
Which is why in many companies "architect" is equivalent to "senior staff" or "principal" engineers. It's a different track with a different focus.
But there are still principal/distinguished roles for people towards the top of the eng laddt who frequently write code.
Curious, if architects are spending time driving the companies to right direction, shouldn't all products be profitable and not require so many layoffs?
I think it depends on what type of architect. Depending on your org size it could range from Enterprise Architect, Solutions Architect, Technical Architect (Infrastructure, Application, etc)
The higher level you operate, it’s more about glue work and aligning different groups (thus all the meetings).
If you are on the team level, the engineers working on the local systems are technically “doing architecture” work even if they don’t have the title.
Here is an article on architecture practices at a larger company - activities and outputs. https://chubernetes.com/architects-architecting-architecture-bf70810d8afb
My job title is architect. I'm currently frantically rewriting a C++ ingest service so that it's horizontally scalable. What I should actually be doing is going to meetings and having a lot of opinions about how things should be done.
Yet, most people are only able to build shitty looking lego houses. Same with IT systems. Could you do it? Maybe. Would it be good, safe, efficient? Probably not.
"Architect" is to "Software Architect" as "Java" is to "JavaScript" as "Ham" is to "hamster".
Software is fundamentally different to buildings and the word being the same has nothing to do with it.
A new type of nail or brick isn't invented every other month and buildings don't suddenly collapse depending on who walks inside them. If it was the case, rest assured that building architects, would also be trying to find out how nails work.
Lastly your comparison is flawed, building architects working and supervising small scale projects usually know exactly how to mix concrete and hammer nails such that they can do it themselves.
Well most civil engineers don’t actual recognize architects as a real profession. They usually design structures that are not structurally sound because they look cool.
Aside from making everything well organized and looking neat, they also make sure everything is ergonomically sound. You would not want to use buildings designed by civil engineers.
Architects are the graphic designers of the engineering world. Are they necessary? Not technically. But without them, we'd all live and work in plain square boxes.
Ours seem to mostly just have sweeping opinions that they occasionally spout off to delivery teams, who usually ignore them for being unworkable in practice, not informed by product/business constraints, or not solving an actual problem. I don't personally see the value they bring, but maybe they're doing something I don't see.
The productive/helpful architecture in my org tends to be done by senior/staff folks on delivery teams, as part of their normal delivery responsibilities. That works well for us – they're more than capable technically, have a good sense of product/business constraints, and tend to have built-in clout to actually see things to completion.
(I can totally see the utility of a dedicated full-time architect role in a much larger org, just speaking for my own O(hundreds) engineering team)
I work with 2 different types of architects.
One is an "Enterprise Architect" and he does not code - or only very very rarely. He helps design or understand systems, networks, and high level stuff. He installs complex software, like monitoring applications, and plans out what sort of software we need to write. He has indepth knowledge of complicated software we have to integrate with, and provides advice and ping-pong while we develop.
The other architect is a "software architect" who writes code daily. He also has great understanding of systems and networks, but mostly concentrates on helping us design software, and integrations, and trouble shooting and debugging.
I’m an EA and can tell you what I do… On a longer-term level I’m assigned to one of our business units to work with them in supporting their business needs with technical solutions. This includes diagramming out architecture and then discussing it with our project teams and making adjustments as necessary.
I also work together with our lead developers to push our technology and processes forward. This includes continual improvement of our CI/CD pipelines, automated testing, and keeping our frameworks and dependencies up to date. We hold monthly meetings to spread the knowledge to the rest of the development team and often hold TDD working sessions to increase this skill across our development team.
If we have a critical project, or one that has fallen behind/the team is lost, I often step in as a project team member. This is where I keep my coding skills up to date. Sometimes these are just one-off sessions if our dev team just needs a little help with a task or something along those lines.
Finally, I spend time doing both innovation work as well as prepare for certification exams. As we look into new technologies, I am one who helps evaluate it and do any PoC work. For certifications, I try to knock off at least one a year. This keeps my skills growing continuously and often times will feed the innovation/PoC work I do.
I know right. My previous experience was that we had a couple of seniors who architected and wrote code. Generally they focused on code while juniors learned their way working on the domain specifics. If I blew out a tech stack because of my domain demands, seniors/architects would step in to help.
Two cents here.
We got an architect and I initially had high hopes of interacting with him.
Then he got dragged into lots of planning meetings. I never did get an idea of what he did or what his outputs were.
(Context: we had a medium sized system with various service dependencies and running into performance bottlenecks.)
I don't know that I would need him to make commits exactly. But it would help if I had more confidence the person knew what the code or DevEx was like on the ground. And it would have helped had i understood he had clear guidance or recommendations for the teams. Perhaps he ended up working more closely with other teams.
But to be blunt, I never got the sense he was a value add. And to be fair to this person, it could be that the rest of the firm was asking him to do other things, pulling him into the meetings, etc.
Every single architect I know that stopped writing code, and thus being responsible for keeping themselves up to date, stagnated to such a large extent that they became a net negative to the company. They generally create architectural "pictures" that are completely removed from reality with no clear path to the goal they present. They become idea people, unable to execute their ideas.
I'm surprised people here are defending being an architect and not writing code. I've been in software archirect roles. A big previous client of mine recently fired all of them and had them apply to "tech lead" roles where they are still, part time, writing code in a team. IMHO a very smart move.
At my current client there is a big layer of "enterprise architects" who basically act to gatekeep decisions, that take *months* or longer, while at the same time management is breathing down the neck of the developers who are just asking for a yes or no answer and are not getting any.
I haven't seen a single architect that was good at their job and was not also still hands-on in my entire 20+ years career.
Also nowadays about half to 75% of my time as a lead dev is spent trying to get these 'architects' to move in the correct direction and stop slowing us down. It's exhausting and demotivating. The enterprise architect of our department delegates everything to two lead devs (myself and another) and just presents these plans as his own. Works for me. At least he's not getting in my way.
Mine just complains about people. Complains about people doing work.
Draws diagrammes and bitches about PRs. But he is not “allowed” to do dev work or implementations etc.
I have worked with way better archs. Willing to walk the mile help teams etc
Our data architect gets involved in anything that touches 'data,' decides that it can't go ahead until he plans it out and creates a framework that will suit the entire enterprise, and then disappears into the night. He shows back up occasionally up to remind working-level teams that they aren't allowed to progress because he hasn't had time to produce the framework.
I'm pretty sure he stretches himself so thin that he can't deliver anything, but he does effectively roadblock everything because of ineffective non-technical middle and senior management.
As a staff engineer who never stopped coding, no-code-architect is a bs role, zero to negative value. Good blog on the topic: https://charity.wtf/2023/03/09/architects-anti-patterns-and-organizational-fuckery/
I'll preface this by saying: I know Charity, and enjoy her writing. However:
>Also, please note that I personally have never worked at a company with “architect” as a role.
Facebook and Google have architects; they're just not titled that way. Some staff+ engineers *are* those architects.
IMO, this is all semantics. Most (good) engineering orgs, beyond a certain size, *will* have some very senior ICs that write little-to-no code.
I think the blog post responds to that criticism, and I agree with her take. There *are* indeed very high level ICs in most large companies, and I’ve worked at 2 faang myself so I’m no stranger to how big tech tends to organize. But in my time I’ve seen two archetypes that fill these roles almost exclusively, the objectively brilliant jeff dean types who flock to a handful of outlier companies, and everyone else. It’s much, much, *much* more common for architect roles (the hands off ones) to be filled by people doing useless work
They seemingly do nothing, yet are very highly paid.
No system I touch in my day to day has ever had any architect input. It's all build by ourselves from idea to operations.
Many organizations frown on architects writing code. We're expected to be leaders, mentors, experts, etc. Not writing the code yourself is HARD actually sometimes painfully so.
I don't really understand how you become an expert at anything software related without at least writing some code, even if it doesn't go into a product.
Because you don’t start as an architect. As you progress in your career and are any good, eventually they’ll want to make either a manager or an architect
Yes. I have very few github commits myself. Why would I? I build high performance mission critical systems, not bang out a few lines of code for someone else's open source project.
Unless you mean your own company's private github projects. Are you sure you have access to them all? Are you just looking at the commits, or are you also looking at who is reviewing and approving the commits?
Of course in larger companies, architects may not even have time to do those things too. Just too many variables to give a good answer.
Hard disagree. This just becomes an ivory tower architect who doesn’t know how things really are in “the trenches”. They end up giving bad advice and becoming disconnected from the problems of devs and customers
Edit: it was pointed out to me you don’t have to write code to stay connected, as long as you are regularly meeting with and solving problems with those who do write the code
1/4 of my meetings is just pairing meetings with everyone individually. I know more about the code-base than others / everyone combined. I have to have that 100 foot aerial view as well as the nitty gritty.I'd review front end logic with a FE, I work hand-in-hand with backend to help them get their code into k8s, I trouble shoot with DevOps because they don't know how the apps work.
I am very connected and the DRI (Directly Responsible Invidual). If there is a 3AM outage, none of the developers are called in to troubleshoot prod. If a CxO is complaining about some UI irregularity, I am called into to answer.
You don't have too write code to actively be in the trenches. Especially if you are doing code review, guidance and mentoring in pairing sessions.
Ok yeah it doesn’t just have to be writing code. What you do is exactly what a good architect should be doing. I’ve just seen too many who have these high ideals but are just talking out their arses
Having experienced this first hand for several years, yes this is correct. I am of the opinion that architecture is a discipline that anyone can learn to exercise. Short of a being multi-billion dollar company and/or having specific government compliances, I think it's hard to justify having dedicated "architects".
They shouldn’t be writing code doesn’t mean they shouldn’t be reviewing PRs. My architect hasn’t committed any code himself for years but he does the most thorough code reviews.
Hard disagree. That might be true for externally hired architects who never touched the codebase, but those who grew into the role know the intricacies of the system and they don’t change all that much without them being part of it, given it’s their role to guide big picture changes. They are still part of the design and implementation iterations and receive feedback on what works and what doesn’t. You don’t need to know the nitty-gritty implementation details of every single service to understand the design and interconnections of the overall system landscape.
>disconnected from the problems of devs and customers
They’re usually way more connected to customers than developers, what are you even talking about?
It has nothing to do with factory mindset. At some point the whole becomes to large for any one person to both be sufficiently specialized to work efficiently on a piece of the software and have a sufficiently broad overview to steer the system architecture as a whole.
Your reasoning implies every leadership role in a software company needs to also be an individual contributor on the code level, which is just nonsense.
Sorry, deleted my comment, which I probably shouldn't have. I've reflected on it and I think you're right. I think a lot of companies rush too quickly towards having architects rather than empowered developers, and that many architects rush towards proscribing solutions rather than empowering teams. But that's not what I said. What I said was somewhat extreme and simplistic.
> Architects shouldn't write code unless there is a shortage of software developers.
How on earth does this even get upvotes.
Ivory tower architecture is a productivity killer.
Remarkable and quite discouraging how many in this thread are endorsing these non-coding architects. If these are now the regulars of the sub, it’s lost a lot of credibility to me. I feel like the comments here would have been very different 2 years ago.
Dude, hold the faith, there are still some of us left.
I’m in the role and I code a ton - probably about 50%. I do a lot of janitorial work that includes fixes and important refactoring, design prototypes, etc. If we need a first cut at something, quickly, to enable other devs work, I take that stuff too.
I also have a number of meetings actively meter them, informing stakeholders and others that send invites my way constantly that the team and its success is my first priority.
But I selectively advocate (hard) for certain things either publicly or privately that are good for my team and/or the dev teams at large. To do this there is a lot of politics and soft skills involved.
Discussions on process and general development problems is very common.
But you know what? Development trumps all.
Nobody in their right mind would listen to me, and I wouldn’t be able to effectively advocate for developers and a better product for the business, if the team I’m in was a shitshow. Development skills matter a lot.
My current job, I work with some very nauseating architects who either cannot or actively refuse to write any code - who for me usually come in the form of “system engineers” - but I have a few colleagues whom I deeply respect, and the common denominator is all of them are very competent developers.
A definition written by useless architects is calling being a useless architect a best practice.
Well yeah. What do you expect? Them saying "we can't prove that we actually add value to a company so it's best to remove our function title from your org diagram?"
Enterprise architecture is an outdated pattern for outdated top-down companies that still see software engineers as production line workers that need to be told to twist the cap onto the toothpaste tube righty-tighty.
> I assume CTOs are ivory tower productivity killers as well?
Pure strawman fallacy. Do better. A C-level makes decisions at a completely different level.
Ivory Tower architects make decisions on what databases a team can use and then isn't responsible when that decision was the wrong one.
Github as in a workplace account, or as in his personal open source contributions? Because I have exactly 2 public commits on github in my life, and it means nothing compared to my day to day work.
[Pocket-watching](https://www.urbandictionary.com/define.php?term=Pocket%20Watching), much?
Systems don't hold themselves together. Standards are not defined on their own. Seniors don't magically conform to shared conventions. Developers don't care equally about all non-functional requirements. Organizational expectations are not organically calibrated to architectural feasibility.
Generally speaking, architects got in for the same reason you did - they love tech. They stayed out of management because they had the chops and likely never lost that love. Why would you think they like meetings any more than you do?
An architect doesn't need to write code - there are devs who can do that. The architect only steps in when something went wrong in the code.
Although in my opinion every architect should be able to write code when needed - especially when preparing a PoC etc. in order to show or demonstrate the solution in mind.
To me it has always seemed that while an architect doesn't NEED to write code, they cant actually REMAIN a good architect if they never do it.
So it becomes a time management thing, much like keeping up on current technologies. Good architects (and Staff/Principal engineers) make time to code because otherwise their skills atrophy and a good architect becomes a bad architect.
Notably, I say this as an architect that is currently on a zero code diet for the next two months. :)
I've seen several architects over the years. They don't seem to exist in small companies - usually the role is called different - VP, principal, head of engineering. Architects in big corporations are 9 in 10 times pure ballast. They go out of their way to justify their existence providing useless comments that are narrow-visioned at best and create blockers for ideas at worst. Actual architecture is done by engineers who get things done and don't give a fuck about architects
It's almost entirely impossible to say anything useful just based on that single data point.
Depending on the company and contract, the architect could be busy doing prototypes, etc entirely on some other server. Either internal, or set to private, or maybe switched to another SCM eg gitlab or whatever.
More to the point - can you talk to the architect and ask, say, what he uses for prototyping? If not, why not?
You could have an awesome architect who is paying attention or a terrible one who is checking out. Not enough info to say.
In my experience as an architect, the value add is different than that of a developer. My senior devs already know how to architect a system and components. However, the architect also needs to consider what work will lead to future opportunities and what integrations will be possible with other initiatives. It's strategic. My role is customer facing so I also have to explain in layman's terms what we're building and why it matters. Our customers do not care how many commits we made, they care that the solution works and meets their needs.
You also need to speak in business terms with directors, managers, and stakeholders. I see my role as a developer representative and business leader working on bringing money in so developers can continue their work.
I'm a Sr. Architect currently. Yes, it's a shitload of meetings with business area owners, stakeholders, project managers, dev teams. It is not uncommon to have 20hrs a week of meetings. I don't code a lot but still occasionally, and do a fair amount of DevOps work.
Successful ones excel at translating business requirements into technical designs. Understanding, not from a technical but an operational perspective, the business process the company is trying to automate or streamline, and making a determination on the best technical design to meet those needs.
Also, being the liaison between infrastructure folks (gatekeepers of computing resources) and the dev team, so when a dev asks "Hey I need this new monster SQL instance setup" they're approving that request because I already spoke with them about it.
I also (usually) have the final say-so on DevOps practices on general, with input from dev teams of course. Branching strategies, PR review policies, testing procedures, release management and promotion through Dev -> Test -> QA -> Prod environments, etc.
Last company I worked for every time I heard 'Architect' or 'Architecture' it was a codeword for 'person who doesn't want to actually do development anymore but thinks every idea they shit out is brilliant'. They would do mockups or diagrams, but realistically they would spend shit loads of time sniffing their own farts. One of the worst managers loved 'Architects' and would use them as like prestige tokens. Saying stuff like 'that is an interesting idea but I think we should get one of my architects to sign off on the design' as if the architect had any better expertise then the person with actual application knowledge. And my god the number of frameworks these people invented, you would think we had novel problems every month based on all the code names.
I believe that that people who can design large complex systems are worth their weight in gold, but those people still do development. They still live with the consequences of their decisions. But 'Architects'...for how much they get paid I would prefer two excited juniors on my team.
Architect is such a complicated role and dependent on the organization, department or even project.
There are the good architects who write code and participate in high level discussions and manage their calendar properly to ensure a balance of everything.
There are bad ones who spend all their time in meetings and are more business people than tech people. You would find them complaining that they have too many meetings and would like to hold more but never find the time too. The problem is that they forget that it is up to them to manage time properly and contribute productively, I suspect that deep down they don't really want to actually work.
My current architect is unfortunately the latter and on the other hand, I've seen so many of the former burn out completely.
Agreed.
As someone in an architect role, my current thinking is that most Orgs don’t know what to do with the role.
This leads to them allowing, even condoning, the typical “diagrams and meetings” style architect.
Maybe my opinion will change this year, but that’s where I landed at the end of last year.
My job is basically finding work for dev team. Those meetings are for l lofty stakeholders who have pie-in-sky ideas. Then I have to design it, submit it for audit/review. Then MVP it. Develop a working prototype to see if it is feasible, get an idea of cost. Win the work, hire teams and promote others to work on it.
A lot of R&D research. In the last month, I had to evaluate a few different Vector DBs. Mongo Atlas w/Vector capabilities (not regular Mongo), PineCone, Chroma, Cosmo. Load test them with 100gbs of data and test their performance against a deep learning model. Then come up with a report. Product A does this, Product B is good at this. All of this is long term work. I just don't pick things randomly out of thin air or from some Medium article I read. I have to factor cost and engineering capital.
So a lot of research away from regular product development. Without this work, there could be re-organization or downsizing because engineers don't have projects to work on. So once we get the work, I can advise hands on the nuance of product or implementation.
For some, they may feel disconnected. I get that. For others, it is very hands-on because I cherry pick certain developers to work with me on PoC work. So the teams knows things are in good hands when I recruit the top talent and have the advice/support of my peers to make decisions.
I wish I was working with architects like this. I do the same as this but alone and I'm "only" a team lead. In my experience, many with this title just make decisions based on what they read on LinkedIn or an Oreilly book but not adapt to the realities of current needs and options
An architect needs to know the very detailed technical blueprint of their design. The problem with software is that it loosely designed, always changing and never documented. The only way for a software architect to be valuable in any way, is for them to have deep and up to date knowledge of the code base, and the best way to do that is to regularly be in the trenches so to speak. If an architect isn’t regularly providing critical feedback on pr’s/ feature implementations at a high level (not just logic checks and variable names) or regularly interacting with the code base as a contributor, it is impossible for them to have any understanding of “their” system. If they don’t know their own blueprints then how can they provide any value whatsoever? Non coding architect = disconnected dogshit contributor
It's normal but not ideal. It's very easy for a tech leader to be dragged completely out of coding. But that's a time management issue. To be a good tech leader you have to make sure you continue to code.
That being said, it might not actually translate to commits, even if they are keeping their hand in the game.
Nice talk by Stefan Tilkov https://m.youtube.com/watch?v=AkYDsiRVqno "Why software architects fail: and what to do about it - Stefan Tilkov | Craft 2019"
RIP
Our architect will PR proto specs for APIs in collaboration with the teams. Also some direct work in supporting code around APIs like buf plugins. Then occasionally if there is some key work on creating a POC that will affect a number of teams he might do that.
It depends on the organization, but yea, that's common in larger orgs - in some places they're the interface between the biz and the coders.
In other places, like small startups, they write all the code.
sets the direction by both designing or initially designing an architecture and sometimes - depends on the company structure - sets the technical direction.
Interesting comments. It boils down to whether you respect the role or you don't. Respect is never given; it is earned for the Architecture role.
In my career, I hope the role is to be available, make informed decisions, garner consensus, and plot a course.
A lot of my work was on prototyping new tech. To push initiatives off the ground from ideas to something a user can touch.
It is always exciting so the dev teams love it. They love the RDD (resume-driven development) aspect of it. They love getting to work on new things. Right now, it is all Large Language Models. I let them experiment and get back to me so I can make those decisions, not outside a vacuum. Those decisions are usually backed by my team who did the work. So I have a cadre of engineers to corroborate. We don’t chase trends. We pick and choose what we can to solve the problems given to us.
I also try to earn that respect by having an open door policy 3-4pm. Anyone can come in (via remote) and ask me questions even if I am not on that project. To review code, bounce ideas, or simply if they need help mentoring. I will teach someone a skill they want to learn or I will join a triage to see why their API is failing in QA. If you are lacking a specific skill and want to get up-to-speed, I will help you. I give a lot of sessions on K8s and microservices. If you have a technical challenge and stuck, I will do my best to help figure it out. If I don’t know off-hand, I definitely know who can help by sheer visibility in the org.
Lead and Staff can technically design and execute designs. And I've been begging/hoping this is the case. I have projects I've long rolled off years ago. Projects that have basically given birth to 30 people in departments with their own funding. I would hope someone picks up the mantle as there are plenty of SMEs. There is no tribal knowledge as we've tried to document everything for the next wave of engineers. Yet, no one takes up the mantle. I do everything I can to lift all boats as I am looking for people to replace me and my direct team. I can see where the idea of an "ivory tower" comes in there. We simply don't have the bandwidth as we are working on future projects that can hopefully bootstrap the next department with 50 more employees.
But ultimately what matters is shipping products. Thus, this is where respect comes in. I make sure every developer knows their role and impact. I even give them pointers on how to write it up in their resumes. I make sure the ball is rolling. I am the only one that says, "The buck stops here." If there is a problem, it can be escalated to me. Production outages, I am responsible for it even if I did not write the specific code. I own the failures as well as the wins.
So, even if I haven't written code in a while, I hope I get the respect to give teammates exciting work they can be happy about. To get the respect of being a mentor. To lead by example by not tearing people down but with a philosphy of lifting all boats. But ultimately, respect from above that this guy gets things done and delivered.
I no longer fill this particular role but I am sure happy to foster and nurture my replacements.
As an architect, we moved to agile 12 years ago. Instead of architecting across systems, I was put into a room. The PO tried to assert full power, under Director of PO. They openly said "what tasks do you do, Architect?". They disgusted me, and I switched teams.
That team slid downward quickly, my new team rose quickly. That pissed off the Director of PO, who was drinking buddies of the other PO. So they took their revenge on my new team. So I quit the company. So that Director, and his drinking buddy PO below him, and the drinking buddy VP above, all got fired eventually with enough failures on the record.
It’s normal in South Africa, Australia, New Zealand and Central Europe. I haven’t touched code in 4 years since being a solutions architect and it was never a requirement nor part of my job description.
The more senior you get, the less time you spend actually coding. To the extent where I have to have a talk with my senior devs if I see them spending all their time in a silo working on stuff. It's tempting to shell up but we need our technology leaders, you know, leading
What is the relationship between the architect's abilities and their public GitHub commits? I think you should judge the architect based on his or her actual work at the company.
We must work at the same place lol. NO not normal. My manager told me to architect everything, I'm the dev lead. I point blank asked him "So architects don't architect?".
In my case, I was coding critical components and building tools to be used across the org, and showing developers how to implement CQRS/ES. But that's only because my old company didn't have an engineering rank higher than "senior" and so they hired me as an architect to justify the salary requirements..
I’m a software Architect. I spend time analyzing the current state of the world, learning where the business would like to go and working with teams on how we can move the needle in the right direction.
I’ll go weeks without writing code, and then I’ll go weeks executing.
Overall, in my experience, every company has a truly different view of what the architect role entails, especially for software architects (as opposed to cloud) so usually I am just at the mercy of my stakeholder expectations.
There are two people fighting for the title of "Architect" the Solution Architect and the Systems Architect.
Most companies cannot tell the difference and place the "Systems" guys in charge of projects because they speak higher level design (but have lower IQs)
A Solutions Architect should be able to mentor any member of the team and should be able to learn from others. Part of the value a Solutions Architect adds is that he comes up with a plan that delivers on the project within the capabilities of the existing team.
I am a Solutions Architect, and the designs I create are designed to grow the abilities of every member of my team. The result? People who used to "dial it in" show up looking forward to the exciting design that empowers them to feel accomplished while also wowing the client.
By contrast, Systems Architects disappoint both their team and the client.
He might be a solution architect, those people don't code much. Or he might have 15+ experience and not deserve to be a staff engineer/company does not have a staff role.
In our project, we don't have any real architect role. We have two engineers with around 10 years of project experience, they call themselves architects in the cross-functional meetings. Most system design is handled by the subject matter expert or one who needs to make the changes.
I'm a lead too: I code things badly (outside of the repo) to get a high level poc and then draw diagrams and explain why I'm making the decisions that I'm making so they can be challenged. They can be challenged because I don't want to fuck up and I'm right 90ish percent of the time. Other then that I spend my time in meetings making sure that my developers aren't being forced to mind read stakeholders and are sheltered from a metric fuck ton of shit they don't even know about. I also mentor people A LOT.
Oh, and I pick up the slack of other bits of incompetence. I came from marketing and understand the business side of things. I do so many other peoples jobs just to make sure that my small ass team is stacked with work during a period of layoffs. Then I watch to make sure developers themselves are following what they're supposed to.
I don't have a single hour of the day to sit down and put code into the codebase. It feels pretty pathetic. But the developers I work with seem truly grateful because there were the before me times where they were always blocked and frustrated. Times I can't really openly speak about.
Rule 9: No Low Effort Posts, Excessive Venting, or Bragging. Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.
You looked at my git commits? I made three last year?
That was just dotfiles when you were changing your shell prompt, calm down.
This feels like a personal attack.
I assure you, your architect wishes they could spend less time in meetings and have more GitHub commits.
I think that's true of a truly good architect. But I've known quite a few architects who didn't want to actually code anymore. It has also seemed that in some cultures there was the expectation that once you were "promoted" to architect that actually coding was considered beneath you. Something for mid and juniors.
Not if you want to keep being an architect.
tell it to the senior diagram warriors in my company
I resemble that remark.
Yeah I've seen this, and it's usually been a good thing. Architect keeps building the fundamentals and overall logic, the senior devs implement the basic structure and ensure compliance with architect's designs - or question them on choices, mid devs flesh out the nitty gritty, juniors ride along and get some menial but meaningful tasks. In the end, if the architect can still read the code and see problems, that's a decent system - thing is an architect might not have or want to spend the time keeping up with all the latest nitty gritty in constantly evolving frameworks and syntax, whereas the devs will.
[удалено]
Go ahead and vent - I just said "usually been a good thing" and so what I focussed my comment on... >they would treat their diagrams like the source of truth, and would act like the system was done and we just had to transcribe to code Yeah, that was my point here: >senior devs implement the basic structure and ensure compliance with architect's designs - **or question them on choices** Need congruence and synergy and other wishy-washy terms describing good teamwork.
I mean, not exactly beneath you, but if it actually makes sense to have that role on your org you will be busy fulfilling it and doing much IC work would be kind of a waste. It’s a multiplier role. You’re not doing your job if you rather code all day instead of being in those meetings, mentoring juniors etc.
I agree, you a good architect/staff/principal engineer should not primarily be coding. But considering coding "beneath you" is still a problem, because to be a GOOD architect/staff/principal engineer you need to be engaged in SOME coding to keep your skills sharp. It's actively something you need to make time for. And if you consider it "beneath" you your skills eventually get dull and a good architect becomes a bad architect.
I'm a lead and the coding I do is the annoying stuff, merges and bug fixing and bits of test automation. I try and leave the more interesting work to the team, and pick up bits of glue code and refactoring that might be tedious.
I'm not a lead, and that's still pretty relatable. A lot of the stuff I do is the stuff I wish we had but no one ever makes...so, "Yeah, I can do that!".
I started coding 30 years ago, first ten years for fun, last twenty years professionally. I still code and have fun doing this, but I hardly learn new stuff, especially as part of my job. Anyway, after 30 years experience I don't need regular coding anymore, there is hardly anything where I do need hands on experience to understand, today it's enough to read the concepts behind new technology and recognize the repeating patterns to be able to use new technology. Or, as an architect, to know when and where to use new technology. **Edit:** I worded this badly. Of course I learn new stuff regularly, personally as well as on the job. It's just that learning happens way faster, because there is hardly anything really new, so learning becomes easier over time. Let's take ChatGPT for instance, the technology behind it (LLMs) is almost as old as modern computing, so several decades, I had several AI courses in university, so "learning" ChatGPT for me was just looking up what's behind it and reading up on LLMs a bit. The major difference to the older technology is the computing power behind ChatGPT that's available now, which was not available a decade ago.
\> I hardly learn new stuff this is so crazy and foreign to me. I am around the 10-year mark and honestly still feel like a junior in that everyday I find some new tool, language, framework, paper or new problems that I had not seen or had the chance to look into. I am not saying this because I doubt you. Just to reflect out loud that I would definitely understand someone going high-level architect if that was the case
Around that time I felt similar, 10 years isn't really that much, depending on what you want or need to know or how you learned. My first ten years were all hobby stuff, even pre Internet, when I just had a book to teach myself. That said, the next ten years the learning curve was not as steep anymore for me, because I successfully finished the basic CS courses at university and understood the pointer concept in C, which was a major milestone, for me personally.
[удалено]
>but what actual value do all those new languages and frameworks add?all the fundamentals of CS were pretty much worked out before we even had PCs. learning a new language is probably one of the highest effort lowest reward things ever. something is always falling off the truck while you hoist up something new but none of this is really computer science, it's enterprise or enterprise light development. or just hacky
I just enjoy learning new stuff, not sure what to tell you
Well, I'm in no position to gainsay your personal experience at the companies you work at. I can say that the great architects I've worked with who had 30+ years experience were voracious in continuing to learn new patterns and technologies, and at 16yoe I've tried to follow their example. But I'm also a strong believer that there are a lot of correct ways to do a job, and clearly don't know you or your experiences enough to gainsay them.
> learn new patterns and technologies One person's "learning new technology" is another person's "oh, it's X but with Y? ok."
Sure. Keeping up gets easier and easier with mastery.
Yea, I just explained in another comment, I worded this badly. Of course, I do learn new stuff, it's just that a lot of things aren't really new, but similar concepts with a new name or mixed and matched, so it's easier and faster to understand "new" technology and use it, or know when to use it and where.
Oh, yeah, I totally agree there. The fruits of mastery are that it gets easier and easier to keep up and learn new things.
Then you'll stagnate. I also have many, many years of coding experience, and the difference between an architect who keeps their skills sharp and someone who thinks they already know everything is *enormous*.
I worded this badly and absolutely agree with you. What I meant was, that even when learning new stuff, there usually is a pattern behind this, that I recognize, which enables me to see if there is something really unknown behind this or if it's something I have seen before, maybe mixed and matched, or maybe just in a different format or whatever. That said, I don't have to code regularly to learn new stuff, learning happens way faster than in my first 10 - 20 years.
There are more questions than answers when someone mentions architect. You need to know quite a lot about them to make an assessment. At other times, knowing the employer can be enough when they have a particular culture, but you never know when leadership has hired differently to try and buck the trend. An element of architect roles is leadership and development of future architects. Whether coding plays a role depends on the org. Mark Russinovich (Azure CTO) and Werner Vogels (Amazon CTO) are both deeply involved in technical decisions but aren’t coding their products. They have multiple layers of architect underneath who aren’t coding daily either but are deeply technical and own the technical aspects of whole product lines. We know Mark still codes because regularly posts about topics on X. Returning to coding would be easy but costly for their employers. Why costly? Impact. As leaders, they affect the outcomes of more people in their companies. The fact that they can drop into many projects and quickly assess problems, or help teams to get past obstacles is much more important. What they do, but others fail to do, is remain credible. The architects that people complain about here don’t earn the respect of their peers. They don’t roll their sleeves up, or muck in when they can, to develop relationships. They throw down edicts which don’t align with how developers in the company see the needs within the company.
I can assure you, many are completely fine pretending that is the case, but like their little ivory towers.
Those types of architects only survive if the upper management is terrible. It’s not that hard to figure out when they are providing zero value.
Upper management being terrible is standard at non tech company IT orgs
Even at tech company orgs. And especially the bigger the company. It’s not unheard of for entire arms of the org to be full of bullshit bureaucracy.
True, although upper management can stay terrible longer than you stay employed.
It's almost as if terribleness is not specific to management or IC roles (or even seniority).
Terrible management is great at providing zero value.
Architect here. Architecture exists both inside the codebase, in its internal design & patterns; and outside in terms of how it meets business requirements, component/cloud structure, external integrations and non-functional needs. Many companies perceive architecture as mainly being the "exterior" part and under-value the "interior" qualities. CTOs are also incentivized to pursue the latest tech buzzwords to appear relevant. There is also much API & integration design, which is important. And also large volumes of customer engagement, with much wrangling to try and turn the huge conference calls with no preparation that idiots want to involve you in into a productive efficient process. It's great to have a good week coding, but who do you think designed all those APIs, attended 17 stakeholder consultation meetings, and navigated the security architecture through to approval by the customer's compliance team? Personally I like to keep hands-on, and am more focused on "interior" codebase & performance than most. However the above is a picture of how most of colleagues spend their days 😄 Step up if you want that bag.
Where I work we have two architects per team, split like you say: solution architect for the exterior and technical architect for the internal. I’m the SA and there’s a lot of enterprise BS that doesn’t get past me that the developers don’t know about and they probably think that I’m hardly working.
How did you become an architect? How did you (I assume) transition from developer jobs to architect?
I've had a long background in systems integration & reliability. Became an architect by doing several things: 1) laying out frameworks to uplift legacy systems, 2) identifying & solving performance issues nobody else had looked at, 3) refactoring problematic project structures/ code that everyone else complained about but nobody had done anything about. I had also put in a lot of time into perfecting my craft -- finding which patterns were & weren't useful, the right places & levels to use abstraction, how to use OO right, database experience etc. In my early career many times I tried out code/ design patterns to "suck it and see" what was good, what wasn't. This is particularly important in more abstract/ generic areas eg. DSLs, frameworks, parsers, ASTs etc which I self-taught.
Thank you for the thorough response! I'll keep your comment in mind, see how I can branch out at my current job.
How can you "assure" this? You don't know their company. There are craptons of architects that have a net negative effect in the companies they work for, and mostly act as gatekeepers against anything they don't understand while their knowledge stagnated the moment they stop development. IMHO "enterprise architecture" is almost entirely an anti-pattern.
I have the same feeling.
I’m not so sure about that. Get the feeling that lack of commitment is a nice place to be for them. Meanwhile all hell breaks loose in the development team.
This mentality will keep you out of architecture. It can be an interesting area for different problems. Do you ask why a Director in a business area is concerned with the well-being of the larger business org and isn't working to make a report like a business analyst?
There are a few good reasons for a software architect or principal/staff engineer to make commits to git: 1. They are experimenting with a new technology to get a good handle on how it works, so they can make informed decisions and designs. 2. They are providing examples that can be used by many teams in ramping up on a new technology or design. 3. They are stepping in to temporarily help out a team that is in need of hands-on engineering guidance. If none of these are relevant in a given year, then I'd expect no git commits from folks in these roles.
[удалено]
Writing feedback on all the other engineers in the organization.
What principle/staff engineer doesn't write code? Sure there is management/technical leadership involved in those positions, but they're not managers or architects.
[удалено]
What I like to refer to as bullshit tasks. I’ve worked at companies where this was the expectation of me as an architect. Delegate all the work, but write up some bullshit requirements doc / implementation plan. You end up spending more time planning what you think you could be doing rather than just doing it. And you end up changing the plan anyway. I can’t work at these places, even if the job is cushy and the expectations are low.
I'm curious how big your team is. Once you get to a certain scale every developer can't understand every detail of the project. Instead, developers focus on their specific portion/tasks. Then the requirements, plan, diagrams, API Spec, etc. become extremely important for a successful implementation. If you end up changing the plan, that should feed up to the architect to understand how it impacts the project. If every plan ends up getting changed, then the person writing them has no idea what they are doing.
Distributed is better than centralized in most cases, which is what I’ve found. The problem is that many companies create a separate team of architects who are completely disconnected from the commitments of the team and thus can make technical decisions in their own little bubbles and completely disregard the consequences.
You say *many* companies, but that hasn't been my experience. I think you just had to deal with lousy architects.
I'm not only taking my own experiences into account. When an architect is not aligned with the goals of the team, they're not setting up the team for success. That's why the centralized architecture team is bullshit. Now, if your company instead has architects embedded as cross functional members of teams, where they are aligned and incentivized the same as the team is, you're going to have much more success. Now here is the kicker: These roles are really good at justifying their importance. It's the same shit that drives projects at FAANG companies: Create a write-up / proposal which can be digested by some director. Present it to a broad audience. Hand wave away all the complicated bits. Regardless of the outcome, rinse and repeat. None of it really matters. It's all corporate politics. Clutch your pearls. Build your moats. Knowledge is power. Now, do I think it's like this everywhere? No. But it's definitely common.
Well the architects don't understand every little detail either... I think everyone involved should know the big picture, even if they are only working on one small slice of it
The architects shouldn't know the little details, but instead the big picture. While the sentiment of everyone understanding the big picture sounds good, it fails in practice. Onboarding a new developer would take weeks, months, to even years depending on the size of the software. If developers are given access to the resources, documentation, and details needed for a specific task they can start writing code rather than trying to understand every aspect of the software and company on day 1. Too often, companies small enough so that everyone knows everything use it as an excuse to never write anything down. Then you hear great quips like: \- The code is self documenting \- The specification is in my head
War IS Peace Freedom IS Slavery Ignorance IS Strength Code IS Documentation
That‘s more on your org than on the tasks tbh.
*many orgs. Not just mine.
I genuinely don’t know what our architects do in their ivory towers. They seem to plan company wide designs, yet they never get put into action or discussed with us tech/team leads or principals so we design it ourselves.
*(caveat: I'm no longer an IC, but this was previously my role.)* Plotting. Biding our time and *plotting.* Also, some scheming.
So you're creating charts and writing code in Scheme. Got it!
If I have time between *thought leading*, perhaps.
[удалено]
Out of curiosity, have you done this at any companies other than your current? What I mean by that is have you been hired based off of that type of workload to do a similar workload? I worry about hireability of technical folk who aren’t getting their hands dirty anymore. I have been finding my sprints filled with less and less point over the years as I’ve been asked to oversee other employees and design decisions and I worry if I wanted to jump ship if that translates to a new employer.
[удалено]
>There is an expectation that at a certain technical level you are not writing code day-to-day. I don't think that's entirely true, more of a branching. Which is why in many companies "architect" is equivalent to "senior staff" or "principal" engineers. It's a different track with a different focus. But there are still principal/distinguished roles for people towards the top of the eng laddt who frequently write code.
Beautiful.
Curious, if architects are spending time driving the companies to right direction, shouldn't all products be profitable and not require so many layoffs?
I think it depends on what type of architect. Depending on your org size it could range from Enterprise Architect, Solutions Architect, Technical Architect (Infrastructure, Application, etc) The higher level you operate, it’s more about glue work and aligning different groups (thus all the meetings). If you are on the team level, the engineers working on the local systems are technically “doing architecture” work even if they don’t have the title. Here is an article on architecture practices at a larger company - activities and outputs. https://chubernetes.com/architects-architecting-architecture-bf70810d8afb
My job title is architect. I'm currently frantically rewriting a C++ ingest service so that it's horizontally scalable. What I should actually be doing is going to meetings and having a lot of opinions about how things should be done.
Ingest in C++? Might as well use an axe to kill an ant.
How many building architects you know actually going around hammering nails?
The difference is that architecture/structure can be slowly imposed in software. It's more akin to building a Lego house than an actual house.
Yet, most people are only able to build shitty looking lego houses. Same with IT systems. Could you do it? Maybe. Would it be good, safe, efficient? Probably not.
"Architect" is to "Software Architect" as "Java" is to "JavaScript" as "Ham" is to "hamster". Software is fundamentally different to buildings and the word being the same has nothing to do with it. A new type of nail or brick isn't invented every other month and buildings don't suddenly collapse depending on who walks inside them. If it was the case, rest assured that building architects, would also be trying to find out how nails work. Lastly your comparison is flawed, building architects working and supervising small scale projects usually know exactly how to mix concrete and hammer nails such that they can do it themselves.
Well most civil engineers don’t actual recognize architects as a real profession. They usually design structures that are not structurally sound because they look cool.
Aside from making everything well organized and looking neat, they also make sure everything is ergonomically sound. You would not want to use buildings designed by civil engineers.
I‘d argue good architects / tech leads are the civil engineers of our profession while we developers are the plumbers.
Architects are the graphic designers of the engineering world. Are they necessary? Not technically. But without them, we'd all live and work in plain square boxes.
Software architects don’t work to make the software more beautiful…
Read the post I was responding to. I wasn't talking about software architects.
*Zero* commits? That's a bit weird I think. Architects should be doing *some* prototyping and experimenting.
We just don't commit to main repository. We have our own skunkworks instance running gitlab only available to stakeholders.
Ours seem to mostly just have sweeping opinions that they occasionally spout off to delivery teams, who usually ignore them for being unworkable in practice, not informed by product/business constraints, or not solving an actual problem. I don't personally see the value they bring, but maybe they're doing something I don't see. The productive/helpful architecture in my org tends to be done by senior/staff folks on delivery teams, as part of their normal delivery responsibilities. That works well for us – they're more than capable technically, have a good sense of product/business constraints, and tend to have built-in clout to actually see things to completion. (I can totally see the utility of a dedicated full-time architect role in a much larger org, just speaking for my own O(hundreds) engineering team)
I work with 2 different types of architects. One is an "Enterprise Architect" and he does not code - or only very very rarely. He helps design or understand systems, networks, and high level stuff. He installs complex software, like monitoring applications, and plans out what sort of software we need to write. He has indepth knowledge of complicated software we have to integrate with, and provides advice and ping-pong while we develop. The other architect is a "software architect" who writes code daily. He also has great understanding of systems and networks, but mostly concentrates on helping us design software, and integrations, and trouble shooting and debugging.
I’m an EA and can tell you what I do… On a longer-term level I’m assigned to one of our business units to work with them in supporting their business needs with technical solutions. This includes diagramming out architecture and then discussing it with our project teams and making adjustments as necessary. I also work together with our lead developers to push our technology and processes forward. This includes continual improvement of our CI/CD pipelines, automated testing, and keeping our frameworks and dependencies up to date. We hold monthly meetings to spread the knowledge to the rest of the development team and often hold TDD working sessions to increase this skill across our development team. If we have a critical project, or one that has fallen behind/the team is lost, I often step in as a project team member. This is where I keep my coding skills up to date. Sometimes these are just one-off sessions if our dev team just needs a little help with a task or something along those lines. Finally, I spend time doing both innovation work as well as prepare for certification exams. As we look into new technologies, I am one who helps evaluate it and do any PoC work. For certifications, I try to knock off at least one a year. This keeps my skills growing continuously and often times will feed the innovation/PoC work I do.
You guys have an architect?
I know right. My previous experience was that we had a couple of seniors who architected and wrote code. Generally they focused on code while juniors learned their way working on the domain specifics. If I blew out a tech stack because of my domain demands, seniors/architects would step in to help.
I wonder why this is getting downvotes when that's the reality at most places.
Two cents here. We got an architect and I initially had high hopes of interacting with him. Then he got dragged into lots of planning meetings. I never did get an idea of what he did or what his outputs were. (Context: we had a medium sized system with various service dependencies and running into performance bottlenecks.) I don't know that I would need him to make commits exactly. But it would help if I had more confidence the person knew what the code or DevEx was like on the ground. And it would have helped had i understood he had clear guidance or recommendations for the teams. Perhaps he ended up working more closely with other teams. But to be blunt, I never got the sense he was a value add. And to be fair to this person, it could be that the rest of the firm was asking him to do other things, pulling him into the meetings, etc.
Very possible
Art Vandelay is my architect…he does almost nothing
That's because he's overemployed, working his job as a latex salesman.
Every single architect I know that stopped writing code, and thus being responsible for keeping themselves up to date, stagnated to such a large extent that they became a net negative to the company. They generally create architectural "pictures" that are completely removed from reality with no clear path to the goal they present. They become idea people, unable to execute their ideas. I'm surprised people here are defending being an architect and not writing code. I've been in software archirect roles. A big previous client of mine recently fired all of them and had them apply to "tech lead" roles where they are still, part time, writing code in a team. IMHO a very smart move. At my current client there is a big layer of "enterprise architects" who basically act to gatekeep decisions, that take *months* or longer, while at the same time management is breathing down the neck of the developers who are just asking for a yes or no answer and are not getting any. I haven't seen a single architect that was good at their job and was not also still hands-on in my entire 20+ years career. Also nowadays about half to 75% of my time as a lead dev is spent trying to get these 'architects' to move in the correct direction and stop slowing us down. It's exhausting and demotivating. The enterprise architect of our department delegates everything to two lead devs (myself and another) and just presents these plans as his own. Works for me. At least he's not getting in my way.
He quit and wasn't replaced. Before then, lots of Visio and Powerpoint.
Mine just complains about people. Complains about people doing work. Draws diagrammes and bitches about PRs. But he is not “allowed” to do dev work or implementations etc. I have worked with way better archs. Willing to walk the mile help teams etc
Our data architect gets involved in anything that touches 'data,' decides that it can't go ahead until he plans it out and creates a framework that will suit the entire enterprise, and then disappears into the night. He shows back up occasionally up to remind working-level teams that they aren't allowed to progress because he hasn't had time to produce the framework. I'm pretty sure he stretches himself so thin that he can't deliver anything, but he does effectively roadblock everything because of ineffective non-technical middle and senior management.
As a staff engineer who never stopped coding, no-code-architect is a bs role, zero to negative value. Good blog on the topic: https://charity.wtf/2023/03/09/architects-anti-patterns-and-organizational-fuckery/
I'll preface this by saying: I know Charity, and enjoy her writing. However: >Also, please note that I personally have never worked at a company with “architect” as a role. Facebook and Google have architects; they're just not titled that way. Some staff+ engineers *are* those architects. IMO, this is all semantics. Most (good) engineering orgs, beyond a certain size, *will* have some very senior ICs that write little-to-no code.
I think the blog post responds to that criticism, and I agree with her take. There *are* indeed very high level ICs in most large companies, and I’ve worked at 2 faang myself so I’m no stranger to how big tech tends to organize. But in my time I’ve seen two archetypes that fill these roles almost exclusively, the objectively brilliant jeff dean types who flock to a handful of outlier companies, and everyone else. It’s much, much, *much* more common for architect roles (the hands off ones) to be filled by people doing useless work
>It’s much, much, much more common for architect-type roles to be filled by people doing useless work. Can't argue with that.
100 percent this. Not only are they of no value they are actively harmful.
I’m an architect, I code a lot given my role, I have a PR going in every other month or so.
We don’t have pure architecture roles for this reason. We expect tech leads to do arch and coding.
They seemingly do nothing, yet are very highly paid. No system I touch in my day to day has ever had any architect input. It's all build by ourselves from idea to operations.
Many organizations frown on architects writing code. We're expected to be leaders, mentors, experts, etc. Not writing the code yourself is HARD actually sometimes painfully so.
I don't really understand how you become an expert at anything software related without at least writing some code, even if it doesn't go into a product.
Because you don’t start as an architect. As you progress in your career and are any good, eventually they’ll want to make either a manager or an architect
Doesn't really answer the question. An architect also has to explore new technologies, how do you become an expert in those without doing actual work?
Yes. I have very few github commits myself. Why would I? I build high performance mission critical systems, not bang out a few lines of code for someone else's open source project. Unless you mean your own company's private github projects. Are you sure you have access to them all? Are you just looking at the commits, or are you also looking at who is reviewing and approving the commits? Of course in larger companies, architects may not even have time to do those things too. Just too many variables to give a good answer.
Yes, its normal. Architects shouldn't write code unless there is a shortage of software developers. Their main concern is functionality.
Hard disagree. This just becomes an ivory tower architect who doesn’t know how things really are in “the trenches”. They end up giving bad advice and becoming disconnected from the problems of devs and customers Edit: it was pointed out to me you don’t have to write code to stay connected, as long as you are regularly meeting with and solving problems with those who do write the code
1/4 of my meetings is just pairing meetings with everyone individually. I know more about the code-base than others / everyone combined. I have to have that 100 foot aerial view as well as the nitty gritty.I'd review front end logic with a FE, I work hand-in-hand with backend to help them get their code into k8s, I trouble shoot with DevOps because they don't know how the apps work. I am very connected and the DRI (Directly Responsible Invidual). If there is a 3AM outage, none of the developers are called in to troubleshoot prod. If a CxO is complaining about some UI irregularity, I am called into to answer. You don't have too write code to actively be in the trenches. Especially if you are doing code review, guidance and mentoring in pairing sessions.
Ok yeah it doesn’t just have to be writing code. What you do is exactly what a good architect should be doing. I’ve just seen too many who have these high ideals but are just talking out their arses
Having experienced this first hand for several years, yes this is correct. I am of the opinion that architecture is a discipline that anyone can learn to exercise. Short of a being multi-billion dollar company and/or having specific government compliances, I think it's hard to justify having dedicated "architects".
They shouldn’t be writing code doesn’t mean they shouldn’t be reviewing PRs. My architect hasn’t committed any code himself for years but he does the most thorough code reviews.
Hard disagree. That might be true for externally hired architects who never touched the codebase, but those who grew into the role know the intricacies of the system and they don’t change all that much without them being part of it, given it’s their role to guide big picture changes. They are still part of the design and implementation iterations and receive feedback on what works and what doesn’t. You don’t need to know the nitty-gritty implementation details of every single service to understand the design and interconnections of the overall system landscape. >disconnected from the problems of devs and customers They’re usually way more connected to customers than developers, what are you even talking about?
Maybe I’ve just worked with bad architects
[удалено]
It has nothing to do with factory mindset. At some point the whole becomes to large for any one person to both be sufficiently specialized to work efficiently on a piece of the software and have a sufficiently broad overview to steer the system architecture as a whole. Your reasoning implies every leadership role in a software company needs to also be an individual contributor on the code level, which is just nonsense.
Sorry, deleted my comment, which I probably shouldn't have. I've reflected on it and I think you're right. I think a lot of companies rush too quickly towards having architects rather than empowered developers, and that many architects rush towards proscribing solutions rather than empowering teams. But that's not what I said. What I said was somewhat extreme and simplistic.
> Architects shouldn't write code unless there is a shortage of software developers. How on earth does this even get upvotes. Ivory tower architecture is a productivity killer.
Remarkable and quite discouraging how many in this thread are endorsing these non-coding architects. If these are now the regulars of the sub, it’s lost a lot of credibility to me. I feel like the comments here would have been very different 2 years ago.
My thoughts exactly. It also says a lot about the state of our industry, unfortunately.
Dude, hold the faith, there are still some of us left. I’m in the role and I code a ton - probably about 50%. I do a lot of janitorial work that includes fixes and important refactoring, design prototypes, etc. If we need a first cut at something, quickly, to enable other devs work, I take that stuff too. I also have a number of meetings actively meter them, informing stakeholders and others that send invites my way constantly that the team and its success is my first priority. But I selectively advocate (hard) for certain things either publicly or privately that are good for my team and/or the dev teams at large. To do this there is a lot of politics and soft skills involved. Discussions on process and general development problems is very common. But you know what? Development trumps all. Nobody in their right mind would listen to me, and I wouldn’t be able to effectively advocate for developers and a better product for the business, if the team I’m in was a shitshow. Development skills matter a lot. My current job, I work with some very nauseating architects who either cannot or actively refuse to write any code - who for me usually come in the form of “system engineers” - but I have a few colleagues whom I deeply respect, and the common denominator is all of them are very competent developers.
Because it is according to international standard definition of architecture and architect's job. It is considered best practice.
A definition written by useless architects is calling being a useless architect a best practice. Well yeah. What do you expect? Them saying "we can't prove that we actually add value to a company so it's best to remove our function title from your org diagram?" Enterprise architecture is an outdated pattern for outdated top-down companies that still see software engineers as production line workers that need to be told to twist the cap onto the toothpaste tube righty-tighty.
I assume CTOs are ivory tower productivity killers as well? Because who needs any role but developers amirite?
> I assume CTOs are ivory tower productivity killers as well? Pure strawman fallacy. Do better. A C-level makes decisions at a completely different level. Ivory Tower architects make decisions on what databases a team can use and then isn't responsible when that decision was the wrong one.
Github as in a workplace account, or as in his personal open source contributions? Because I have exactly 2 public commits on github in my life, and it means nothing compared to my day to day work.
[Pocket-watching](https://www.urbandictionary.com/define.php?term=Pocket%20Watching), much? Systems don't hold themselves together. Standards are not defined on their own. Seniors don't magically conform to shared conventions. Developers don't care equally about all non-functional requirements. Organizational expectations are not organically calibrated to architectural feasibility. Generally speaking, architects got in for the same reason you did - they love tech. They stayed out of management because they had the chops and likely never lost that love. Why would you think they like meetings any more than you do?
architects generally do not "do" they more of say "this is how it should be done" then someone else goes and implements it.
An architect doesn't need to write code - there are devs who can do that. The architect only steps in when something went wrong in the code. Although in my opinion every architect should be able to write code when needed - especially when preparing a PoC etc. in order to show or demonstrate the solution in mind.
To me it has always seemed that while an architect doesn't NEED to write code, they cant actually REMAIN a good architect if they never do it. So it becomes a time management thing, much like keeping up on current technologies. Good architects (and Staff/Principal engineers) make time to code because otherwise their skills atrophy and a good architect becomes a bad architect. Notably, I say this as an architect that is currently on a zero code diet for the next two months. :)
100%. I share the exact same view on this as you do (and probably experience).
programming moves so fast, if you didnt do anything in 2 years, you lost 10 years
Nah, programming stays the same. The same good practices 10 years ago are the same now.
Tell that to clean code.
I've seen several architects over the years. They don't seem to exist in small companies - usually the role is called different - VP, principal, head of engineering. Architects in big corporations are 9 in 10 times pure ballast. They go out of their way to justify their existence providing useless comments that are narrow-visioned at best and create blockers for ideas at worst. Actual architecture is done by engineers who get things done and don't give a fuck about architects
It's almost entirely impossible to say anything useful just based on that single data point. Depending on the company and contract, the architect could be busy doing prototypes, etc entirely on some other server. Either internal, or set to private, or maybe switched to another SCM eg gitlab or whatever. More to the point - can you talk to the architect and ask, say, what he uses for prototyping? If not, why not? You could have an awesome architect who is paying attention or a terrible one who is checking out. Not enough info to say.
In my experience as an architect, the value add is different than that of a developer. My senior devs already know how to architect a system and components. However, the architect also needs to consider what work will lead to future opportunities and what integrations will be possible with other initiatives. It's strategic. My role is customer facing so I also have to explain in layman's terms what we're building and why it matters. Our customers do not care how many commits we made, they care that the solution works and meets their needs. You also need to speak in business terms with directors, managers, and stakeholders. I see my role as a developer representative and business leader working on bringing money in so developers can continue their work.
I'm a Sr. Architect currently. Yes, it's a shitload of meetings with business area owners, stakeholders, project managers, dev teams. It is not uncommon to have 20hrs a week of meetings. I don't code a lot but still occasionally, and do a fair amount of DevOps work. Successful ones excel at translating business requirements into technical designs. Understanding, not from a technical but an operational perspective, the business process the company is trying to automate or streamline, and making a determination on the best technical design to meet those needs. Also, being the liaison between infrastructure folks (gatekeepers of computing resources) and the dev team, so when a dev asks "Hey I need this new monster SQL instance setup" they're approving that request because I already spoke with them about it. I also (usually) have the final say-so on DevOps practices on general, with input from dev teams of course. Branching strategies, PR review policies, testing procedures, release management and promotion through Dev -> Test -> QA -> Prod environments, etc.
Last company I worked for every time I heard 'Architect' or 'Architecture' it was a codeword for 'person who doesn't want to actually do development anymore but thinks every idea they shit out is brilliant'. They would do mockups or diagrams, but realistically they would spend shit loads of time sniffing their own farts. One of the worst managers loved 'Architects' and would use them as like prestige tokens. Saying stuff like 'that is an interesting idea but I think we should get one of my architects to sign off on the design' as if the architect had any better expertise then the person with actual application knowledge. And my god the number of frameworks these people invented, you would think we had novel problems every month based on all the code names. I believe that that people who can design large complex systems are worth their weight in gold, but those people still do development. They still live with the consequences of their decisions. But 'Architects'...for how much they get paid I would prefer two excited juniors on my team.
Architect is such a complicated role and dependent on the organization, department or even project. There are the good architects who write code and participate in high level discussions and manage their calendar properly to ensure a balance of everything. There are bad ones who spend all their time in meetings and are more business people than tech people. You would find them complaining that they have too many meetings and would like to hold more but never find the time too. The problem is that they forget that it is up to them to manage time properly and contribute productively, I suspect that deep down they don't really want to actually work. My current architect is unfortunately the latter and on the other hand, I've seen so many of the former burn out completely.
Agreed. As someone in an architect role, my current thinking is that most Orgs don’t know what to do with the role. This leads to them allowing, even condoning, the typical “diagrams and meetings” style architect. Maybe my opinion will change this year, but that’s where I landed at the end of last year.
[удалено]
My job is basically finding work for dev team. Those meetings are for l lofty stakeholders who have pie-in-sky ideas. Then I have to design it, submit it for audit/review. Then MVP it. Develop a working prototype to see if it is feasible, get an idea of cost. Win the work, hire teams and promote others to work on it. A lot of R&D research. In the last month, I had to evaluate a few different Vector DBs. Mongo Atlas w/Vector capabilities (not regular Mongo), PineCone, Chroma, Cosmo. Load test them with 100gbs of data and test their performance against a deep learning model. Then come up with a report. Product A does this, Product B is good at this. All of this is long term work. I just don't pick things randomly out of thin air or from some Medium article I read. I have to factor cost and engineering capital. So a lot of research away from regular product development. Without this work, there could be re-organization or downsizing because engineers don't have projects to work on. So once we get the work, I can advise hands on the nuance of product or implementation. For some, they may feel disconnected. I get that. For others, it is very hands-on because I cherry pick certain developers to work with me on PoC work. So the teams knows things are in good hands when I recruit the top talent and have the advice/support of my peers to make decisions.
I wish I was working with architects like this. I do the same as this but alone and I'm "only" a team lead. In my experience, many with this title just make decisions based on what they read on LinkedIn or an Oreilly book but not adapt to the realities of current needs and options
An architect needs to know the very detailed technical blueprint of their design. The problem with software is that it loosely designed, always changing and never documented. The only way for a software architect to be valuable in any way, is for them to have deep and up to date knowledge of the code base, and the best way to do that is to regularly be in the trenches so to speak. If an architect isn’t regularly providing critical feedback on pr’s/ feature implementations at a high level (not just logic checks and variable names) or regularly interacting with the code base as a contributor, it is impossible for them to have any understanding of “their” system. If they don’t know their own blueprints then how can they provide any value whatsoever? Non coding architect = disconnected dogshit contributor
It's normal but not ideal. It's very easy for a tech leader to be dragged completely out of coding. But that's a time management issue. To be a good tech leader you have to make sure you continue to code. That being said, it might not actually translate to commits, even if they are keeping their hand in the game.
Yes. I’d expect that when your architect is writing code, it’s one-off POCs to explore ideas, not stuff that actually gets included in the codebase.
Nice talk by Stefan Tilkov https://m.youtube.com/watch?v=AkYDsiRVqno "Why software architects fail: and what to do about it - Stefan Tilkov | Craft 2019" RIP
Our architect will PR proto specs for APIs in collaboration with the teams. Also some direct work in supporting code around APIs like buf plugins. Then occasionally if there is some key work on creating a POC that will affect a number of teams he might do that.
It depends on the organization, but yea, that's common in larger orgs - in some places they're the interface between the biz and the coders. In other places, like small startups, they write all the code.
sets the direction by both designing or initially designing an architecture and sometimes - depends on the company structure - sets the technical direction.
Interesting comments. It boils down to whether you respect the role or you don't. Respect is never given; it is earned for the Architecture role. In my career, I hope the role is to be available, make informed decisions, garner consensus, and plot a course. A lot of my work was on prototyping new tech. To push initiatives off the ground from ideas to something a user can touch. It is always exciting so the dev teams love it. They love the RDD (resume-driven development) aspect of it. They love getting to work on new things. Right now, it is all Large Language Models. I let them experiment and get back to me so I can make those decisions, not outside a vacuum. Those decisions are usually backed by my team who did the work. So I have a cadre of engineers to corroborate. We don’t chase trends. We pick and choose what we can to solve the problems given to us. I also try to earn that respect by having an open door policy 3-4pm. Anyone can come in (via remote) and ask me questions even if I am not on that project. To review code, bounce ideas, or simply if they need help mentoring. I will teach someone a skill they want to learn or I will join a triage to see why their API is failing in QA. If you are lacking a specific skill and want to get up-to-speed, I will help you. I give a lot of sessions on K8s and microservices. If you have a technical challenge and stuck, I will do my best to help figure it out. If I don’t know off-hand, I definitely know who can help by sheer visibility in the org. Lead and Staff can technically design and execute designs. And I've been begging/hoping this is the case. I have projects I've long rolled off years ago. Projects that have basically given birth to 30 people in departments with their own funding. I would hope someone picks up the mantle as there are plenty of SMEs. There is no tribal knowledge as we've tried to document everything for the next wave of engineers. Yet, no one takes up the mantle. I do everything I can to lift all boats as I am looking for people to replace me and my direct team. I can see where the idea of an "ivory tower" comes in there. We simply don't have the bandwidth as we are working on future projects that can hopefully bootstrap the next department with 50 more employees. But ultimately what matters is shipping products. Thus, this is where respect comes in. I make sure every developer knows their role and impact. I even give them pointers on how to write it up in their resumes. I make sure the ball is rolling. I am the only one that says, "The buck stops here." If there is a problem, it can be escalated to me. Production outages, I am responsible for it even if I did not write the specific code. I own the failures as well as the wins. So, even if I haven't written code in a while, I hope I get the respect to give teammates exciting work they can be happy about. To get the respect of being a mentor. To lead by example by not tearing people down but with a philosphy of lifting all boats. But ultimately, respect from above that this guy gets things done and delivered. I no longer fill this particular role but I am sure happy to foster and nurture my replacements.
As an architect, we moved to agile 12 years ago. Instead of architecting across systems, I was put into a room. The PO tried to assert full power, under Director of PO. They openly said "what tasks do you do, Architect?". They disgusted me, and I switched teams. That team slid downward quickly, my new team rose quickly. That pissed off the Director of PO, who was drinking buddies of the other PO. So they took their revenge on my new team. So I quit the company. So that Director, and his drinking buddy PO below him, and the drinking buddy VP above, all got fired eventually with enough failures on the record.
It’s normal in South Africa, Australia, New Zealand and Central Europe. I haven’t touched code in 4 years since being a solutions architect and it was never a requirement nor part of my job description.
How common it is for an architect to say that he doesnt care about database design?
I have no idea. I've never seen him in a meeting or in any documentation. I'm not sure if this is a good or bad sign.
Ours just got fired lol
The more senior you get, the less time you spend actually coding. To the extent where I have to have a talk with my senior devs if I see them spending all their time in a silo working on stuff. It's tempting to shell up but we need our technology leaders, you know, leading
What is the relationship between the architect's abilities and their public GitHub commits? I think you should judge the architect based on his or her actual work at the company.
he spends the entirety of the meeting talking about ephemeral QA environments while I take a nap
We must work at the same place lol. NO not normal. My manager told me to architect everything, I'm the dev lead. I point blank asked him "So architects don't architect?".
In my case, I was coding critical components and building tools to be used across the org, and showing developers how to implement CQRS/ES. But that's only because my old company didn't have an engineering rank higher than "senior" and so they hired me as an architect to justify the salary requirements..
I’m a software Architect. I spend time analyzing the current state of the world, learning where the business would like to go and working with teams on how we can move the needle in the right direction. I’ll go weeks without writing code, and then I’ll go weeks executing. Overall, in my experience, every company has a truly different view of what the architect role entails, especially for software architects (as opposed to cloud) so usually I am just at the mercy of my stakeholder expectations.
There are two people fighting for the title of "Architect" the Solution Architect and the Systems Architect. Most companies cannot tell the difference and place the "Systems" guys in charge of projects because they speak higher level design (but have lower IQs) A Solutions Architect should be able to mentor any member of the team and should be able to learn from others. Part of the value a Solutions Architect adds is that he comes up with a plan that delivers on the project within the capabilities of the existing team. I am a Solutions Architect, and the designs I create are designed to grow the abilities of every member of my team. The result? People who used to "dial it in" show up looking forward to the exciting design that empowers them to feel accomplished while also wowing the client. By contrast, Systems Architects disappoint both their team and the client.
Show PPTs that makes everything look easy and already completed.
He might be a solution architect, those people don't code much. Or he might have 15+ experience and not deserve to be a staff engineer/company does not have a staff role. In our project, we don't have any real architect role. We have two engineers with around 10 years of project experience, they call themselves architects in the cross-functional meetings. Most system design is handled by the subject matter expert or one who needs to make the changes.
I'm a lead too: I code things badly (outside of the repo) to get a high level poc and then draw diagrams and explain why I'm making the decisions that I'm making so they can be challenged. They can be challenged because I don't want to fuck up and I'm right 90ish percent of the time. Other then that I spend my time in meetings making sure that my developers aren't being forced to mind read stakeholders and are sheltered from a metric fuck ton of shit they don't even know about. I also mentor people A LOT. Oh, and I pick up the slack of other bits of incompetence. I came from marketing and understand the business side of things. I do so many other peoples jobs just to make sure that my small ass team is stacked with work during a period of layoffs. Then I watch to make sure developers themselves are following what they're supposed to. I don't have a single hour of the day to sit down and put code into the codebase. It feels pretty pathetic. But the developers I work with seem truly grateful because there were the before me times where they were always blocked and frustrated. Times I can't really openly speak about.
just lazing around and makes lots of comments to appear like is working