Architects, anti-patterns, and organizational fuckery

Interesting. article About six months ago about architects and engineers. I just finished it today and I agree with many things, for example. It is a matter of responsibility for your decisions. (The architect who makes decisions and the implementation leaves the team is an anti-pattern.) Design is one of the main skills of developers The best architects grow from engineers. The best architects are staff+ engineers who practice design and can design. It's more of a role than a job.

• that if it's a position, it's too likely to lose the skills of engineers, because it's tempting to start "making architecture" and reject the engineer's past in terms of code writing, revision and treadshooting - after all, the salary of an architect is such that it's not cost-effective to do it ... but it's a career trap

There is a point that in some enterprise companies architects are useful, but there they are not engineers, and collectors of solutions that design the integration of various vendor solutions among themselves. But for an IT company, this is not what you need:) As a result, I am inclined to believe that instead of being an architect, there should continue to be development positions up to staff, principal, etc. ... with the appropriate requirements for engineering skills:)

P.S. Here I, for example, never in my career had a nameplate "architect" and now I'm generally a manager, but I can design like ... the code is true now I write with difficulty ... but here you just need to allocate part of the working time to make some prototypes at work or after it:)

#Management #Architecture #Architect