I'm giving up; Becoming a yes man.

[-]

InformalInsect5546@reddit

It might be your colleagues are idiots. But it might be you are in an annoying spot in your carreer where you are the problem with trying to follow theoretical nonsense that doesn’t work well in practice. Please read https://grugbrain.dev/

[-]

FeistiestMeat@reddit

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.

[-]

Cherubinooo@reddit

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

[-]

FeistiestMeat@reddit

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.

[-]

BringBackManaPots@reddit

It's confirmed, he works for valve

[-]

FeistiestMeat@reddit

HL3 confirmed

[-]

Abject_Flan5791@reddit

I jizzd

[-]

Trick-Interaction396@reddit

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.

[-]

Special_Database2491@reddit

If it makes you feel any better, this shit mountain will collapse under its own unsustainability and eventually every company will have to deliver real value in order to survive.

[-]

fangisland@reddit

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.

[-]

Prestigious_Tip310@reddit

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.

[-]

fangisland@reddit

Yeah that's fair, and it depends on how evolved the product space is. If you're spending a ton of time treating a product like it's a commodity, when you don't even know if it has value yet and could be thrown out, you're spending the wrong type of energy on it. I like Wardley mapping for this, to use different methods depending on how novel the product space is. But there are some generic "before first feature" guardrails I always like to put in place, like CI quality checks for secret detection, linting, pre-commit hooks, etc. Certain things are just table stakes imo.

[-]

no_onions_pls_ty@reddit

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.

[-]

hippydipster@reddit

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.

[-]

creaturefeature16@reddit

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.

[-]

Cube00@reddit

At least it's not SAP.

[-]

dontquestionmyaction@reddit

Somehow the SAP alternatives suck worse.

[-]

leafEaterII@reddit

Or atleast it’s not Salesforce

[-]

Electronic_Yam_6973@reddit

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

[-]

mile-high-guy@reddit

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

[-]

NerdEnPose@reddit

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

[-]

mile-high-guy@reddit

The key is to always join the companies on the upswing

[-]

myaltaccountohyeah@reddit

How to identify that?

[-]

polypolip@reddit

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

[-]

-S-P-E-C-T-R-E-@reddit

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

[-]

RustOnTheEdge@reddit

This is depressing

[-]

guasanas@reddit

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.

[-]

gsxdsm@reddit

Why? Don’t let it be. It’s easy.

[-]

RustOnTheEdge@reddit

This has a very high “just stop being poor” vibe lol

[-]

anotherleftistbot@reddit

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

[-]

AvailableFalconn@reddit

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

[-]

Material_Policy6327@reddit

It’s the reality of life sadly

[-]

Empanatacion@reddit

"The Zen State of Fuck-It"

[-]

Working_Noise_1782@reddit

Dude, you don't understand. I'll develops some hardcore HDL crap that works to the T. Satisfied all reqs. Then I'll have people crow in and trifle on variable names, comments being to long or short. Oh you used the same line twice, why didn't you make a function.

I had a dude that insisted on adding change comments at the beginning of each file with a date describing what you do on each commit.

I.e. First comment: I added variable a Second comment: I renamed variable a to b.

[-]

vvf@reddit

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

[-]

INFLATABLE_CUCUMBER@reddit

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

Source: Me. Sorry.

[-]

goonifier5000@reddit

The fuckening state programmers

[-]

Neuromante@reddit

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.

[-]

ThlintoRatscar@reddit

But, y'know, there is love of the paycheque.

Unless you are the founder, we are professionals hired to do a job for pay.

Nobody buys tests. They buy features that work to make their lives better.

Testing is about finding defects that compromise the ability of features to deliver value. It doesn't fix anything - it finds things and measures the state of a version.

A testing culture is one that is adjacent to a quality culture. We are paranoid so we over inspect the artifacts to find flaws. We also invest in tecniques ( best practices ) to reduce the scope of testing by reducing the ways that the code can possibly break.

But, every flaw discovered through testing also needs an imvestment in fixing. And every flaw that could have been prevented is a flaw in ourselves as technical professionals.

