Skip to content
GitHub Copilot is now available for free. Learn more

Finish your projects

Don’t let fear, or that last 10%, hold you back.

Artwork: Micha Huigen

Photo of Aaron Francis
PlanetScale logo

Aaron Francis // Developer Educator, PlanetScale

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

Starting a new project is a rush. The possibilities are infinite. There's no legacy code dragging you down; we're only making good decisions this time! The beginning of any project is always characterized by blissful productivity. There's so much to be done. How could you not get a lot done in a short amount of time? Edge cases don't exist. There are only happy paths. There are no hard decisions, no tradeoffs, no users, and no customers. Just you and an infinite canvas.

Sooner or later, the blissful productivity gives way to something that feels much more like... work. More like a grind. But it's probably just this project, right? You've lost interest. The passion is gone. It's not as fun as you thought it would be. All that's left is the "boring" stuff. 

You have a new idea, though, and you're sure that you'll see this one through! 

And so the cycle continues, over and over again, until you're left with a graveyard of unfinished projects, wondering how anyone ever finishes anything. What does everyone else know that you don't? 

Don’t worry, though, you're not alone. In fact, you're probably in the majority! Most people dream of doing great things, but many never start. Of the few that start, even fewer finish. Those few people—the ones that actually finish—know the deep satisfaction of seeing something through to the end. It’s a satisfaction much deeper than the euphoric high of starting. 


In this Guide, you will learn:

  1. How finishing a project is different from solving the problem you set out to solve. 

  2. What role fear might play in limiting you from reaching your potential.

  3. What you stand to gain by seeing a project through to the end.


Finish your projects for long enough, and you'll come to know a satisfaction that vanishingly few enjoy: a body of completed work spanning years or decades.

What is it about finishing a project that's so difficult? What makes the last 10% of a project take as much time as the first 90%? Every person and every project is unique, but two broad themes have continually come back to the surface for me:

  • Finishing requires work

  • Finishing requires courage

Let's start with work.

The work of finishing

You usually start a project with a big, singular thesis in mind: one thing you want to solve or one thing you're trying to say. This is the core of the project; this is the big idea. So you set out to prove that single hypothesis. That's the fun part! You know exactly what you're trying to do, and there's little consideration given to any of the surrounding concerns. It works on your machine, the error messages are cryptic, and it takes a magic incantation to run, but it works. That's the blissful productivity stage. 

Once you've proven that the thing can work, you must start building all the scaffolding around it—all of the infrastructure to take it from proof of concept to a releasable project. It's all the stuff you don't really want to do, like writing documentation, setting up CI, properly handling user input, or figuring out how to correctly bundle the package for release. These aren't the fun parts, or the things you set out to do in the first place, but these are the things that stand between you and the satisfaction of a finished project! A project that you've released to the world and can be proud of. 

There's no way around it: Finishing a project takes a certain amount of pure, unpleasant work. The first step is to embrace the fact that it won't be fun all the way through. You must become comfortable with the grind-it-out nature of the last 10% of a project. This is what separates people who finish from people who wish they could. 

If I knew any secrets, I would give them all to you, but unfortunately, I don't. You may find it somewhat uninspired, but here is the system that has worked for me:

  1. Set aside a block of time.

  2. Decide upfront what you're going to work on.

  3. Fight with everything to focus on that one thing.

Really? That's my productivity method? 

Yes.

Doing that last bit of work isn’t glamorous, there are no shortcuts, and there are no hacks. There’s only work. But let this be a comfort to you! No one accomplishes anything great without sitting down at their desk every day and fighting for it. 

Jerry Seinfeld, the most prolific comedian of our time, was asked by aspiring comedians for advice on how to succeed in comedy. His response? "Just work." That's it. Just work.

While I may not have any tricks or secrets for getting around the work, there are strategies for getting through the work. This is a key distinction: You can't avoid the slog, but you can figure out the way that works best for you to get through it. 

