4 ms·

I think this is helpful advice for people who are new to software development. My experience has been that there are essentially an infinite number of things to

by jm__87 10y ago

I think this is helpful advice for people who are new to software development. My experience has been that there are essentially an infinite number of things to learn and improve upon, so you will never really do anything perfectly. There is always something to criticize, but it may not be worth the time or money to fix it. To give some examples I've come across: Critic: Component X could be Y times faster if you did it this way. What you should ask yourself: Is performance of X actually a problem that your user base cares about or has complained about? If you improved performance of X, would it help your team in the long run? Critic: Your code for X is hard to read. What you need to ask yourself: Is this a core component that is going to stick around forever or is it some temporary thing you slapped together that is going to be replaced in the near future? If it is going to stick around, you should definitely refactor to make it readable. Otherwise, not worth the time unless you literally have no other priorities. Critic: I noticed this new UI component you wrote has a bug. What you should ask yourself: Is it critical to your company/team's image to have your UI working perfectly or do your users mostly care about other functionality which is higher priority? Does the bug stop anyone from using your software properly or being able to do something they want to do?

lstyls 10y ago
> Is this a core component that is going to stick around forever or is it some temporary thing you slapped together that is going to be replaced in the near future? In general I'm in total agreement with your points, but in practice this one is really hard to do well. The majority of code that did anything useful tends to stay around for a long time, whether intentionally or not."There is nothing more permanent than a temporary fix." This is why best practices and established patterns are so important for long term productivity. They help bridge the gap between effort and quality and in general work well. They're not panacea, but the exceptional case is a different issue.
- jm__87 10y ago
  Yeah, you're totally right here. Maybe a better way to look at this point is whether the code is in the core or the periphery. Give higher priority to refactoring core stuff since many people will have to digest this, as opposed to some periphery item which is stable and rarely changed (assuming you have readability issues in both core and periphery code). A lot of judgements going on as to which code is most important so probably best to have this discussion with multiple team members. Regardless, my hope was to offer some rebuttals for bad code critics. Getting defensive at every criticism is not productive. Giving in and trying to fix everything is not a smart way to handle criticisms either since you might just be wasting time and money.

by jm__87 10y ago

lstyls 10y ago

> Is this a core component that is going to stick around forever or is it some temporary thing you slapped together that is going to be replaced in the near future? In general I'm in total agreement with your points, but in practice this one is really hard to do well. The majority of code that did anything useful tends to stay around for a long time, whether intentionally or not."There is nothing more permanent than a temporary fix." This is why best practices and established patterns are so important for long term productivity. They help bridge the gap between effort and quality and in general work well. They're not panacea, but the exceptional case is a different issue.

jm__87 10y ago
Yeah, you're totally right here. Maybe a better way to look at this point is whether the code is in the core or the periphery. Give higher priority to refactoring core stuff since many people will have to digest this, as opposed to some periphery item which is stable and rarely changed (assuming you have readability issues in both core and periphery code). A lot of judgements going on as to which code is most important so probably best to have this discussion with multiple team members. Regardless, my hope was to offer some rebuttals for bad code critics. Getting defensive at every criticism is not productive. Giving in and trying to fix everything is not a smart way to handle criticisms either since you might just be wasting time and money.