Hacker News new | past | comments | ask | show | jobs | submit login
It’s Never Going to Be Perfect, So Just Get It Done (nytimes.com)
375 points by mhb 72 days ago | hide | past | web | favorite | 129 comments



I’m reminded of a similar online NY Times piece I read, years ago, I think by a woman named Gladys, which was entirely about the harrowing process of procrastinating on, and eventually writing, the piece. All I could think was, poor Gladys. Not, here’s an authority on procrastination. Heck, I’m more of an authority on procrastination, based on my high school and college years alone, not even counting that I’ve overcome it in my 30s.

There is so much better advice than “just get it done” (isn’t that like telling a commitment-phobe, nobody’s perfect, so just pick someone and commit? I’m sure someone, somewhere, has given themselves that advice and taken it, with positive results, but it’s kind of questionable advice in general).

For example, “meditate” is good advice. Let the anxiety come up; allow it to flow, and leave; see it without judging it or trying to figure it out. Even realizing your problem with starting is an anxiety problem, and feeling the feeling in your body, is a huge step. Maybe noting some beliefs that contribute to it. “Journal” is good advice. Practice writing in your voice, and the act of writing. Journal about your anxiety. Learn to enjoy your writing. Practice will improve the quality. Discounting quality will not help.

Stories about how I procrastinated on something for a month and then late one night managed to forget my usual thought patterns for an hour and do it? I have hundreds of those from my past. There is some information in the thoughts I had when finally doing it (“I get it! You just do it!”), but not relative to the information you will get from going inwards and asking how to change your own patterns of feelings, thoughts, and behaviors.


I often tell myself to "just start" rather than to "just get it done," especially when I suspect my anxiety is driving.

If I tell myself I'm just going to sit down and pretend-work on the thing that's making me anxious for five minutes, just to get a feel for it, and if it ends up being crappy, I'll just toss it and start over later, I'm usually able to short-circuit the anxious "everything must be well-understood and perfectly optimized before you even start, or you're going to fail, because this problem is crazy hard" part of my brain.

Usually five minutes turns into 45 minutes, and I either finish, or conclude that it wasn't so bad after all.


>> I often tell myself to "just start" rather than to "just get it done," especially when I suspect my anxiety is driving.

Same here, and specifically for tech work: I try to start with a unit test and a random-generator algo. Getting that trivial thing to run is often the activation energy I need to get started on writing the main workhorse functions.


Exactly. Seed, trunk, branches. They last thing you want is to build something big that, when it does the wrong thing, leaves you with too much code that you're not sure about.


> pretend-work

I pretend I'm live streaming my programming session, it seems to cause some switch to flip in my brain and seems to help.

Maybe I should actually live stream? But I probably wouldn't have real viewers, and don't know how to fit multiple monitors into a stream.


I'm convinced that the majority of the value from pair programming (literally sitting next to each other, not "virtual" pair programming) comes from the fear of looking like a lazy idiot in front of the other programmer.


Hah same here. Half the time I ask someone to pair with me it’s because I simply cannot muster the motivation to do anything for whatever reason. I find I go through a couple of weeks of this a couple of times a year, I guess you’d call it mild burnout.


If you assume mild burnout, do you think it’s long term the right strategy to force yourself through it? What would your body have to do to tell you that it’s not mild anymore? What if it does? Take care!


Just a bit of anecdotal experience for additional thought: I did the same for years, ignoring the signs, pushing through long hours, etc. and eventually developed idiopathic epilepsy. As it’s idiopathic, there’s no known direct cause (e.g. no head trauma, no tumors, etc.), but there’s a decent amount of evidence that supports at least a strong correlation between my lifestyle (lack of sleep, overwork, etc.) and the development of the disease. And of course lack of sleep is now one of my primary triggers, but that’s also fairly common amongst epileptics once the disease is ‘active’.

Best wishes GP.

Edit: point really being: it’s mild burnout until it’s not.


^that + usually when you pair program, you try to explain your thought process and reasons behind the decisions you make to another person, and in doing so, you actually end up delivering. And learning the material through explaining it to others is a very effective and very known technique, so that makes sense.


I think it's more related to having to communicate your problem(s) and intention(s) to someone else. I often find myself overwhelmed by tasks at work and home. The best solution is a to-do list, but even reciting out loud the steps necessary is enough to calm the anxiety and focus.


I don’t think communication has anything to do with it. It’s just shame.

I tested this out once with a friend who complained about procrastination issues. I suggested he have his wife sit by him while working from home. His wife has no programming background whatsoever but she knows that browsing Reddit or YouTube isn’t work. Apparently he got a lot done that day.

Free Startup Idea: Supply “interns” to shadow employees to create the same effect. Logo could be a Peter Pan style comic of a programmer and his silhouette.


>> His wife has no programming background whatsoever but she knows that browsing Reddit or YouTube isn’t work.

Or Hacker News...


Oh yes indeed. My wife can spot the orange banner from a mile out. She also knows when I'm instinctively alt-tabbing as I hear her coming near. For tasks where I know what to do and just need to code it, I'm easily 2x as productive with my wife around, and that's after accounting for the distraction of us talking about stuff.


Strongly agreed; that is my impression and experience as well. Two people paired up keep each other in check. I sometimes find it stressful and exhausting, but it's hard to deny the productivity boost.


There's a few people online I talk to working on completely different side projects than me. Maybe I should suggest pair-programming remotely to them.


You dont, usually.. I keep one for the code and the other for the browser/private stuff.

