4 ms·
I've seen some senior engineers take this too far. It's as if they are burnt out from all the code they shipped into production that broke things. They tend to
by sreque 10y ago
I've seen some senior engineers take this too far. It's as if they are burnt out from all the code they shipped into production that broke things. They tend to favor solving problems operationally rather than through correct code. They also favor dumping problems onto third party libraries to the point of causing more problems than they would by allowing a more specific implementation.
Some fallacies I've seen from senior engineers:
"Let's ship the simpler solution even though it has clear problems. We'll hide it behind a feature flag and deploy it to a few machines first to make sure nothing disastrous happens."
"Let's coerce a third party library to do the thing we want even though it wasn't really designed to do what we want. By using the third party library we don't have to take ownership of what we are writing! So much less code to maintain!"
The second bullet in particular can be ironic because I've seen senior-engineer-written code break production because it tried to rely on a third party library to do something without doing any unit, functional, or performance testing to ensure it was doing the right thing and doing it fast enough.
After having been in the software engineer for close to a decade, I see an increasingly worrying trend where companies just assume their engineers are incompetent and favor delegation to third party libraries, external services, and devops/metrics/monitoring to solve all problems. As someone who considers himself a competent engineer, I find the trend saddening because I'm not trusted to write correct code either.
- angryasian 10y agoTo 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).
- nsm 10y ago> The second bullet in particular can be ironic because I've seen senior-engineer-written code break production because it tried to rely on a third party library to do something without doing any unit, functional, or performance testing to ensure it was doing the right thing and doing it fast enough. Seems like they were "senior" only in title.
- jdcarter 10y agoWith third-party code, I'd say a true "senior engineer" has been burned enough to understand that third-party code is no different than any other code--it can have bugs, security flaws, and other risks. Third-party code gains trust the same way that first-person code gains trust: testing and time in service.