4 ms·

To answer your points from the perspective of a senior. 1. "Let's ship the simpler solution even though it has clear problems." You wouldn't believe how many

To answer your points from the perspective of a senior. 1. "Let's ship the simpler solution even though it has clear problems." You wouldn't believe how many times I've had to try to convince younger engineers that we don't need to over optimize and can't initially create the perfect solution because 9 times out of 10, the feature will change significantly, or get abandoned completely. Shipping the simpler solution is a way to test the waters and make sure you're building what is expected or wanted. 2. "Let's coerce a third party library to do the thing we want even though it wasn't really designed" Same point as #1. Whats the easiest way to get something out so that we can test and measure assumptions. Overall if you've read the article its about reducing risk. I don't want my team to spend 6 months on a feature to find out the feature is something that business or users want, nor do I want complete crap. The idea is where is the middle ground. Believe me I've dealt with many younger engineers like yourself that believe we should always roll our own solutions when its just not feasible. This is a clear distinction between a senior engineer and younger ones.

sreque 10y ago
"Whats the easiest way to get something out so that we can test and measure assumptions." I was focusing less in my comment on time-to-market and more on risk aversion to code ownership. But, to address your concern, doing things the right way up front can often cost less time and money than doing it the wrong way and working around the brokenness. This can be truth for both initial time to market as well as the more obvious long-term maintenance costs. At the end of the day it's a calculated judgement call, and I've seen senior engineers get it wrong as well as juniors.
tedmiston 10y ago
> You wouldn't believe how many times I've had to try to convince younger engineers that we don't need to over optimize and can't initially create the perfect solution because 9 times out of 10, the feature will change significantly, or get abandoned completely. Or it performs well enough that it's not a bottleneck in profiling (and deliberate performance optimizations are unnecessary).

sreque 10y ago

"Whats the easiest way to get something out so that we can test and measure assumptions." I was focusing less in my comment on time-to-market and more on risk aversion to code ownership. But, to address your concern, doing things the right way up front can often cost less time and money than doing it the wrong way and working around the brokenness. This can be truth for both initial time to market as well as the more obvious long-term maintenance costs. At the end of the day it's a calculated judgement call, and I've seen senior engineers get it wrong as well as juniors.

tedmiston 10y ago

> You wouldn't believe how many times I've had to try to convince younger engineers that we don't need to over optimize and can't initially create the perfect solution because 9 times out of 10, the feature will change significantly, or get abandoned completely. Or it performs well enough that it's not a bottleneck in profiling (and deliberate performance optimizations are unnecessary).