For most of my career, I set goals the way everyone does. Quarterly objectives, a list of things I intended to build, a rough sense of what a good year looked like. I hit maybe half of them, which I think is a normal hit rate, and the half I missed were almost never the ones I had judged least important. They were the ones with no external date attached.
This year I did something different, and I want to describe it precisely because the version of this advice you usually hear is not quite right.
I entered a series of hackathons. Not for the prizes, though one of them I won and another placed third. I entered them because each one is a hard deadline set by somebody else, with strangers who will look at the result, and a rule that you have to actually submit something rather than describe what you would have submitted.
Over a few months that produced six finished projects. Six things that exist, that run, that someone other than me has used. In the years when I set goals instead, I would have described roughly the same intentions and finished two.
Why the deadline is doing the work, not the goal
A goal is a statement about what you want. A deadline with witnesses is a constraint on what you can get away with.
Those feel similar and behave completely differently. A self-imposed deadline is negotiable, and the negotiation happens in your own head where you always win. There's always a reason it slipped that's genuinely true. The scope grew, something urgent came up, the initial estimate was optimistic. Every one of those was accurate in my case, every time, and collectively they meant nothing shipped.
An external deadline removes the negotiation. Not because you are more disciplined but because the person on the other end doesn't know or care about your reasons, and the submission form closes at a specific minute.
The witnesses matter separately from the deadline. Something changes in how you finish work when you know a stranger will look at it. The last ten percent, the part that is all polish and no fun and gets abandoned in private projects, suddenly gets done. That last ten percent is often the difference between a thing that exists and a thing that works.
The scoping effect is the biggest gain
Here's the part I didn't expect and now consider the main benefit.
A fixed short deadline forces a decision I'm otherwise bad at making: what isn't in this. When the timeline is open, everything can be in it, so nothing gets cut, so the project grows until it is too large to finish. I've killed more of my own projects by addition than by anything else.
With a fixed date, the cut list writes itself on day one. I have to name the single thing this project is actually for, build that, and let go of the rest. The results have been consistently better than the sprawling versions I used to build, and not just faster. Better, because a thing that does one thing completely is more useful than a thing that does six things partially.
That's a general lesson about constraint, and I resisted it for years because it sounds like a platitude. It stopped sounding like a platitude when I had six finished projects to compare against my previous rate.
How to get this without hackathons
Hackathons happen to fit my work. The mechanism is more general, and it has three parts.
A date you didn't choose. It has to come from outside. Any date you set is a date you can move, and you will, with a good reason.
Someone who will look. Not necessarily an audience. One person expecting to see the finished thing on a specific day is enough, and is dramatically more effective than ten people who vaguely know you're working on something.
A definition of done that's binary. Submitted or not submitted. Shipped or not shipped. The moment "done" becomes a judgment call, it becomes negotiable, and you're back where you started.
Conference talk proposals do this. So does committing to publish on a schedule, agreeing to demo to a specific person on a specific day, or entering any competition with a submission form. The form of it matters much less than the three properties.
What it costs, honestly
It's a worse tool for long work. Some things genuinely take six months and cannot be decomposed into deadline-sized pieces without damaging them, and if you organize everything around short external deadlines you will systematically avoid that work. I'm aware this is a real limitation of how I have been operating and I don't have a clean answer to it.
There is also a failure mode where the deadline becomes the point. If you are entering competitions to accumulate entries rather than to build things you want to exist, you have made a treadmill. The check I use is simple: would I still want this to exist a month after the deadline passes? If no, I do not start it.
The reframe
The advice I would actually give isn't "set better goals." It's: stop treating your intentions as the thing that needs improving. My intentions were fine. They were always fine. What was missing was any mechanism that made the difference between finishing and not finishing consequential to anyone but me.
Find something that puts a real date and a real reader on the other side of your work. Then let the deadline do what your discipline was never going to.