You can setup a 'scene' in obs to switch to the other window if you need to, but keeping it focused on your editor/work display really helps those private moments slip to the stream less often.


Jordan Peterson has talked about getting something started in the context of "negotiating with yourself" to get past anticipatory anxiety. In short you have a conversation with yourself and agree on some minimal step forward, even if it is seemingly trivial.

Basically it goes something like "Do I agree to update my resume tomorrow?", "No.", "Am I willing to open up my past resume, and just add the companies, positions, and dates?", "Okay, I can do that".

So you realistically go back and forth with yourself until you find some step, even if it seems pathetic, that won't cause much anticipatory anxiety. Then sincerely feel good about getting that step done, because it is infinitely better than do nothing.

I have found that to be a useful mental tool/trick - will edit if I can find the reference because he conveys the concept much better.

Edit References:

- https://www.youtube.com/watch?v=CfQZcpaBqo4&t=5475s "CV Writing Example"

- https://www.youtube.com/watch?v=c-kWEDr6VS0&t=3462s "I don’t even have the conscientiousness to sit down and do Self Authoring. I bought it over a year ago and haven’t opened it. What the hell is wrong with me?" (A little more funny, similar thing)


Joel also had a good essay on this, fire and motion. https://www.joelonsoftware.com/2002/01/06/fire-and-motion/


When you say you want to completely understand the problem before starting, your personality sounds like an enneagram type 5, check it out to see if that describes you. If so, that might shine a lot of light on where your anxiety comes from.


There's a good TED talk on procrastination which might interest you: https://www.ted.com/talks/tim_urban_inside_the_mind_of_a_mas...


Eh, I'll get to it later.


Oh, the irony.


I love that guy, but I think the best use of this level of awareness into the mechanics of your procrastination — the elaborate story — is to realize it’s just a story. The moment you really realize this, the story changes.


I personally ended up in the 'just get it done'. I find it very very effective.

I tried many other approaches, sliced tasks, meditation etc.. and no amount of sugarcoating made me evolve.

Mentally overcoming the drag was key in my own experience.


"Mediate" and "journal" are two specific solutions. The general answer is "figure out what's stopping you from getting something done and take steps to mitigate or reduce it."


That's barely a restatement of the question "how do I stop procrastinating", not an answer.

