Have you heard the phrase “Fail Fast”?
Several people have used failure as a means to learn and do things better.
Scott Adams, creator of the Dilbert comic, wrote a book called How to Fail at Almost Everything and Still Win Big.
The idea is that you try a very small subset of the big goal and get quick feedback on it. Rather than lump everything into a big hit-or-miss target, you break it up into tiny pieces. Each piece can be successful or unsuccessful. This quick feedback can help you learn a great deal towards whatever the bigger goal is.
By breaking apart your goal, you end up wasting a lot less time. You don’t go down a rabbit-hole that wastes tons of time. Either the idea is not good and should be stopped/changed, or there is a better approach that might make it happen.
Before diving in completely, I would like to explain how TDD (test-driven development) has helped me embrace this idea.
Learning TDD Made Me a Much Better Developer… and Person
It was my first job. We developed telecommunications equipment (both hardware and software) that helped connect people to the Internet using different technologies (such as DSL, GPON, and others).
This company was good (at the time) to give software developers training to help them become better at their craft. One of those sessions was on TDD.
An instructor walked us through some C++ code with #defines that commented out test cases. We would first move the #define so that a unit test would run. It would fail. This is because the source code did not implement something.
I hastily implemented the new feature, then watched the test pass.
The biggest eye-opening thing about TDD is the extremely quick feedback you get.
Whereas you may have to compile some huge chunk of code, then load it into a system, then run a manual test against it, this thing ran and validated in a matter of seconds.
Coming from the world of…
- A 10-20 minute compile (or 3-4 minutes for a non-clean build)
- 5 minute load onto the embedded product
- 2-3 minute to boot process once the code was loaded onto the board
This was revolutionary. Rather than wait 10 minutes or so (non-clean build) to test my code, I could test it in seconds. My productivity sky-rocketed.
Over time, I started to see this pattern more and more. Not just in software, but also in my life.
If I can test something quickly…
If I can fail fast rather than going months before validating something…
If I can learn a lot sooner rather than going through the whole process…
I come out way further ahead. I save myself a lot of time and end up with a much better end result. This not only applies to code, but it also applies to all of my goals.
How can you apply TDD to your non-programming goals?
Let me set the scene…
You have this huge goal. We’ll start with one of my own. I want to earn money outside of my job. Income that doesn’t force me to be completely reliant on an employer. I have been trying for quite a while to do this through blogging.
Unfortunately, I have failed in bad ways quite a few times. I have this grandiose idea of what I think my audience might enjoy.
I blog about it. Lots of crickets for a long time.
After several months, I give up.
I don’t know if you have been through this process before. It doesn’t have to be blogging, but with any of your goals. You try, and try, and try for a really long time. Eventually, you realize you aren’t making progress and you give up.
The problem with this or other similar big goals (losing weight, starting to exercise, waking up earlier… anything) is that we don’t have good ways to test and validate our progress throughout the process.
Instead, we need to spend perhaps a LOT of time figuring out how to test and get quick feedback on what we are doing.
In terms of blogging, I recently joined a course that is going to make me a much, much, much better blogger. It’s also going to help me monetize my blog.
One of the first things it shows how to do is to validate your idea by using certain metrics.
This validation occurs before you even have a blog (you don’t have to setup WordPress) or buy a domain. You post on another website’s page in order to validate or refine your idea.
This is the kind of quick feedback you need to be successful regardless of your goals.
If your feedback only happens after weeks, months, or years, you are setting yourself up for a potentially massive failure.
Don’t let that happen!
You can be different! You can achieve your goals! Just go about planning for your success a little differently.
A real-life example for myself: Improving my tennis serve
If you don’t play tennis, bear with me. This example is going to show very clearly how you can use TDD to get unstuck with your goals.
I play in a USTA tennis league for 3.0 players. I want to make progress and become a better player. Specifically, I would like to become a 3.5 player (the next level up).
One way I can greatly improve my game is to improve my serving consistency. In order to improve that following a TDD approach, I need to first break it down into tiny pieces. So I’m going to attempt to do that.
First thing is first: I need to be a lot more consistent with practicing. My first match this season was lost mainly because I had become rusty. My second set was played much better than the first because I was warmed up at that point.
- So one mini-goal might be to get on the court at least 3 times per week.
Once I’m on the court, how do I make my serve better? Well, rather than attempt to have a huge serve (which I can, albeit inconsistently), I need to focus on the proper form with a slow motion. So perhaps my next goal can be hitting 10 serves that are in, in a row, using proper form. (I tend to have different form for a second, weaker serve… which isn’t ideal. Having the same motion for both first and second serves will help a lot.)
- Another mini-goal is 10 serves in a row that are within the service box.
Once I get 10 in a row, I can start serving faster. How can I track faster? I’m not really sure… so this is where I have to be creative. I can start counting in a second or two in my head how long a slow serve takes to land on the other side of the net. A faster serve will land in fewer (fractions of?) seconds.
- Land 10 serves in a row in the service box with a faster serve.
And so on.
So breaking down my more consistent serve, I have 3 quick-feedback goals that can tell me my progress:
- Make it on the court 3 times per week.
- Land 10 serves in a row using proper form (slow).
- Land 10 serves in a row using proper form (fast).
Following this idea, there’s no point in practicing my serve at all if I’m not consistent with my practice every week. If I fail there, then I need to change that before I focus on proper serving technique.
The Ball Is In Your Court
Now it’s up to you. Follow the same process I used to help achieve your goals and get unstuck.
- Break down your big goal into bit-sized chunks that you can quickly test.
- Sometimes it takes a lot of creativity to determine how to test. This is crucial though – you must be able to test, and test quickly.
- Make sure you pass one test before moving on to bigger things.
By breaking apart your goals and testing them rapidly, you are ensuring you don’t get to the end and fail. You can quickly change course as you learn more and get closer towards your goal.
Great! Now go achieve something!