[-]

Neuromante@reddit

But, y'know, there is love of the paycheque.

I'm not arguing that we like to get paid, I'm arguing that what was supposed to be a career about building stuff has become a dilbert-esque hellscape of corporate nonsense at best (and the foundations of a surveillance estate at worst, but that's another topic).

We are taught to care only about the business side of things while we progressively forget why are we doing the things we are doing. Testing is there to prevent stuff breaking when adding new stuff, and to ensure the stuff we add does not break. Period. I do understand that the explanation to a business guy should be in terms of money and time lost, but I'm not the one who should convince the business guy to go for that approach, I'm the one who will pass a job offer if there is no previous understanding of this concept.

[-]

TheLastKingofReddit@reddit

Teach me your ways. I need to learn to be like this

[-]

AbstractLogic@reddit

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

[-]

gsxdsm@reddit

Money is time and time is all we have.

[-]

BlackCow@reddit

Make the money why you can because it won't last, eventually the bullshit will hit a critical mass.

[-]

Krackor@reddit

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

[-]

kingofnaps69@reddit

I think OP’s point isn’t even just about doing what makes the most money, at least long term. It’s more that things that make money in the short term at the expense of the long term and things that look flashy are what get you rewarded

[-]

Trick-Interaction396@reddit

You're right. Thanks for your insights.

[-]

kingofnaps69@reddit

… shit lol

[-]

Working_Noise_1782@reddit

From the start I didn't give a fuck. I'll commit wtv trash that passes tests.

[-]

aristarchusnull@reddit

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

[-]

rco8786@reddit

This is the way.

[-]

Deep_Ad1959@reddit

the reason testing never gets rewarded is usually because the cost of writing and maintaining tests is too high relative to the perceived value. when your e2e suite takes a full sprint to update after a UI refactor, nobody wants to be the person advocating for it. the teams where testing actually sticks are ones that invested in making test creation nearly zero friction, automated selector maintenance, and kept CI under 5 minutes. at that point testing stops being a political fight because it just catches regressions that would have slowed down the shipping velocity everyone cares about.

[-]

SerLarrold@reddit

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

[-]

soul4rent@reddit

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 test total runtime. In general unit tests are faster than integration, which in turn are faster than E2E tests, but 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 to make writing bad software that introduces bugs more miserable and less rewarding than writing good software.

[-]

black_tamborine@reddit

I’m sending you a huge bouquet or flowers. 💐

[-]

Kaenguruu-Dev@reddit

Last project I worked on took ~ 1.5h for the full test suite. That was some great fun

[-]

Head-Bureaucrat@reddit

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

[-]

WebMaxF0x@reddit

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.

[-]

tatorface@reddit

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.

[-]

black_tamborine@reddit

I totally fell for the bait. Thanks so much for flagging this. 🤗

[-]

engineered_academic@reddit

Thank you for your service!

[-]

Yabakebi@reddit

Deary me. It's really over man

[-]

black_tamborine@reddit

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

[-]

Deep_Ad1959@reddit

oh nice, what kind of stack are you testing against? curious if you've found anything that actually keeps e2e maintenance sane or if its still mostly pain

[-]

tatorface@reddit

bad bot

https://s4l.ai/stats/Deep_Ad1959

[-]

ExperiencedDevs-ModTeam@reddit

Rule 8: No Surveys/Advertisements

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

[-]

Electronic_Yam_6973@reddit

IMO, after 20+ years of development, unit tests are a negative return on investment. 99% of the bugs I encountered are integration issues that a unit test would have never picked up. Yet, in my experience integration tests are severely neglected because it’s hard and still probably a net negative return on investment.

[-]

Big_Bed_7240@reddit

Yes, but I think most people mess up integration tests too. Your integration suite should run almost as fast as your unit tests, or no one will maintain them, because the feedback loop is too long

[-]

zerd@reddit

Also, Nobody ever gets credit for fixing problems that never happened. https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf

[-]

NickW1343@reddit

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 quantify into dollars how much that's worth? 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.

[-]

pydry@reddit

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.

[-]

Electronic_Yam_6973@reddit

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.

[-]

Live_Fall3452@reddit

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.

[-]

djnattyp@reddit

And then new nontechnical manager comes in, complains that the barn is too expensive to support and makes new features take too long to release and burns it down.

[-]

oupablo@reddit

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

[-]

Deep_Ad1959@reddit

i've actually seen it work without the outage wake up call, but only when someone frames it in terms execs already care about. like instead of 'we need e2e tests' you say 'deploys take 3 days because we manually verify everything, here's how we cut it to 2 hours.' suddenly testing is a velocity play, not a quality sermon. still hard though, you're not wrong that most orgs learn the hard way.

[-]

Live_Fall3452@reddit

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

[-]

TheSexySovereignSeal@reddit

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 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"

[-]

Ok_Individual_5050@reddit

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

[-]

positivelymonkey@reddit

In my experience they just fire the QA team and tell engineers to be better. Also your job is easy now cause AI

[-]

PlasmaFarmer@reddit

I miss other companies where CI was <5 mins. Here I push and go get a coffee and when I come back I still need to wait for that damn thing to complete.

[-]

speculator100k@reddit

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

Anyways, update the tests as you go.

[-]

PM_40@reddit

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.

[-]

Healthy-Dress-7492@reddit

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

[-]

vom-IT-coffin@reddit

End of the day nobody cares about it, they make money using the product not building it.

[-]

Ashken@reddit

The only thing clean code follows is a rewrite

[-]

oupablo@reddit

you sure about that?

[-]

Athen65@reddit

It's almost inherent. Business needs become clearer, feedback is gathered, and requirements that were previously unknown become known. Better decisions can then be made about code design (especially OOP, APIs, and DB), since you have a clearer picture of the domain and I/O

[-]

Ashken@reddit

Yes. Not to say all rewrites produce better code, but I’ve never seen a first pass codebase just get cleaner code overtime just because.

[-]

d0ntreadthis@reddit

Unless the team doing the rewrite didn't understand the initial quality issues in the first place, and end up producing the same hot garbage again ;-;

[-]

oiimn@reddit

Preach brother

[-]

Big_Bed_7240@reddit

Clean code does not exist.

[-]

adhd6345@reddit

DevEx falls under that same category…

[-]

mckenny37@reddit

"clean code usually follows"

This seems rather unlikely.

[-]

this_is_a_long_nickn@reddit

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

[-]

Sunstorm84@reddit

In my experience as a contractor, clean code almost never follows.

[-]

digibath@reddit

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

[-]

Big_Bed_7240@reddit

Average soulless answer. I absolutely hate everything about this

[-]

digibath@reddit

you hate making money and keeping your job?

[-]

Big_Bed_7240@reddit

Having 0 emotional attachment to your work must be absolutely horrible. I’ve never understood this cope. You are going to spend 9 hours of your day on something you don’t care about just because you are so jaded? That’s not a solution to anything. That’s how you turn old and bitter.

[-]

eightslipsandagully@reddit

Working 40 hours a week from the comfort of an air conditioned office, mainly at home. Getting paid enough to live in a nice house in a good location and do whatever I want on weekends, travel when I wish etc.

There's definitely far worse lifestyles, you just have to find enjoyment and fulfilment outside of work.

[-]

digibath@reddit

I actually like my job, and I’m not bitter. Emotionally detaching is a pretty stress free mindset. I’d argue it’s pretty healthy thing to do. You can have both.

[-]

Big_Bed_7240@reddit

Can you? How?

[-]

digibath@reddit

Stop treating the code you write for a company like your personal baby. You don’t own it, the company does.

[-]

Big_Bed_7240@reddit

That’s not a problem for me, but you can have emotional attachments to other things than the code.

[-]

digibath@reddit

I like the people in work with, the job is relatively stress free, flexible work/life balance, and it pays well. I don’t need an emotional attachment to anything else regarding my work to be happy.

[-]

positivelymonkey@reddit

Job market is booming for top level. Juniors fucked.

[-]

forbiddenknowledg3@reddit

My biggest wins this past quarter are publishing my prompts as "skills". Just what are we doing lol.

[-]

ContraryConman@reddit

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.

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.
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 their 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 piece 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

[-]

Hamburgerfatso@reddit

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.

[-]

Material-Smile7398@reddit

This is the exact problem I face, it’s impossible to escape the bad practices

[-]

ContraryConman@reddit

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

[-]

Hamburgerfatso@reddit

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.

[-]

Creaking_Shelves@reddit

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.

[-]

unknownhoward@reddit

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]