Advice like "find a way to start, and finishing will come later" is at least a substantial step forward. (But still incomplete, as it doesn't solve the problems of distraction, meandering, prioritization, time management, perfectionism)


It's not a restatement of the question; it's an algorithm.

The problem with procrastination is that it has so many different potential causes and idiosyncrasies that a random advice from the Internet or self-help literature isn't likely to work long-term (once the novelty factor wears off, which for me is usually around a week). The solution really seems to be to keep trying all of the advice, one after another, in combinations and with personal modifications, until something sticks and you start to do better.

For me personally, what seems to have stuck is, in order:

- Doing a "mind dump" whenever I'm overwhelmed by anxiety or confused by what to do. It usually calms me down and clears my head.

- Doing work in pomodoros to reduce the starting anxiety; setting a modest goal of pomodoros to achieve any given work day to consider it a win.

- Most recently, a perverted form of Unschedule. I tried Unschedule and started failing after just 3 days, but I twisted it into the following form: I don't schedule/unschedule anything at all, but just reward myself with 1 point of "guilt-free play" per each 2 work pomodoros completed. I get to spend the points on whatever hobby project or videogame or other fun activity I want, without feeling any guilt or obligation or pressure to do something else. The ratio is somewhat arbitrary (like, e.g., 1 point = 1 flight in Kerbal Space Program), but that doesn't matter. What I realized is that I started to like raking in GFP points, and then spending them in bursts on some projects I previously kept in a "someday/maybe" list. I find myself thinking, "hey, let's work some more, gotta earn GFP points to burn in a couple of days on $project". It seems that I like accumulating them just in anticipation of spending them.


It's not a restatement of the question; it's an algorithm.

This is what I meant, thank you for stepping in to clarify.

Figuring out "what's wrong" in a case like this isn't always easy. Sometimes you don't actually need to know the underlying reason, and mediation or journaling just works and that's all you ever need to do.

Other times it's not so easy. That's when other interventions like psychotherapy (not just the traditional headshrink-and-couch version) can become relevant and important.


I've found that I'm generally more productive and happier when I both meditate and journal, but I can't say which way causality flows


>I can't say which way causality flows

In my personal experience, it flows both ways. It's a positive feedback loop. When I'm productive, I'm happier, even if being productive means meditating or practicing mindfulness (as long as the dread that comes with "wasting time" is not there, all good), and when I'm happier, I can be more productive. The hard part, for me, was getting the loop started, pushing the rock down the mountain, so to say, getting past the first hurdles of procrastination. What helped me was getting professional help and medicine, but I was a pretty bad case.

An analogy I have used to describe this to family before was an internal combustion engine. Normally, once you get an engine started and keep supplying it with fuel, it'll keep generating everything else it needs to keep running. But it still needs a battery and a starter motor to get it running in the first place. Sometimes just getting it running is good enough, and most engines start with one crank, but other times, something is not quite right and it takes a couple of cranks and maybe some starter fluid to get it started. Even once you get it started, maybe the alternator is faulty, so until you get that fixed, you have to keep supplying electricity some other way to keep it running.


Well, they've got a point. There are definitely quite a few projects whose creators needed to step back, stop spending years focusing on the wrong things and actually get something done. I mean, look at Duke Nukem Forever. Might have done pretty well had they not spent 14 years on it. Same with many other games and pieces of art that spent decades in development, and sometimes bankrupted/broke their creators in the process.

Does that mean you should rush? Obviously not. Does that mean having an eye for detail is bad? No, not at all.

But it does mean you should try to finish your projects at some point. Something that never gets released at all is pretty much useless, and it's probably better to get your products while you're alive rather than have them released posthumously by your estate.

It's also probably worth pointing out that a creator will likely never be as happy with their work as a customer will. After all, you created it, you've got nothing to be surprised by. So right off the bat, some of the 'magic' found in experiencing a piece of fiction/work of art for the first time is immediately gone.

You're also quite likely to see all the flaws, all the things you could have done better, all the possibilities that didn't pan out yet, etc and feel disappointed compared to some ideal you had in your mind.


For software you should make something - any part - work and release it. Then do regular feature releases after that.

If you are not working alone you can ask your marketing people for help, sometimes it is worth waiting for a big bang release, sometimes not (For some things if you miss Christmas you should delay until next Christmas). I recommend you err on the side of release too soon - customers are the ultimate answer, if their feedback on what is important is useful to have (but their feedback is not always correct!)


This doesn't work so well for video games. Reviews come out saying its thin on content with a score to match and can kill a game before its had a chance to expand. Developers have started trying to do this more often lately with mixed results, DICE and Blizzard are high profile examples of this. Blizzards latest World of Warcraft expansion was heavily criticized for the lack of content on release day and has yet to shake the bad blood even after two big content patches. DICE tried this with Star Wars Battlefront but couldn't keep fans long enough with the limited maps it released with.


It doesn't work for AAA games, but it can work really well for indie games. Think of something like Factorio, where version 0.1 looked like this:

https://www.factorio.com/blog/post/fff-184

Then they just kept releasing every week for 7 years, and now you have people building CPUs and explaining Apache Kafka with it.

Ostriv is another recent game that comes to mind as having a similar development cycle. Also many F2P MMOs - most of the non-Blizzard online games I know do regular releases that frequently change the game mechanics (often, to a big player uproar) but still keep their userbase. Fortnight and Pokemon Go are two big ones here.


Lots of games come out in early beta now and raise money through sales as they are developed. It is a better model than crowdfunding for games, because you start from a demonstration of competence in game development and you (usually) have direct view into the development process.


While we're on the topic of Factorio, I find that even from a Factorio player's perspective, the OP is good advice. I've wasted so much time trying to build the perfect base and starting over after building myself into a corner, when really I should have just built something that works "right now" and make iterative improvements over time.


Not just videogames, it's also a terrible strategy for something like self-driving cars or medicine, where "Move fast & break things" ends up breaking people.


The problem is people want a simple, one-size-fits-all mental model of what an MVP is.

Different industries, different problems, different solutions = different definitions of what an MVP will and can be.

Most of this entire discussion is useless.


You are right, but the situations with wow and battlefront are a bit more complex than that. Wow was more due to unfun mechanics and poor reward systems than lack of content (though that was a factor). Also battlefront had a size-able protest due to pricing disagreements. Both of which are dependent on community so as it diminishes it rolls downhill fast.


I'm trying it with my indie game. We'll see it works, but I realized Danger World (https://danger.world) at the end of January this year, and multiplayer is still under active development.


Which is why I said sometimes it is worth waiting for a big bang release. You need to understand your product and customers.


The counter-example here would be fortnight.


With videogames in the cloud, you can release the first level, then work on the next level.

You can even make it so that players can't reach the end of level 1 before you've completed level 2 :)


God, that sounds absolutely awful.


Considering the garbage fire state of modern technology, I am not convinced this idea is a good one.

xenospn 72 days ago [flagged]

coughs Chinese Democracy cough


"Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents."

https://news.ycombinator.com/newsguidelines.html


I was referring to the Guns N' Roses album.


I still build out everything required to realise the vision, and that usually takes at least months to build.

There's an analogy in startups that you should build a great skateboard first if your vision is to build a better car, but I just don't agree.

If you have a vision for a better car then you need to deliver a better car, not a skateboard, because, well a skateboard just isn't a car. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-...

If my idea is to create a business for sharing cars, but it's cheaper and quicker to build a business where local kids drive you around on their pushbikes, I just don't see that as being the same. Those who argue for skateboards versus cars would say "well you are solving the problem of rental transport and starting in a practical way". Meh.

The other thing I think is important is not to waste the initial attention for your product on something that is not in fact the true vision of what you had in mind.

But so far I haven't succeeded so my philosophy can't be given much credence.


I think you are just using the wrong analogy, because the vision is not usually to build something but to achieve something. So the analogy should be something like:

If you have a vision for getting people to move from one place to another in a better way, you should build whatever achieve moving people from one place to another in that better way. Getting rid of everything that is not necessary for you to test if you are really getting people from one place to another in a better way.

update: typo


>> They had tried to build similar systems in the past and failed miserably, mainly because of Big Bang thinking. They told me that one of their previous attempts took 7 years from inception to first release. SEVEN YEARS! By then of course everything had changed and the project was a total failure. So this time they wanted to do it differently.

Or well... Maybe it's just that they have failed to build a system because the IT industry had been changing incredibly fast at the time. So they built their skateboard, but the government closed the skateboard parks, and everyone jumped ship to rollerblades. And that's how they've spent the full 7 years.


At least agile, whatever it may be to people, has worked well in government/public sector IT projects. If ever a project was going to require many changes in its development lifecycle it's government. No more 7 year projects with no working product at the end. It was common practice to underbid the price to win the contract and rinse it on the change requests.


It makes perfect sense Agile works a lot better for Government projects. Also probably for agencies too.

I'm not 100% on SaaS. Need something more fine-tuned. Call it SaaSGile.


In practical startup terms, if your idea is to deliver either a better car or a better skateboard, you've already failed. Both these industries have a century of optimization behind them; even if you did manage to catch up, any useful innovations would be copied by incumbents. Successful startups usually come out of new markets: areas where the environment has changed such that existing product categories or delivery channels no longer match what consumers want to do. You can't really define these as "better" except in the sense of users adopting them rather than existing alternatives: if you could, the existing companies would've done it.

Rather than designing a great skateboard or a better car, your goal might be to design the Schweeb, or OneWheel, or Segway, or HyperLoop, or rideshare or scooter rental company. There're still plenty of ways to fail with these, but at least you have a chance of success.


The real question is "what, exactly is an MVP?"

Some people interpret an MVP almost literally as almost nothing - just a web page that describes the idea and asks for email addresses.

Others interpret the MVP as almost nothing, but a "workable" almost nothing - i.e. some code that users can find. After users have found it, the code will be iterated upon until the original vision is realised.

The skateboard people interpret an MVP as making a series of easier-to-build similar, broadly analagous products on a path to eventually building the full product that you envision.

I interpret the MVP as being the minimum system that completely realises the vision. That might takes months to build. but the point is that when any user sees it, they should understand completely what this thing is meant to be. It doesn't mean the software is complete in every possible way, but it does mean that everything needed to make original vision working and obvious.

Speaking to the original post, this takes time and it might take alot of time.


The vision is irrelevant to the customer.

There's an easy way to tell in hindsight whether something was an MVP. Did it get beaten to market by someone who came out with something worse? Then it's not Minimal. Does nobody use it? Then it's not Viable. Do they get bored and move on? Then it's not a Product.

Doing this with foresight, so you're the one who actually puts out the MVP for the market and captures it, is significantly harder. Whoever manages to do that ends up rich, so if it were easy, we'd all be rich. But a general rule of thumb is that if the world is moving on and other people are getting rich while you sit there refining your idea, your idea of "Minimal" isn't actually minimal, while if you're continually pumping out ideas that nobody likes, your idea of "Viable" isn't actually viable.


>> The vision is irrelevant to the customer.

Having vision for a product means correctly identifying customer's problem and proposing a solution for it. Dropbox vision is: "Make user files accessible anywhere, by storing it in the cloud synching them across devices". Google's vision is: "Make all information in the world easy to find and access, by having search engine know you better than you know yourself" :)