Everyone is different. Our brains, environments, and experiences all vary. A foolproof strategy for some is doomed from the start for others. My challenge to you is to start with a system—any system at all—that you think will tip the odds even slightly in your favor. Try a system, keep the parts that work, and iterate on the parts that don't. 

Personally, I like to put a single song on repeat for hours and hours, days even. It helps me zone in. Why does this admittedly strange behavior help me? I'm not sure exactly, but I've known it to be helpful for more than half my life. I like to get up early before the family is awake, close Slack, put my phone in Do Not Disturb mode, and work. I even put a Post-it note on my monitor with the task I'm focusing on to help keep me on track. Sometimes I can accomplish more in that quiet hour and a half than I can in the rest of the day. 

These things work for me, but you'll need to find what works for you. Figure out how you can set yourself up for success and give yourself every possible advantage, because doing the work is hard. And once you’ve found a personal strategy to push through the painful grind, there remains a deeper and wholly distinct impediment to finishing our projects: fear.

We want to hear from you! Join us on GitHub Discussions.

The fear of finishing

You've slogged through, done the hard work, lashed yourself to the mast, and finished the project, yet you still can't bring yourself to publish. Instead, you tinker endlessly, changing things that don't matter, fiddling around the margins and swapping out libraries or build tools until finally you're all out of things to tweak. 

Even with a fully completed project, you convince yourself that it's not quite good enough, so it remains unreleased. You move on to a new project, and the cycle repeats. 

Finishing requires work, but it also requires a great deal of courage.

Behind the fear of releasing is often the fear of exposing your work, and yourself,  to criticism. 

It’s easier and safer to tell yourself that the project isn't quite right and that it’s better to spend your time on a new (and better!) idea. You tell yourself that it could have been a success if only you’d released it, but you decided not to... for "reasons." It's a comforting narrative that tricks you every time and leaves your best work to gather dust on your hard drive.

You have a duty to your past self to release the project. It’s a way to honor your work and sacrifice. All the time spent on the project is time you could have spent on something else. That time was not without cost.

You also have a duty to your future self to release the project. Every time you don't release a project, you're telling yourself that you’re the kind of person who doesn't ship. Tell yourself that enough, and you'll start to believe it. Trust me, it's hard to unwind. Possible! But hard. 

The fear is real, it exists, and it's something you'll have to wrestle with. 

I've written about how publishing your work increases your luck and how outsized benefits accrue to the people who are willing to put themselves out there by pressing the publish button. I said it then and I'll say it again: For every vocal critic, there are 10 times as many people quietly following along and admiring not only your work, but your bravery to put it out publicly. Let that be an encouragement. 

Finishing takes work, and finishing takes courage, but finishing is itself a reward.

The joy of finishing

There is a deep satisfaction in having finished something. You put in a massive amount of work, see it through to the end, and release it to the world. 

There's the high of starting, the agony of seeing it through to the end, and finally the thrill of releasing. But after everything else has worn off, there remains the deep and quiet joy of having accomplished something. Maybe it was a great success, maybe it wasn't. That part is out of your control. What’s in your control is seeing it all the way through, and you did that. 

Sometimes finishing is the end: You release the article, the podcast, the book, and that's it. The artifact is in its final form.

Sometimes finishing is just the beginning: You release the library, the package, the SaaS product, and your work is really just beginning. Users have issues, customers have feedback, and dependencies need upgrading. In some sense, there is no finished software; there is only released software.

Whether it's the beginning or the end, take pride in what you've accomplished. You've finished something. You are a person who finishes things. Keep finishing things and your body of work will continue to grow over time. Finishing is a skill, and you can hone it. With each release, you tell yourself that you are the kind of person who ships.

One day you'll look back with quiet satisfaction at all the projects you've finished, and you'll feel proud of yourself—as you should.

Hello, my name is Aaron. I live in Dallas with my wonderful wife Jennifer and our two-year-old twins. 👦 👧 I'm a developer educator at PlanetScale, where I write and record videos about MySQL. I love making things, constantly have a side project going, and am keenly interested in processes and automation.

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

Thank you! for subscribing