[-]

ContraryConman@reddit

Mine did. Sorry if you can't relate

[-]

30thnight@reddit

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

[-]

unknownhoward@reddit

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?

[-]

ryhaltswhiskey@reddit

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.

[-]

hdkaoskd@reddit

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.

[-]

crabsock@reddit

I don't think in the long run this approach will actually take that much longer. Far more important to be solving the right problems, actually shipping solutions, and estimating well. If the solution takes 4 weeks instead of 2, no one will care as long as you communicate that from the start.

[-]

Rich_Classroom3133@reddit

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

[-]

Ok-Entertainer-1414@reddit

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

[-]

timewarp33@reddit

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.

[-]

ContraryConman@reddit

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

[-]

arshbio009@reddit

i’m printing and framing this to a wall

[-]

hockey3331@reddit

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.

[-]

nooneinparticular246@reddit

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.

[-]

TheRealJesus2@reddit

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!

[-]

Careful_Let509@reddit

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.

[-]

Bousha29@reddit

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

[-]

WellHung67@reddit

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

[-]

jakster355@reddit

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.

[-]

chaoticbean14@reddit

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.

[-]

Big_Bed_7240@reddit

I ask the same question to people like you, why don’t you do it yourself? Don’t ask. Just do it.

[-]

chaoticbean14@reddit

