Here's my world view.
A junior engineer is proud he got his code to work, an experienced engineer is proud of the code he wrote to get the feature to work, and a senior engineer is proud of the code he didn't have to write to get it to work.
A junior engineer is proud he got his code to work, an experienced engineer is proud of the code he wrote to get the feature to work, and a senior engineer is proud of the code he didn't have to write to get it to work.
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.
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.
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.
Or it performs well enough that it's not a bottleneck in profiling (and deliberate performance optimizations are unnecessary).
Seems like they were "senior" only in title.
I would counter that a senior engineer is proud of his team, who knows the best practices to ship stable, working solutions. And they are not afraid to throw code away when it ages, because they have the confidence and the team to quickly build something new, that's maintainable and reliable.