Comment by hinkley | Hacker News Reader

Comment by hinkley | Hacker News Reader

Parent Full thread

To me one of the unsung skill sets of the industry is tool selection. The ability to look at a tool and imagine how it’s going to behave for different pay grades of coworkers, different specialties, and to predict how that will pan out in the future.

Sometimes you pick the simpler tool, and hope it has legs. Sometimes you tweak your product roadmap to dovetail with the tool’s. Sometimes you push to get 25% of a feature set released so you can make progress. Sometimes you temporarily add another tool, and sometimes you fork for a while.

What most people just do though is measure power of the system, ignoring the Principle of Least Power for third party code, if not in fact for the entire project. Approachability is often better than power. Quickly knowing what a tool can or cannot do is generally more productive and results in less politics (who hasn’t worked on a project where person A keeps criticizing Group B for not knowing the framework can just do the thing they wrote, but it’s not immediately obvious that it can? That’s someone tearing down the team to boost their own ego. I don’t like it. I liked it even less when I was the one doing it. Don’t be That Guy, he’s an asshole)

Yes, and even though a lot of tech companies killed the architect role, this is exactly the job function assigned to architects, or more specifically enterprise architects in a lot of more traditional companies.

I haven’t had a lot of luck with architects. In one case I came to a company that got rid of their architect and hired me and another person to replace him (to be fair they were too small to warrant a full time role anyway, not sure what they were thinking).

Especially in the post refactoring era, they tend to have an inaccurate account of what the code is actually like and make bad calls based on bad info. It’s a responsibility that works better when the people have their hands in the code. I’ve had better luck with Architecture as a job description shared by the lead developers. In large enough companies they have Staff Engineer that scratches that itch with perhaps slightly less people skills (though I really don’t recommend it).

yep, if your architects don't have their hands directly on the code, they're making bad decisions.

People talk about enterprise architects as these pie-in-the-sky people who shit diagrams and everything works wonderfully. In practice it's "seagull architecting", with everyone else forced to deal with the reality on the ground.

At some scale architects need to be more hands off. When that happens they need to have a _very_ strong relationship with the people on the ground or it doesn't work well. Even then I would argue they should be getting their hands dirty in terms of reading code, etc, they just may not have time for implementation duties.

Reply on news.ycombinator.com