I've done that where I can. It's why we've made improvements. But there are certain things that are beyond my control and need administrative approval and buy-in from other teams. That's why. There are certain things that are simply impossible for me, myself, to 'just do it'. While our team is small, the organization is large. Server admins, network admins, security teams, software approval process', etc. Just spinning up a random server without approval? The network is locked down and it wouldn't work - I imagine there would be big repercussions if someone were to just go all rogue.

So, you can ask people that question - but I would recommend you stop saying that. It comes across like you lack understanding of large organizations and/or experience and/or how things operate in the real world with large teams of people. I can't think of anywhere I've worked in the last 15-20 years that would allow devs to 'just do it' for things outside the scope of development.

[-]

Big_Bed_7240@reddit

As is usually the answer on this sub: move to a smaller company

[-]

chaoticbean14@reddit

That's insanity and again screams: "I have no experience". I'm not moving from a company that offers me a fully funded pension and literally tons of other great benefits you don't find elsewhere (retirement matching, excessive vacation days, low stress, etc.).

I can put up with the lack of ability to do anything I want, for all these benefits. But I've been thinking about adjusting my workload and personal expectations of what should be done versus what I currently do for the reasons I mentioned - it's a personal battle.

Additionally, letting certified pro's handle their area of expertise is a boatload better than me thinking I know how to properly securely setup everything in areas where my expertise is lacking. That's ignorance. I'm okay with not being the ignorant guy that fucked up things and broke everything by moving to a company where he could just 'do what he wanted'. That's terrible advice.

[-]

Big_Bed_7240@reddit

Yet you complain about a situation at work that you can’t change. You said it yourself. It’s an external battle.

I guess you could just spend your last years hoping for the best. Sounds like a great way to live life. But that’s just me. You do you.

It’s very ignorant of you to think I don’t have any experience and that there aren’t jobs out there with the same benefits, better pay and with fewer employees.

About your comment regarding “certified pros”, you are just contradicting yourself. If they are so good, why are you complaining about them? Sounds extremely silly.

[-]

Acceptable-Wasabi429@reddit

Unfortunately, this has also been exactly my experience. I’ve also arrived at the same conclusion as you and decided to do what I can where I can. My primarily focus is on getting along, doing my part to keep the lights on, and passing Go every two weeks.

