5 ms·

My first boss once asked me in a performance review if I was a perfectionist. I was and told him so. He then explained something that left an impression on me:

by procarch2019 5y ago

My first boss once asked me in a performance review if I was a perfectionist. I was and told him so. He then explained something that left an impression on me: the value of shipping something that works even if it’s not elegant. I think there’s a happy medium between getting stuff done and getting stuff done ‘the right way.’ A lot of young engineers seem to miss the forest for the trees and this can be seen early in a project’s timeframe. Sometimes customers don’t help either because they lack the vision to know what they are really asking for as well. I know there’s a problem when people start suggesting solutions, elegant or otherwise, before the user requirements are fully fleshed out. I work in an industry where CI/CD isn’t really a thing due to qualification/validation, so getting things perfect for re-using or servicing codebase is really inconsequential, but you’ll see people fall into the trap of ‘this has to be genericized 100% so we can use it everywhere.’ In reality nothing really gets re-used in such a way that it’s effective in reducing effort. I’m not saying it’s that way for everyone, but in my company’s pseudo programming space this is true.

skytreader 5y ago
This. Clean and correct, but correct above all else. A correct solution, even when not clean, isn't going to earn money. No one (except perhaps textbook publishers) will pay for a solution that is clean alone. You can clean up a correct solution at a later date, all the while maintaining correctness; a clean (but incorrect) solution might need to be completely redesigned to make it correct. I've come to accept that the best engineers are those who ship (you don't get to 10x productivity if you don't ever ship) and that often means being able to call the correct compromises to make. Heck, I'd even say engineering in general is finding a working compromise given a set of constraints.
- heavenlyblue 5y ago
  > often means being able to call the correct compromises to make The fact that you redefined “clean solution” as “correct compromises” doesn’t say much unfortunately.
  - procarch2019 5y ago
    I’m not sure I follow how you came to that conclusion. I think their point is, paraphrased, spaghetti code that meets the requirements, schedule and budget is better than pretty code that functions, but does not meet one or more of the aforementioned. That’s not to say that only spaghetti code can make a good project, but to illustrate the point. Sure, sometimes everything works out where you can refine something to the point where it’s a golden (or near perfect) solution, but any solution that meets business requirement x is better than one that does not at all. I’m not sure if it really comes down to this, but my standards for internal tools are much higher than things developed on the customer facing side. I think I mostly attribute that to the fact that we know how to successfully develop our user/business requirements versus our customers who do not. Hell, I have customers who have asked us to write their requirements. That’s a huge red flag for an unsuccessful solution.
- procarch2019 5y ago
  > A correct solution, even when not clean, isn't going to earn money Was that meant to be ‘is’?

skytreader 5y ago

This. Clean and correct, but correct above all else. A correct solution, even when not clean, isn't going to earn money. No one (except perhaps textbook publishers) will pay for a solution that is clean alone. You can clean up a correct solution at a later date, all the while maintaining correctness; a clean (but incorrect) solution might need to be completely redesigned to make it correct. I've come to accept that the best engineers are those who ship (you don't get to 10x productivity if you don't ever ship) and that often means being able to call the correct compromises to make. Heck, I'd even say engineering in general is finding a working compromise given a set of constraints.

heavenlyblue 5y ago
> often means being able to call the correct compromises to make The fact that you redefined “clean solution” as “correct compromises” doesn’t say much unfortunately.
- procarch2019 5y ago
  I’m not sure I follow how you came to that conclusion. I think their point is, paraphrased, spaghetti code that meets the requirements, schedule and budget is better than pretty code that functions, but does not meet one or more of the aforementioned. That’s not to say that only spaghetti code can make a good project, but to illustrate the point. Sure, sometimes everything works out where you can refine something to the point where it’s a golden (or near perfect) solution, but any solution that meets business requirement x is better than one that does not at all. I’m not sure if it really comes down to this, but my standards for internal tools are much higher than things developed on the customer facing side. I think I mostly attribute that to the fact that we know how to successfully develop our user/business requirements versus our customers who do not. Hell, I have customers who have asked us to write their requirements. That’s a huge red flag for an unsuccessful solution.
procarch2019 5y ago
> A correct solution, even when not clean, isn't going to earn money Was that meant to be ‘is’?