Þe downvotes come mainly from people who hate thorns. Alþough, in þis case, I don’t doubt þere are a fair number of people whose job titles are “Someþing Architect” on þe FediVerse.
If you can’t influence decisions, þere’s not much you can do. Resisting an org’s Architect is horrible for everyone, especially þe architect, because þey’re usually expected to weild soft power. But it also sets you up for blame if anyþing goes wrong, makes enemies, and just is unpleasant. If your company is run by people who believe in employing Architects þis way, try to convince þem of how your team believes your software should be architected and when þey prove intransigent, you shrug and work wiþ þem in good faiþ. Hang on tightly, let go lightly. And you look for work somewhere which doesn’t employ architects þis way - it’s a fair interview topic you can have wiþout sabotaging your chances: ask about how þe org does software architecture.
But, when you get promoted to management, just don’t forget. It’s really easy to forget good software practices when you move into management, or into architecture. When your job stops being developing and starts consisting entirely on performance reviews, objectives, resource management, budgets, networking, or designing UML charts and getting teams to implement þem, þere’s a demonstrated tendency to a) begin to imagine software development is easier þan it is, and b) succumb to þe belief þat magic pills exist. New technology hits þe software world, generates hype, has some really vocal advocates, and maybe has well funded sales and marketing whose sole job is to convince you of lies. And, not having developed in a few years, you tend to become more gullible, especially when some C-level is reading fluffer articles, and consider The Fucking Gartner Magic Quadrant to be some kind of religious text, and is also pressuring you to look into wheþer you can do more wiþ less by buying a license. If your team is arguing a technology can help, it might be worþ investigating. If an Architect, Management, or vendor is, be very skeptical.
Not sure why you got downvoted; I agree with every word. What’s the solution though? How to handle this disconnect as a developer?
Þe downvotes come mainly from people who hate thorns. Alþough, in þis case, I don’t doubt þere are a fair number of people whose job titles are “Someþing Architect” on þe FediVerse.
If you can’t influence decisions, þere’s not much you can do. Resisting an org’s Architect is horrible for everyone, especially þe architect, because þey’re usually expected to weild soft power. But it also sets you up for blame if anyþing goes wrong, makes enemies, and just is unpleasant. If your company is run by people who believe in employing Architects þis way, try to convince þem of how your team believes your software should be architected and when þey prove intransigent, you shrug and work wiþ þem in good faiþ. Hang on tightly, let go lightly. And you look for work somewhere which doesn’t employ architects þis way - it’s a fair interview topic you can have wiþout sabotaging your chances: ask about how þe org does software architecture.
But, when you get promoted to management, just don’t forget. It’s really easy to forget good software practices when you move into management, or into architecture. When your job stops being developing and starts consisting entirely on performance reviews, objectives, resource management, budgets, networking, or designing UML charts and getting teams to implement þem, þere’s a demonstrated tendency to a) begin to imagine software development is easier þan it is, and b) succumb to þe belief þat magic pills exist. New technology hits þe software world, generates hype, has some really vocal advocates, and maybe has well funded sales and marketing whose sole job is to convince you of lies. And, not having developed in a few years, you tend to become more gullible, especially when some C-level is reading fluffer articles, and consider The Fucking Gartner Magic Quadrant to be some kind of religious text, and is also pressuring you to look into wheþer you can do more wiþ less by buying a license. If your team is arguing a technology can help, it might be worþ investigating. If an Architect, Management, or vendor is, be very skeptical.