3 ms·

My advice is to first show ability within the current framework. Fix a few bugs quickly, show a good understanding of things. This gives you credibility and tru

My advice is to first show ability within the current framework. Fix a few bugs quickly, show a good understanding of things. This gives you credibility and trust. Then make your suggestions. A lot of people come in and immediately say "this is all shit" but never prove that they actually have ability. If you are good you can make improvements in the worst code base without having to change everything first.

zimpenfish 9y ago
> This gives you credibility and trust. Then make your suggestions. Many years of experience has taught me that this is 99% of the time useless. If management were listening to suggestions, they'd have been listening to the suggestions of the people already there. But they're not.
- maxxxxx 9y ago
  I guess I was writing from the viewpoint of a tech lead. In general I don't let management make any technical decisions so if a new idea comes up it can get implemented if the rest of the team agrees. But if someone is new he first needs to show ability first. Too many people come in, want to change to their favorite stack and just trade the current set of problems with a different set of problems.
papito 9y ago
Yes, working with shitty code is part of the job. You can't refactor if you can't read other people's code, no matter how bad it is. It's still code, and it probably does something in production that's needed.
- JoeAltmaier 9y ago
  Sure bad code that works is defensible in a cost analysis. But buggy code in an elaborate, overheated pile is not the same as 'shitty code'. Its doing all the wrong things and going nowhere. Another cost analysis includes 'opportunity cost', the good that you could be doing instead of massaging the dinosaur this product has become. By that measure, work done on this 'product' is money down the drain. I've fixed megabytes of bad code in my day. If it was just a matter of code preferences, then sure I'd agree. But this thing is irresponsibly put together. So much drama to do so little, that 'fixing bugs' in it is really just moving them around.
  - maxxxxx 9y ago
    I agree that there are just plain bad code bases that aren't worth fixing. But my point was that a lot of us (including myself) have a tendency to immediately dismiss what our predecessors did without having made an attempt to understand the situation.
    - papito 9y ago
      Let's just say, assuming that you are a rock star and everyone else can't code is a poor starting point. I have been on the receiving end of this attitude, and it's not pleasant. These people just come across as arrogant, and they look really bad when they screw up right out of the gate. Some humility goes a long way, EVEN IF YOU ARE 100% RIGHT.
  - jxramos 9y ago
    That's exactly it, professional experience opportunity cost and what you spend time getting good at.

zimpenfish 9y ago

> This gives you credibility and trust. Then make your suggestions. Many years of experience has taught me that this is 99% of the time useless. If management were listening to suggestions, they'd have been listening to the suggestions of the people already there. But they're not.

maxxxxx 9y ago
I guess I was writing from the viewpoint of a tech lead. In general I don't let management make any technical decisions so if a new idea comes up it can get implemented if the rest of the team agrees. But if someone is new he first needs to show ability first. Too many people come in, want to change to their favorite stack and just trade the current set of problems with a different set of problems.

papito 9y ago

Yes, working with shitty code is part of the job. You can't refactor if you can't read other people's code, no matter how bad it is. It's still code, and it probably does something in production that's needed.

JoeAltmaier 9y ago
Sure bad code that works is defensible in a cost analysis. But buggy code in an elaborate, overheated pile is not the same as 'shitty code'. Its doing all the wrong things and going nowhere. Another cost analysis includes 'opportunity cost', the good that you could be doing instead of massaging the dinosaur this product has become. By that measure, work done on this 'product' is money down the drain. I've fixed megabytes of bad code in my day. If it was just a matter of code preferences, then sure I'd agree. But this thing is irresponsibly put together. So much drama to do so little, that 'fixing bugs' in it is really just moving them around.
- maxxxxx 9y ago
  I agree that there are just plain bad code bases that aren't worth fixing. But my point was that a lot of us (including myself) have a tendency to immediately dismiss what our predecessors did without having made an attempt to understand the situation.
  - papito 9y ago
    Let's just say, assuming that you are a rock star and everyone else can't code is a poor starting point. I have been on the receiving end of this attitude, and it's not pleasant. These people just come across as arrogant, and they look really bad when they screw up right out of the gate. Some humility goes a long way, EVEN IF YOU ARE 100% RIGHT.
- jxramos 9y ago
  That's exactly it, professional experience opportunity cost and what you spend time getting good at.