2
Nmeri17
24d

Has anyone ever resumed at a new place and was impressed by the code inherited from their predecessor? If yes, did you see any need to communicate this information to the admin or the superiors he left behind?

For as long as I delved into code quality, I've taken great pride in my work and have been enthusiastic to show it off to anyone who cares to listen. I'm morbidly afraid of a colleague berating my work over something I didn't do correctly or don't know. But none of those I've worked with have that kind of time for pedagogy. The only thing I've witnessed them care about is how much your code breaks, to what extent your endpoints break, etc

Does this make code quality practically an overrated metric? All your fancy oop patterns and clever algorithms or business logic basically goes unnoticed. The business cares about output and your colleagues are more concerned about implementing their deliverables.

Is this just my experience or a more general situation of things?

Comments
  • 3
    fancy and clever serve to prevent code from breaking and making deliverables faster to complete. if they're not serving these ends then it's bike shedding instead of the reason why fancy and clever was invented in the first place

    when I left a place, a month later I had an exit interview with 2 managers I worked with. they said the new guy they hired to replace me said my code quality was really good. nobody at that company cared about code quality, nobody ever looked, but the senior staff guy kept estimating tasks would take me x5 as long as they did and the CEO, who was an angry Italian guy who was never happy, memed I was perfect for a couple months once so I'd say code quality does make business happy, or at least the results of it which is the codebase is easier to work with and consequently meets business needs better
  • 2
    and I don't know, code reviews are a little awkward. I tried to be nice then just rewrote stuff when people left

    had a web dev change projects on me once cuz she couldn't do a css framework and kept making custom css... and I kept telling her to use the framework in her reviews. next I knew she was resigned. I don't think she appreciated that very much

    another time had a guy argue with me at my desk for 2 hours because I didn't approve a PR. I wasn't on their project. it was a project I wrote prior and he was on it then, and the CEO had asked him to ask me for a review. so I reviewed it. well the guy really had a big ego about himself I guess. for example, this was in Java and he wrote public loggers everywhere... I told him to make them private. he came up to me in person and argued that he needed the loggers to be public for testing. this codebase had no unit tests and only external integration tests. I was already going easy on him wtf lol
  • 0
    Good code and software design is not something to be "noticed" but it's definitely not overrated. Because if you do it wrong, everyone, including the end-user will notice.
  • 1
    I think when it's more team code than a person's coe quality is usually better.
  • 1
    To be fair and honest, many of the teams I worked with didn't care enough about code quality. As you rightly said, people mostly care whether it works and if the end user/client is happy

    However, when something breaks especially in production, everyone jumps onto a bridge and tries to dissect the code as if they are the Fathers of Programming and spews whatever nonsense they come up with
  • 1
    I always wait a bit before i go bat shit positive or negative about a predecessor. It's better to know his reputation first. If he is - somehow - know to be sucky and you adore him, it's not good for dem reputatii. Also, the other way around - if the code sucks, maybe it takes some time and there's a good reason why it sucks. So I always TRY to wait with complain
  • 1
    @jestdotty I don't know whether I agree with your take that "fancy" (oop patterns and structural designs) makes delivery faster. If anything, it's the inverse. Glossing over the intricacies that would be useful tomorrow or make code more maintainable obviously takes more time than someone doing everything the easiest way there is, or someone not thinking things through. If both could be achieved in same time or with same effort, there would be more incentive to being a carefree developer

    Code reviews sound great on paper but are actual nightmare in reality, especially when the reviewee perceives they share similar or greater competence with their supervisor. It creates bad blood more than it improves skill-set, even though the idea behind it may be noble. Maybe a middle ground is the reviewer defending their rejection of incoming code using publicly available standard practices informing their decision
Add Comment