startups and code

Practice does not make perfect

← Back to home

"Practice makes perfect" is a phrase we have all heard. It actually has some negative impact that many people don't realize. The subtlety of that creates a belief that perfection is attainable. It also means repeating the same thing over and over again will lead to this unattainable perfection goal.

Let me tell you, it's a lie. You will not be perfect. Also, practicing doesn't mean you are getting better. You may be practicing bad habits and actually you may be getting worse. There are some critical steps that can help you get better.

Step 1 - Document your practice

You need to document each step of your practice. Now you can document by recording your screen, writing a blog post, or take videos of yourself doing whatever you are practicing. This is very important to document. Without actual documentation, you will go through a memory recall which will be running through your filter of what you want to remember. When you document your practice, you can review it... which leads to the next step.

Step 2 - Analyze your practice

You can practice to your heart's content, but if you don't realize you are doing something wrong, then you are reinforcing something that should be removed. This is probably the most difficult of the steps, because it involves you admitting that you are not perfect, that you do stupid things, and you can be better. The ego is quite powerful here and I often rely on someone else to review my documentation to see if they see something I can't see.

Getting feedback from someone will help you truly analyze your practice. This means showing someone your mistakes, admitting you need help, and it may be your manager, coach, or significant other. This is critical in growth.

Step 3 - Make a small change

You need to make small changes based on the feedback you learned from your documentation.  Make a small change and then practice again. This will help you test the feedback you identified. It means that not all feedback is an improvement, but you can only prove that by implementing a change.  Some feedback may be to stop doing something rather than starting something new.

Step 4 - Repeat steps 1 - 3

For those that are familiar with agile methodologies, you may see similarities in this post. The retrospective is really step 2, and step 4 is the next sprint. It is not some magical formula. It is simple. However, we get so wrapped up in delivering something we often skip the step of documenting your practice. You don't have to analyze your practice immediately, it can be a few weeks out. It depends on what you are practicing. It depends on how long your practice is. If you are practicing free throws, then you can watch the video immediately and change that same day. If you are practicing a continuous integration and deployment process on AWS, it may take a few days to analyze it.

Let me give you a great example of this.

I documented a build process, I started with grunt. I automated things, and had a great time. Then I reviewed it and by the time I reviewed it, gulp came out... so I migrated to gulp and I love gulp. I also removed some steps, added watch for development. The next time I stopped and reviewed it, I realized that npm can do a lot of scripts and then I combined steps in my npm scripts.  Then webpack came out... well, you see the progression. It really helped me realize that documenting the process was important.

I always would have those moments, OMG, I've done this before... how did I do that again? I google, I look at my githubs, and then find something close, and then I duplicate, improve, and then update. It works in so many different areas too. I use it for work, but it is important to note that you can do it in so many things.

I love writing, in case you haven't noticed. I don't claim to be a great writer, but I do it a lot. I don't analyze my writing, but I should.

Reading has helped a lot

Reading so much recently has taught me a lot. I have read "So good they can't ignore you", "The subtle art of not giving a f**k", "Sprint", "Thinking, Fast and Slow".  So many of these books have similar ideas and concepts. I realized that most of the books out there are teaching similar ideas, but they do that in different ways so it will send the information to the right person at the right time. I am reading more and more, and still every Saturday I write more code on something.

Keep practicing, analyzing, and improving!  It is important to get better to be successful.