Protecting people from themselves is a thankless job in the workplace and out of it. Not gonna waste time losing sleep over this stuff.

[-]

Complete_Regret_9466@reddit

The highest form of engineering is sales!

[-]

kruvii@reddit

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

[-]

rupayanc@reddit

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.

[-]

pigeonJS@reddit

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

[-]

qperA6@reddit

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

[-]

hipsterdad_sf@reddit

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.

[-]

Zulakki@reddit

"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

[-]

Federal_Ad_5275@reddit

what made you decide to stop fighting for quality practices

[-]

RabbitLogic@reddit

Sounds like a culture which only cares about quality through platitudes rather than actions.

[-]

DigThatData@reddit

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.

[-]

k8s-problem-solved@reddit

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

[-]

DWebOscar@reddit

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.

[-]

Infamous-Hand-707@reddit

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.

[-]

WellHung67@reddit

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

[-]

Infamous-Hand-707@reddit

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.

[-]

WellHung67@reddit

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.

[-]

chaitanyathengdi@reddit

Overcoming the obstacles internally is what I would recommend.

People want solutions, not problems.

[-]

ugh_my_@reddit

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

[-]

HowTheStoryEnds@reddit

The bus bounces their monies to you!

[-]

thekwoka@reddit

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

[-]

Illustrious_Plum_964@reddit

This complaint sounds very junior IMO.

[-]

Stealth528@reddit

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

[-]

Outside-Storage-1523@reddit

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.

[-]

AlexanderTroup@reddit

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.

[-]

loosed-moose@reddit

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

[-]

talldean@reddit

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.

[-]

Ch3t@reddit

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.

[-]

shaq_disel@reddit

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.

[-]

WebMaxF0x@reddit

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)

[-]

DutyStrategist1969@reddit

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.

[-]

AbstractLogic@reddit

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?

[-]

ninja_cracker@reddit

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

[-]

AbstractLogic@reddit

Are you a PM? The onsights I’ve done with customers they are always asking for more stuff.

[-]

NoPainMoreGain@reddit

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.

[-]

mikkolukas@reddit

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.

[-]

bigmoneyclab@reddit

Nailed it. If you want to make toys, do free work under open source or work on your own stuff. We are making businesses here.

[-]

polypolip@reddit

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.

[-]

sM92Bpb@reddit

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

[-]

Soasafrode@reddit

Dev is technically engineering, but dev jobs are not ruled by engineers. It is run by those who fund the project. They can be dumb as fuck. All they want is a ROI. They or those the 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, etc. So is being a dev engineering? Mmm... sorta. But in a lot of ways no.

[-]

Gunny2862@reddit

Being a great developer and a great manager are two separate things.

[-]

norrise44@reddit

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.

[-]

crownclown67@reddit

In my core I'm a perfectionist. It doesn't mean that everything I do is perfect. But I always fixed things when I saw that they can be improved. But in reality it is my brain issue. So my advice is to not to be a yes man, but rather understand why it is happening. why perfectionism is blocking you? Is perfect solution is better than a working solution?

I'm thinking lately about Pareto and how I can use it (as a filter) :
- work 20% to give 80% of results.
- same with tests, first 2-3 tests covers 80% of cases.
- same with projects management - 20% of meetings will cover 80% of problems.
- in meeting focus on core things (20%)
- improve existing code only if (it is failing or if change (20%) will give 80% of improvement - whatever it is)

What I want to say is - don't do the 80% to gain 20%.
"Working" is better than "perfect".

[-]

stinkusdinkus@reddit

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

[-]

InfamousJack9@reddit

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.

[-]

adhd6345@reddit

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.

[-]

ActuallyFullOfShit@reddit

You can be cynic about it, but, there's an aspect of pareto principal at play here. Shipping something functional with mediocre architecture is maybe 80% as profitable as a perfected version that would take twice as long to build. Your company would rather make $80 twice than $100 once.

You are confused if you think performing your own artform with world class precision is actually aligned with your employers profit motives. It is not. Good enough is good enough.

[-]

