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.

  • 11
    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.
  • 8
    Well they all were fired a few months later. (restructuring)
  • 1
    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
  • 0
    Their comment on your desire to learn and grow as a developer is bullshit. Keep learning!
  • 1
    @Rabb thank you,
  • 2
    @chrisalexthomas totally agree. I saved them some 12 x 9 x 40 man hours. That's a lot
  • 1
    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.
  • 1
    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
  • 1
    Also, use psychology. Instead of pointing out what is bad, show opportunities. Never associate devs with their bad code. If you need to, refer to code as if it was God-given. The dev who did it probably could do much better today but had his reasons back in the days.
Add Comment