As a team member, pareto programmers are the worst. They do all the fun interesting work, then raise their hands and push the important work on the team. They refusw to take ownership of their features, create a mess for you to clean up because they certainly missed a detail or two, and just generally suck to work with.

The worst is when they say "This is your code man. I'm just helping you out a bit."

No. Finish the fucking feature so I can focus on my fucking feature without having to tripple check all your damn work.

I get your frustration, but I've also seen some pretty bad code where junior developers were given too much freedom to do the "fun, interesting" work. When concerns were raised during pull request reviews, the inevitable answer was "not gonna change it -- approve it now because my sprint is in danger".

That's a problem with everything.

If an obviously junior developer is given an obviously 'fun, interesting' task, they should pair with a developer or have frequent reviews so any problems are caught before pull request stage. You need to catch these sorts of things before you get so late in the stage.

Additionally, you need a structure and culture that is able to hold back pull requests if the code is bad - that's the whole point of code review!

Of course, but my architect is an ex Java guy with 20 years of experience, 2 years frontend.

And I'm a guy with 15 years experience, 10 years frontend.

Hence much frustration often.

You just hand them fun, interesting work that doesn't do too much damage to the company when it fails. In practice, this means that your most senior people end up doing work that is very interesting, yet very arcane.

I mean, anyone senior around here should know that it's precisely making something production ready, as opposed to just 'work in theory', is one of the hardest parts of software: Who hasn't seen some code that mostly works, but is operationally unusable? Something that works with 1 server, but when you put it in 20, it all blows up? It's not about the nice presentation, or the talk where you explain how you turned MongoDB into a queue, but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable.

The sad part is, the world is so full of powerpoint architects and projects that don't provide any real value that many people have never seen a system work right. And that's why we see tons of SV companies that are built around tire fires: Nobody in charge of anything has ever seen a system that we shouldn't be embarrassed of.

> but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable

This is exactly where senior architects make all their money.

There is a serious project management problem if the excuse "Sprint is in danger" is acceptable. Its quite common though.

Sounds like a problem with management. Decisions shouldn't be made around arbitrary ideas like 'sprints'.

I guess architects as pareto-programmers is great from a business side since it hopefully means things get done faster as the 'difficult' work can be done by the most experienced programmer(s).

Unfortunately, to work, the team under the architect needs to want these hand-outs. I'd wager that a lot of developers do not want to be simply told what to do or to clean-up and make it production ready.

In the end, I think a pareto-programmer architect selects for a team that simply does what it's told and that leads to a situation where no one will question the architect and that leads to bad code.

Yes this is exactly what happens in my experience. I've recently gotten rid of both architects on the application I work on. The programmers you want on your team are the ones who feel empowered by thinking for themselves and owning the solutions they come up with.

Hence why I am always cautious when getting architecture tasks.

Behind the name Architects, you get lots of different understandings depending on the organization.

I have seen in being used as technical architects, business architects, solution architect, application architects. Usually only technical architects tend to mean some kind of coding, with the other ones being synonyms for some sort of manager.

So I always feel I need to describe what I understand for architecture role, to make sure everyone is on the same page.