4 ms·
It's really hard to be a good architect, because their job is not supposed to be to leave their mark. An architect is doing a great job when the codebase is bor
by hakunin 2y ago
It's really hard to be a good architect, because their job is not supposed to be to leave their mark. An architect is doing a great job when the codebase is boring, and everybody talks about business. That doesn't help the architect however, because people can't tell how it would've been had they not been there. "Our codebase is so simple and boring, why do we even need an architect". That's how you get the kind of architects that try to look impressive to the management.
There are a few things a business can do to get a good kind of architect.
1. Hire them to be hands on with code (give them secondary features or refactors, not major lifts, since shipping speed is not the priority).
2. Don't give them authority over devs, rather ask them to provide mentorship and demos. Their job is to excite devs about a clearly better approach, not to force their opinion.
3. Encourage devs to come to the architect for advice as needed.
4. Have the architect organize long term refactors[1] when needed.
Basically make them a developer whose audience is other developers, and the product of their work is developer buy-in/excitement over good practices and software design directions.
[1]: https://max.engineer/long-term-refactors https://max.engineer/long-term-refactors
- Quothling 2y agoI completely agree with you. To me a good architect is someone who enhances software developers and if not mentors them then guides them in the same direction. Unfortunately there are simply so many barriers in the way of this ever becoming an actual option in most organisations. You'll need this unicorn situation where you have architects with very good social, communication and change management skills who are also technical apt and very good at dealing with "developers". I put developers in quotes because if we're honest with ourselves we all know that we're probably one of the most unmanageable groups of employees out there. This is the easy part. The hard part is to find an organisation which will give your architects and software developers the time they need to actually perform this sort of work, and, you need IT management with clear role definitions so it doesn't end up in a confusing mess where nobody really knows who can decide anything. Since this rarely happens, most architects either become managers or go back to being developers leaving only the people who actually enjoy the "process" more than "results" being long time architects. Obviously not in 100% of the cases, but in most of them. There is nothing I personally dislike more than "process" people. I used to think of them as an unecessary evil that I just didn't understand, but then Covid happened while I was working in a 6000 employee organisation. Virtually every one of our "process" people was unable of doing any sort of work for 9 months, and during those 9 months our production and employee happiness sky-rocketed across every field. Well... happiness didn't increase for middle managers or "process" people, but...