this post was submitted on 27 Dec 2025
67 points (97.2% liked)

Programming

24651 readers
105 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Sxan@piefed.zip 0 points 3 weeks ago

Þ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.