Every piece of advice is based on optimizing away from a given impulse.
The reason influencers focus on the grind; fitness, entrepreneurship and the like, is that for most of us it's an unnatural impulse. I don't want to speak for everyone, but my most natural impulse is towards laziness. Definetely towards not doing. But the grind isn't "good". Not in an unqualified way. For the first part, if what you're doing is not working, you probably need to grind less, step back and assess your strategy. The entirety of the Google SRE model exists because people optimize too much towards feature delivery. But there are two equally competing facts -- No one will use your e-mail platform without key features like spam filtering, and ("The most important feature of any system is it's reliability")[https://www.youtube.com/watch?v=U53wC2A75Is]. These are both true. Google SRE exists to pull people towards this reality, but it's not the only true reality. "Don’t find customers for your products, find products for your customers." -- Seth Godin "A product is only ever as good as its UX. You can have the most innovative technology, but if it isn’t user-friendly, it will struggle to reach mainstream adoption" -- Blake Ross Sure, a product with 0 uptime has no UX, but I think most early stage companies would say that actually focusing on reliability is probably the wrong task, because you don't have enough users to realize that your product is unreliable. A little downtime is ok to speed up the learning that comes with developing and testing UX/features quickly to find product/market fit. You could say that Ben Treynor isn't wrong in the last scenario, and he's not, but very clearly that piece of advice is not useful because it's not trying to optimize away from an unhealthy impulse. Focusing on UX and feature testing for product/market fit is the correct impulse. All other pieces of advice would be irrelevant if not downright harmful. Why do I think this is important? It's important to know that when a blog post states "Well, actually..." It's not really demonizing the impulse it's speaking against -- or, you shouldn't interpret it that way. Concerns about Exercise Addiction are useful to a very small subset of the population, and this population probably doesn't even include ultra-marathoners who run 100 mile races. Almost every post on agile fits into this category. It's only useful if you're company fits into one of the pathologies discussed in the post. Agile in general is a reaction to absurd levels of planning and refusal to get started until everything fits into a perfectly planned waterfall chart. It doesn't mean that adding traditional project management techniques to your company will slow things down and create the pathological behahviors Agile was railing against. Agile means we don't plan is facilly ridiculous. I think the place this becomes most important is when it's not obvious. Sometimes I hear a piece of advice that I immediately put into this category. "I generally speaking obsess in this area, so this piece of advice is not specifically for me, I already optimize in that direction". What pieces of life advice go unquestioned. Internal Development Platforms. One of my favorite things to question lately is the idea that an internal platform should be entirely optional. That if people aren't using it, it's because you've built the wrong thing, and that more product focus is the answer. I could probably write multiple articles on this. But let's start by saying. This is mostly the correct impulse. Most platform / sre / devops teams are optimized in the opposite direction. They most would rather just mandate their platform and move on with their lives. And maybe the response is more internal sales and marketing over a top-down mandate. But I think the point of this dichotomy is to imply a push-pull between, sort of an internal self-deprecating focus, towards an external figure out what the problem really is focus. Even if you've built the right thing, and developers acknowledge that you've built the right thing, there can be other things getting in the way of platform adoption. So get out there and figure out what that is, and figure out if a team just needs the time to do so -- sure make it easier -- but don't assume you've built the wrong thing just because that, in many ways, is what is easiest to focus on and the most in your control. Once you start the journey towards platform engineering, you may find that talking to your fellow developers and building the right thing become the easy part. I thought I'd close just by linking this inc.com article on "The 7 best pieces of advice for living a happy life" How does this principle apply to this article? The subheading here is "This applies to everyone" (Hint: It doesn't) inc.com -- The 7 Best Pieces of Advice for Living a Happy Life This applies to everyone. Stay true to yourself. Do what you love–not what you’re told to love. Create the environment that’s right for

The reason influencers focus on the grind; fitness, entrepreneurship and the like, is that for most of us it's an unnatural impulse. I don't want to speak for everyone, but my most natural impulse is towards laziness. Definetely towards not doing. But the grind isn't "good". Not in an unqualified way. For the first part, if what you're doing is not working, you probably need to grind less, step back and assess your strategy.
The entirety of the Google SRE model exists because people optimize too much towards feature delivery. But there are two equally competing facts -- No one will use your e-mail platform without key features like spam filtering, and ("The most important feature of any system is it's reliability")[https://www.youtube.com/watch?v=U53wC2A75Is]. These are both true. Google SRE exists to pull people towards this reality, but it's not the only true reality.
"Don’t find customers for your products, find products for your customers." -- Seth Godin
"A product is only ever as good as its UX. You can have the most innovative technology, but if it isn’t user-friendly, it will struggle to reach mainstream adoption" -- Blake Ross
Sure, a product with 0 uptime has no UX, but I think most early stage companies would say that actually focusing on reliability is probably the wrong task, because you don't have enough users to realize that your product is unreliable. A little downtime is ok to speed up the learning that comes with developing and testing UX/features quickly to find product/market fit.
You could say that Ben Treynor isn't wrong in the last scenario, and he's not, but very clearly that piece of advice is not useful because it's not trying to optimize away from an unhealthy impulse. Focusing on UX and feature testing for product/market fit is the correct impulse. All other pieces of advice would be irrelevant if not downright harmful.
Why do I think this is important? It's important to know that when a blog post states "Well, actually..." It's not really demonizing the impulse it's speaking against -- or, you shouldn't interpret it that way. Concerns about Exercise Addiction are useful to a very small subset of the population, and this population probably doesn't even include ultra-marathoners who run 100 mile races.
Almost every post on agile fits into this category. It's only useful if you're company fits into one of the pathologies discussed in the post. Agile in general is a reaction to absurd levels of planning and refusal to get started until everything fits into a perfectly planned waterfall chart. It doesn't mean that adding traditional project management techniques to your company will slow things down and create the pathological behahviors Agile was railing against. Agile means we don't plan is facilly ridiculous.
I think the place this becomes most important is when it's not obvious. Sometimes I hear a piece of advice that I immediately put into this category. "I generally speaking obsess in this area, so this piece of advice is not specifically for me, I already optimize in that direction". What pieces of life advice go unquestioned.
Internal Development Platforms.
One of my favorite things to question lately is the idea that an internal platform should be entirely optional. That if people aren't using it, it's because you've built the wrong thing, and that more product focus is the answer. I could probably write multiple articles on this. But let's start by saying. This is mostly the correct impulse. Most platform / sre / devops teams are optimized in the opposite direction. They most would rather just mandate their platform and move on with their lives.
And maybe the response is more internal sales and marketing over a top-down mandate. But I think the point of this dichotomy is to imply a push-pull between, sort of an internal self-deprecating focus, towards an external figure out what the problem really is focus. Even if you've built the right thing, and developers acknowledge that you've built the right thing, there can be other things getting in the way of platform adoption. So get out there and figure out what that is, and figure out if a team just needs the time to do so -- sure make it easier -- but don't assume you've built the wrong thing just because that, in many ways, is what is easiest to focus on and the most in your control. Once you start the journey towards platform engineering, you may find that talking to your fellow developers and building the right thing become the easy part.
I thought I'd close just by linking this inc.com article on "The 7 best pieces of advice for living a happy life" How does this principle apply to this article? The subheading here is "This applies to everyone" (Hint: It doesn't)
inc.com -- The 7 Best Pieces of Advice for Living a Happy Life This applies to everyone.
- Stay true to yourself.
- Do what you love–not what you’re told to love.
- Create the environment that’s right for you.
- Choose your friends wisely.
- Develop positive habits.
- Create certainty and leave room for uncertainty.
- Be vulnerable.
Posts that fit into this category:
- Do things that don't scale Paul Graham