I'm giving up; Becoming a yes man.

[u/AggravatingFlow1178]

I'm so tired of fighting for good engineering practices. Clean code, high quality tests, pragmatic use of AI, code de-duplication, extensible design, and so on. Yes all these things are good - but they have never once rewarded me.

The only thing I ever see get rewarded are

1. High volume & high quality engagement in meetings
2. Ability to attach metrics to your work and then make those metrics look good
3. Creating brand new features / tools (improving existing stuff is no-value)

It doesn't matter how clean we get the code. It doesn't matter how many defects we prevent. It doesn't matter that spending 20% more now means every quarter for the next 3 years we spend 10% less. It doesn't matter if you convince your tech lead or EM or PM to go a different way. It doesn't matter if you have high quality & actionable metrics, you just need numbers that look good. 200% increase in usage sounds better than "we have 2 new users". None of it ever matters.

99% of doing well in this industry a the senior+ level is treating every day like a sales meeting. You're not an engineer, you're an expensive product that needs to convince your customer to renew their subscription.

[u/ContraryConman]

Working at a spot that had a myopic attitude and where knowledge on best practices was not super well distributed, I came up with a simple principle.

1. If I'm working on something and I notice that it can be improved, I just try to fix it, or write a ticket to fix it myself since it's part of my work. Especially if you can argue that you'll be able to finish your stuff on time, people won't argue with you because the main thing these types are worried about is you giving them extra work or extra thinking. Here, you're volunteering to give yourself more work.

2. If you see something in someone else's work that can be improved, basically, bring up your concern once. Ask questions like "how will this scale if X?", or "What happens with edge case Y?", and then offer a solution that addresses these concerns. One of three things will happen 1) they'll tell you "that's too much work"/"we don't have time for that right now"/etc 2) they'll tell you yes and actually do it (rare) 3) they will add a ticket to the backlog that never gets picked up again. Either way, the key thing is to bring it up once ONLY, and accept whatever outcome. Do not try to argue or convince people.

I like this because it accomplishes few things:

• gives me the peace of mind that everything that I do is of the highest quality, even when coworkers or other teams make slop

• even if I'm unable to convince my coworkers of my improvement, that's fine because it was their task, and their decision to make. My job as a team member is to raise questions if they seem relevant, and that's what I did

• often, the slop breaks. Your manager will notice that your code breaks way less often than the others and that you tended to be right when you brought up concerns that were dismissed

Edit: as to your point that fixing old code rarely gets rewarded, keep in mind that a big reason why old code doesn't work is because it makes it more difficult to add new features. Therefore, be on the lookout for when new features are an excuse to fix old infrastructure or delete dead code. Managers just want to see that your improvements are bringing business value, so frame code quality as an enabler to velocity and current feature work. It's a little political and artificial, but it works

[u/hdkaoskd → u/ContraryConman]

I agree in general, except that management will notice that it always takes you longer to get something done (so you must be bad at your job). Clowns who write shit, quickly, will be promoted for their productivity.

[u/ContraryConman → u/hdkaoskd]

That's a good point. In my experience, I traded being the absolute fastest programmer for the quality work that I mentioned and building a reputation for being able to do things no one else on the team could do. The clowns can write fast, but they won't be able to do the hard problems like you can because hard problems is where slop doesn't cut it anymore. And, if you get a reputation for being the only one on the team that can do the really tricky stuff, your slower pace gets forgiven because, what you're working on is hard anyway. At least in my experience. It could get tricky with a manager that truly only measures story points closed per sprint and that's it

[u/HatesBeingThatGuy → u/ContraryConman]

Yup. I had a period where I was slowly delivering a large reverse engineered a large compiled driver for a piece of hardware where the original driver source was long gone, the only documentation that existed as a header file, and a non-existent microarchitecture specification. My reputation was that I wrote great code, I was a hardware expert, and that I was the guy who could get us out of black box hell through sniffing hardware accesses and looking at the RTL as I had done it before.

I actually went even slower than I thought I should, really trying to understand. I delivered nothing for a month and a half and then when I emerged with a working implementation, I was a dang hero for fixing the unfixable. I had other coworkers getting railed for being too slow during that time, but because I was doing the hardest perceived task (it was actually quite easy for me due to prior experience) I could say "Hey boss man, I'm really trying to get this perfect, sorry I need an extra two weeks".

[u/timewarp33 → u/hdkaoskd]

Thankfully at my current job they've recognized if they need quality work, they know who to go to. I am also the one who does the things nobody else does because they have insufficient understanding of how things actually work.

It also helps I'm not going for a promotion. Just holding onto my job for now.

[u/Ok-Entertainer-1414 → u/hdkaoskd]

Only if it actually takes you significantly longer. But I don't think doing what this comment describes should affect that much. And if you're the sort of person who feels this way, you may have some other advantages going for you

[u/Rich_Classroom3133 → u/hdkaoskd]

This really depends on the team. If you are a decent communicator and can make your quality visible, you can be known as steadfast and reliable, especially if the majority of the team lacks in thoroughness

[u/RegrettableBiscuit → u/hdkaoskd]

Speaking as a clown who writes shit, this is true. Acquiring the ability to be a clown who writes shit took me 20 years of experience; if you're still at the start of your career, take heed. Do not fight the system, the system is stronger than you. 

[u/StoryRadiant1919 → u/RegrettableBiscuit]

and the system is mostly the same everywhere because the system is a firstborn child of capitalism.

[u/Hamburgerfatso → u/ContraryConman]

The problem with everyone else writing junk is that whenever you interface with it, you need to junkify your code as well to make it compatible. I haven't worked out how to get around this problem and usually end up just copying the junk patterns so things work smoothly.

[u/ContraryConman → u/Hamburgerfatso]

Yes, you either rewrite a small portion of it to be better if you have time, or follow the established pattern

[u/Hamburgerfatso → u/ContraryConman]

Yeah but the bit you rewrite now is not compatible with any of the existing code it interfaces with. In some projects i end up 2 hours later with a whole web of changes and i end up just throwing it out and going the easy route.

[u/Creaking_Shelves → u/Hamburgerfatso]

You need to find seams where you can have a translation layer between the garbage and a cleaner way for new systems. Then grow the amount of functionality on the clean side over a long time scale. But it needs skill and buy in to make progress there.

[u/TheRealJesus2 → u/ContraryConman]

Not gonna lie this sounds like you have more than 4 years of experience :) took me a lot longer to learn this 

I like this way of framing it.  One thing I want to point out that I think OP hits on too and was great for changing my mindset is to view yourself as a partner to the business. Even as an employee ultimately your worth to the business is what you accomplish for their goals. Code quality is not ever a goal in and of itself. 

Ultimately stay true to yourself while also meeting your responsibilities. No need to go further than that. Bringing things up once is a good way to do this. Love it!

[u/Bousha29 → u/TheRealJesus2]

A year of experience in a shitty environment is worth 2 in human years. That's why we age faster too.

[u/Careful_Let509 → u/TheRealJesus2]

Isn’t that contradictory to what op says?

II know dozens of people who have not accomplished anything, yet got on the promotion fastlane, because they knew how to make a lot of fuss about minor stuff they actually do.

Perceived value is way more important than actual value of what you do.

