Scott Hanselman

Optimize for Tiny Victories

September 13, 2015 Comment on this post [15] Posted in Productivity
Sponsored By

I was talking with Dawn C. Hayes, a maker and occasional adjunct processor in NYC earlier this week. We were talking about things like motivation and things like biting off more than we can chew when it comes to large projects, as well as estimating how long something will take. She mentioned that it's important to optimize for quick early successes, like getting a student to have an "I got the LED to light up" moment. With today's short attention span internet, you can see that's totally true. Every programming language has a "5 min quick start" dedicated to giving you some sense of accomplishment quickly. But she also pointed out that after the LED Moment students (and everyone ever, says me) always underestimate how long stuff will take. It's easy to describe a project in a few sentences but it might take months or a year to make it a reality.

This is my challenge as well, perhaps it's yours, too. As we talked, I realized that I developed a technique for managing this without realizing it.

I optimize my workflow for lots of tiny victories.

For example, my son and I are working on 3D printing a quadcopter drone. I have no idea what I'm doing, I have no drone experience, and I'm mediocre with electronics. Not to mention I'm dealing with a 7 year old who wants to know why it hasn't taken off yet, forgetting that we just had the idea a minute ago.

I'm mentally breaking it up in work sprints, little dependencies, but in order to stay motivated we're making sure each sprint - whether it's a day or an hour - is a victory as well as a sprint. What can we do to not just move the ball forward but also achieve something. Something small, to be clear. But something we can be excited about, something we can tell mommy about, something we can feel good about.

We're attempting to make a freaking quadcopter and it's very possible we won't succeed. But we soldered two wires together today, and the muiltimeter needle moved, so we're pretty excited about that tiny victory and that's how we're telling the story. It will keep us going until tomorrow's sprint.

Do you do this too? Tell us in the comments.

Sponsor: Big thanks to my friends at Raygun for sponsoring the feed this week. Only 16% of people will try a failing app more than twice. Raygun offers real-time error and crash reporting for your web and mobile apps that you can set up in minutes. Find out more and get started for free here.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
September 13, 2015 13:39
Your post really resonated with me. Over the past year I've changed from a perfectionist get-everything-right-the-first-time attitude (which resulted in many failures) to a who-cares-how-the-code-looks-as-long-as-it-works attitude; get it working, make it beautiful later.

But it feels as though I'm fixing the wrong problem. Instead of trying to fix motivation, I really need to fix my expectation that result should come quickly. I need to learn to shift my focus from short term gains to long term rewards.

I'm still trying to figure out how.
September 13, 2015 14:07
These little wins are everything to me. You can apply them in every aspect of your life. As you say, at the end of the day, it's about moving the ball forward and having achieved *something*. I think this meta habit is a great foundation for a positive attitude towards just about everything in life.

I just moved to another country (remote worker here, too) and I need to get as much little wins as I can get. Great post and thanks for sharing!
September 13, 2015 14:27
We tend to practice Agile development with Scrum methodologies and assign story point to all our features. This allows us to gauge complexity and we know that anything that is too big has not been defined correctly and therefore we need to break the task down more in order to get those quick wins in. It also allows us to define a Minimum Viable Product on which we can build on more slowly is needed whilst keeping the business happy and ourselves sane!

This coupled together with continuous integration/deployments and frequent code check-ins means the teams function better together with each others code as well. We're not 100% in the dream zone yet, the team is adapting but those small wins is not just a victory for ourselves but also the project owners who are able to see and feel their project coming together.
September 13, 2015 14:28
It DOES take a *tremendous* amount of effort to get the simplest things done, especially with technology, and ESPECIALLY with side projects. Basically what Jon said. It really takes managing perfectionism and really hold true to Lean and work towards a minimal viable product.

As Reid Hoffman says, "If you are not embarrassed by the first version of your product, you’ve launched too late." :)