03263@reddit

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.

[-]

djnattyp@reddit

Welcome to r/ABoringDystopia

[-]

Ok-Armadillo-5634@reddit

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

[-]

Idea-Aggressive@reddit

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

[-]

nkondratyk93@reddit

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

[-]

webwizard1990@reddit

“Disagree and commit”

[-]

AdministrativeMail47@reddit

This is why I left my previous job, and why I am about to leave my current one (which is massively worse than my previous job at testing). at my last job we had QA sprints, this one, fuck-all. PM and client just says YOLO PUSH STRAIGHT TO PROD. I warned them in writing. They DGAF.

[-]

CurrentlyAdulting@reddit

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.

[-]

gibbocool@reddit

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

[-]

bigmoneyclab@reddit

Are you 12? Feels like you just learned basic human relationships. Also all your proposal about “clean” code are probably subjective, which is why people try to use metrics lol

[-]

Minimum-Reward3264@reddit

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

[-]

PressureHumble3604@reddit

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

[-]

HoratioWobble@reddit

I've seen this a lot and also your new stance.

What often comes next is denial, engineers who think they're producing high quality, they're convinced they're creating an amazing, polished product and get annoyed when anyone challenges that.

I've seen teams happy with poor test coverage, weekly outages, manual testing, code bases that are about as readable as the clockwork orange.

Genuinely it's a frustrating industry to work in

[-]

DiscoLemon_@reddit

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.

[-]

theodordiaconu@reddit

I'm writing tests because I move much faster with more precision. Even pre-AI era, writing tests was a way for me to consume less 'thinking tokens' about what I'm building as I had a loop where whenever I clicked save, it would run all tests that failed until they were all green like the grass of my neighbour.

The reason I write clean code was not at all to prove my 'sensational' coding traits, but rather because I knew higher ups always change their mind, and then I had to re-engineer everything so I tried to sort-of predict and think ahead.

Writing tests was not a negotiable thing to me, once you get the hang of it, it is actually a way to speed up dev, instead of testing like a monkey with Postman or from UI.

[-]

superpitu@reddit

Why do you need to tell these people what you do? Quality is an integral part of what we do, it’s not done until quality is assured. You simply do what you need to do and that’s the end of it. They have no clue what we do anyway, it’s a black box for them, you don’t need to explain. Just give them an indication of progress so that they feel in control.

[-]

InterestRelative@reddit

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

[-]

CaitAndaCat@reddit

I've found a way for myself to show the value of code improvements to the business. It doesn't work for all tech improvements but doing it for some gives you trust and credit to do more. I've been refactoring navigation in-between feature tickets and then I did that: Step 1. Sounding like a broken record that a lot of new features planned for next quarter will be done faster if I got some time allocated to finish my refactoring (I exaggerated ofc cause this did not apply to all the features but a couple of them). My PO is quite reasonable so I got one sprint for that. Step 2. Implemented performance metrics and measured performance before and after refactoring. Measurements can vary, so I ran them multiple times and picked those looking the best for me. Step 3. Created an amazing presentation with the help of Claude showing the difference for the user: stuff loads 30% faster and costs us a bit less. I presented it during a sprint review to business stakeholders. Everyone is surprised and excited. When devs are talking about the importance of good code and tech debt handling it all sounds hand-wavy to business. They don't know how to talk about it to stakeholders. When you turn it into a user value, now you are on the same page and speak the same language.

Now I have more weight when asking for some time for tech tickets and I've put this stuff on my performance review and got a max raise (not only because of this but still gives a lot).

Hope it helps. But I do agree that just producing great code that doesn't give any problems to anyone is not going to move you far.

[-]

Thedaruma@reddit

I’ve been more lenient with other folks shipping things that they and I both know is garbage into the repositories I maintain. I smile and nod when they promise to clean it up (and ultimately never do). I ask them to create a ticket to address the nonsense and do it the right way once their experiment finishes and they gathered the proper signal for further investment or not.

