Anyone think the job hopping culture produces too many engineers that don’t care about maintainability?
Posted by Beneficial_Pay_6317@reddit | ExperiencedDevs | View on Reddit | 163 comments
Joe Schmoe comes in as a new hire and says we’re going to change the world with my new ideas. Joe Schmoe has full buyin from management. Over the course of two years, Joe Schmoe implements his ideas to revitalize the software. Wow, Joe Schmoe is great. He gets a new job or moves up the ladder to somewhere else.
Joe Schmoe is gone. It turns out there are holes all over Joe Schmoes changes. Maintainer Mike now has to clean up Joe Schmoes mess.
is this common in the industry
MindlessPractice2556@reddit
Yeah this is super common honestly. I've been on both sides, came in hot early in my career, had my big ideas, shipped stuff, moved on. Then I spent years cleaning up after people who did the same to me and I finally got it. maintainability doesn't show up on anyone's resume. So why would Joe care?
BusEquivalent9605@reddit
or worse - people who want job security and so purposefully make it hard for others to work with their stuff so they can remain the “expert”
Aleks_Zemz_1111@reddit
The industry rewards the vandal because management only measures what's visible at the end of the quarter. Joe gets a promotion for the 'revitalization' because it looks good on a dashboard today. The fact that the internal structure is hollowed out won't matter until the next guy takes over.
I’ve seen this on factory floors for years. A guy pushes the equipment past its tolerances to hit a production target, collects his bonus, and is gone before the machine self-destructs. If you're the one left cleaning up the wreck, you're effectively paying for Joe's career advancement with your own time and health.
pavilionaire2022@reddit
No, management with short-term reward structure produces products without maintainability. Engineers care but are discouraged from caring.
davwad2@reddit
If it doesn't create revenue, the business, and my extension, management, isn't that interested. Until it impacts revenue generating changes.
Ashken@reddit
I second this. Regardless of how many jobs I’ve had, I was very concerned about maintainability. At my last job I actually facilitated and succeeded in a whole application rewrite because the original version was so bad. I still ask some people from that job about it and they’ve told me it’s still in production, rocking along fine.
arnitkun@reddit
I haven't checked the OPs profile, but find his take suggesting they might not be a dev at all, or too far removed from the actual dev work that happens at lower levels.
Seems like a deliberate attempt at pinning all the fault on engineering.
CivilianNumberFour@reddit
Eh idk ive definitely suffered my fair share of contractors that don't give 2 shits about how their code reads or maintains over time and their entire job history is them hopping every 1 to 2 years.
Thing I've noticed is some of the biggest, toughest problems aren't going to be fixed by recent hires regardless of talent, some things take years of institutional knowledge and you just won't get that if you are always job hopping before you get there. Also you don't get the reputation as a problem solver/answer giver without that seniority, which would be nice lol.
SypeSypher@reddit
I mean....they're contractors.....the very nature of their employment is "We want you to do work...but we don't want to provide any sort of expectation or incentives for you to stay long term because the millisecond the work is done we're going to let you go probably"
If anything contractors are semi-encouraged to produce bad/hard to maintain code to keep their jobs longer. Good ones don't do that obviously, but companies don't hire contractors for the highest quality they can find, they hire them to save money.....and usually end up paying out the saved money later anyway.
If companies truly wanted highly maintainable, good quality code and good long-term engineers who are driven to produce it, they would incentivize it. Set a reasonable expectation of new features over time, bring back pensions to show you care about retaining people, give 5% MINIMUM annual raises and clear paths forward for promotions/growth and if you can't then give larger bonuses or flexible work arrangements like WFH, give a decent amount of PTO and ACTIVELY ENCOURAGE its use, be generous with extra bonuses and time off as well,
"hey guys so looks like we're ahead of schedule this sprint, everyone is done with their stories except for Bob, if you guys want to pair with Bob and get that over the finish line feel free to take the rest of the day off and go home early if you want!"
vs
"great job guys finishing all your stories! Lets look at the backlog to see what else we can grab! Aren't you all so happy that we finished more points this sprint!?"
\^ If the reward for good work is just more work.....the overachievers do that until they get promoted away and the maintainers work slower and more carefully and don't get promoted...and eventually leave too. If the reward for good work is an actual reward (like leaving early on fridays because your work is done already) then devs are incentivized to actually set themselves up for success by focusing on making their code reliable, and easy to work with so they can actually finish their work faster/better.
Devs WANT to work on easily maintainable products, and they WANT to create simple solutions to most problems especially when they know that they'll be working on the product years down the line.
Unfortunately. Companies do not want this. they want more features and do not care that the backend is complete spaghetti and the front end is held together by a billion random node dependencies that don't do anything. Dashboard is working now? "FANTASTIC can you add xyz now too?, sorry we don't have time for technical debt."
arnitkun@reddit
OOP also somehow missed this. Hence this comment chain.
BoringBuilding@reddit
I mean, if someone is a contractor it is very common that there is an actual 2 year duration limit with clients. After that you often need to go on a brief break from them before you are eligible to join them.
arnitkun@reddit
Oh wow i didn't know that. After knowing this i myself wouldn't have them to put their all in even if they might be absorbed.
arnitkun@reddit
I think expecting a contractor to care for the product at the same level as an FTE is mostly a losing endeavor. Atleast the ones i've worked with were couldn't be bothered beyond a point in a problem, it isn't theirs always. In many places they are paid less as well.
I understand the value of institutional knowledge, but quite frankly being underpaid for years to accumulate that, with the clouds of layoffs always hovering doesn't seem like a fair ask.
Obviously people can be well paid to begin with, but I've personally found that is seldom the case.
That's actually one of the reason I suspected that the OOP might not be dev or dev adjacent, it overlooks massive issues just to say "developer bad".
Infact it also reveals their own, and quite possibly the most common experience people have; tribal knowledge. Sometimes intentionally gatekept.
ConfidentGenesis@reddit
Management also talks out of both sides of their mouth on this. On one hand, engineers are encouraged to work on tech debt and build maintainable solutions. When planning rolls around however there suddenly isn't any time because the next Feature^TM is extremely high priority for this quarter. We'll make time for tech debt after the next quarter. Rinse and repeat until backlog is unmanageable.
Oo__II__oO@reddit
The ones that do care end up lead to a team of engineers with at least one developer who will argue and implement solutions to serve their short term needs, and not long term health of the project. Typically this is to pad their resume, or move on to other projects in the space that do use that implementation.
Couple that with a management chain that wants results now, maintainability be damned, and you get a code line squeezed from both sides with a lot of compromises.
Justin_Passing_7465@reddit
When the brass is hyperfocused on quarterly stock-price results, that discourages long-term thinking throughout the hierarchy.
EntropyRX@reddit
Companies don’t care. Loyalty is completely dead and it was killed by corporations.
hallzm@reddit
Almost seems like Joe Schmoe was a great developer who should have gotten a raise and didn't.
kingduqc@reddit
And where does that culture comes from? Developers adopted the management reward system. They've killed long term vision and loyalty, reap what you sow.
Mithrandir2k16@reddit
That's the wrong frame imho. The correct frame is "we have unmaintanable software because management doesn't reward producing easily maintainable or replacable software". In fact, the highest paid engineer I've ever met only maintains a single excel sheet that basically runs an entire production line for a large company.
Don't ask.
goffley3@reddit
Isn't that just the market reality? Short term incentives flow downhill and that results in short term decisions.
asapbones0114@reddit
Resume Driven Development
Merad@reddit
The problem is actually more insidious than engineers who don't care. Even the ones who do care aren't developing the skills for maintaining software. Writing code and then working on it for say 5+ years teaches you a lot about patterns that work/don't work, what assumptions hold up (or not), and just generally how a code base needs to evolve with time.
It also goes beyond job hopping. When you have a higher performing engineer who does stay with the same company it's rare for them to stay on the same team for more than 2-3 years. The company is going to want to move them around to start new projects, help fight fires in problems areas, etc. I've seen it on every new project I've been involved in. The company wants to do something big and shiny and important so they bring together their best and brightest, take a couple of years to get the project off the ground, and then look to move those people on to the next big thing. These people will probably spend most of their career creating new shiny things and never learn the lessons to help those projects have long term success. Meanwhile people who sit on the same team for a decade and learn lessons through long term maintenance tend to be less ambitious or less skilled devs who probably won't be involved in spinning up new projects.
pseudophenakism@reddit
Yes.
bit_shuffle@reddit
In general, bad code that works now, is better than beautiful code that works in two weeks.
Because your competitor is going to deploy their bad code that works in one week, and lock in market share.
That is just capitalism. It is also nature and evolution. The world is willing to sacrifice design quality in software when the short term return is so big it justifies it.
So coders go where the money is, when the money goes somewhere.
Beneficial_Map6129@reddit
it's all PDD anyway (promotion-driven-development)
retirement_savings@reddit
I work at a FAANG and it's crazy how true this is. I was on a project once where we needed to implement a ranking feature. I proposed two solutions: one very simple one using data that was already available and a strong proxy for what we wanted, and another to build a service that did the exact ranking we needed (lot of extra work, minimal difference for the user).
I presented them to my tech lead, and he said "if we choose the easy way, we don't get to say we did something hard." So we did it the convoluted way.
Beneficial_Map6129@reddit
I've worked some internal tools teams where our "customers" were literally 10 employees who did nothing of real consequence and we just made basically "AI-powered" HR tools for them
koreth@reddit
"Burn 1000 hours of engineering time to save the sales team 15 minutes a year of manual data entry." Tale as old as time.
brokedahmouth@reddit
My euphemism for this is "boiling the ocean".
thorodkir@reddit
To be fair, could still be worth it to eliminate human error if the impact is high enough. For example if it's a literal life or death situation, or huge financial implications. Most are not though.
upsidedownshaggy@reddit
And then when it's finished they go "What about X feature we never brought up once during this entire process?"
Neuromante@reddit
And then you want to build something that would save YOU time from boring tasks and suddenly there's no time alloted for that.
Saki-Sun@reddit
I think I would become a potato farmer.
pro__acct__@reddit
Just keep cashing the checks looks nervously over shoulder at Claude holding a whip
TehTriangle@reddit
Jesus!
TitanTowel@reddit
FAANG promotions care more about difficulty than actual business impact/value?
EnderMB@reddit
It depends what you mean by impact.
My most impressive delivery was "deprecated" weeks later. My second most impressive was given to a team in another continent to own. Both had huge impact, or huge potential for impact, while they existed - and in fairness the former did get used for parts in highly-visible areas.
Impact typically means "I was able to tell my director/VP that this had huge impact". The sad fact is that many of us work on systems that are far abstracted/removed from real customers, so impact might be cost savings or latency improvements - or the perception of them.
gefahr@reddit
Well now we know which FAANG you're at. ;)
BenOfTomorrow@reddit
This is bureaucratic corruption in action, not the designed purpose of the system.
The individual engineer needs to demonstrate they have particular technical skills to get to the next level; they are far removed from business value.
Their tech lead is also probably pretty far removed from business value; they should shut the wasteful idea down, but they probably get rewarded more for their engineers advancing and supervising big projects than they do for delivering business value.
A PM is who should be catching this on the ground in many org structure; efficient business value is their job.
Either they don’t have one or they have a bad/powerless one.
Izacus@reddit
At lower levels you have practically no freedom around business value so it would be dumb for you to be graded on that.
retirement_savings@reddit
At lower levels, the business impact is not as important as the impact you had on the project. If you wrote little code because it was easy to implement, you don't get a lot of credit. If you write a big design and explain how you're going to make a new service and then execute, that's how you get promo, even if it was unnecessary.
TitanTowel@reddit
I see, but then it was a tech lead that made that point. I'm just surprised since typically delivery speed/pumping out "I lead and delivered X/Y/Z" is more what I'd expect.
retirement_savings@reddit
The tech lead then got credit for leading the effort to build this complicated system across multiple platforms.
WeHaveTheMeeps@reddit
Oh my god… that was my experience too 😂
All about visibility.
Ok_Particular143@reddit
This is doubly true if the lead need immigration so he'll add mountains of complexity to justify why only he could do it. Green Card driven development, GCDD.
sd2iv@reddit
My favorite realization of this is was when I viewed my ex TPM's LinkedIn profile claiming success for the project 'we' worked on together. He literally did nothing but present my extensive write-ups to the higher ups. He was totally MIA for 6 months, because he was studying for a job hop to a different FAANG. Apparently my outlook is the naive one.
pydry@reddit
This right here is what I think Elon Musk was trying to kill off at twitter. He just hamfisted it.
If the billionaires ever figure out how to do it properly we are toast. They really will be able to fire 3/4 of us.
sirspidermonkey@reddit
You joke, but at the end of the day PDD engineers are just responding to the incentives the industry provides.
And frankly it's a side effect of a broader societal trend of companies only looking to next quarter instead of next 5-10 years.
There are people who care about the craft, and the people who care about the money. The latter control the companies because they released a buggy pile of shit while the people who care about craft and still running the test suite. Would the world be a better place if it was different? Probably, but there's not much we can do about it.
ironichaos@reddit
I prefer PoS promotions oriented systems.
ta9876543205@reddit
Is there a tutorial on PDD?
k958320617@reddit
Or resume driven development
xXxdethl0rdxXx@reddit
Yes. It’s a big reason to provide incentives for people to stay.
hangerofmonkeys@reddit
Unfortunately there's not many (if any at all) incentives to stay with employers. If anything employers actively incentivise leaving, lack of promotions or pay rises, more likely to get either or both of those by going else where.
If pathways and "loyalty" were reworded you'd fine resume-driven-development, longevity and maintainability will organically increase.
Void-kun@reddit
It's not just about money though.
My current employer doesn't pay as well as some of the offers I have had. And few places give me this level of freedom in my work, with lack of deadlines.
This is the first job out of 5 since I have graduated that I'm not burning out consistently every 6 months. I've not burnt out once in my current position.
For me having good mental health and being happy is worth the pay cut.
hangerofmonkeys@reddit
Absolutely. I agree. My main fear is having an environment like yours and realising it still doesn't provide security or longevity.
Reliability and assurance absolutely has a value but so few organisations have or will give you career safety.
Void-kun@reddit
To be fair we have multiple Devs who have been here for over 30 years.
Other seniors who have been here nearly 15.
I've been here 4.
Company has been operating for 40-50 years, so I do have that reliability and career safety.
I work in education tech in the UK so we don't have a layoff culture here either like the US.
hangerofmonkeys@reddit
Ignoring all the atypical noise you see in tech, it sounds like you've got the employer most would be envious of.
dudaspl@reddit
I was thinking about it. It's not only compensation - for majority of people it's also about learning a new technology when they change environment, networking with peers that they might benefit from in the long run. There's very little incentive to stay, unless you have a high ownership role which you can leverage when you eventually change your job
SkyPL@reddit
Yep, that's very true. Also, the reason why companies in the US tend to incentivize people with stocks after some period of time. The more mentally invested you are in the company, the better it is for the employer. If you don't have anything other than the 8-16+salary, and the outside world has a lot of new flashy things.... there is a ton of temptation to move and you stay for these 2 years to get a nice item in the CV (that changed a lot with the current market situation, where it's not that easy to find a new job, but still)
bcireddit@reddit
I’m unfamiliar with the term 8-16+salary, what does it mean?
SplendidPunkinButter@reddit
But the reason people want those things is because job security is shit, and you need to keep yourself hireable
valence_engineer@reddit
That has it's own issues. I've been at a company with amazing retention. It had solid tech... a decade ago. Not much has changed since including the stock price despite record growth in the market. It's the like the old joke that science moves forward one funeral at a time. Same for tech in companies except it's one departure at a time.
fued@reddit
incentives to stay - "no we cant afford a payrise this year"
upsidedownshaggy@reddit
"Despite bragging about our record breaking profits this year there's no room in the budget for a promotion, sorry!"
markedasreddit@reddit
My understanding is that in most companies, hiring budget is usually bigger than retention budget.
Interesting_Debate57@reddit
Clever.
ugh_my_@reddit
Sure blame the victim
tmswfrk@reddit
Yes.
And AI is gonna continue the trend if the tech industry keeps doing what it’s doing now. When new features are cheap, their volume will increase and their maintenance will grow exponentially.
Now you could have AI then do the maintenance too, but at some point you’re not even going to know how things actually work, which will further things more.
That’s how I’m seeing it for now.
cmgg@reddit
My current company has high rotation rate, people last 1-2 years before they quit or are laid off.
The code is the equivalent to the Frankenstein monster, made of patches, stitches, and random components. From what I understand this has been like that for a long time. Code maintainability left the picture 10 years ago.
They’re now encouraging us to use AI tools like Cursor and Claude to improve our delivery rates, but as we all know this is a double edged sword that’s going to cause even more mess on the long run.
BetterWhereas3245@reddit
You shouldn't care. By the time the shit hits the fan, you should be far away from that company. It's not your fault or responsibility to fix their broken incentives and management culture. They want shit, they get shit.
TheRealJamesHoffa@reddit
I think job hopping is a result of employers not valuing their employees enough to retain talent and expertise.
engineered_academic@reddit
I had a stint in my career where I was the guy you called when someone from Google came into your company, implemented Bazel, and then peaced out. Now it's 6 months later, you need to change your pipeline but everyone is afraid to touch this magical creatuee.
SS_MinnowJohnson@reddit
I was a job hopper. I always wrote code with the mindset of helping the poor bastard that came after me
bluetista1988@reddit
Yes and it's the fastest way to inflate your title and get big raises/promotions/accolades. A big part of being successful like this is sales, marketing, and networking. You need to be able to sell yourself and what you've done at company A to pivot into company B, and then schmooze your way into getting free reign to do what you want. I've worked with people who are incredibly successful at it, but are prototypical Joe Schmoes whose plan will not survive 3 months of battle-testing in prod. They're usually gone by then though.
In my opinion you aren't "experienced" unless you've stuck with at least 1-2 places long enough to see the longer-term ramifications of something you were pivotal in building. You learn a ton in that experience to prepare you for the next systems you will build. You get to see how:
PressureAppropriate@reddit
I became Joe Schmoe because of AI...
Manager wants slop and slop is what he's getting.
JandersOf86@reddit
I think this culture is also perpetuated by companies / studios that over-hire for a project only to then layoff after the project is finished. This seems to be the go-to method for most game studios, at least, that Ive worked in (I spent almost 20 years in software QA, mostly game studios, and this modus operandi is rampant).
I do agree that many people leave after a shorter stint at a studio, usually for more money elsewhere, and Im sure this could devolve into a chicken or egg debate, but the companies themselves seem to perpetuate this, too.
darthsata@reddit
It is not just about not caring, unless you own the long term pain of your decisions/code, you won't learn how to make maintainable, extendable systems.
TemivelPirataRoberto@reddit
Let's be honest, the vast majority of people job hop because it is the only way to get promoted or get a raise.
I honestly do not care, I make due with what I have on my teams. If people decide to leave because they believe they're doing a good job and we can't promoted them or give them more money, then by all means take the new job. If the company can't keep you around that is their problem to solve, not yours.
You can hate me for this but I have zero sense of of allegiance to any company that is not mine. We all know that the second they don't need you anymore they will kick you out.
So accept reality as it is, do your job to the best of your ability and forget about the rest.
skidmark_zuckerberg@reddit
Honestly I don’t think job hopping is good. I think 3-4 years minimum is a great timeframe. You are there long enough to see yours and others decisions play out in the long term.
Also I really think companies weigh your past tenures heavily. Would you rather hire the dev who has had 3 jobs where at each of those jobs they stay for 3-4 years, or the dev who had 6 jobs with 1-2 years at each? Sure having 6 jobs exposes you to a lot potentially, but then you have a high chance of being the person OP describes and also look like a flight risk.
Antique_Fudge_7484@reddit
I've been in my current role for about 3 years. Does it suck, yea kinda, but one thing it's done, is that it forced me to live with my technical choices. Nothing like trying to debug code you wrote at 11pm because it's throwing a tantrum in production. It really humbles you.
rectalrectifier@reddit
Maintainability is for suckers, man 😏
kaisean@reddit
The companies themselves don't care about maintainability.
Ch3t@reddit
There are plenty of lifers who write unmaintainable piles of garbage.
rangorn@reddit
You are supposed to build software for the next guy. I try to live by this principle as I have been the next guy quite a few times.
03263@reddit
I assume the next guy is just me a few months later, having lost all memory of what I did and why.
knightcrusader@reddit
That's exactly me.
I will spend an absurd amount of energy making my software and API interfaces as intuitive as possible, because I know future me is not gonna remember something so I am covering all my bases now.
eightslipsandagully@reddit
Agree but if management is gonna constantly crunch me for time and then stiff me on promos and raises I'll happily churn out spaghetti and then leave someone else to deal with it
Crazy-Platypus6395@reddit
Honestly I think thats a red herring. I job hop time to time and most of my codes still there. But to be sure it doesnt help, probably.
ProbablyANoobYo@reddit
That’s a funny way of writing that companies not giving adequate raises and having ridiculous promotion requirements financially incentivizes employees to deprioritize maintainability and the companies could stop this whenever they wanted to.
EmberQuill@reddit
Yes, but I think part of the blame for job hopping culture lies with the managers and senior leadership who either don't know how to retain engineers or actively try to get rid of them, and who basically killed the idea of career advancement by any means other than leaving for a new company that pays more.
I've known a few engineers who are absolutely the worst kinds of people to maintain software long term and they'll quit rather than do that, but I've known quite a few more who are very good at long-term support but the company laid them off. Right now I'm dealing with fallout from a bit of both, unfortunately.
spacekats84@reddit
YES YES YES
I've been saying this for years. Our company has a lot of long-term employees, I myself am coming up at 18 years in the development team and worked my way up from the bottom to 2nd in command in the dev team. Average tenure in our team is about 11 years across 10 people.
We had a guy that made me realize this a while back. He was great at talking up an idea and then prototyping something half-assed and then left the company. Then he came back and did it again. We learned much later that his work was shoddy as shit and he was just good at jumping places to go up the ladder and never had to experience the consequences of his design decisions.
I always called him a seagull developer - he swooped in, made a bunch of noise, shit over everything, and then flew out. Of course he's a VP at whatever poor company he's at now. Nothing like failing upwards.
Usual_Ad_2177@reddit
Why would I care about maintainability for a codebase that I do not own? My current company does layoffs every year and it is dumb luck lack I haven't been picked yet.
TurboMuffin12@reddit
Yes
horror-pangolin-123@reddit
Job hopping culture is a direct response to corporate culture of layoffs instead of giving raises and promotions based on merit and tenure.
Employees are incentivised to change jobs frequently to maximize their salary because the reward for loyalty is stagnation and loss of job.
Quality of software doesn't even factor in an equation such as this one.
BoringBuilding@reddit
It is wild to mention job-hopping as the culprit without pointing out what you just pointed out.
This reads more like someone that does layoffs more so than someone that is from a developer perspective.
arnitkun@reddit
Yet somehow OP missed all of the points you raised, which are probably at their most visible in recent history in market. Doesn't seem to be the views of a developer.
crustyeng@reddit
I’d hate to be one of those guys in this market, that’s for sure.
Saki-Sun@reddit
Consultants vrs Product developers.
I think I've learnt 95% of my lessons about technical debt from other people. But it still sucks when the technical debt is a choice you made.
arstarsta@reddit
Maintainability in itself is a bit unclear.
Is the 200 line monolith function easier to maintain or something that have splitted everything to 5 line functions but it's 1000 lines and you have to jump around to follow easier?
The first one could be simplier to debug while the second one easier to extend for new functionality.
03263@reddit
Yeah I tend to do very monolithic initial implementations then start separating into logical units as my mental model grows. I'm not very good at anticipating what those will be, but it becomes clear as I'm working on it and moreso as needs change.
It can make it harder to follow but it also gets hard to follow some deeply nested code too and better to break out into things with meaningful names. And write plenty of comments!
arstarsta@reddit
A few functions usually makes it better. But subclasses where part of the code is in parent and part is in child can get confusing. Add on that the generator yield pattern and I have to read it 5 times before getting a clear picture.
An example:
https://github.com/huggingface/smolagents/blob/df846f842241aab5a7a17f8136574928e347feb6/src/smolagents/agents.py#L1215
03263@reddit
Yeah, too much abstraction is bad unless you really need it. AI agents tend to produce it regardless of need, ugh.
I would have to spend a while with that code to understand all that it's doing.
papawish@reddit
It's not only software. Read Moral Mazes.
It's an established fact of liberal bureaucracies. Short term and individual interest first, always.
ewankenobi@reddit
When I was growing up Lada was literally a punch line in jokessome examples. They only got good when they were bought by Renault Nissan.
You can't use cars as an example of statue communism working. For example when the Berlin wall came down West Germany had to give special dispensation for East Germans to drive their Trabants across the border as they were 4 times over their emission limits. We're talking about a car where the designer forgot to include a fuel gauge and they didn't update it to fix it for decades. They were using 2 stroke engines in the late 80s. If you gave anyone the choice between a Volkswagen from that era or a Trabant no one would pick the Trabant. It's literally seen as an example of how bad communism was.
Capitalism has it's flaws, but I doubt anyone that thinks communism is good has ever visited a former communist country.
papawish@reddit
You obviously know more than me about Ladas.
I'm still amazed by how they still run today while our modern cars will go to the trash in 5 years.
sciences_bitch@reddit
I drive a 2003 Toyota. What is this nonsense about “our modern cars will go in the trash in 5 years”?
papawish@reddit
Reread my original message about "old Toyotas"
BeerPoweredNonsense@reddit
Not convinced that you picked the best example there.
papawish@reddit
Those are all best in class in terms of availability/reliability.
paagul@reddit
Any resume I see where the average tenure is less than 2 years automatically gets tossed. You’re not doing any real engineering unless you’ve supported work you’ve done for more than 2 years.
mrequenes@reddit
It’s also an issue with managers. Maybe worse. They push a new, high profile , complicated feature. Release a MVP/skateboard version, that will require tons of work to maintain, add a bullet point to their performance review and LinkedIn profile, then move to another team or to another higher profile “effort” or leave entirely.
The devs left behind get associated with the half-assed, unfunded feature.
Tired__Dev@reddit
No. I believe growth and market demands do far worse. Having an application in ongoing development for years upon years with new features being added outside original intent is what destabilizes all of the applications I’ve seen after seeing dozens of shitty private repos by dozens of companies. Software that was delivered on floppy or disk still could be shitty but didn’t have these problems.
In an idea world, a product manager would do their job by conducting well informed market research or just have natural ability to know what customer wants (Steve Jobs/ Akio Morita), but they’re mostly rather bad and tech companies suffer because of it. Many people have jobs because of it.
Now there is what I’ve seen too. Most of you guys can’t greenfield a project. Mostly because there is a perverse incentive for engineers to do resume driven development or work with what they think is cool. To be good at greenfielding software you usually have to create a startup and suffer from your own decisions a few times. If you can’t anticipate what the market will need then it won’t be good.
BillyBobJangles@reddit
This exact thing is much more common at the director / executive level.
Big sweeping changes that fucks everything in the short term but "aligns us with our long term goals". Pick some metric that's easy to cheat tk show progress. Then find a new job right around the time your company starts to see the consequences of your action. Moves to a different company and talks about how they improved velocity by 30% or some shit at their old job. And the grift just keeps going.
randomInterest92@reddit
Short term yes.
Long term, No, because the most lucrative job hopping opportunities come from old coworkers "who made it". They will only remember and recommend you, if you did excellent work.
Remember, most people get rich at age 45+ .. it's all a long game.. don't fool yourself that you can "get rich quick"
So you should do both. Aggressively job hop, while also leaving a long lasting impression and legacy.
13--12@reddit
What’s the problem? Joe improved your job security
fued@reddit
100% there is no need to build code to last if you know you are going to be somewhere else in a few years.
contracting in general just leads to worse outcomes
yerfdog1935@reddit
The contractors I worked with at my last job did some diabolical shit. Like creating a whole new Lambda for moving a file every time we created a new report type instead of having one Lambda with parameters.
anonymous-12358@reddit
To be honest, that doesn’t sound too bad and you caught that early before it snowballs into nested spaghetti code. But that is how spaghetti code starts, especially if the next set of engineers develop and grow those lambdas independently.
yerfdog1935@reddit
Tbh we didn't really catch it all that early. They weren't having us do code reviews for what they were doing (I was low on the totem pole and had no influence on how things were organized broadly) and we only realized when I had to investigate why our builds were failing. They'd created so many essentially duplicate lambdas that we'd exceeded the resource limit for the stack.
pydry@reddit
IME the biggest difference to code quality wasnt average job tenure it was how much emphasis management put on it relative to delivery time.
fued@reddit
I dunno, if the staff had been there for years and werent stressing about thier jobs, they might be able to push back against the manager better
yxhuvud@reddit
Just wait until the next real downturn comes and Joe ends up stuck at the same position for sufficient years to have to eat his mistakes.
ButWhatIfPotato@reddit
The stakeholders who do mass layoffs and never invest in employee retention are the ones who do not care about maintainability. Just because their brains tune in to circus music whenever those pesky employees tell them that their Tony Hawk Pro Capitalist corporate power moves are not sustainable does not absolve them from their responsibility of their actions.
Cahnis@reddit
Job hopping culture happens because their position does not appreciate the engineers salaries properly. No one wants to Job hop, it is an incredibly annoying, risky, anxiety indulcing move...
grizzlybair2@reddit
No I think companies that don't want to pay much are the problem. They'd rather drop 120k on a new guy than give the 90k person who is the MVP of the whole org a real raise. Then it turns out the new guy can barely open intellij.
Then management says get it done yesterday. They promise some nonsense date that isn't aligned with the dev teams. Even if you manage it, next feature MUST be completed 10% faster with 10% less resources available. So you get slop there instead of doing it the right way.
03263@reddit
I see somewhat too much focus on maintainability from a lot of devs.
Or perhaps what I consider maintainable is different. I care about readable code with lots of comments, and using well documented and well established third party dependencies. I do not consider premature optimization or excessively "enterprisey" code a part of maintainability because code is not chiseled in stone, we can go change it later as needs change, it just has to be able to be read next time we look at it.
I see a lot of devs jump towards using unnecessarily levels of abstraction and design patterns, anticipating that the use case will grow over time. Sometimes that's useful but usually the times it is are obvious and we don't need to be discussing it. If the client asked for a new type of widget to appear in one place, we only need to write one very specific implementation until this type of widget becomes a repeated pattern.
I make this mistake too. The other day I started writing a class to handle tracking batches of data to insert into a database, to accommodate one process that inserts millions of rows. Then I started abstracting it into a generic batch processor and puzzling over how to create a nice interface for batch processes, batch database processes, then finally the specific implementation of my one need. Then I stopped and put it all into one class that does one very special thing because that's the only use case.
Outside-Storage-1523@reddit
That means nothing works from code review to management, so it’s just a bad company.
GargantuanCake@reddit
Yes.
Joe won't be around anymore and management is demanding more features faster. Even if he knows he's creating technical debt who cares? He isn't going to be around by then and this job is, at best, resume padding for more money from another company. He can then say "look at this cool thing I made really fast!" as well as any other metrics he can wring out of it that would look good on his resume.
Interesting_Debate57@reddit
You haven't been a dev in silicon valley, I take it.
Not a real dev.
They've got you by the balls because for most people compensation = living, but not living well, and due to it being California, you can (and will) be fired anytime for any reason or no reason at all. All legal proceedings, even if it somehow were a magical "illegal firing" are conducted by arbitration, where they have an insanely massive advantage.
So if they start putting the screws to you, your only option other than suffering until you break is to job hop.
Maybe have a decent environment for actual employees who are actual human beings, and see if people stick around longer.
At union shops in the trades, people stick out the lean years because the long-term goal is stability, not wealth. The same goes for firefighters and police officers. The job kinda sucks but you get a very large chunk of guaranteed pension and the ability to actually retire.
It is a war at this point, in many many dev shops, and shopping around is nearly the only way to improve your work environment, not just your salary.
-TRlNlTY-@reddit
I think the implied terms of healthy work relations for developers is "give me autonomy and good compensation, and I will deliver good software." This has been happening less and less.
olzk@reddit
I’d make a remark: it’s not job hopping, it’s deliberate choice by companies and their management to destroy loyalty as an institution. Loyalty is what creates basis for said care and quality provided by employees. Without it, there’s no reason to stay. Even if the market is shite, people won’t be motivated to do extra, quite the opposite will take place.
thecodingart@reddit
I like how the insinuation is that John Doe whose been at the company for 10 years, whose entire career is home grown and whose perspective is shallower than a puddle, somehow does a better job.
Idea-Aggressive@reddit
Hilarious! 🤣
Same people who do 1 contribution every 3 months and spend most of their time booking meetings. Delusional!
Even more hilarious when they decide to create a whole presentation to share their pointless contribution to the whole team.
“Thanks John Doe! That text change was fantastic!”
Conceptizual@reddit
I have been laid off three times since 2020, I would love to stop job hopping but it hasn’t been my decision
Idea-Aggressive@reddit
Exactly! Some people here have no empathy and I believe they might not even understand that their knowledge from 15 years ago is useless. Some people here can’t even see that their own implementation is poor, or that change can be beneficial! In fact, some people don’t even give it a chance. They rather spend their time on meetings, doing podcasts and sharing their time at the gym, their baby photos etc.
“Let’s book a meeting for next week” “Yeh going to the gym now will look into this later” “Oh sorry, did see your message but forgot to reply” “Sorry to interrupt your presentation, I don’t know what to say, but it’s important to interrupt and say something so people know I exist” “I’ve been working on this project for the past 4 months, and just completed but the main branch changed a lot and there are too many conflicts. This is unfair! It’s 5 lines of CSS, I’m very upset and should’ve been informed”
Idea-Aggressive@reddit
I’d like to share my point of view as a contractor.
After months looking for a work, spending 5 to 6 stages of interviewing, references I land myself a 3 months contract role. Of course, I have to pay bills like everyone does, and 3 months contract is better then nothing; but much better to have a long term relationship.
The goals is to solve critical issues at a big and popular enterprise infra company. Because the internal teams, of +100 people weren’t able to!
I come in and immediately told that have no access to their main discussion channels on slack. Put in a separate chat group with no visibility.
The team is not very collaborative, and for them everything is difficult and not possible.
I introduce a few chances to allow myself but anybody to iterate quickly. Improve the DX, introduce documentation and simple concepts such as code quality checks, semver, changesets, etc.
Furthermore, without breaking any APIs (although bad), introduce new file architecture, solve cyclic dependency references and safe guards, reduce the distribution build to 1/4 of its size, and much more. Ultimately, solve the main critical blockers.
Most team members are happy with end result, but some people find their reputation damaged so start picking on pointless discussions, but keeping it internally and only surfacing them during meetings which only happen every couple of weeks. I listen and immediate respond with confidence and in short minutes PR. I politely ask them to provide feedback, or comment directly in the only channel I have access to, to allow me to participate and collaborate; but the same people decide to keep making noise internally to damage my reputation.
A few questions: - Why wasn’t the team capable of solving the problem? - Why do they prefer to spend days discussing issues that are easily solved in a couple of lines in a form of a PR? - Why is everything a meeting in a week? - Why don’t they provide feedback on RFC, PR, etc? - Why don’t they show up in meaningful spots or rank in git contribution insights? - Why do the take days to respond? - Why is that with 4 different notification systems informing them about PR, previews, releases, across slack, GitHub, email, personal DM they claim they were not inform and did not see the PR, RFC, etc? - Why don’t they give credit to the author who solve the problem? - Why do they make it sound they are the ones solving the problems? - Why don’t they show a better solution?
Most importantly, why do people haven’t got any empathy towards others who dedicate their time and life to solve complex problems, are quick to help? What have they’ve done to you?
When working in a team, you need to learn to collaborate. Learn how to present evidence, benchmarks, improve communication, stop with private messages, be inclusive, stop the nonsense!
Spider_pig448@reddit
Probably, but it's necessary to keep the QOL for engineers high and to maintain bargaining power for engineers. If you are staying long-term at a company that offers you a below-average experience, then you are contributing to the problem.
Minimum-Reward3264@reddit
Hiring budget is bigger than retention one. For what reason should you over-invest if they are not invested at all.
Kobymaru376@reddit
Joe Shmoe is exactly what management wants. Management did not provide a good reason for Joe Shmoe to stay and care about the product .
Management also never cared about maintainability or thought about the future of the product at all for that matter. They just wanted Joe Shmoe to churn out features ASAP AND WE NEED IT YESTERDAY. They didn't learn from Joe Shmoe leaving, they don't care how much Maintainer Mike is suffering. They're probably wondering why Maintainer Mike isn't churning out new features as fast as the previous guy and assume it's because he's just not as good of a programmer.
Maintainer Mike should probably also job hop ASAP but he can't afford to lose the job due to life circumstances.
Windyvale@reddit
Not like we are given the option.
gjefle@reddit
I like to think Joe Schmoe cares. The problem is he wont't learn from his mistakes when he never sees the long term results of the decisions made.
Emotional_Street217@reddit
My works in a blitz right now with the growing fear of mythos. Thousands of app/container services developed by the Joe shmoe’s that slapped some core slop together left 10 years ago and wasn’t maintained at all by the 8 different teams it’s been hand balled off to, and now requires intensive uplift. Think Java 7/8 to 21/24. I’ve found some whack stuff in my deep dive expeditions.
tiagocesar@reddit
It does. But not many companies are focused in retaining talent. What's the incentive for staying if in 3 years your new colleagues will have salaries 10% higher than yours?
AggressiveAd5248@reddit
Poor technical decisions by engineers generally result from pressure to go faster by management.
You sign my cheques, I can tell you that in my professional opinion, X is a stupid idea and Y is better but slower to deliver, but if you want me to do X because you want to ship now, I’m gonna do X.
A senior engineer told me that you have to look at all code as if it was written at 2am during a production incident , with a crying baby in the background and management looking for 10 minute updates because that is sometimes the case!
Clitaurius@reddit
I can't think of a single software feature across any industry that you could pay me enough to care about. You had a bug in your Amazon cart? Boohoo. There was a glitch in spy satellite that resulted in guided missile missing its target? Womp womp. Some automation caused an internet outage for an entire hemisphere? Yawns vigorously.
And you know why nobody can pay me or anybody else enough to care about any of this? Because it is way more profitable for a company to SAY that they can provide/prevent all of this shit and keep all the money for the promises for themselves rather than pay people enough to care. And then they just apologize, fire me so the stock goes up, and do it all over again.
notrealtedtotwitter@reddit
This industry has moved forward but we still haven’t been able to get to a better solution than “make another useless service” and “have more reports” of measuring impact. This has to be crazy.
mpanase@reddit
Nothing to do with job hopping.
Maintainer Mike has probably given up, hasn't learned anything new in the last 15 years, is comfortable being the guy who knows where all the dead bodies are, ...
It's a bout the character and goals the individual has.
If your goal is to "progress your career", you want massive new hype-filled projects; you want to change the architecture of the whole thing (and leave before it's deployed); doesn't matter whether it makes sense.
If your goal is to ensure you are unfireable, being the hero every week and the only guy who understands the mess will be your way; maintainability is your enemy.
PressureHumble3604@reddit
In my experience people who don’t care about maintainability are the people that build the system with all its flaws, got used to it and don’t plan to ever leave the company.
I do job hopping when I join a team/company that doesn’t care about maintainability .
codescapes@reddit
In a word, yes. It is also worsened by Agile-as-micromanagement wherein fake autonomy is 'given' to teams but individual tickets, assignments, points etc are so heavily scrutinised that it's in many ways worse than a pure command and control setup.
Because then you have a panopticon effect where if you try to independently pursue important maintenance work your boss gets messages like "why is Bob working on BAU tasks for System X instead of building out New Feature Y"?
And if you just go "fuck it, boss says so, let's work on New Feature Y" and "System X" breaks you also get blamed for it so there's basically no winning and this it how you quickly end up burned out, trying to cram work in out-of-hours etc. So much of why job hoppers don't care about maintenance is because as new arrivals they are not burdened by existing maintenance needs yet (they don't know the system) so they can just hop on new stuff and look productive and then leave before it needs to be looked after.
muscleupking@reddit
I work for money only.
CodelinesNL@reddit
That nothing in your post mentions the root cause, that it's the companies that create these incentives, is troubling.
HolyPommeDeTerre@reddit
Yes, it's common.
Some of us are still caring for the next guy. Some are just caring for the next job.
So, all of us are dealing with the other ones' sh*t (unless greenfield, but that's cheating).
Gabe_Isko@reddit
It's not the job hopping cutlure, it's the management not investing in devs culture. I really hate being asked to take ownership of a product that I don't own, and am in fact on contract for.
CodeToManagement@reddit
Nope because If the project was big enough that it’s a problem multiple people would have worked on it - it’s the teams responsibility to write clean maintainable code.
If it was small enough for one person to do alone the problems wouldn’t be that big since one person could just do the rewrite - but also the company should have a PR approval process for code so one person can’t ship bad code.
If this happens it’s a process and company failing and I’d leave for new opportunities as fast as possible.
IngresABF@reddit
Yes but - groupthink happens too unfortunately
ub3rh4x0rz@reddit
It's not so simple. Joe Schmoe has seen many flavors of unmaintainable systems, as he's inherited many more systems than someone who's been festering in an idiosyncratic system for 10 years.
mysteryihs@reddit
More like companies not rewarding loyalty and low annual raises leads to job hopping culture which leads to engineers not caring about maintainability.
Dhczack@reddit
Job hopping culture produces entire orgs with no maintainability lol
lordnacho666@reddit
Helping create jobs for each other!
rangorn@reddit
Together shitty developers strong!
TopSwagCode@reddit
Yes and no. But it's not really the engineers faults, but more company fault for not doing anything to keep engineers. They would rather pay people less to save money, just to loose them and spend more training / hire.
nrcomplete@reddit
Honestly this is how management works too. New manager / we’re gonna need a re-org / this guy is great at re-orgs, promote him / re-org is a clusterfuck and work stops. Someone got a bonus and it’s not the people stuck with the broken org.