[cmhnn]

Any software "Architect" who can't build what they say to build should have to get a new job.

Any programmer of less experience who continues to argue with the "Architect" after they have met the challenge of proving their ideas can be done should also have to get a new job.

Many less senior programmers are better at the every day idioms of a given language or tools used in daily programming. Many senior people have to do more than just code. But most senior people who can still practice if called upon are much better problem solvers in part because they have already failed so many times and each new batch of programmers keep re-inventing the same mistakes.

[richardw]

Generally true but some architecture jobs have you designing solutions across multiple technologies that you just can’t be expected to master. Sometimes you need to rely on experts, including devs or other architects. The job then becomes finding a workable rough outline and then checking it heavily (and iterating) in areas you don’t fully understand. You don’t spring fourth a design so much as collaborate one into life.

I like people who want the right answer more than those who want to be right.

[cmhnn]

If I take your comment to mean collaborating is good and some people are better than others at parts of a solution because they are currently specialized I agree. The "right" answer is often difficult in practice especially when you depend on many other teams as dependencies and need to get something out the door.

On the other hand if you're drawing diagrams of things you haven't personally made sure could work well together at even a trivial POC level then I am not a fan because that is precisely why some devs hate anyone who is called an Architect.

[jungturk]

> if you're drawing diagrams of things you haven't personally made sure could work well together

If you're producing work products that don't accomplish their job, then you're probably just not good at your job, architect or no.

In this case, the diagrams are to guide development toward an acceptable conclusion, but if they instead impede or misdirect development then you failed.

Fortunately, there _are_ lots of ways to validate a technical design, among them toys & POCs, but also rtfm, reference works, etc...

The architect needn't rough things out in code all the time, though.

[Ill_ban_myself]

What toxic pit do you work in where junior programmers are ARGUING with senior architects and the senior devs aren’t mentoring, reviewing and empowered to make key decisions in another room before junior developers ever see a spec? And how do I avoid working there?

[cmhnn]

A1) Your typical mega corp that is too big to be one thing and filled with geniuses around every corner. So some parts are a pit and some parts aren't. It depends.

A2)Probably don't have to worry about it.

[anon73044]

A 20 year old "startup"/feature factory where all the original talent left years ago and everyone in an IT management position has been with the company less than 6 years. The majority of developers(200+) here are hired fresh out of school, or only had 1 previous employer. Now the CEO spends all day courting the "institutional investors" so he can secure his retirement.

[nitrogen]

I've seen this in a couple of places. Junior dev assigned to design new system. Senior dev assigned to mentor junior dev. Senior dev encourages junior dev based on experience. Junior dev ignores everything senior dev says. Manager listens to whatever junior dev says and sidelines senior dev. Senior dev goes on vacation. System explodes.

[Ididntdothis]

At my company management often gives new stuff to interns while senior people are stuck with maintenance work. It’s really weird.

[cbm-vic-20]

I've been at a mega-corp that let newly hired developers to build new stuff while senior devs are busy putting out customer fires that in many cases, were caused by those junior devs in the first place. "We want to make sure the junior devs have interesting things to work on so they stick around."

[rimliu]

Not really. A new system means it is not in production yet, so if something goes wrong there is little impact. Breaking the working system doing maintenance can cause lots of problems, so it is seniors who are tasked with changing it.

[Ill_ban_myself]

Your manager should be called a practice lead and they should have recently been a senior dev. They should have been picked by other senior devs as the obvious choice since he’s the guy who spends more time on lunch and learns than writing code.