It's Halloween today in the US!
Halloween is a day where kids can dress up as something scary and go out at night to knock on the doors of strangers.
That's a lot of things to be scared of! Scary costumes, out in the dark, and talking to strangers. But what is the reward for confronting those fears?
🍫🍭🍬 CANDY 🍬🍭🍫
Pounds and pounds of glorious candy...
Fear in Software Development
While coding, there is a similar list of fears we might have. Do any of these thoughts sound familiar?
"This block of code looks gnarly; let's ignore it for now"
"That library seems confusing; I'll figure it out later"
"This feature seems hard... I'll skip it and come back tomorrow"
I have those thoughts all the time.
Recently though, I realized how it holds me back to put off the difficult tasks until "later".
Those tasks sit on my todo list, staring me in the face, and I know that I'm going to have to figure them out at some point...
Embracing Your Fears
So what happens when I finally do get around to tackling the very difficult problems?
They usually aren't so bad after all.
It happened to me recently with Stripe:
I hadn't ever done a full Stripe integration front-to-back by myself. I've worked with it before, but had never actually done the setup and initial integration myself.
The tasks seemed really difficult; my thought process was something like this:
- "Charging people real money? Sounds pretty hard"
- "What if I do it wrong? I don't want to make a huge mistake when it involves charging money"
- "There are a ton of docs, and so many ways to do it... where do I start?"
All the while, the bullet point of "Integrate Stripe" was on my todo list - just staring at me 👀
Eventually I just had to get it done, so I got started... And you know what? It really wasn't all that hard after all.
It was kind of tricky, yes; and it did take most of a day to feel like I really understood what I was doing; but after that? It became easy.
Difficult tasks have a way of becoming easy after just a little bit of learning.
Fear Driven Development
So I'm trying something new now.
Whenever I have a really scary task on my list: I'm going to tackle that one FIRST.
We don't need to let our scary todo items paralyze us. We get to choose our response to them - and I choose knowledge and understanding.
Big gnarly todo items are often not so big and scary once you break them down a bit - but it's the fear of those items that can paralyze your development and slow you down.
Reaping the Rewards
So what's the reward for tackling the unknown?
🍫🍭🍬 GLORIOUS CANDY 🍬🍭🍫
oh, that's Halloween.
I mean:
Knowledge and peace
It feels really good to tackle a big problem. The build-up feels awful (not knowing where to start; not knowing how long it will take) - but the only solution is to get started.
So next time: instead of procrastinating on the big, scary thing I have on my todo list... I'm going to start with that one.
Like this post?
Find more on twitter: @chrisachard
Or join the newsletter: 📬 https://chrisachard.com/newsletter/
Thanks for reading!
Top comments (10)
You've tried Error-Driven Development, now try its bigger brother, Terror-Driven Development.
This is very similar to "risky things first" or not? When I start off with a new concept or a small proof of concept, it's best to tackle the scariest, most risky (at least the ones assumed to be) tasks first.
Well themed post!
Yep, exactly! I'm trying to not put off the risky/scary things - because I usually find that once I get in to them, they aren't as risky or scary as they seem :)
Fear Driven Development is closely linked to PDD - Panic Driven Development.
PDD - Panic Driven Development.
"Panic is a sudden sensation of fear, which is so strong as to dominate or prevent reason and logical thinking, replacing it with overwhelming feelings of anxiety and frantic agitation consistent with an animalistic fight-or-flight reaction."
I see PDD as an anti-pattern that many organisations and product development teams end up adopting. It's not conductive to creating anything. It's destructive to the team. It's destructive to the organisation and it's destructive to the product.
As software product development is primarily knowledge work, there is a requirement for calm, peaceful space so that enhanced thinking and problem solving can be attained.
Yes - I see "Panic Driven Development" as something to be avoided for sure: you don't want to be rushing because of some anxiety - that leads to errors.
What I really mean by "Fear" driven development is kind of the opposite: instead of succumbing to whatever fears you have, fully embrace them in a calm and collected way. Basically: the things that seem scary are often not so scary once you have all the information :) (whereas with Panic Driven Development, you never get to that point: you're always "running scared")
Yes - so the Fear, isn't external to your team, but the Fear of something uknown. As you say, embrace the "Fear" and let it drive you forward
I’ve always measured this as confidence.
New stuff, or important features, are scary, and that means we move slower to avoid failing.
The fix is to embrace failure, fail fast, and often and then have systems to correct.
Making a payment system is much easier if you know QA, tests, code reviews will verify it for you, or if you do gradual deployment with monitoring, at least only a few customers will experience the problem.
let’s make systems were we can be fearless. :)
Yes, good point! It's easier to get started with something if you know that things won't fall apart the second you make a mistake :)
Hello
Hi 👋