Customers either buy into your vision, or ignore it, and the latter means that the problem that you stated does not exist or is not important enough to your users.

For you, having clear vision helps you create MVP, because you can easily identify which features are crucial, and which are nice to have.


This sounds an awful lot like the famous HN criticism of Dropbox; don't make a better version of something which already exists. Is there any existing data about this (whether new markets or established ones are more fertile ground for startups)?

It seems to me that GoPro did a pretty great job innovating in a highly established market, for example. PayPal is another good case study here.


In the eyes of its users DropBox is a fundamentally different product from the filesharing sites like YouSendIt that already existed, or the techie utilities like rsync that HN commenters compared it to. There's an easy way to see this: people talk about dropping a file in their DropBox, they don't talk about this new filesharing program they're using called DropBox.

Similarly, people talk about buying a GoPro and putting footage of it up on YouTube. They don't talk about buying a digital camera from GoPro and putting their videos up on this video-sharing site called YouTube.

Similarly, people Google questions and Xerox pages, they don't search the web with Google and copy documents with a Xerox copier.

Conversely, people stop at the gas station (which might happen to be a Mobil or Exxon or 76 or Valero) in their car (which might happen to be a Honda or Subaru or Ford) on the way to the supermarket (which out here is probably a Safeway, but that varies depending on location). Or they might stop on their way to Whole Foods, which actually did succeed in differentiating, while driving a Tesla.

The customer's mental model is the only thing that matters here. If you're building a car or a skateboard, you're seeking to fit into an existing category in their head. Even if you win (which is unlikely, because incumbents optimize very heavily with lots of resources), you lose, because you're a commodity in a market with lots of substitutes. If you want to actually win - in the sense of create a monopoly product that defines its own market - you, as an entrepreneur, need to be thinking in terms of the overall problem that the user wants solved (transportation, or information access, or answers) so that you can define the terms of the market in a way that you're the only reasonable solution.


Your explanation is very clear and really makes a lot of sense.

> The customer's mental model is the only thing that matters here.

Totally right

> If you're building a car or a skateboard, you're seeking to fit into an existing category in their head. Even if you win (which is unlikely, because incumbents optimize very heavily with lots of resources), you lose, because you're a commodity in a market with lots of substitutes.

> If you want to actually win - in the sense of create a monopoly product that defines its own market - you, as an entrepreneur, need to be thinking in terms of the overall problem that the user wants solved (transportation, or information access, or answers) so that you can define the terms of the market in a way that you're the only reasonable solution.

At what point should you start doing that?

Using one of your examples: I don't think the Google founders had a vision of defining a new category of service. And they didn't even have a business model for several years. So what actually made them "win"?