Be embarrassed, fail fast, and (most importantly) learn learn LEARN!
September 13, 2015 18:26
I've started breaking my larger Sprint tasks down into what I'm calling "nano-sprints", where I set a timer for 20 minutes or so, and focus on one very discrete piece of functionality. Something like, "flesh-out this static method body that is not yet implemented". I don't always get finished on time, but it always gives me a great feeling to have that little "rush" at the end. This also has the advantage of pointing out areas of the overall sprint where I might not be allowing myself enough time.
September 13, 2015 20:19
Yep, I do exactly this. My 8 year old wants to make his own Minecraft mod. Day 1 was get MC running under a debugger. Day 2 was get our own custom block into the game. Today is day 3 and we're going to get our own texture on our block.
September 13, 2015 23:18
Hi Scott!

Yes, this is SO true. I guess we all tend to underestimate hoe much time projects cost. I create tiny milestones as well, I integrate them in my workflow in Trello. That satisfying feeling of moving a task card to the 'Done' column! Before I started doing this, it was, well, horror. I used to burn the midnight oil while trying to live up to my promises. But creating tiny milestones and planning those in, helped me to celebrated the little successes, it gives me more energy (instead of sprinting towards the next mega goal) and more importantly, it helps me writing more realisitic timetables in my project proposals.

Thank you for your relatable story and your honesty in this blog post.

All the best,
September 14, 2015 6:40
Yep! We're moving tomorrow, but we didn't pack the whole house. We packed the linen closet, then the pantry, then this bookshelf, then that bookshelf, then the shoe rack, then the filing cabinet, then the...

Same for programming: my git branches all represent small units of work, each of which (usually) has its own ticket. Each commit is a chapter in the short story that is that branch. Reminds me of the ABCs from Glengarry Glen Ross: always be closing (tickets and branches). It's easier when all they're small.
September 14, 2015 7:58
This post reminds me of the TDD process.
September 14, 2015 19:24
I couldn't agree more; if I go too long without accomplishing some small goal, then I get fidgety and irritable, and end up losing my focus for a long time. I use Trello religiously for work (thank goodness for Trello checklists and card lists), and Github issues for my personal projects, just to be able to look back and say "I got this done, I'm getting somewhere."

I try to set small-term goals and timelines for myself, and I get those broken down into medium and small steps before letting myself run through my queue of work, so that once the work is summarized, I can just zip through it and stay focused until the end.

Nothing beats me down more than getting nothing done.
September 14, 2015 19:26
For me, life isn't a marathon - it is a series of a very large number of sprints.
September 15, 2015 11:03
Tiny victories this week and last:
. Resisted temptation to play with (unnamed) cool new javascript library for mobile
. Resisted temptation to start watching a 3rd TV series from streaming service
. Started reading 350 page historical novel set in the 1800s
. Played basketball 3 days in the last week
. Played board games 1 night
. Learned a few new things for technology already in the project I'm working on... not blue sky, it'd be nice to work on this someday technology
. Solved 1 business problem for our project within the already in use technology/methodology
. Learned to live with others coding styles better...
. Reduced screen time.
September 15, 2015 12:32
This works for me but in the other direction, I optimise for a lack of time and thus want to feel like I've done something.

Small achievements add up. I further this by making a todo list with small tasks on it and then getting the satisfaction of crossing things off quickly and consistently. Also if I did something that wasn't on the list, I add it and cross it out. Then when you look back on your list for the day you can recount what you did. I use a pocketmod for my lists.

Projects are more involved than this, but again it boils down to just a work list: pick the project up, complete something, put the project down.
September 15, 2015 19:11
When you're doing something as a hobby like this, the working quadcopter is not the end result. The enjoyable time spend working with your kid and learning something is the end result. If it never flies it may still be a success. Having it fly is just the icing on the cake. (Not the case if building it was your job.)

I completely agree that what you've described is a great way to prove to yourself and your younger lab partner that you're achieving something.
October 01, 2015 1:02
When I was building my first electronic thing my dad told me, "Life by the yard is hard but life by the inch is a cinch."

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.