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.
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.
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.
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.
Best wishes GP.
Edit: point really being: it’s mild burnout until it’s not.
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.
Or Hacker News...
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.
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.
- 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)
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.
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)
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.
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.
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.
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.
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!)
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.
Different industries, different problems, different solutions = different definitions of what an MVP will and can be.
Most of this entire discussion is useless.
You can even make it so that players can't reach the end of level 1 before you've completed level 2 :)
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.
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.
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.
I'm not 100% on SaaS. Need something more fine-tuned. Call it SaaSGile.
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.
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.
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.
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.
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.
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.
> 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.
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"?
(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.
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?
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 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).
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?
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.)
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.
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.
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...
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.
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.
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.
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.
So how many mechanical watches do you folks recognize? ;)
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.
Woz: "Look we can do this better just give me some time."
Steve: "Ok fine."
Woz: "Hey we can also-"
Steve: "Damn it Woz no we need to sell a thing already!"
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.
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.
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.
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_.
"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."
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.
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)
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.
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.
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
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.
>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
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’.
"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.