I think the Google founders had a vision of solving a problem. They wanted to make search work right.

(Well, technically, they wanted to get their Ph.Ds - the actual history of Google was that Larry had the idea to download the web and throw away everything except the links, so he did that. Then he had the idea to visualize it as a big eigenvalue calculation on the probability of a random surfer ending up at a given page, and that's where he got the idea for PageRank. Then someone - might have been him, Sergey, or Scott Hassan - got the idea to sort webpages by PageRank, and the results were better than existing search engines, and so they launched BackRub as a search engine. Then Andy Bechtolsteim thought it could be a really big company and gave them $100K to make it one, and the rest is history.)

If you steer towards problems, and do so without fear of the unknown, you'll naturally move towards ideas where you get to define the category. They wouldn't be problems if someone had already solved them! The rest - building a business, making money, marketing it, defining it in customers' heads, etc. - can all follow later.


> even if you did manage to catch up, any useful innovations would be copied by incumbents.

If your optimization is sufficiently novel, can't you use intellectual property to protect yourself?

If that isn't an option, how do you provide yourself enough runway to scale fast enough to escape the incumbents?


Only if you can a.) detect that the incumbents are copying you (in ways that can be legally protected - in general you can't protect what a product does, only how it does it) and b.) have the money for a legal battle against a well-funded incumbent and c.) know that you aren't infringing on any of their patents or IPs. Most startups don't fit all 3 of these categories.

The way most startups manage to get big is to fight on ground that big incumbents are unwilling to occupy, while their attention is occupied elsewhere. IBM thought that software was a loss-leader and the money was all in hardware: they came out swinging hard with the IBM PC and eventually dominated the market, but didn't realize that leaving the IP for MS-DOS in Microsoft's hands would be a crucial error when the PC BIOS was cloned. Microsoft knew how to fight on platforms and ended up crushing Netscape, but they had no idea that Google (ostensibly "just a search company") would end up occupying the crucial real estate on the web.


I really wish I could stop seeing this everywhere I went. I get that there are people who need this kind of advice, but for someone like me, this advice is poison. For everyone who needs to be carefully and constantly reminded that you can't let the perfect become the enemy of the good, there's someone else, maybe several someones, who need to be carefully and constantly reminded that "good enough" is almost never good enough. And this latter group, when left unchecked, tends to do a lot more harm than the former.


This is definitely in the category of advice (much like GTD) of "if you don't think you need this advice, you probably don't need it."

I feel like there's an alternate wording for this advice that is less "cut corners" and more "determine how many corners you don't want cut".

Maybe involving a target condition? You want to make the best thing possible. Keep on aiming for the best, but establish a baseline that you would find acceptable. Maybe you won't make something perfect, but you'll now have a target that you _can_ get to.

This thought process reframes the discussion of "good enough" away from "did I spend enough time on this? Surely I can spend another week and make it 10% better" to "Does this meet the requirements". There is no longer a debate to be had, just a yes or no question to answer.

So when people ship things that just aren't good enough you don't have a discussion around spending more time on things or being more careful, you have a discussion around what your baseline requirements are (which is _actually_ what you care about).


This makes sense to a certain degree, but "just ignoring it" only goes so far: even seeing it is corrosive to a certain extent, and by the time you've even registered it enough to ignore it, a lot of the damage is done.

Perfectionists undergo a similar phenomenon, I'm told. After all, the modern "Do it badly" movement was itself a response to the corrosive effect of the "'Good enough' isn't" message permeating all of society. I'm not unsympathetic. In solving one problem, it didn't exactly create another -we've always had perfectionists to some extent- but it made that problem much, much worse than it had once been. But the fact is, it was done to solve a real problem in its own right, and that problem has not gone away.

What it comes down to is conflicting needs. The all-pervasive "'Good enough' isn't" came about because some people genuinely need it, and they genuinely need it at that level. The same is true of the now-pervasive "Do it badly": it is genuinely needed, and at this level. And you can't balance them, because they inherently undermine each other. So what do you do?


Hey, nobody said it was perfect advice. :)


Steve Wozniak suggests the Apple II became successful because he's a perfectionist. He talks about throwing out almost-finished designs because he thought of a more streamlined approach while implementing the existing one.

Then again, Steve Jobs has suggested that "Woz" spent so much time fiddling with Apple II hardware that he never got around to adding floating point math to Apple BASIC. (They probably should have hired somebody else to work on BASIC if Woz seemed more hardware-oriented.)


Perfectionism is great when you know exactly what the customer wants (like a custom made shoe). It wastes too much time when you're experimenting to find out what the market wants.


The part I’ve always had trouble with is you need a certain amount of polish before the idea is acceptable. The quality of delivery heavily influences people’s perceptions. So this is a very fine balance.


One of the recent entrepreneurial posts here mentioned a question like "do your users know how much they are suffering for lack of your product right now?" and I think that related to polish.

If you have a machine that cures baldness you don't need polish. The knobs can be any color you want and give the user little electric shocks it doesn't matter. Nothing like this exists and potential users really know they want it.


Consider a hypothetical low quality situation with this product.

A guy running up to you on the street offering yellow colored baldness pills in a baggie. Sure they might work, but you’re not going to be the one to find out. The inventor, after many failed sales, may erroneously conclude there's no market for this product.


If you told someone from 1700 about any modern surgery they would think you are nuts for risking it - the little yellow pill is is less risky to them.

