7 ms·

>> My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. I would agree with this, you need to be careful. I've s

by LandR 8y ago

>> My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. I would agree with this, you need to be careful. I've seen a friend start at a new company with a horrendous code base, bring up the issues and be let go because they hurt / offended the existing developers. SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies. So get through your probation period then you can maybe start making noises.

zorked 8y ago
> SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies. It's very easy to criticize, often not easy to understand the situation where the bad code was written. Maybe the hastily-written code was the thing that saved a company from bankruptcy and was written by dedicated engineers, and bringing your friend to fix it was the plan all along, and what they needed was someone to fix the code and not decry everybody as stupid. [I'm not saying this is what actually happened to your friend. I don't know your friend :)]
- Aaargh20318 8y ago
  > It's very easy to criticize, often not easy to understand the situation where the bad code was written. A lot of people seem to think that criticism of the code is the same as criticism of the person who wrote the code. They are not the same thing. Root knows I've written plenty of crappy code over the years for very valid reasons. You are not your code, saying the code sucks doesn't mean I think you suck.
  - deleted 8y ago
    [deleted]
  - laughingpine 8y ago
    > You are not your code, saying the code sucks doesn't mean I think you suck. Some people take _any_ criticism of their code personally regardless of how constructive you are being. I have had a person completely blow up at me for simply asking (literally a question - a valid question) "why did you choose to use a BindingList instead of a List?" Maybe it was how I phrased it? People are tough to get sometimes.
circlefavshape 8y ago
And some people are sick to their back teeth of listening to new devs come in and whine about poor code without understanding any of the context. Perhaps you do know better than everyone else, but you ought to make damn sure of it before you open your mouth
- Aaargh20318 8y ago
  The first course of action if you find some ugly/bad code is to ask a dev with more history with the codebase why it's like that. In my experience 9 times out of 10 the answer is "we know, it's like that because of reason but we haven't had the time to fix it yet".
  - pbhjpbhj 8y ago
    Surely in a commercial setting the primary factor is RoI rather than time? Will rewriting this old, stable, code increase profits or substantial reduce revenue impacting risks? #notacoder
    - TheGrumpyBrit 8y ago
      Often, it's a simple case of business need. As long as the offices are clean, the business doesn't really care if the cleaning cupboard is tidy. It applies to a lot of business areas. If you want to introduce new processes or fix any problems, you need to justify why you want to do that, and "This isn't very pretty" isn't generally considered a good enough reason. If something works, nobody ever got into trouble for leaving it alone.
    - maxsilver 8y ago
      > Surely in a commercial setting the primary factor is RoI rather than time If it's a smaller company (op mentioned 50-100 people) they might not even know what RoI is, and/or might not care about it.
      - pbhjpbhj 8y ago
        That's a strange comment, surely it's impossible to stay in business and not understand RoI to some degree.
Aaargh20318 8y ago
> I would agree with this, you need to be careful. I've seen a friend start at a new company with a horrendous code base, bring up the issues and be let go because they hurt / offended the existing developers. I'm not sure if I agree. As a programmer I feel my primary responsibility is towards the code, not the company, not my colleagues feelings, not the customer. There are other roles who speak for them (sales, product owner, managers, etc.), I speak for the code. When you get into the office in the morning, you hang both your coat and your ego on the coat rack, you can pick them back up when you leave. If someone can improve the code by tossing away 3 years of my work, then by all means. Doesn't matter if the person who suggested it is a senior with 20 years experience or the fresh out of college guy/girl who started just last week. You judge the idea on it's own merits, not by who suggested it. I really don't get the tendency of allistic people to involve emotions in parts of their life where it's not helpful at all.
- LandR 8y ago
  > When you get into the office in the morning, you hang both your coat and your ego on the coat rack, you can pick them back up when you leave. If someone can improve the code by tossing away 3 years of my work, then by all means. Doesn't matter if the person who suggested it is a senior with 20 years experience or the fresh out of college guy/girl who started just last week. You judge the idea on it's own merits, not by who suggested it. >I really don't get the tendency of allistic people to involve emotions in parts of their life where it's not helpful at all. I complete agree
- wool_gather 8y ago
  > You judge the idea on it's own merits, not by who suggested it. > I really don't get the tendency [...] to involve emotions [...] You're absolutely right: if someone has a good idea for improvement, it should be adopted regardless of who they are. The difficulty is that the suggestion of a total rewrite is not-infrequently prompted by a mostly-emotional reaction. It may not be taking all the important objective factors into account, so you have to be careful to assess whether it truly is a good idea.
- GVIrish 8y ago
  I agree that ideas should be judged on their merits but you're still dealing with human beings. Someone could approach a bad codebase and say, "Here are some ways we could improve X, Y, and Z," but you could have another person say, "This was done in the stupidest way possible, we have to throw all this crap out." If someone approaches things politely and professionally then no one should have a problem with constructive suggestions for improvement. But people sometimes approach things in a combative or disrespectful manner and that's when you run into problems.
raztogt21 8y ago
Disagree, joined a company 3 months ago. Started a huge refactor the first week in. Then, a bigger refactor the second month in. I feel I've already earn my credentials with these 3 refactors. The directors and the team leader appreciate the honesty and my initiative to make the codebase healthier. Like Ray Dalio says, 'don't tolerate shit'. P.D: I rewrote a huge section of the application on Vue2 with SFC's. The other three developers who wrote backend mostly, tried to do the FrontEnd, but made a complete mess.