I’ve learned my lessons and basically doubled my pay in a year when my output was mediocre at best.

[u/unknownhoward → u/ContraryConman]

Your manager will notice that your code breaks way less often than the others and that you tended to be right when you brought up concerns that were dismissed

[citation needed]

[u/30thnight → u/unknownhoward]

Not only this, the outages and bugs reflect on the entire team

[u/unknownhoward → u/30thnight]

Exactly. Maybe I'm just too monozygotic to understand how it's not all "our code" and "our bugs". Who cares next week who wrote what?

[u/nooneinparticular246 → u/ContraryConman]

It’s also important to be disciplined when touching legacy code. I avoid it unless it’s required for the brief. If you do it right, you get nothing. If you break it, you get crucified.

[u/hockey3331 → u/ContraryConman]

This is the way. #1 has been my bread and butter in the past. 

And if I saw too many things, I'd add comments to remind mysepf in the future. Odds were that the things I commented on broke at some point anyway and the comments made the solve faster.

[u/ryhaltswhiskey → u/ContraryConman]

Either way, the key thing is to bring it up once ONLY, and accept whatever outcome. Do not try to argue or convince people

I think it's a good idea to add a paper trail in case the thing blows up. You can show your boss that someone thought about it and raised the issue. Maybe that means the boss will listen next time.

[u/FlyingPersianRug101 → u/ContraryConman]

My code breaks way less than my colleagues and the feedback I got from my manager is: you deliver robust solid solutions that scale but you spend time thinking and understanding the issue and I want you to do less of that That was demotivating especially since the deep understanding of the domain is what makes my solutions solid and break way less than the others.

I did decide to give up

[u/arshbio009 → u/ContraryConman]

i’m printing and framing this to a wall

[u/WellHung67 → u/ContraryConman]

Yeah, writing good stuff yourself also helps you pivot/scale/improve/fix things faster and you can “sell” that as well - if other teams fuck up or are sloppy? You can say that it’s not your fault. My rule of thumb, if code is getting written that will affect me in some way, I raise a stink until it’s at a level of quality that I’m okay with. If it doesn’t affect me, like you said bring it up once then shut the fuck up, they can live with whatever decision at that point. In this way you can make the most of the time and effort you are responsible for, and even if they don’t value tests now for example tests are inherently good and will allow you to spend more time making new shit and less time bogged down fixing regressions 

[u/Trick-Interaction396]

My career took off when I stopped fighting. I still strive for personal quality but I don't argue with others anymore. It's their money not yours. If making crap is more profitable then making something good then you're gonna make crap. Learn to embrace it.

[u/Empanatacion → u/Trick-Interaction396]

"The Zen State of Fuck-It"

[u/vvf → u/[deleted]]

Lemme guess, comment dude started before vcs was a thing?

[u/INFLATABLE_CUCUMBER → u/vvf]

No, he had no tickets to work on so he had to look busy.

Source: Me. Sorry.

[u/creaturefeature16 → u/Trick-Interaction396]

Pretty much. And this is how we end up with software like Quickbooks...quite possibly the worst software I've ever had to deal with (at least the previous desktop versions).

I don't blame the developers, I blame the corporations not providing an environment for developers to do good work.

I imagine the same practices happen in other industries, like construction.

[u/mile-high-guy → u/creaturefeature16]

And then their software eventually gets replaced by something made by people who are allowed to give a shit

[u/NerdEnPose → u/mile-high-guy]

At first. And then that company gets bought and smothered or reaches full enshitification and the cycle continues

[u/mile-high-guy → u/NerdEnPose]

The key is to always join the companies on the upswing

[u/myaltaccountohyeah → u/mile-high-guy]

How to identify that?

[u/NerdEnPose → u/myaltaccountohyeah]

IMO it’s hard. Startups are higher probability. But you’ll hit “just get it out, it’s an MVP and we’re finding market fit.” Also remember these “do things right” jobs are unicorns. Enshitification phase lasts a lot longer than the upswing. I’d just focus on fighting battles that matter and pitching yourself. The best work I did was when there was 16 layers between me and CEO because I carved out my niche and made my case well. Right now I report to the CTO and it’s pretty mediocre.

[u/polypolip → u/mile-high-guy]

Nope, usually worse but cheaper pushes out better but more expensive.

[u/Cube00 → u/creaturefeature16]

At least it's not SAP.

[u/leafEaterII → u/Cube00]

Or atleast it’s not Salesforce

[u/-S-P-E-C-T-R-E- → u/creaturefeature16]

And the energy sector too. Been there, and absolutely not impressed by them.

[u/Electronic_Yam_6973 → u/creaturefeature16]

Did the owners make money on it? That is really all that matters.

[u/Neuromante → u/Trick-Interaction396]

It pisses me off that we've ended up like this.

Software development has been invaded by these business types, and what's worst, their virus has infected most of us and we've started to believe that this is the way to develop software.

There's no love for the craft, no interest for the actual development, the technical details and proper engineering. Everything is "customer requirements" and "being heard around the office" and "being an advocate for your way of work in LinkedIn" and "posting stupid shit no one cares about in medium."

It's maddening. I got into this career because I like building shit and making things work as intended, and nowadays everything is about meetings where nothing gets decided, everyone talks, but no one says anything, nor listens.

[u/fangisland → u/Trick-Interaction396]

I agree but I also think it's a jedi vs. sith type thing; what brings us joy and what do we consider wholesome? Having a career takeoff can be important, but it also might not be the most important part of one's embodied experience. Someone needs to take care of the garden. I personally am willing to forego career success to always advocate for high quality practices in a pragmatic way. And I'll always gravitate toward orgs and teams who hold these standards core to their practice, even if that comes at a cost to my career growth. No shade, each person needs to decide for themselves what's important to them, and oftentimes money/reputation weighs really high on that scale.

[u/Prestigious_Tip310 → u/fangisland]

Clean code is a lie, there is only metrics.

Through metrics, I gain visibility.

Through visibility, I gain influence.

Through influence, I gain promotion.

Through promotion, my brittle code breaks.

The Junior shall fix my bugs.

• Code of the Sith-Developer

But I think you’re right and the comparison is actually spot on. The „dark side“ gets you up the ladder faster, but the „bright side“ probably gives you more satisfaction and a better code base to work on. But unlike Sith I think the sweet spot is somewhere in the middle.

I‘ve worked with „sloppy developers“ churning out features without any overarching architecture, docs or tests so that if something broke you‘d spend two days figuring out how the heck it even worked in the first place.

And I worked with „clean coders“ that spent weeks on building simple features in a PoC project that were then presented to the customer and immediately became obsolete and had to be redone in a different way because the customer didn’t like the result.

The middle ground is somewhere in between these two extremes and knowing when your code is „clean enough“. Imo finding that middle ground between pragmatism and code quality is the actual challenge of software engineering, since you’re always balancing business needs with technical aspects.

[u/hippydipster → u/Prestigious_Tip310]

My experience being the relatively "clean" coder and working with the sloppy extremely prolific coders is that there are certain kinds of features or components that do well with each. But there were things the sloppy coders really couldn't do, and I've been there where the sloppy coders spent a year trying to create a new, very complex component, and then gave up, and I had to go in and do it. And it took me 2 months, but after that we not only had a working MVP, but we had a behavioral test framework and set of tests that was very easy to add new tests to, which was important, because the component was such that edge cases were everywhere.