If something sucks sufficiently (because it’s someone unfamiliar with the stack or…unfamiliar with code/programming at all, as is increasingly the case…) I’ll go in with an LLM and take a pass that usually condenses their dumpster fire of 500-1000 lines down to a clean fraction of that with an LLM. Takes a few minutes these days.

I don’t mind cleaning things up in this manner. They’re either thrilled to have an opportunity to learn how to do things cleanly (I work with a lot of curious and driven people) or they’re happy that I let them invest in short term productivity/experimentation while keeping tabs on the withdrawal of quality in the longer term.

[-]

kramit@reddit

Lean into the enshittification. Let the world burn, it’s what they want to happen, let them make all those mistakes. Just be ready with a fire extinguisher and an invoice

[-]

NotHachi@reddit

What are you gonna tell me next... We all get paid in the end of the month and we worked for money ? xD

I gave up on the "artisanal" side of coding on year 2.

The name of the game is do as little as possible while making sure you get promoted as high as possible.

In the end, they don't give a shit about us and most of us ain't linus... So why bother...

[-]

ilyas-inthe-cloud@reddit

I got a lot less frustrated once I stopped selling clean code as virtue and started selling it as speed or risk. Most orgs do not reward elegance. They will sometimes reward "this cuts incident volume in half" or "this saves us two engineers worth of maintenance this year."

Annoying reality is senior+ work is part engineering, part translation. If leadership only speaks revenue, risk, and delivery dates, you have to package the engineering argument in that language or it dies in the room. Doesn't mean become a yes man. More like pick fewer battles and bring receipts.

[-]

imightbewrong@reddit

It puts the fries in the bag

[-]

nasanu@reddit

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 an the UI designer came up with. 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.

[-]

hdkaoskd@reddit

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.

[-]

Different_Alps_9099@reddit

“It doesn't matter how clean we get the code” you’re right. It doesn’t.

[-]

GiveMeSomeShu-gar@reddit

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.

[-]

Tervaaja@reddit

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

[-]

ultraDross@reddit

Ability to attach metrics to your work and then make those metrics look good

Can you give me some examples of this? I'm struggling to visualise what this would look like.

[-]

olzk@reddit

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

[-]

tvnerd0@reddit

Yes sir!

[-]

BoringBuilding@reddit

I’m not trying to sassy but this isn’t really that weird is it? Most of us are employed in this field for tasks very far disconnected from the things you are passionate about. There are exceptions but the majority of us are paid to support business units of various stripes. You may feel that the things you are describing are generating value, but the chances are that value is realistically far lower than you think. I’m not saying this out of any disrespect or disagreement with you, it may just be that I have already resigned myself to this truth.

You can get away from this paradigm to a certain extent in certain industries that have human safety involved in the mvp. They tend to be more receptive to these types of values in my experience.

[-]

cleverchris@reddit

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?

[-]

Typhon_Vex@reddit

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

[-]

chrisal1224@reddit

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.

[-]

FitUnderstanding2278@reddit

Very well said. It's a common story in many companies. People ignore the fact that sometimes "slowing down now to speed up much more later", is critical. Most people just focus on visibility.

[-]

vbilopav89@reddit

None if matters in reality. Only true value delivered to users. Nothing else.

[-]

chaitanyathengdi@reddit

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

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

[-]

zayelion@reddit

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.

[-]

Dialed_Digs@reddit

Just make sure every request is in writing. They WILL toss you under the bus if necessary.

[-]

IntelligentFire999@reddit

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

[-]

e430doug@reddit

All of the things that you’re saying are good engineering practices are very subjective. Are you advocating in good faith or are you complaining? Are you trying to teach people? The job of your team is to deliver software. There is no absolutely good way or bad way to do that. It’s all gray.

[-]

hw999@reddit

If you arent an owner or shareholder, then why care? it aint your money. do your 40 hours and relax.

[-]

RespectableThug@reddit

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, 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 you lost or the number of customers that were 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 is hard.

[-]

seanoz_serious@reddit

If you’re not attaching good-looking metrics to your improvements of existing systems, it’s no wonder you’re not being appreciated for those actions. If you can’t measure your changes, it might be hard for others to know that they were indeed improvements.