by LandR 8y ago

zorked 8y ago

> SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies. It's very easy to criticize, often not easy to understand the situation where the bad code was written. Maybe the hastily-written code was the thing that saved a company from bankruptcy and was written by dedicated engineers, and bringing your friend to fix it was the plan all along, and what they needed was someone to fix the code and not decry everybody as stupid. [I'm not saying this is what actually happened to your friend. I don't know your friend :)]

Aaargh20318 8y ago
> It's very easy to criticize, often not easy to understand the situation where the bad code was written. A lot of people seem to think that criticism of the code is the same as criticism of the person who wrote the code. They are not the same thing. Root knows I've written plenty of crappy code over the years for very valid reasons. You are not your code, saying the code sucks doesn't mean I think you suck.
- deleted 8y ago
  [deleted]
- laughingpine 8y ago
  > You are not your code, saying the code sucks doesn't mean I think you suck. Some people take _any_ criticism of their code personally regardless of how constructive you are being. I have had a person completely blow up at me for simply asking (literally a question - a valid question) "why did you choose to use a BindingList instead of a List?" Maybe it was how I phrased it? People are tough to get sometimes.

circlefavshape 8y ago

And some people are sick to their back teeth of listening to new devs come in and whine about poor code without understanding any of the context. Perhaps you do know better than everyone else, but you ought to make damn sure of it before you open your mouth

Aaargh20318 8y ago
The first course of action if you find some ugly/bad code is to ask a dev with more history with the codebase why it's like that. In my experience 9 times out of 10 the answer is "we know, it's like that because of reason but we haven't had the time to fix it yet".
- pbhjpbhj 8y ago
  Surely in a commercial setting the primary factor is RoI rather than time? Will rewriting this old, stable, code increase profits or substantial reduce revenue impacting risks? #notacoder
  - TheGrumpyBrit 8y ago
    Often, it's a simple case of business need. As long as the offices are clean, the business doesn't really care if the cleaning cupboard is tidy. It applies to a lot of business areas. If you want to introduce new processes or fix any problems, you need to justify why you want to do that, and "This isn't very pretty" isn't generally considered a good enough reason. If something works, nobody ever got into trouble for leaving it alone.
  - maxsilver 8y ago
    > Surely in a commercial setting the primary factor is RoI rather than time If it's a smaller company (op mentioned 50-100 people) they might not even know what RoI is, and/or might not care about it.
    - pbhjpbhj 8y ago
      That's a strange comment, surely it's impossible to stay in business and not understand RoI to some degree.

Aaargh20318 8y ago

> I would agree with this, you need to be careful. I've seen a friend start at a new company with a horrendous code base, bring up the issues and be let go because they hurt / offended the existing developers. I'm not sure if I agree. As a programmer I feel my primary responsibility is towards the code, not the company, not my colleagues feelings, not the customer. There are other roles who speak for them (sales, product owner, managers, etc.), I speak for the code. When you get into the office in the morning, you hang both your coat and your ego on the coat rack, you can pick them back up when you leave. If someone can improve the code by tossing away 3 years of my work, then by all means. Doesn't matter if the person who suggested it is a senior with 20 years experience or the fresh out of college guy/girl who started just last week. You judge the idea on it's own merits, not by who suggested it. I really don't get the tendency of allistic people to involve emotions in parts of their life where it's not helpful at all.

LandR 8y ago
> When you get into the office in the morning, you hang both your coat and your ego on the coat rack, you can pick them back up when you leave. If someone can improve the code by tossing away 3 years of my work, then by all means. Doesn't matter if the person who suggested it is a senior with 20 years experience or the fresh out of college guy/girl who started just last week. You judge the idea on it's own merits, not by who suggested it. >I really don't get the tendency of allistic people to involve emotions in parts of their life where it's not helpful at all. I complete agree
wool_gather 8y ago
> You judge the idea on it's own merits, not by who suggested it. > I really don't get the tendency [...] to involve emotions [...] You're absolutely right: if someone has a good idea for improvement, it should be adopted regardless of who they are. The difficulty is that the suggestion of a total rewrite is not-infrequently prompted by a mostly-emotional reaction. It may not be taking all the important objective factors into account, so you have to be careful to assess whether it truly is a good idea.
GVIrish 8y ago
I agree that ideas should be judged on their merits but you're still dealing with human beings. Someone could approach a bad codebase and say, "Here are some ways we could improve X, Y, and Z," but you could have another person say, "This was done in the stupidest way possible, we have to throw all this crap out." If someone approaches things politely and professionally then no one should have a problem with constructive suggestions for improvement. But people sometimes approach things in a combative or disrespectful manner and that's when you run into problems.

raztogt21 8y ago

Disagree, joined a company 3 months ago. Started a huge refactor the first week in. Then, a bigger refactor the second month in. I feel I've already earn my credentials with these 3 refactors. The directors and the team leader appreciate the honesty and my initiative to make the codebase healthier. Like Ray Dalio says, 'don't tolerate shit'. P.D: I rewrote a huge section of the application on Vue2 with SFC's. The other three developers who wrote backend mostly, tried to do the FrontEnd, but made a complete mess.