I wouldn't be the first to try your yellow pills on the street, but I know some people who would be. If they found it worked they would tell everybody, so things would quickly spread. (I'll ignore the FDA though government is a factor in the real world) In a few years people would be asking me why I haven't gone for those yellow pills yet...


There is continuum and a point where the low quality of the product/presentation makes it extremely unlikely you will find market fit. A needed investor may see that only 1 in 1,000 of people talked to will buy it and conclude the market is too small.

To give another anecdote: people had an immediate need to not die from infection after surgery but it still took over 50 years for doctors to wash their hands because it was originally perceived as an attack on the doctors cleanliness. A bit of polish on the presentation would have went a long way.


Quality is local optimization, Market Fit is global optimization. As the saying goes, if you're not embarrassed by v1 you waited too long to launch.


But consider results in consumer technology: Palm versus Blackberry versus iPhone.


Did you use the first iPhone? It had a ton of gaps, even in the market at the time. I believe they would have hamstrung it if not addressed in subsequent versions.

I personally have never viewed iPhone as an example of perfectionism in product delivery. To me it's a whole bunch of solid execution over a very long time scale, before and after introduction.


Consumers and the press were much more forgiving of the iPhone's shortcomings than they were with anybody else. The 2007 iPhone was 2G only (when 3G on Nokia, Samsung, and Blackberry phones was standard), and it constantly dropped calls on AT&T in the US. Steve Jobs was in full reality distortion mode thanks to several successful iPod/Mac releases, and people loved the showmanship. Loyalty to Apple wasn't purely about the quality of the product.

The Blackberry Storm was released in 2008 to compete with the iPhone and was completely trashed by critics, despite doing the basics extremely well (call reliability, high quality capacitive touchscreen). I had one at the time and apart from the fact that BBOS 6 wasn't 100% touch-optimized, it was very usable. Unfortunately its app store was lacking, whereas the iOS app store had plenty of flashy, gimmicky apps that better served as a showcase for the iPhone's capabilities (gyroscope, motion sensor, etc) rather than useful functionality.


The polish was in the fluidity of the interface. To make touch easy the interface couldn’t jump around just as you touched the screen.

Its not that the iPhone was fast - but when it couldn’t render it showed a square pattern and still scrolled roughly in tune with your finger. None of the other players thought that was important.


Wow, that took me back...I remember the little mosaic graphic to display parts of the web page that the browser hadn't loaded. Feels like a lifetime ago, but it makes sense to have that little bit of UX improvement, since back then all we had were full-fat desktop websites.


What's to consider? Palm never had the mass market engine behind it that Apple had coming from Mac; Blackberry got lazy and sat on irs laurels; Apple was the first big company with a big budget to launch a full screen high-resolution capacitive touchscreen in USA.


Quality and polish do sell in long term while even brands fade away.

So how many mechanical watches do you folks recognize? ;)


I think that a big part of the problem is that the economy fundamentally doesn't make any sense anymore so it's impossible for entrepreneurs to predict what the market wants. Nowadays, the market wants products made by companies whose founders have raised a lot of VC money and which are heavily advertised.

If you're working on a product and you don't have good business connections, then you should make your product as perfect as possible because otherwise you don't stand the slightest chance in this economy. It used to be that your product had to be 10x better than the competition in order to make any impact, nowadays, 10x better is not enough to even be noticed; consumers just follow the capital.


Who you know always has and always will be more important than what you know. If you don't know everybody find that person who does. Remember, Jobs got richer than Woz, but Woz wouldn't have anything without Jobs: take what you can get and don't worry about someone else getting more so long as you are not completely cheated.


Probably helps to have a combo of such personality types.

Woz: "Look we can do this better just give me some time."

Steve: "Ok fine."

-time-

Woz: "Hey we can also-"

Steve: "Damn it Woz no we need to sell a thing already!"


This is how I get research papers done with a collaborator! You need the one who wants to generalise a little more, and the one who wants to get it published and out the door. It's OK if these roles switch over time, but having both is good.


At least in software "getting it done" is only half the problem. The real problem is knowing how to find a balance between good enough and catastrophic long term consequences. It's a balance between tactics and strategy.

The approach is different in other disciplines such as artistic creation where blind confidence in what you are doing is a better long term strategy and we give a lot more importance to tactics. The more you work the better you become.


This comment speaks to me. I'm in a weird point at my job where I'm right at the tail end of supporting this legacy app I've worked on for years, and a brand new app my team will be building from scratch.

It's pretty surreal, because I've been dealing with many of the negative long term effects of decisions that were made for this app years ago, meanwhile I'm about to have to make a whole host of similar new decisions for the next app. I know there are going to be compromises, I know I won't be able to make it perfect, so finding that balance is going to be critical.

I'd love to hear from someone who's had to find that balance and what they've learned.


I'm sure you learned a lot about the problem from maintaining the legacy app.

There is some intuition that develops over the years, but honestly the only reliable way I've found of knowing how to properly solve a problem is solving it multiple times.


From my own experience maintaining legacy systems and then re-implementing them — strive for a system that future maintainers will be able to refactor instead of wanting to replace it, whatever that entails. Even if all of what you write will be refactored away, you've accomplished something if they're able to continue using the code base in some form.


I had the same negative reaction to the title that other commenters had, and of course I was thinking about software. But then I opened the article and saw a picture of a canvas and my mind shifted to music.