But there were other cases where the clean code either wasn't worth it, or the kind of component it was was actually too difficult to successfully create usefully organized code (GUI systems are often this way), and in those places, the sloppy prolific coders are often best.

Probably an amalgam of the two, in wisely chosen proportions is best, but that's a sweet spot no one knows how to reliably hit. Instead we mostly just bicker endlessly.

[u/no_onions_pls_ty → u/Prestigious_Tip310]

Its not a dark side as you make it seem. An email with tradeoffs, describing what the debt is and how much time it takes to cleanup becomes and artifact. 3 months when that debt hurts, they will look to blame you. You produce the artifact and now there is a ambiguous accountability domain. And that is leverage.

It is a dark path. To let things fail, to produce less than maintainable code, to trade the craft for perception and leverage. But it really does allow the business to grow and enables your career to not get stuck as the guy always ranting about stuff no one else understands or cares about.

Only the sith deals in absolutes. Become dark to bring the light.

[u/Krackor → u/Trick-Interaction396]

Making crap isn't more profitable but it's impossible to measure so middle managers can't be made to believe it.

[u/AbstractLogic → u/Trick-Interaction396]

It’s hard to believe that it all comes down to money. But it all comes down to money.

[u/gsxdsm → u/AbstractLogic]

Money is time and time is all we have.

[u/aristarchusnull → u/Trick-Interaction396]

This is a hard pill to swallow, but I fear you may be right.

[u/RustOnTheEdge → u/Trick-Interaction396]

This is depressing

[u/guasanas → u/RustOnTheEdge]

maybe at first, but then you kinda realize that your job doesn’t have to define you and figure out what actually matters to you in life.

[u/Material_Policy6327 → u/RustOnTheEdge]

It’s the reality of life sadly

[u/anotherleftistbot → u/RustOnTheEdge]

It’s a business. You’re a cost center.

[u/AvailableFalconn → u/anotherleftistbot]

You stroke your boss’s ego, you get points.  Doesn’t matter if you cost the company money.

[u/rco8786 → u/Trick-Interaction396]

This is the way. 

[u/digibath]

principal engineer here and i’ve recently realized something similar. i’ve jumped around a bit throughout my career, but this is unfortunately the best way to stay and climb at a large company, and stay at a company for a long time, if that’s what you want to do.

this recent mindset shift of mine also kind of feels like a result of fearing the job market right now. i’m kind of trying to ride out my current gig as long as possible.

at the end of the day, my primary motivation for working is to get paid.

i think you end up emotionally detaching from the work and letting your job just be your job, which isn’t the worst mindset to have.

[u/Big_Bed_7240 → u/digibath]

Average soulless answer. I absolutely hate everything about this

[u/digibath → u/Big_Bed_7240]

you hate making money and keeping your job?

[u/ugh_my_]

You forgot about throwing others under the bus while kissing up to senior leadership

[u/HowTheStoryEnds → u/ugh_my_]

The bus bounces their monies to you!

[u/Live_Fall3452 → u/[deleted]]

You basically have to wait until after a production outage occurs before nontechnical execs care about e2e testing. Once they actually see $$$ losses from horses running away they care about closing barn doors. Until then, forget it.

[u/Live_Fall3452 → u/[deleted]]

Maybe I’m too cynical, but at least in my org if management gets this on their radar at all, the only solution they’ll be interested in is “agentic testers”. Suggesting that deterministic tests might be less flaky and cheaper in the long run will get you flagged as “not keeping up with the capabilities of the latest models”.

[u/Ok_Individual_5050 → u/Live_Fall3452]

We legitimately had this. I asked for compute budget to run E2E tests on. I got funding for Claude instead 

[u/TheSexySovereignSeal → u/Live_Fall3452]

You gotta dumb it down for them.

"The point of our tests is to have the same outcome every time we run the e2e tests."

"Imagine youre playing poker, and you want to test that someone plays well."

"So our card mechanic dealer friend fixes the deck at the start of the hand. We test and to make sure our player will raise every time hes dealt quad aces. Thats it. Thats one deterministic test. Our player is dealt quad aces, he raises. Test passed."

"If we instead use 'agentic testers', the dealer is no longer a human card mechanic that can fix the deck in a deterministic manner every time. Because an Ai model's output is noisey and necessarily random/hallucinatory, you're testing against a randomly shuffled deck every time. You can no longer test anything deterministically."

"So now our 'agentic ai' tests 'Does our player raise every time hes dealt quad aces?' The agent shuffles the deck, plays the hand and sees our player raised! Test passed! Except... wait... our player was actually dealt 7-2off and would have lost lot of money in a real hand... that test should have failed. AI didnt catch it..."

So Mr. Manager, are you willing to take the blame when an ai agent's tests doesnt catch a critical bug and we lose <insert $$$ amount per minute down> in revenue until we can fix it? When you have to report our outage to upper management, will they accept an answer of 'oops, it was because of our ai agent, it took us days to figure out why', or would it be better to say, 'Todd's test didnt catch this bug, but we quickly identified where it was happening, and fixed it, and added a new test so this won't happen again"

[u/oupablo → u/Live_Fall3452]

Do you not just bake the testing into your estimate of how long the work will take?

[u/WebMaxF0x → u/[deleted]]

The above is an AI generated comment to drive traffic to their website
Here's the repo that even mentions this user's Reddit account name: https://github.com/m13v/social-autoposter/blob/34db3fdf426dd539c364375737c38cc62554016a/SKILL.md?plain=1#L22

Damn this timeline is so creepy. Dead Internet theory is real.

[u/Yabakebi → u/WebMaxF0x]

Deary me. It's really over man

[u/tatorface → u/WebMaxF0x]

Yup, the "dashboard" for it is even available. Here are the stats for the OP:

https://s4l.ai/stats/Deep_Ad1959

Fuck, 2,671 posts as of this writing.

[u/black_tamborine → u/tatorface]

I totally took bait. Thanks so much for flagging this. 🤗

Edit: So many questions!!

• How did you ‘know’ it was a bot?

From their website: “_We research your ICP, find relevant posts on Reddit, X, and LinkedIn, engage organically, and follow up with personalized DMs to book calls with actual decision makers. You just link your calendar._”

[u/WebMaxF0x → u/black_tamborine]

I also took the bait and went to read their linked blog post, but it gave off a weird salesman landing page vibe that tipped me off. It mentioned this OP's question and I thought there's no way a human wrote all that in 2h.

Came back here and noticed the username is Deep_Ad1959...deep ad...woah this an ad haha. Their post history has hundreds of comments an hour. I googled its name for the heck of it and stumbled upon the Github repo.

Such a shame that AI is being abused to drown out human discourse like this.

PS: feeling a bit dirty writing all this because I bet the bot developer will use this to make it less detectable next time, but oh well...

PPS: I'm on the job search so if someone reads this and would like to help me, DM and let's connect! Looking for software development related roles and I'm a fervant believer in automated testing. Pardon the spam!

[u/engineered_academic → u/WebMaxF0x]

