> #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".
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!
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.
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.
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.