I know lots of people who love to write music or want to write music but can never get anything done because of a feeling that it has to be perfect. I have always embraced an aesthetic of rough imperfection in my music and (I suppose) as a result I have record over 30 albums and EPs. Sure, lots of that music is, well, cringe-worthy, but there are some gems in there that wouldn't exist if I let perfectionism get in the way of _production_.


For artistic creation I always come back to this anecdote from the book "Art and Fear":

"The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."


That anecdote seems to be a story that was just made up. It is believable if the students have never done ceramics before, however if the students have done a lot before I would expect thinking about what to make would become more useful than doing something again for the millionth time.


> That anecdote seems to be a story that was just made up.

It's true, although they changed the medium: https://news.ycombinator.com/item?id=19960342

> James Clear reached out to the authors of Art & Fear and this is his footnote: https://jamesclear.com/repetitions

> This story comes from page 29 of Art & Fear by David Bayles and Ted Orland. In an email conversation with Orland on October 18, 2016, he explained the origins of the story. “Yes, the 'ceramics story' in Art & Fear is indeed true, allowing for some literary license in the retelling. Its real-world origin was as a gambit employed by photographer Jerry Uelsmann to motivate his Beginning Photography students at the University of Florida. As retold in Art & Fear it faithfully captures the scene as Jerry told it to me—except I replaced photography with ceramics as the medium being explored. Admittedly, it would’ve been easier to retain photography as the art medium being discussed, but David Bayles (co-author) & I are both photographers ourselves, and at the time we were consciously trying to broaden the range of media being referenced in the text. The intriguing thing to me is that it hardly matters what art form was invoked—the moral of the story appears to hold equally true straight across the whole art spectrum (and even outside the arts, for that matter).” Later in that same email, Orland said, "You have our permission to reprint the any or all of the 'ceramics' passage in your forthcoming book." In the end, I settled on publishing an adapted version, which combines their telling of the ceramics story with facts from the original source of Uelsmann’s photography students. David Bayles and Ted Orland, Art & Fear: Observations on the Perils (and Rewards) of Artmaking (Santa Cruz, CA: Image Continuum Press, 1993), 29.


I also remember this story and hearing that it was just made-up rather than real. However, I know a lot of professional artists and most of them do not have a process that consists of "sitting and thinking about what to make." It is often a generative process that consists of making small/sketchy things and iteratively fleshing it out. In other words, although that anecdote doesn't seem to be referencing any sort of study, it matches very well with my experience in the art world & in teaching art.


I agree that spending most of a class thinking about what to produce is not useful. However just creating without thought isn't the best way either. Someplace in the middle is where to be.

That is get an idea, and create it in sketch form. Then examine the sketch (often waiting a few days is required to be a good critic of your own work). If the idea is good start fleshing it out a little at a time - examining it critically at each step. In some mediums you can erase, in others you need to create a new sketch of the same. Eventually you get something good. Many artists will have more than one piece in progress at a time so they can have that break to get away from their mental investment and look critically at it. (this last is not universal)


Yeah it's probably a parable, but the point it makes is valid.


At some point there is no substitute for doing. This is why directed practice is such a good method for learning something. It is practice with some theory in mind.


Funnily enough I had the opposite reaction; I thought this was a standard "Move fast & break things" article over a SaaS app or whatever, but the picture gave me a negative impression that this was less of an article about how great is the enemy of good, and more justification for doing the most half-assed job humanly possible and then trying to justify it posthumously as a tactical decision. The worst thing is that I read the article and I logically know he's not advocating for that, but that image provoked such a visceral reaction that I'm unable to shake that impression.


So-called satisficers are happier with their decisions probably because they are decisions, that give them a sense of control. "I chose this 'good-enough' option, I will now proceed." In other words, if there exists some better path out there, I don't care, because this is good enough, and I want to proceed. It's all coming from, and directed from, within. You are the agent in charge.

Whereas so-called maximizers are always at the mercy of an external world that might contain a previously-unknown "better" or "best" option that they feel obliged to find. It comes from without; the world is in charge, the vagaries of a perfect ideal are in charge; the person is only hapless and reactive.

Thinking you're in control of your destiny (even if it's not true) is more satisfying for people.


There are several kinds of procrastination, so it's impossible to generalize.

Some projects require very large time commitment to get right, reworking several times, etc. Some others reach a diminishing return stage very quickly and continued effort is wasted. You definitely shouldn't just take whatever you have in front of you and just rush it until it's barely workable.

The critical skill is to be able to judge without anxiety and with some precision how much additional time is going to improve the outcome, and what is the rough global value (to you) of this improvement. Some projects have long ramps of effort and refinement, some are just not worth the time and can arrive at a good enough stage very quickly.

I think the best advice I could come up with is that if you're having this sort of problem, recognize it, try to deal with the anxiety and get a perspective on the risks vs benefits, and improve. If possible find an environment/hobby /side occupation where you have to make a ton of such decisions to get a lot of practice. College/personal projects tend to be pretty sparse and give a lot of room for failure and delaying I guess.

For me it's been a very slow, progressive realization that I'll never get things I wanted done by just leaving them to an arbitrary later date, or obsessing too much over details. In nothing vs something, something wins.


This is exactly what I was saying in the other HN thread today about code reviews, and I got downvoted a bunch of times. A lot of people have a perfectionist mindset and lose sight of the fact that "perfection" can be subjective and that the product they are creating for the user is more important than the engineer's personal vision. This isn't to say that we should just throw out best practices, wing it, and never take criticism. Being willing to break work into further tickets and actually giving them priority can mitigate long-term problems created by imperfection in the first place.