[-]

iprocrastina@reddit

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.

[-]

Glass_wizard@reddit

The code does not matter. Features matter. Performance matters. Ease of use matters. Functionality matters. Bug free matters. Developers, in general, care about all the wrong things.

[-]

konovalov-nk@reddit

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”

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)

[-]

konovalov-nk@reddit

And a bonus point for this workflow is you can use agents with it, so they produce amazing work artifacts instead of slop. But humans is my priority for now.

[-]

thewindjammer@reddit

Took me getting laid off to realize this but really does not care about code quality.

[-]

Sakura48@reddit

It's a balance. Shit quality code will implode the whole product but too high quality will delay the time to sell the product to generate revenue. Stay in the middle is the sweet spot.

[-]

ParadePaard@reddit

I’m known to have strong opinions. It’s been a reason for promotion multiple times.

But… I can’t anymore. Just tell me what to do and give me the money. I think there’s a breaking point where it goes from positive to negative, having too many opinions.

[-]

HeeheeHarharr@reddit

This past year I stopped caring/trying to write perfect code. I am more at ease, less anxious and work about half as hard as I previously did.

My coworkers enjoy working with me more now and my review came back much more positive than the previous year.

[-]

TheTrailrider@reddit

Honestly, what matters is that you get paid well and are comfortable with the job.

[-]

Longjumping_Bug423@reddit

Say it with me: TRADE OFFS

[-]

BoBoBearDev@reddit

How familiar are you with MVP, AC, and scope creep? Because it wasn't about how bad the company is, it is about priorities and values. And there are many wildly used terms such as MVP to set expectations. You are upset the company doesn't align with you, but the truth is, you are supposed to understand the company and align with them.

[-]

hammertime84@reddit

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

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

[-]

Special-Fee-4418@reddit

I just merge whatever my junior puts in and finds bugs later and fix them

[-]

notquitezeus@reddit

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…

[-]

No-Economics-8239@reddit

All value is subjective. There is a systolic pressure of forces at work in business. One job for leadership is trying to balance those forces and provide direction that makes sense. That can be hard to do when the forces who see the technical side give up and throw in with other aspects of the business.

But, I get it. Fighting the good fight is hard. And ideology doesn't pay the bills. Technical debt is functionally invisible to the rest of the business. They can only see the indirect symptoms, and without the insight to know the cause, they can misattribute it to other problems.

Even when we have the necessary soft skills to successfully communicate what we see to leadership, it doesn't mean we have the trust and political capital to outweigh the other forces and priorities at work. And, of course, value is subjective. So even if we're right, that alone doesn't matter if we can't convince the decision makers.

[-]

IGotSkills@reddit

I've given up but for another reason: with AI agents, you can quickly refactor and do things the right way, so why fight over it?

[-]

Dissentient@reddit

I will work the way I'm incentivized or explicitly asked to work. The company gives me money in exchange for my time. I do not care whether they ask me to write maintainable code or just push AI slop to prod, all work is unpleasant regardless.

[-]

suck_at_coding@reddit

I gave up years ago 😂

[-]

kevin074@reddit

Yeah and the only way that I’d care about quality is if I work in a product that have direct consequences to real life instead of just ticking numbers into someone’s bank account

[-]

TranquilDev@reddit

Welcome to the dark side.

[-]

yxhuvud@reddit

Yes, doing things that matter is more important. That doesn't mean code quality isn't important, but choose your battles. Also learn the situations where the solution is not to ask around for opinions but to just do. Managers don't care about code quality. It is needed for you to being able to mentally handle the code base. That means if something ends up being too complex to deal with, just take the time and rewrite it. Just take it piecemeal.

[-]

revelm@reddit

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.

[-]

creaturefeature16@reddit

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. Once you get past a certain tier, the bottom line becomes the only thing that matters to companies at that size.

[-]

alien3d@reddit

i dont care about clean code and new shiny new framework . i want something long term stable and i able to sleep at night peacefully .

As experince , you should know about "customer" experince and not one day clerk . ehh ? why this not work anymore ?

[-]