Picture this: you write a piece of code to implement some brand new features, or an asyncronous workflow to deploy to multiple worldwide-distributed servers; you try it out and BOOM! No bugs: no problems, no warnings, no unexpected effects. Wow, you wrote the perfect code, right?
WRONG.
(I mean, there can be an incredibly small probability that, yes, you wrote the perfect code, but, come on… would you bet on it?)
No code is perfect. It’s just that your bugs aren’t visible (yet). That’s where failure comes in handy, for (at least) two reasons.
Reason one: educational.
Mistakes are the only measurable feedback in your journey to mastery, the only feedback of your learning process. Sure, it’s nice when you get it right the first time, but was it your raw talent or just beginners’ luck? Your growth is like a function test: watch it fail, make it better, succeed, repeat. And this is true for every aspect of your life, not only your career.
Reason two: technical.
Given we can’t write the perfect code, we have to assume we’ll introduce bugs. And the best way to find them is to watch your code crumble.
Failure isn’t just unavoidable: it’s desirable.
Embrace the process: the more you fail during development, the less you will after deployment. This is the key to better software (and better sleep!):
1 - be careful while you write your code
2 - test the hell out of it (Unit Testing, Integration Testing, Manual
Testing…)
3 - fix everything you can find
4 - and lastly: never, EVER, deploy on a Friday ;)
There you go: next time your code blow up, be happy… you are doing great!