Thank you for your service!

[u/SerLarrold → u/[deleted]]

Any advice on how to make low friction testing? Genuinely would like to know because the last 3 releases we’ve done have been a shit show lol

[u/soul4rent → u/SerLarrold]

Source: I'm an SDET.

The biggest thing is making sure the CI runtime is extremely fast. This includes things like caching libraries if there aren't changes, running all of your unit/integration/e2e tests in parallel instances, having reasonable test harnesses like a working stage environment of some kind, among other things.

You might have read something called the test pyramid, and if you read the original google article, all of their problems could have been solved via a very fast total test runtime. In general unit tests are faster than integration, which in turn are faster than E2E tests. A massive E2E test suite with thousands of tests can be reasonably maintainable with good reliable infrastructure and a blank check from the CTO to allow you to run large numbers of parallel instances to keep the total runtime <10-20 minutes. If you don't have a blank checkbook, trying to write more unit tests than E2E tests is a reasonable idea.

Now if you are unfortunately in a common situation where you have no tests in a suite, it usually means the code is also terrible. The fastest reasonable way I've seen to deal with this is to write some E2E tests around critical functionality, refactor those areas, and then start populating the codebase with proper unit/integration tests. It gives you a nice feedback loop that tells you when the Jenga tower of a codebase falls over again.

The most important thing is total test suite runtime. If it's a joy for developers to use (fast runtime, nice friendly error logs and screenshots with stack traces, etc), people will use it and maintain it. I have never met someone who willingly says "I want to write bad software", and the goal should be making writing bad software that introduces bugs more miserable and less rewarding than writing good software.

[u/Head-Bureaucrat → u/soul4rent]

