Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Kicking out the chair under long time employees are rarely going to be popular unless you get the boss on you side because the old timers are usually hard to get rid of even if they are incompetent and often they do have knowledge the company still have use for.
But at the same time you might need to at least shake things a bit. Its a thin line to thread unless you get some existing employees support.
Good luck with your own and make sure you dont repeat the same error once you start growing large. -
Blimey, what a shitty situation, sorry you had to deal with that, sometimes you uncover a shitshow of a software and make others look bad, just do your job and be happy, you probably did the company a solid for that, even though it made you quit, the senior devs were hiding this for a while and the company was silently drowning
-
@Rabb thank you,
-
@chrisalexthomas totally agree. I saved them some 12 x 9 x 40 man hours. That's a lot
-
Had a very similar situation when I started a few years ago. It took me long time to learn how to deal with bad code done by senior devs. first of all you have to consider this: the shitty code you'd like to rewrite from scratch Is good enough to earn the company money. That spaghetti code pays you!
Often features are deployed ASAP and dropped shortly after, so writing high quality code might be too slow in the beginning and might be completely wasted time in case of it being dropped.
Another aspect is legacy code. State of the art code from 5 y ago would now be considered monolithic, untestable and stuck because of its dependencies. Rewriting or updating that code is a big investment of valuable time for no immediate return of investment. The users won't pay you more because there's clean code under the hood now. They want half-baked features instead
Think of what needs to be done from the user's perspective. If you cannot develop new features, analyse whether it's the arch. -
The reasons for refactoring or rewriting shouldn't be best practices or personal taste. It should be backed on user requirements like "improved stability", "shorter down times at redeployment" or "users want new features faster and we can't deliver because of old cosebase". In these cases consider what really needs to be changed and plan that with your whole department
At my previous job I was told by "senior" devs that my interest in learning new things and knowing more is not a good thing. And that I should learn to increase my depth in the programming of the product that was being used.
As part of my job I was asked to analyze the product's architecture. I found out that it was needlessly complicated and performed horribly. The senior devs that were on that product for a while had been hiding their mess from the rest of the teams. Needless to say, my report didn't make me very popular with them.
I was asked to help come up with a strategy for testing.
A guy who had just joined our company out of college and me worked really hard for a few weeks and managed to bring testing down from 3 months to around 3weeks. Our reward: he was fired(albeit for different reasons. The company was trying to restructure)
My yearly review was terrible and I was put on 2 months probation. So I quit.
It sucked. And made me question my ability as a programmer for a while. I've floated my own firm and though money is hard sometimes, it so much more rewarding.
undefined