This sounds like some non-engineer talk that ends up fucking the team up 1 year later as there code starts breaking everywhere, the code becomes very difficult to refactor, new hires start to struggle ramping up, etc.

I agree that sometimes people can be too focused on perfection in code reviews but consistency, modularity, and other seemingly unimportant things are crucial in maintaining hygiene for your project


> This sounds like some non-engineer talk

Does it merely sound like non-engineer talk, or is it actually non-engineer talk? I just want to make sure you aren't making the wrong assumption or implying the wrong thing. I've been saying what I've been saying as a result of my 5+ years experience doing full-time software engineering.

> I agree that sometimes people can be too focused on perfection in code reviews but consistency, modularity, and other seemingly unimportant things are crucial in maintaining hygiene for your project

It's interesting to me how easily people here are assuming that I'm implying the absence of standards merely because I'm suggesting people opt not to chase perfection in favor of providing a non-blocking pathway for engineers to make changes or improvements. Maybe my phrasing is poor.

I don't think you and I disagree that consistency, modularity, etc., are important and should have some amount of enforcement. The point I'm trying to make is that, in my experience, people sometimes go too far with this, so there should be some set expectations as to the limits of an individual code review. Limiting the amount of review iterations in a unit of work and splitting feedback-related work into other tickets can help address the issue of perfection zealotry.


What I meant is, I've heard this kind of language from non-engineers before (mostly PMs) trying to get developers to ship something in a bad state. Most probably because they'll be gone before they start having to deal with the repercussions of the technical debt.

>Limiting the amount of review iterations in a unit of work

Fully agree. I think there should only be two iterations max, preferably just one.

>splitting feedback-related work into other tickets

Would never work at places I've worked. The backlog of "important tasks" is never-ending so code cleanups, optimizations, etc. never get done because there is always higher priority work. This isn't really in control of the team because even if the PM agrees to let you lose a week of productivity making the code better without adding features there's a good chance their manager, the engineering director, etc. won't like to see that. So at least in my experience you only have one shot at getting that code in a good state, with the alternative being the code slowly getting worse and worse until it gets so bad you opt for a rewrite or lengthy refactor


That's a totally valid point, and perhaps I am too optimistic. I do think that a company with the right values could do that properly, but most don't, including best ones I have worked for.


The article is just the title stretched out into a few paragraphs. Signal to noise ratio is close to zero.


Has anyone else just stopped reading stories on sites like NYT that block reading if your browser is in private browsing mode?


And all the sites that won’t let me use an ad blocker or Firefox Foxus. I don’t trust any of them not to load 300 ads.


I’ve seen some code done by perfectionists, it was beautiful to behold. It did it’s job well. Unfortunately it was considered the “legacy system” and was eventually retired.


Some things belong in museums.


The problem with the headline is that if you think ‘it’ isn’t good enough, then ‘just getting ‘it’ done’ will send you into a vicious loop that will spin out of control as the pressure to over-achieve builds up.

You really have to reframe your view of ‘enoughness’ in a more positive light, so instead of something being perfect (not enough until then), it’s finding a way to see what is good enough for the time being, that allows you to move on. Then you can go and do what you need (or do nothing if what you have is adequate) and take the weight off your shoulders.

The startup lingo for this is MVP. There’s no getting it done with that until you’ve reduced the scope of ‘it’.


Just don't take it as far as Boeing did.


Is it time for "That's what Boeing said" already?


Reacting solely to the headline, no.

"We're never going to find an energy better than coal, so just go down in those mines and go earn your living like a real man!"

Critical thinking is an extremely important skill, always, forever. Not impulsivity.


This is a difficult decision in science. If you are too perfectionist you will fail. If you are not, then your contributions can be bullshit. However, there is no such thing as a perfect experiment (at least in cognitive sciences), so we depend on converging evidence, so pretending it can be perfect is procrastination.


I think many people and teams (myself included) have pretty poor self-knowledge. You should aim to create the best product you’re capable of. Most people either over or under estimate that, and they’re left either never delivering, or spending the rest of their lives complaining about technical debt.


Non-paywalled link, anyone? NYtimes won’t let me read it in Firefox’s Private Mode.


Use the temporary account containers plug-in. Also very useful for software testing.


Firefox Focus works flawlessly


It's blocked as "Browsing in Private Mode" for me on mobile.


Disable Javascript to circumvent the paywall


That worked, thanks! In Chrome, I was able to use "Site Settings" to disable JavaScript for [*.]nytimes.com for the current incognito session only. [TLDR: Voltaire was right, perfect is the enemy of good.]


"le mieux est l'ennemi du bien." is wrongly translated into "perfect is the enemy of good". The correct translation is "the better is the enemy of good". Totally different meaning IMO. I understand it as the new "better" will eventually replace the existing "good".


Do you have a citation for that? Wikipedia disagrees on the history (it's originally Italian before French: "Il meglio è l'inimico del bene"), and playing with Google Translate shows its ambiguious without context

http://go/wiki/Perfect_is_the_enemy_of_good

https://www.google.com/search?q=le+mieux+translation


Unfortunately, I don't speak Italian, but I feel a better translation for "the best" in French is "le meilleur". In fact, if you just click the swapping icon in the Google translation link you posted above, you'll see it uses "meilleur". "c'est mieux" = "it's better", "c'est mieux que..." = "it's better than..."


“Il meglio è nemico del bene”


Paywalled but, I guess the headline contains all the actionable insight already




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: