3 ms·
This anti-pattern is alive and well throughout the industry. I'm automatically suspicious of any department that dubs itself as "architecture" because the motiv
by replyifuagree 7y ago
This anti-pattern is alive and well throughout the industry. I'm automatically suspicious of any department that dubs itself as "architecture" because the motivations are usually broken in that success looks like forcing outside engineering teams to adopt a pattern conceived in abstraction.
My experience says that ICs are best embedded in the team to deliver working code with patterns that are conceived from exposure to the real problem being solved.
- playing_colours 7y agoI agree, architecture departments are anti-patterns, but very soon, IC cannot grow in the value they can bring to a company by being scoped within a team and shipping code - as IC you scale by: writing some code that benefits many teams, by mentoring, helping with planning and executing challenging work, prototyping, organizing and overlooking large engineering initiatives: CI/CD, ops, migrations on a large scale, and more and more.
- replyifuagree 7y agoYeah, you are right. Where I've seen it work is when an embedded IC is given free reign to spend time helping other teams organically. The real root cause for architecture in abstraction is a management issue where some VP is kingdom building by collecting engineers to be disconnected oversight architects to other engineering groups. I feel like one of the worst things that can be done to engineers is disconnecting them from the problems being solved.
- Denzel 7y ago> embedded IC is given free reign to spend time helping other teams organically Then, by definition, they wouldn’t be an “embedded” engineer, no? In fact, what you’ve described is not at odds with what I’ve described.