3 ms·
This feels like a really good starting point to me, but I just want to point out that there's a very low ceiling on the effectiveness of "carefulness". I can sp
by camgunz 2y ago
This feels like a really good starting point to me, but I just want to point out that there's a very low ceiling on the effectiveness of "carefulness". I can spend 8 hours scrutinizing code looking for problems, or I can spend 1 hour writing some tests for it. I can spend 30 minutes per PR checking it for style issues, or I can spend 2 hours adding a linter step to CI.
The key here is automating your "carefulness" processes. This is how you push that effectiveness curve to the right. And, the corollary here is that a lack of IC carefulness is not to blame when things break. It is always, always, always process.
And to reemphasize the main point of TFA, things breaking is often totally fine. The optimal position on the curve is almost never "things never break". The gulf between "things never break" and "things only break .0001% of the time" is a gulf of gazillions of dollars, if you can even find engineers motivated enough and processes effective enough to get you anywhere close to there. This is what SLAs are for: don't give your stakeholders false impressions that you'll always work forever because you're the smartest and most dedicated amongst all your competitors. All I want is an SLA and a compensation policy. That's professional; that's engineering.
- klysm 2y ago> lack of IC carefulness is not to blame when things break But if you can trust ICs a bit, you can move faster