I'm fast approaching a place where I'm going to implode if I have another argument around whether service A talks to service B and it should instead be talking to service C because of magical boundaries that we've setup. I'm so tired of dependency arguments and what should be exposed and what shouldn't. Even more tiring: arguments about process and story points/estimation and what should be the ideal workflow and people whose entire jobs it is to facilitate these arguments further.
I just want to build cool stuff.
Every company is the same, with the same problems and the same arguments made by the same personalities. You'd think all of the accumulated human hours we've spent arguing about the perfection of code over the decades of computing we'd have arrived at something decent by now, but spaghetti is spaghetti and it's everywhere. Is there a world where we just embrace it all and save our breaths? Can we build something new that will ultimately remove these discussions? I want to go to a place where people are passionately arguing about the direction of the product and what to build next, not mindless code structure arguments that will happen all over again in a month when someone leaves and someone new joins and shoves a new dependency into the mix.
Before everyone starts furiously typing that thinking about clean code for the future is critical for a good engineer, I'm well aware. I'm just so exhausted by it all. I don't know how to phrase it properly about the dichotomy of "I understand, but...ffs" that I'm feeling
Most of what you describe are people issues / classic bike shedding.
You should be able to find some ways to shut this down fairly efficiently.
"A talks to service B and it should instead be talking to service C":
* Yes, I agree! Let me know when you have a PR to look at!
* Yes, it really should! Please create a work item for it, and we can prioritize it in the context of our other initiatives!
* Should it? What problem does that solve? How will our customers tell the difference?
* Let's review our product roadmap and mission statement and see which heading this falls under?
* This is our daily standup where we briefly touch on all of our work in progress, please set up a dedicated time for a deep dive on your idea!
Those are some polite ways to shut this stuff down and move onto whatever you want to talk about. They might work, and if they don't, you can be sure you have some major personality problems to contend with.
I'm no psychologist... but I think a lot of people that indulge in this stuff just want to be heard, and in some cases want to rearrange deck chairs so it looks like they're taking action and getting stuff done.
Ultimately you need to find a way to move the discussion whatever you find important and stimulating, and not let these folks set the agenda.
Hillel Wayne recently wrote about this distinction:
> New Newsletter! An exploration of a core difference between "programming" and "software engineering": how much you work on "solving the business problem" versus "solving the problems of the code that is solving the business problem."
https://twitter.com/hillelogram/status/1486079674795143170
https://buttondown.email/hillelwayne/archive/software-artifa...
And sounds like you enjoy "product engineering" more than "infrastructure engineering."
Michelle Lim wrote a post about it, which was discussed on HN.
> Try using the "Product/Infrastructure" axis as the first axis to understand your career preference.
> Broadly speaking, there are 2 types of engineers: "Product-first" engineers are obsessed with using code to solve a user problem and they see code as just a means to an end. "Code-first" engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end.
https://news.ycombinator.com/item?id=28476538
https://www.michellelim.org/writing/stop-using-frontend-back...
Then work on your own stuff. Companies don't pay the big bucks for working on pleasant tasks only. If you are an employee you: play good with others pushing stuff to production while keeping the business happy and the kitchen (code) clean. If you work on your own stuff: do whatever you want.
To clarify: I feel like you as well. I think almost everything in software engineering is subjective... but I'm a professional: I do my best and get paid.
However, I tend towards a pessimistic nature, so hopefully I'm wrong.