> #5 Architects make the best decisions when they code.

It's not just a matter of coding, it's about the right kind of coding.

I like to have architects be pareto-programmers, that is they get to 80% of of the solution so that they can hand off the rest to a less-experienced team member. They can solve the hard part of the problem without getting stuck making it productionized and provide an opportunity for mentoring.

There's two other code related tasks that are important: code reviews and commit reviews. They give views at different "heights". We have fairly good tooling around the former; I'd love a tool that gave me an email every morning that had X number of random commits distributed over the total committers as best as possible while showing me who hasn't committed for a while.

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.

Architects coding can be a challenge. I try to write code as often as I can, but I usually don't want to actually take ownership of dev tasks because I usually can't complete them quickly enough with all the demands on my time. Usually in the middle phase of a project when the architecture is set, we've delivered a few sprints and launch is still a little ways away is a good time to dive in for a bit.

I agree. Even when its not coding, I try to take on a technical part of the delivery for myself, particularly a tricky integration that I've got the best knowledge on, or most suitable background to solve.

However, like you, I find that I'm often pulled away, and if I invest the time time make what I'm doing of a high quality (walk the talk), I'm typically neglecting higher value tasks.

The biggest challenge I have is managers who know you get on the tools, who turn around at crunch time and expect you to dive in and fix issues. Sorry but whilst I am indeed an expert troubleshooter, because I know the architecture, and designed to minimise a lot of these issues, I'm not usually the best person to foresee the impact of my fixes, and again, due to wanting to set a solid example, I don't want to do a hack to fix it, so it takes a quite a long time... when I should be triaging, providing troubleshooting insight, and considering any architectural changes that make whole classes of problems less impacting.

> #10

An age old rule for managers. You can't manage or treat everyone the same. Certain people respond to certain things. That's why great managers are able to really pull the best work out of their employees. They know what drives each one of them.

Those lessons are golden. I've picked them all up along the way, but its worthwhile to verbalize them consciously every few weeks.

Liked a lot your observations. Specially, the one about bugs. Being capable of fixing fast is really important.

My definition of Architecture: all that flexibility you build in from the beginning, that you never end up using.

My definition of Architecture (from another commenter): 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.

I spend the vast majority of my time on "architecture" (as opposed to coding) making it so that it's trivial to track down problems in production, trivial to identify the cause once you do, and trivial to deploy the solution once you've made the fix.

If you do architecture right, most fixes end up being the moral (if not literal) equivalent of one-liners. At least, that's been my experience.

Do architecture wrong (or worse: not at all) and you end up having to rewrite and/or redesign your code entirely, just to identify and/or fix bugs (i.e. not even adding new features).

Says every architect ever. Hifalutin words. So what, we build in 'flexibility' - guessing which way we plan on going in a year or two. Then in 6 months we pivot, and find we didn't anticipate that direction.

Yeah. I found that generic flexible solutions usually end up constraining me.

YAGNI FTW!