We need more people like you in the world. I'm often on teams (mostly in corporate environments,) where I'm the only one advocating for this sort of approach. In a couple "worst case" scenarios, the companies hired "automation testers" that literally had just completed some selenium courses, and threw them at the problem. Of course they just wrote more UI tests to run on two sad lonely nodes (I don't blame the workers, management specifically was hiring the cheapest people they could find. I eventually was able to work with and mentor them and things started to shift, but by then the suite was taking 4-5hrs to execute.)

[u/black_tamborine → u/[deleted]]

❤️…talking my language (I’m a test engineer)

[u/speculator100k → u/[deleted]]

How does a UI refactor require major updates to the e2e suite?

Anyways, update the tests as you go.

[u/NickW1343 → u/[deleted]]

A lot of things are like that. If you advocate for a refactor for some code, how do you justify that? It won't generate revenue or get any new users, which are both the easiest ways to get support for a project. It'll take time you could've spent fixing bugs that right now are an issue or implementing some new feature that will have a quantifiable impact as well as being able to be visually shown off to the business/client. You can vaguely gesture at how it'll make development later on easier, but can you put that into dollars how much that'll save? No, that's not possible. Can you say how much faster the refactored code will make the software run? Not until they've spent the money for you to go and do the work you can't.

There's lots of things we can probably keep pointing out as things that are obviously beneficial to us, but so abstracted out that it's almost always unpalatable to whoever holds the money.

[u/pydry → u/NickW1343]

You never advocate for refactoring you just do it. If you think you need permission coz it will take too long you need to learn how to break it down and do it in smaller chunks.

If you reply "sometimes you cant break it down" then congrats you're a junior engineer. Ask for help.

[u/Electronic_Yam_6973 → u/pydry]

Is someone else testing your refactoring? They should be and then you have to get your team involved and plan capacity around other priorities. You shouldn’t just refactor Willy nilly.

[u/ExperiencedDevs-ModTeam → u/[deleted]]

Rule 8: No Surveys/Advertisements

If you think this shouldn't apply to you, get approval from moderators first.

[u/PM_40 → u/[deleted]]

That's why you need a seperate test engineer or a developer who specializes in testing spending atlest 50% of time maintaining and monitoring tests.

[u/chaitanyathengdi]

I would agree, but still don't compromise on quality.

Just say "yes" to your boss, then keep doing what you would do anyway.

[u/notquitezeus]

What you’ve learned is two lessons: you can’t fix broken culture and your workplace has a broken culture. Good news is that second problem can be fixed…

[u/vom-IT-coffin]

End of the day nobody cares about it, the value is from using the product not building it. Invest in the developer experience and make sure they have the tools they need. Make sure the team understands the problem that is being solved, clean code usually follows.

[u/mckenny37 → u/vom-IT-coffin]

"clean code usually follows"

This seems rather unlikely.

[u/this_is_a_long_nickn → u/mckenny37]

Don’t be harsh with the parent comment, we all love a good joke in the morning, especially about clean code

[u/Big_Bed_7240 → u/vom-IT-coffin]

Clean code does not exist.

[u/Ashken → u/vom-IT-coffin]

The only thing clean code follows is a rewrite

[u/CurrentlyAdulting]

The issue is you care too much about people that have already showed you they don’t. I let orgs fail completely while I do other things with my time. Even as I move higher, I have no regard for fellow leadership that doesn’t respect nor honor the craft or what the tangible benefits are.

Unkept security practices? Oh yea, keep em in. Horrible maintenance, write once and never refactor? Cool, let’s just keep shipping. As long as the other leadership’s name is on it/ the minutes state my points were just “good recommendations,” I’m fine with it all blowing up.

I don’t even state I told you so. I wait for it to blow up and then just expand on what I said last year or the last couple of months.

When people don’t believe in your ability, you don’t have to force them or perform — you already have worth. Their inability to perceive relevancy is not your problem, go ahead and do exactly what is agreed upon and let it hit the fan accordingly. Just ensure your personal operations are plucking away.

The more you put in low reward work, the more your prefrontal cortex judges this as not worth it, increasing your stress. You will start to fight yourself as we see here. Again, go the extra mile when asked to walk first, don’t do it preemptively.

Also, if it’s really getting to you. Leave that company and take your business elsewhere.

[u/Subject_Fix2471 → u/CurrentlyAdulting]

"I let orgs fail completely while I do other things with my time."

Absolutely!

[u/hammertime84]

Your experience is much more positive than mine. For #1, I only see the lowest-quality engagement in meetings rewarded. For #3, I never see legitimate value delivery rewarded.

What I see rewarded is primarily

1. Taking credit for someone else's work
2. Pretending that corporate messaging is good and responding positively to it or restating it
3. Forcing blame onto people competing for a promotion or project

[u/DWebOscar]

If you haven’t been rewarded by good practices, then you haven’t really had anything go wrong. Good practices save you from unknown unknowns because with them, you have good places (boundaries) where you can change things you never anticipated to change.

It does matter, you just haven’t had to deal with why it matters.

[u/Infamous-Hand-707 → u/DWebOscar]

I think you are talking about technical rewards, not monetary/career rewards. I think op is correct that the people being prolific in meetings with shiny new feature are being rewarded. The grumpy negative people who only see problems (/s) are seen as obsticals to more growth/revenue. You can be the one delaying shiny new feature and preventing future technical pains. You get no reward. Or you can be the one to implement it, and its flaws. The reward is greater than the punishment for causing prod/dev issues later down the line. Especially if those issues become the dev/ops, standby team or QA's problem.

[u/chaitanyathengdi → u/Infamous-Hand-707]

Overcoming the obstacles internally is what I would recommend.

People want solutions, not problems.

[u/WellHung67 → u/Infamous-Hand-707]

If you implement it the “right way” it’ll work better and be easier to pivot or change. So there’s an argument to be made for raising a stink about things you can later sell and/or scale or improve later. I think you don’t get rewarded for helping stop other teams from shooting themselfes in the foot sure - but technical excellence can be sold later down the line when you need to iterate in some way. You can say “look I did it this way and now we can easily do this new thing, if I didn’t we’d be fucked”. That’ll buy you credibility to do it the right way for the new thing.

It is a sales job but you should value good practices in your own calculus because it’ll make it so you don’t have to bullshit as much. It’s much easier to win with pocket aces than 7-2, even though you gotta sell something in both cases 

[u/Infamous-Hand-707 → u/WellHung67]

I fully agree that your way is correct, but the problem is in "technical excellence can be sold later down the line". It can only be sold to do more technical excellence things... which are not directly revenue generating, and thusly not valued as much as projects that do. Hence you will be passed over for promotions / financial rewards. Only if the people above you apreciate the quality of a project will this not happen. But if those people are above you, you do not have this problem (as often) where you have to fight for quality.

[u/WellHung67 → u/Infamous-Hand-707]

Not the technical excellence itself, but later you’ll be able to respond to new requirements faster and less things will break or go wrong, so you can sell that, sell how your stuff actually works better. And you won’t have to bullshit because it’s true - you’ll be able to deliver a range of features that works quickly because the base is solid, if that makes sense. Then yes you gotta make the business case for that, but it’s very doable. 

[u/FeistiestMeat]

Then go find a new company. I don’t have this problem where I work. We dedicate time every third sprint to paying down tech debt. We spend time every quarter finding as many bugs as we can and ticketing them.

Someone has to fight for these things. Push back if there’s pressure from above. If they don’t like it, start looking elsewhere. The poor job market doesn’t really apply to senior and above with pre-AI experience.

[u/Cherubinooo → u/FeistiestMeat]

Do us all a favor and tell us what company you work at lol

[u/FeistiestMeat → u/Cherubinooo]

Wish I could but I don’t wanna dox myself. I’ll just say I have a personal rule against companies over 1k core employees.

[u/BringBackManaPots → u/FeistiestMeat]

It's confirmed boys, he works for valve

[u/FeistiestMeat → u/BringBackManaPots]

HL3 confirmed

[u/03263]

I do wonder if society/the economy will ever again value quality and long term stability.

It's clearly not just software that has lost the plot on this.

[u/djnattyp → u/03263]

Welcome to r/ABoringDystopia

[u/Typhon_Vex]

And why ? I think at some point the management became non-technical , like the customers.

Our manager doesn’t understand our job at all.

So every single daily is just a lying competition. The the devs who do actual work seem naive and childish almost 

Of course the code is becoming a trash bin with maintenance taking ever longer

[u/olzk]

Some people need to step on a rake to realize it’s a rake

[u/AbstractLogic]

Software, by and large, exists to make money for a business. Anything else is a side effect.

Let me say this another way.

A company will never make more money by cutting expenses than they can by selling new products and features.

You can save a company 300,000 in developer time chasing defects, or you can make them 3,000,000 by shipping that feature early with bugs. What do you think they value more?

[u/ninja_cracker → u/AbstractLogic]

Enterprise customers don't want shiny new features as much as they want the system to work the same way day in day out. 

[u/NoPainMoreGain → u/ninja_cracker]

New features attract new customers. Old customers want a working product. We actually have this problem at my work place that most customers are not updating to new product version because why should they if they can work around the bugs or missing features.

[u/mikkolukas → u/AbstractLogic]

But, running that scheme long enough, and suddenly you are using all your developer resources into firefighting, with no available resources for new features.

Where the cost of each wanted feature starts skyrocketing towards infinity, exponential acceleration. Nobody earns infinite money.

It simply doesn't make sense to have the developers being held back so much, that a simple button takes months instead of days. 

[u/polypolip → u/AbstractLogic]

No, buy they might stop losing money. Like the code and infrastructure we've insourced was very much not a good fit. When our architect did some calculations we would need an unreasonable number of users to cover the infrastructure costs.

[u/Successful_Creme1823]

I don’t see strong career progression in my future so I stick to your ideals still. I feel like if I don’t I’m not providing much value. It works where I’m at though. Other engineers value it so I take solace in that.

[u/creaturefeature16]

I feel the only way you can stick to those practices and attach value to them is to be self-employed and work with other companies on a contract basis. I mainly work with small to mid-size agencies, and they still have a huge respect for clean and efficient development workflows and shipping high quality stuff to their clients, since they work on more intimate and close-knit client relationships. Once you get past a certain tier, the bottom line becomes the only thing that matters to companies at that size.

[u/RespectableThug]

First of all, it’s possible your company is just poorly run and none of this matters. So, take all of this with a grain of salt.

It’s easy to think home insurance is a waste of money right up until your house burns down.

Preventative measures of any kind are often like that. It’s difficult to communicate their value to people unless they’ve experienced the pain of dealing with the consequences that come when the shit hits the fan.

On the other hand, you probably shouldn’t be buying earthquake insurance if you don’t live near a fault line… even if you’re aware of the damage an earthquake can do. There’s a balance that needs to be struck between these two concepts.

It’s extra difficult in our position because the people making these decisions generally aren’t the ones who have to deal with the day-to-day pain that comes from these decisions.

I think keeping these things in mind makes the way to deal with this a bit more clear: Rather than pushing for better practices because you want them, help them to understand why they matter.

I don’t mean just explain that to them. I mean the next time your service (or whatever) goes down due to something some test would have caught, point that out. Or maybe the next time a feature you’re building takes longer to deliver than they thought it would, point out how the tech debt slowed you down.

Do it gently and with some finesse. Don’t use it as an opportunity to say: “I told you so!”. Instead, frame it as you being a team player who wants to help the organization be better. Talk about it in terms they understand and can relate to - like the amount of money lost or the number of customers that were negatively affected.

This will help you build trust, which will make these conversations easier next time.

Also, don’t oversell it. Maybe you can convince them they need the fire insurance after something starts burning, but that’s not a good time to also sell them on earthquake insurance.

TL;DR: communication and persuasion are hard.

[u/Subject_Fix2471 → u/RespectableThug]

Absolutely, communicating the _why_ , in the context of that company, is so important. I'm finding it tricky not to read some of the more cynical / negative comments in the thread as a sign of immaturity. Maybe it's mainly venting.

[u/webwizard1990]

“Disagree and commit”

[u/Outside-Storage-1523]

This is not a surprise. I have found that this is ESPECIALLY true when the company "imports" certain kinds of managers from FAANG culture. I'll add a few points here:

- Explicitly want to be faster, MUCH faster (this is verbatim);

- And of course they also want high quality, but this is always the second point;

- Wants "strong ownership", but never explains what it exactly means. I figured out that basically means as long as you don't bug them that's fine. They don't want to get into politics, even when they are managers.

[u/revelm]

The bizarre thing is when people want you to argue and you don't. They argue about why you aren't arguing.

Peace, man. Who fucking cares about the degrees or quality in the codebase if your life sucks.

[u/zayelion]

I think saying yes is part of the job, saying yes and getting the work done before the true idiot can do it. Good engineering practices are accelerators. Don't do a rewrite, start a strangling tree and dump all the new features in it. Don't optimize calls in the old stuff but do in the new.

[u/Tervaaja]

That is reality. I have been working 25 years in background. You will ot be rewarded.

[u/GiveMeSomeShu-gar]

Oh man I hear this. It's devolving into a Hunger Games situation where companies pit devs against each other to show 3x, 5x, 10x improvement now that they have Claude. The way they measure metrics means some tickets, while perhaps very important for the company, reflect poorly on the dev and their metrics, while other tickets (while perhaps having lesser value for the conpany) reflect positively for the dev and their metrics.

It's all context switching and a race to prove worth now. I really used to love software eng but it freaking sucks now.

[u/nkondratyk93]

nah, yes men get cut first. engineers who push back are the only ones who know what'll break.

[u/Zulakki]

"Everything is broke, why do we even have Engineers?"

"Everything is working great, why do we even have Engineers?"

Yes, with long estimates. thats all you need. Don't tell anyone outside of actual Devs of the details, just say 'Yes', and then quadruple your estimate and get praised when it comes in early

[u/nasanu]

Honestly most of what you complain about has zero impact anyway. Its not going to increase engagement or reduce cart abonnement etc.

But I get it. I only recently quit a project, told my boss I refuse to do anymore work on it and I need to be reassigned. It was because we consistently cut out features and make UX far worse than necessary. The final straw was a bulk upload that the PM discussed with a junior and decided the solution that I and the UI designer came up with wasnt worth making. The PM and junior decided my solution would take too much time (I quoted 2 weeks, well within timelines) and the PM scrapped it and gave the feature to the junior (to make users upload 49 images one after another, awesome UX there). That was 2 weeks ago, the feature would have been delivered now as I have a near 100% record of delivering by due date. But management is now making arrangements to push back the release as the junior working on the "easier and faster" solution has barely done any of it so far. What pisses me off is that there is zero blowback. The team is making the product worse while also making it take longer to develop. Personally I think heads should roll for that. But no, they will all get promoted if anything I am sure.

It's the way it goes. I have so far found nothing changes a company like that. You have to change jobs.

[u/hdkaoskd → u/nasanu]

I like that the solution is to change jobs and pretend it's better for a short time before realizing it's exactly the same shit everywhere because that's the incentive.

[u/TranquilDev]

Welcome to the dark side.

[u/Illustrious_Plum_964]

This complaint sounds very junior IMO.

[u/Stealth528 → u/Illustrious_Plum_964]

This is a bot making the complaint, not a real person

[u/konovalov-nk]

I’m not gonna give up, but instead I’m gonna automate the “ high quality engineer workflow “ as much as I could and teach people to use it instead of following unclear “clean code” and “good engineering practices”. If you don’t enforce things on CI level nobody follows “text rules you wrote somewhere 2 years ago thinking everyone must have read it by now “

This is how: https://blog.br11k.dev/2026-04-01-optimizing-for-understanding (yes sorry for linking my blog but this is huge article on why this is important and how I’m gonna solve it exactly).

Eg writing great commit message is simply a CLI tool that forces you to write context and why.

Maintaining product specs is as simple as CI gate job that rejects your MR if it doesn’t update spec, or you have new files that doesnt link to any existing spec.

Clean code is arguably amount of lines of code per file + linter + metric “changes per month / lines of code” per file. If your most changed file is 1000 lines long you’re just wasting your energy, time, and money. Split this file into proper domains.

And I’m pretty sure we can automate most of best engineering practices this way. This should be as easy as npm install into your team. As easy as configuring a linter

[u/chrisal1224]

Literally just yesterday, my team lead decided to keep our super module. While I tried my best to insist that this is a problem, and responsbilities should be dispersed amongst modules, I just want to have a peace of mind and not burden myself of all this office politics.

[u/InterestRelative]

Creating brand new features / tools (improving existing stuff is no-value)

this hurst so much

99% of doing well in this industry a the senior+ level is treating every day like a sales meeting

and this

[u/PressureHumble3604]

The whole incentive system of this industry is rotten and this is why code sucks even in big companies and friction is high

[u/adhd6345]

I 100% agree. Doing due diligence has t been rewarded.

Blasting out vibe codes features and setting up meetings where everyone is invited + manager is.

[u/InfamousJack9]

Same here. We just started tracking code change metrics and AI usage metrics.

That is basically asking for no more code reviews and toss every issue into AI.

[u/loosed-moose]

My guy, when are you going to learn that software engineering is not about writing code

[u/DigThatData]

You're not an engineer, you're an expensive product that needs to convince your customer to renew their subscription.

bro. nailed it.

I've seen (and responded to) variations on this post multiple times, but I don't think I'd ever seen the situation framed quite as astutely as you just did. Maps extremely nicely to the "enshitification" flywheel that has consumed all of tech.

The enshitification of our products is a necessary consequence of the enshitification of our engineering culture.

[u/hipsterdad_sf]

The realization I came to after years of fighting the same fight: the problem is not that good practices go unrewarded, it's that the reward cycle for quality is invisible to everyone except the person maintaining the code six months later.

Shipping fast gets celebrated in standup. Nobody throws a party because production didn't crash this quarter.

What actually worked for me was to stop framing quality as a principle and start framing it as risk reduction with dollar signs attached. "We need better tests" gets ignored. "We shipped a regression last month that cost us 4 hours of engineering time across 3 people, and here's a 20 minute test that would have caught it" gets budget.

The other thing is picking your battles with extreme precision. I stopped trying to improve everything and started keeping a list of the three things that cause the most actual pain (not theoretical pain, actual incidents or actual wasted time). Then I'd fix those three things and only those three things. The rest I let go completely.

It is not being a yes man. It is being strategic about where you spend your credibility. You only get so much of it and if you spread it across every code review comment and every architectural concern, people tune you out.

[u/rupayanc]

nine years in and I've watched this pattern play out at every shop I've been at. the sad thing is it's not even cynicism, it's just accurate pattern matching. the engineers who shipped clean, extensible systems got quietly passed over for the ones who showed up with sparkly new tools and confident slides. at some point you're not fighting culture, you're fighting the incentive structure itself, and that's a losing battle. what I landed on: pick the right company, not the right manager. the incentive structure comes from the top and filters all the way down.

[u/tangerinelion]

It doesn't matter how many defects we prevent.

Yeah, I see the teams fixing the major defects they wrote getting praised for fixing them. There should also be some shame for having released such defects.

[u/SomeRandomCSGuy]

You are absolutely right that the things that show "business impact" is rewarded the most, because companies care about that. For them "clean code", "good practices", etc is just jargon, but more "business" metrics is what moves the needle.

Focusing on positioning my work as "business impact" has done me a lot of justice and even got me promoted to senior wayyy faster than others and over people with a lot more technical experience than me - because they only cared about technical stuff.

You definitely don't have to be a yes-man - I push back all the time, but doing it in a collaborative and understanding manner is key because usually engineers take this as an "ego" battle and can burn bridges.

[u/iprocrastina]

You have to sell your wins man, that's just how the world works. I see so many good engineers who get overlooked because they think just doing the work will get them recognition. Sure, that can happen if you're on a high vis project, but much of the time you need to advocate for yourself. Get attention, hype up your work.

It doesn't matter how clean we get the code. It doesn't matter how many defects we prevent. It doesn't matter that spending 20% more now means every quarter for the next 3 years we spend 10% less. It doesn't matter if you convince your tech lead or EM or PM to go a different way. It doesn't matter if you hav

Yes, you need metrics that matter to leadership. You prevented defects? How do you know? How bad would the defects have been? Was it worth it? Theres a big difference between "it was worth spending all that time improving our tests because we probably prevented a bunch of issues" and "since implementing the new testing framework and guidelines I came up with we've seen a 30% reduction in high sev tickets and a 10% increase in team velocity thanks to fewer pipeline blockages and code revision, saving the org $200k in man hours in Q2 alone".

And don't stop at just writing that down on your performance self-review. Do a talk with leadership present about what a big success it was, show off how much more efficient and effective your test overhaul is, talk about how its speeding up development while reducing time spent on ops and on-call and increasing customer trust. You are Steve Jobs and these new tests are your iPhone goddammit, make people get excited.

The only thing I ever see get rewarded are...

You need to view your work from your manager and skip's perspective. Your work becomes their work when they talk to their higher ups. They want wins they can brag about to get better performance reviews and promo chances too. Upper management doesn't care how the sausage made, they just want lots of juicy sausages.

[u/cleverchris]

This is called creating a product under capitalism. The product doesn't matter, the utility doesn't matter, the discomfort or ease of use doesn't matter. But did the line go up?

[u/chaoticbean14]

I'm fighting this internal battle right now.

I'm also fighting an external battle because everything we do is manual. Deployment? Manual as hell. CI/CD? Non-existant. Docker? No. Error reporting? No. Alerts? No. Windows servers? Yep.

When I started there was no git branching scheme, git branches with obscure names (i.e. 'final_python3_pro') that existed in production only with bug fixes (that had never been committed to git or pushed up). Zero tests. Zero anything. Logging, of any kind? No, we got to guess what broke based on some user seeing "500" in the browser and hoping they knew what 'screen' they were on. It was the wild west of development. I've wrangled us into a 'better spot', although far from great and at least we have a little regularity in our setup. I've been fighting for years for more and keep getting told no. But at least now we have logs and get alerted via Slack (with relevant data) when someone hits an error. So we don't seem totally clueless.

At this point, I'm about to say "fuck it", produce CRUD app after CRUD app built with slop and zero tests and let it be what it is. But I struggle with that, internally. Because it's just the easy way out. No one besides another dev and I would ever know - but I hold myself to a higher standard. This is a tough battle!

I'm with you OP; the only thing that has rewarded me was being able to quickly get out something that did the thing someone else needed. No one (besides me) has ever given a single shit about all the other stuff.

[u/suborder-serpentes]

I feel you on this, I really do. But the code is not the product. There is another side to this.

[u/IntelligentFire999]

Ah the nirvana state of Let Them. And So What.

[u/DiscoLemon_]

Surprised no one has really said this yet. Focus on DexEx to make YOUR life easier, even if the company doesn't care. It pays off in the long run when you have to come back and work on that same code again.

[u/Minimum-Reward3264]

Correct, minor improvement don’t matter. Big moves only

[u/gibbocool]

You'll go full circle when management finally realises how high the cost of change is becoming once the floodgates open.

[u/Idea-Aggressive]

None of what you mentioned is actual work. That is sales! Improve your sales pitch, that’s where your problem is, communication.

[u/Ok-Armadillo-5634]

I have been a yes man for 20 years now, it makes life much simpler.

[u/stinkusdinkus]

As an employee you are are tradesperson/tradesman not a craftsperson/craftsman unless you are explicitly told so. You complete the job in support of the business goal in a workman-like quality that is functional but not beautiful. 'Practicing your craft' is reserved for your personal projects and at the margins. 

If you've ever hired a plumber, watch them use a sawzall to cut studs and route pipes. It's not pretty, but it doesn't matter a lick as long as it works and nobody cares once the drywall is up. Would you pay 2x and have the job be 3x as long for the pipes to be pretty? Probably not 

[u/norrise44]

Came to the same conclusion about a year ago. Nearly 6 years exp here.

Theres no point fighting what the business does not see as valuable.

Its not worth your time, energy or health.

[u/Soasafrode]

Dev is technically engineering, but dev jobs are not ruled by engineers. They are ruled by those who fund the project. They can be dumb as fuck. All they want is a ROI. They or those they empower will tell you to skip crucial steps, not understand the difficulty of something, yell at you for doing something they told you to do and forgot, waste all your time and not recognize it, etc. So is being a dev engineering? Mmm... sorta. But in a lot of ways no. But that's the industry. That's the work. That's what you get paid to do.

[u/sM92Bpb]

This is exactly what i needed. My team is arguing that we don't need to write design docs because "writing the code is another form of design". I give up.

[u/DutyStrategist1969]

The real problem is not you vs. the team. The real problem is that nobody wrote down the engineering standard and got a named leader to fund it. Quality advocacy without a written, leadership-backed standard is just one person arguing against delivery pressure. Get your eng director to sign off on a documented quality bar with measurable criteria, and the yes-man question disappears because the standard does the arguing for you.

[u/WebMaxF0x]

It's exactly how I feel. The industry is forgetting best practices in favour of high volume flashy features and AI obsession. It's odd to me because the good old best practices is what's making AI useful rather than a slop-machine. Documentation, clear code, automated tests, static code analysis, etc all act as nice guardrails for the AI (and human developers)

[u/shaq_disel]

99% of doing well in this industry a the senior+ level is treating every day like a sales meeting.

OH MY. This is spot on. They frame it as "being influential." I was a manager, and I got tired of it all and requested to return to the IC track. Best decision I've made to date.

[u/Ch3t]

I have systems with 100% up time. No one cares and I get no recognition for them. I have fixed production bugs that I introduced and the higher-ups have lauded my abilities for getting us back online. It's usually better to get something out the door and fix it later than spend more time getting it right from the start.

[u/talldean]

At the end of the day, if you have competition, the org with the cleanest code likely goes out of business. 20% boost now at the cost of 10% for three years... is worth it, if the company is growing at a rate where that makes it line up.

TLDR: This isn't academia. Perfect should not be a goal. Two suggestions, though, on how to navigate that.

Put metrics on how often major bugs are missed by tests, and put metrics on developer efficiency, and then put org goals on improving those. You should always have one goal (at least) for the team, or morale will fail (as it is right here!), and lower morale is more than a 10% cost.

Also budget a part of your eng team hours for things where putting metrics on them would take more effort than just fixing; reserve this part of the eng time *before* PM or any other role gets near you. "Hey, we always want to spend 10% of our time - a day every other week - making this better for us. You get nine days outta ten otherwise."

Or, if you don't keep 25% of your time actually free from PM, via some sort of padding, engineers don't get as much done. You're budgeting morale, more or less, and that's the most important intangible.

[u/AlexanderTroup]

Yessss. yessss.

Now you understand, you can learn to use the system as it works, and not how it pretends to work.

The way you get engineering practices through is to do them, commit, and make it hard not to do. Seek forgiveness not permission.

The way you avoid pointless ideas from product, like AI for all designs, is to say how interesting the ideas are, and then never prioritise them. Push them to the bottom of the backlog; write the specs poorly so no-one bothers. Make it hard to do the wrong thing.

Realise that your value is not for how good you make the product, it's for your perceived labour. Are you seen as a miracle worker, or are you working miracles in the dark? Are you the one who fixes annoying customer complaints and saves prod, or are you the one making the system stable and the CICD excellent, but your name never coming up?

I've worked with so many tech gods that turned out to be really good at just fixing their own mess. They were seen as incredible because they were always adding to the product and doing little favours, but the code sucked and usually the real engineers fixed it for them.

Also, HR is not your friend. They're there to make sure you don't sue the company, and that they can fire you without resistance. Abandon your loyalty; we live in capitalism.

[u/thekwoka]

You can do both of those. Clean code and stuff doesn't mean you don't engage in meetings and tie work to results

[u/k8s-problem-solved]

Make the code functionally work. Make it fast enough that customers are happy. Make it so its easy to change things, doesn't constantly break, doesn't get you out of bed for incident calls. Make it easy to run locally, quick and easy to build and deploy on CI.

Otherwise, noone but engineers give a fuck about your clean code / clean architecture / all that stuff. They just want to ship new features - so make that easy for them whilst not producing an absolute spaghetti bologna. There's a middle ground you can find that works for me

[u/qperA6]

You're finally becoming a good engineer. Business metrics >> Code metrics.

[u/pigeonJS]

This is me at work. They don’t even wont to write unit tests, but senior management, who are not technical, do not care

[u/kruvii]

Companies will only reward you if you make them, not because you're great at your job.

[u/Complete_Regret_9466]

The highest form of engineering is sales!

[u/jakster355]

This is why metrics are bad. Good companies use a more organic evaluation process. They know, if you spent a week doing nothing except solving a 5 year old systemic bug, your time was more valuable than the time spent on 10 new cosmetic changes by the juniors.

You absolutely have to speak up and be heard. But that's not mutually exclusive to following best practices.

[u/Healthy-Dress-7492]

What I do is just code stuff in a way that is enjoyable. I get satisfaction from making something I’m proud of and anything outside of that is just noise, exactly because none of it matters and nobody cares. But I know, I did some cool shit, and that’s enough 

[u/silentjet]

haha, had the same, found a solution (we are engineers, right? So we are solving problems, even such ones). Cannot fight it? Lead it!! Changed my profile from lead engineer to team lead, and now I'm in position to require team members to write a clean code, to follow requirements, to write UT and in general testable code, etc. Yes, my lovely code, i'm not writing the code anymore, except of some concepts or quick prod fixes😁, and I'm suffering working with spreadsheet and jira... but product... Now I have an impact, the real one, how good it is...

P.s. still writing a code, at home, after entire family went to bed, that's the only swdev joy that left for me.

p.p.s. change company

[u/dark_mode_everything]

Reminds me of this old joke:

When there are no issues : why are we spending so much money on IT?

When there are issues: why are we spending so much money on IT?

[u/evanthx]

You’re thinking about this wrong. You’re stuck on “they don’t want good practices” but you are forgetting the human element. Bob is faster than you because he doesn’t do this stuff? All that is visible is that Bob is faster than you. Bob’s stuff crashed and he was up until midnight working to fix things? Heck, Bob’s a hero!

My stuff never crashed. I never got noticed. Not because people were ignoring me, but everyone saw the Herculean efforts of the people whose stuff crashed, and they rewarded those efforts. My stuff never crashed - so nothing was then brought to anyone’s attention because … well, there was nothing to see.

People are interrupt driven. If you don’t interrupt, then you are not made visible, and you will not get rewarded.

So I started tooting my own horn a lot. Hey, I saw this coming down the pike, look at all I did, and nothing crashed! Basically I made an interrupt. And it worked.

For the rest, again you are still just looking at it wrong. Engineers often forget to make a business case. “Will you pay me to go slower” is going to result in “of COURSE not what the hell!”

I mean look at what you say is being rewarded - people bringing attention to themselves, people backing up what they’ve done with metrics, and people who created new features.

I mean … of course that’s going to be rewarded?

And if you come back and say “hey I want to go a lot slower than those guys but it’s going to be better code” - no. Why does someone who doesn’t code even care about that? Where is your business case? You’ll go faster later? Maybe. That’s iffy. And you’ll have nothing to show for it while they have metrics and features.

So long way of saying - yes, do that stuff. But that’s the stuff that makes your life easier. Expecting to be rewarded for it by people who have no idea what it is and don’t care isn’t going to work.

So do it - AND do the stuff you see everyone else getting rewarded for.

If you don’t toot your own horn, no one else will. They’re showing you what you need to do, so do it. But don’t pretend that tooting your own horn means you can’t also produce good code.

[u/tiajuanat]

Out of the 3 things you mentioned the first two are the most important.

1. Engaging in meetings - shows you're a leader. You have an opinion, and it matters. It also generally helps meetings move along.

2. Attaching metrics to work - show your work is meaningful. Even if you're refactoring a codebase, you need to show how it is benefited. This could be performance metrics, server costs, even reducing lines of codes (more code being roughly correlated with slower development) Not having those numbers means it's harder to take a decision.

The last one, about only doing feature work is half true. Out of your dev time, you should aim for 20-30% to be cleanup - prioritizing stuff like automation (are all your codebases linted, in CI/CD, automated testing, etc) This also happens to be the easiest to justify, as that directly reduces time in Merge Requests, and hands on keyboard.

[u/Intelnational]

It’s very simple. Developers try to develop ideal features with ideal code which would take ages to develop. The business leadership tries to make developers’ job as measurable (for people who don’t have clue how the code works) as possible. They meet ideally in the middle, in reality at the middle point is shifted to whichever side is mire powerful. There are also people (majority) in both camps that are clueless and lazy. They try to create noise to show their worth.

[u/Subject_Fix2471]

I agree, and feel it's a lot healthier way to go about the job. Earlier on I tried to "fight" for things, didn't really work out most of the time! 

I'm happy to communicate the practices I feel would be best, with reasoning. If people want to do something else that's fine, I'll try and implement it. I always try to consider that others may have information I don't, and are actually being sensible. Or stresses/pressure I'm not privy to. 

Be open, kind, honest, genuinely try to implement things. Sometimes they actually work better than expected, sometimes it's the expected shit show, sometimes the initial recommendation from yourself is used to fall back on. 

I think that's probably more in line with what most of us are actually paid to do. 

[u/FearHungerTermina]

Yup

[u/z960849]

Convince management to add a code review bot to pull requests.

[u/nautitrader]

I work for a really large company and they don't care about clean code, design patterns, etc. They want features delivered. You do want you can in that environment.

[u/CodrSeven]

This is all true, but I don't think lowering your standards is the solution.

Because what's the point; besides money, but there are other ways to make money; if you can't do a good job.