I found it confusing. Article says "Do the work" but gave 2 choices for the friend: "What’s the priority? Writing software for future use cases, or finding an assembler to build the signs for him?" If the friend wants to grow the project into a business, this is a false dichotomy. The friend should be doing both: adding value to his project by doing what he does best (enhance the product offering) as well as delegating jobs that someone else can do (find a builder). Either choice is "doing the work". Also, the friend has to be able to walk and chew gum at the same time if he wants to expand.
I took his advice haha. I have 300 fully packaged signs to pick up this week. Excited to fix the supply chain issues and start shipping end of the week.
Last year, I forced myself to release something every two weeks -- even if it wasn't finished or was just a poorly-written blog post. I can proudly say it was one of the most productive years of my life[1]. Most of those projects won't see the light of day -- no one will care and no one will notice -- but releasing is far better than endless planning.
And just to really hit it home: this year I built Lofi (a small Spotify player replacement[2]) and I shared it on reddit[3] (and on HN). But if you read most of the posts, it's a whole bunch of angry people arguing about Electron sucking, about why the app is 100mb, about how C++ and Qt would be better, etc. etc. The difference between me and those people? I'm already working on my next project ;)
If so, that makes 2 of us. I re-read the post, and he talks about releasing something on a regular basis. I don't see anything about then going back and unpublishing things once he decides it actually isn't good enough? Sorry if there are edits in play or I'm just missing something, but it sure looks to me like broken links should still be surprising.
Great piece.
Last year, I forced myself to release something every two weeks
Out of habit I tend to check the comments here before reading the article, and um... I did a serious double-take between the title and your opening sentence. For about a second I just stopped and stared at the phrase, “even if it wasn’t finished” and just thought, “Wow... here’s a guy with high standards!”
Anyway, then I read on, sighed, chuckled, and read the (very good) blog post.
The title mentions masturbation and the top commenter said they forced themself to release something, which could be read as an euphemism for masturbation.
Well I guess it's not everyday you see "Masturbation" in a HN #1 post's title and the sentence "I forced myself to release something every two weeks" in the first top comment.
Awesome! Does Lofi work on Linux? It would be a fantastic addition to my i3 setup (and the main Spotify player can go nowhere near as small as I want it!)
Someone actually built it on Linux[1] but there's a few bugs that need to be addressed (mostly dealing with graphics/transparency issues) before it's ready for prime time.
I'm confused that so many people on this site seem to be working on ancient weak sauce computers. The difference between a 1mb and 100mb app today is nil. I run Slack, vscode, and tons of other apps. Even if they take few gigs of RAM each, there's 62 more where that came from. They all run just fine.
It's like a forum full of carpenters that are using Black and Decker tools to build houses.
Most of us are running other, more important shit that takes up RAM, like an IDE for my code and DB, plus some shells, text editors, etc. If we can get the less important shit to run faster, it would be a win.
Your desktop isn't magic either. Ever run a benchmark with slack turned on versus off? Try it out sometime. You'll be amazed.
> I run Slack, vscode, and tons of other apps. Even if they take few gigs of RAM each, there's 62 more where that came from
Okay, and if your apps used sane amounts of resources, then you could do that on <$1000 of hardware - or even <$100 on a Pi or used machine. Sure, on a programmer's budget/salary it's okay to buy expensive hardware, but it still adds up, and you shouldn't need it.
> It's like a forum full of carpenters that are using Black and Decker tools to build houses.
In that analogy the end result is the same, but the process to get there more complicated. In reality, the difference is between a house that has stuff like insulation and faucets that don't leak, versus than something slapped together in 5 minutes for $50 that costs 50 times more to live in, for as long as you live in it.
It's less effort for the programmer, more effort for every machine it gets run on, every time it gets run. And that stuff compounds in non-linear ways, too: The more data has to be read from disks, the more useless the disk cache becomes, the more data has to be shuffled around in RAM, the more useless the CPU cache becomes. Using gigantic frameworks for programs that use 0.1% of them, which still set up and maybe even poll for all sorts of stuff, not knowing it's not needed, is not "wrong" (certainly not ever when it's open source), but it's more wasteful for what it achieves.
I just checked, and my Directory Opus with 3 windows open, one of them having 2 panes, and all the custom buttons etc. is taking up 100 MB of memory. The list of features is huge. Another thing I have to think of is audio software. Sure, there's also VST that come with gigantic bitmaps or whatever, but generally, efficiency is king. They know their code doesn't run in a vacuum and they are dealing with customers (even when talking about free software) who pay keen attention to such things, to a degree unheard of and unstrived for here.
Sometimes I wish we could just completely freeze hardware development for 20 or more years (if it wasn't for improvements in energy efficiency) just to be forced to become better at programming again. Just look what in 2015 could be done with a machine from 1981: https://www.youtube.com/watch?v=hNRO7lno_DM ... What could we actually do with our current hardware? Who even knows?
Sure, we could optimize the heck out of everything. But at what cost? There is a reason many developers rail against premature optimization. It would cost much more and development would progress much slower. Hardware is cheap. Developer time, not so much.
Hardware isn't cheap, certainly not multiplied by millions of instances. It's just that you don't have to pay for it. But someone down the road will, be it other people or future generations.
You're also confusing premature optimization with skillfull use of resources. Not driving a car with the handbrake on isn't premature optimization.
That's the thing isn't it? People are always so sure that the one they could have built but didn't is so much better than the one you could build and did. Except for that one tiny detail of not actually existing.
So true. I remember a few years ago when I built Game:ref[1], everyone on reddit was an eSports anti-cheat expert. Right now, they're all Qt/C++ experts. It comes and goes in waves ;)
Just would like to offer a joke and a quote from the music world. The joke is, How many guitar players does it take to screw in a light bulb? And the answer is, 10: 1 to do it, and 9 to stand around saying how they could've done it better.
The quote is from Ian MacKaye: "The best records are the ones that get made."
A stirring speech, and a good reminder to press on, and to press for results (just be careful not to reference it as an excuse to dismiss constructive criticism, or to play a martyr).
This is good advice, will read the article now. Just checked out lofi, looks really great actually! Been looking for a minimalistic spotify visualiser / interface for my linux htpc.
I'm glad that not every programmer follows your example and spews out a new piece of half-baked, buggy, bloated software every fortnight. I don't know why you feel superior about the fact that you don't like executing projects to a high standard.
It's pretty easy to insult someone anonymously online. This is why I actually make a point of having my real identity connected to my HN (and reddit) account.
But let me just say this: after I built Lofi and got more hate than I would've imagined for what was really a throwaway project, a great dread came over me. What if I was new at programming? What if I was just a college or high school kid learning how to use Electron because I simply didn't know C++ or Java or what-have-you? I know that if I got this much hate in my teens or early 20s, it would've discouraged me tremendously from pursuing startups, programming, and building. I really hope you realize that your words can deeply affect people. I have thick skin, went to an elite school, wrote a book, I'm arrogant af, and couldn't give a damn about what you have to say, dear anonymous HN commenter....
...however, keep in mind that you might be negatively impacting an impressionable young person; or an underprivileged minority; or a total newbie. I hate the term "safe space" but we should all fight to keep HN as close to a Miltonian "marketplace of ideas" as possible.
Your arrogance was evident in your original comment, and as such, I felt no qualms about expressing my disapproval of your attitude towards shipping software. You're right - if you had come across less cocksure, I wouldn't have left a comment.
Arrogance? I saw no such thing. Maybe jealousy about his attitude to projects.
I introduced a friend of mine to programming. He picked up pyret and released a cool little game with it. Instead of the community encouraging him, they shit on his code. Called it ugly, and pointed out a lot of nothings.
Consequently, the dude quit programming. He now considers it something the smart ones do. He agrees with me when I say those haters don't matter. But, the spark's dead.
I'm not saying we shouldn't give feedback. But feedback is different from nagging, complaints and bullying. A good way to give feedback correctly is the sandwich method.
Specific Praise -> specific critique-> specific praise.
>I know that if I got this much hate in my teens or early 20s, it would've discouraged me tremendously from pursuing startups, programming, and building.
I would like to think that such personal attacks would be downvoted/flagged into oblivion here.
How do you find motivation to continue working on a bunch of things that don't pan out?
Most of a what I code in my free time is 'useless'. Project Euler and the like.
When I think of building something and actually releasing it, my immediate impulse is that no one would use it so it'd be a waste of time. It bothers me a bit.
> What have you done to market it?
Nothing, because...
> Who is your primary user? What pain does it solve?
I don't know :D
I guess it helps them with the pain of sounding shitty on video calls, by telling them how to improve.
I don't see a market for it at the moment because the problem it solves is so incremental.
I was actually looking for something similar to this recently. Very first thing you need to do is fix your title and description tags for SEO. Second, contact some sites where this product might be useful for their users.
But, i don't want anyone getting the wrong idea. The vast majority of stuff released on the web these days, never ever sees any users at all. You'll be lucky if your web server even gets hit by actual users a couple times a week. and the vast majority that do, will churn.
> Most of a what I code in my free time is 'useless'. Project Euler and the like.
The key question is why are you writing code in your free time? Entertainment? Profit? Personal Development?
I'd rather write code to solve an interesting thing that is entertaining to me than to work on things that nobody (including me) will use. Because I'd only do it as entertainment.
Drew Houston's Show HN post (Dropbox) that, you guessed it, got a ton of hate (on HN of all places). I don't believe for one second that money brings happiness, but a decade later, Drew's the one laughing all the way to the bank :)
"But if you read most of the posts, it's a whole bunch of angry people arguing about Electron sucking, about why the app is 100mb, about how C++ and Qt would be better, etc. etc. The difference between me and those people? I'm already working on my next project ;)"
This is a typical style of web app development that is rightfully criticized: the average web developer thinks it's okay to offload their performance problems on everyone else as long as they reach their personal or company goals.
Pumping out many unsupported, mediocre projects isn't something to brag about either.
I think they mean that for the most part developers spend their time complaining instead of doing.
In the end, someone can always rewrite something that's successful to fix performance issues, but what's the point of making something performant (or focusing heavily on architecture) before you even know people want your product? Performance matters to a degree (after all, performance is a feature), but the product matters the most.
The point is professional pride and the "engineering" in software engineering.
Which can admittedly get in the way of half-assing a start-up into life... and that's why many devs are not good business men. That's a feature, assuming we don't want all our sw to be complete crap.
> the average web developer thinks it's okay to offload their performance problems on everyone else as long as they reach their personal or company goals.
Why is it not okay? He solved his problems under his requirement, if it doesn't solve your problem under your requirement, it's not his fault and he isn't forced to follow your requirement.
> Pumping out many unsupported,
Why you consider that bad? He is learning, he is building, he is solving issues. The fact that he keep doing this is bad? I only see positive in that...
I'm pretty sure it's supported as much as he need them to be. He is his only client. I'm pretty sure too that if anyone wanted theses projects to be supported, he would gladly accept to be hired by them with a compensation worth his time.
I just saw that he was even generous enough to give his source code, with a MIT license on top of that!
> mediocre projects
That's just means and uncalled for. You should really think more over this issue you seems to have.
* the software was released/published and the author's idea about what are the minimum requirements that should be fulfilled by any and all software apparently doesn't include efficient use of system resources (Electron) or at least some minimum support (many projects already gone, moved to the "next project", bragging about quantity).
* they are learning and building but they're learning bad practices which they'll naturally continue to make use of, if they will developing software professionally or already are. Perfect practice makes perfect, this doesn't.
I have thought about this issue for years. There is no overabundance of quality software in the world, the opposite is true. If every simple open source project is praised just for the very simple and frankly nowadays fashionable act of offering the sources, no wonder.
As Steve jobs said, ( that guy was genius regarding seeing understanding thing so completely that he can explained it in really simple terms ) , "Real Artist delivers"
For people turned off by the title: "Future You Masturbation gives you the pleasure of all your future accomplishments with none of the work. It’s your brain tricking you into something that feels good today in exchange for lost meaning and purpose and accomplishment in the future."
It actually sounds a lot like the concept of not telling people about dieting or whatever long-term task you're engaging in due to the dopamine rush from telling people rather than accomplishing things.
Maybe the friend just doesn't want to make a Serious Business out of this yet, maybe he just enjoys having this side project. Maybe he's still refining the physical design of these signs along with the software with every one he builds. Maybe he's got enough sources of chaos and craziness in his life already from work/family/the hairbrained schemes of his buddy Trevor and he just wants a nice little hobby where he can fiddle around. Maybe he just does not need a Side Hustle in his life right now.
Maybe this is just what he's playing with instead of putting together model kits, y'know?
It's quite possible to get lost in the weeds planning stuff with no forwards motion. It's also possible to make really, really expensive mistakes by plowing forwards. I've done both of those. There is an alternate reality where the friend has been looking for people to make this thing fast and cheap, and is now sitting on a pile of these things that he can't sell at a price point that will break even, much less make a profit, with an order of magnitude more money than he is comfortable losing sunk into them. And maybe that reality's Trevor just wrote a blog post talking about how this friend should have done their research first, what kind of idiot doesn't do their research?
I'm not saying forging ahead is always bad. I've done it a lot in the past. Sometimes it's worked out, sometimes it hasn't. And when it doesn't work out it is a shitload of hassle and stress and I can only take so much of that at once.
> I've done both of those. There is an alternate reality where the friend has been looking for people to make this thing fast and cheap, and is now sitting on a pile of these things that he can't sell at a price point that will break even, much less make a profit, with an order of magnitude more money than he is comfortable losing sunk into them.
Been there, done that.
"Customers" that love the product, at the price point of the raw materials.
Charges that come at you from nowhere because you didn't hire an import agent that knows widget X has anti-dumping duties attached to it for the next six months.
Warehouses that look good until it rains and then your whole stock is ruined. This one was actually the best thing that could happen, because between the insurance and accounting the business finally broke even and I walked away from it.
Hardware is different to software. It's all downside all the way. The only thing I learned is that you should do the most pessimistic accounting you possibly can for sales and manufacture and then divide the first by 10 and multiple the second by 10 and you will be right for what will happen in the first year.
> It's quite possible to get lost in the weeds planning stuff with no forwards motion. It's also possible to make really, really expensive mistakes by plowing forwards.
An excellent point which is often omitted in such articles. Finding the right balance between careful planning and plowing forwards is of great pertinence. I look at planning as a risk minimization exercise. Once risks associated with failure are minimized, I can then forge ahead. Hence, the time planning is a function of the project's risk profile, which can vary drastically.
I think the friend making signs is a bad example - he is actually doing something, having fun and making money. The reason he is not modifying his business plan is likely more complex than "building a tower of research"
However, the overall point of the article is still meaningful, it's something I find myself doing a lot - plan and think about a project but not actually getting started in any meaningful way. Obviously some amount of research and planning is necessary for everything, but doing that endlessly is the problem being described.
I noticed many people doing the same thing with "to do"/"to read" lists. They'll add items to their lists thinking they'll get around to doing them some day, not realizing that future me is probably just as lazy as present me, and if I were going to do something, I would have done it now.
So, todo lists become a bit of intellectual masturbation in the sense of "oh I'm not putting this off, I'm definitely going to do it, since it's on my todo list!"
I have on my todo list (see the irony) to build a mobile todo list app where tasks will disappear if not finished in a while, along with some other bells and whistles (they'll all move to another screen where you can't remove them and they'll mock you for ever), mostly as an art piece on this exact phenomenon rather than a useful app.
I found maintaining a TODO list was helpful in seeing how fragmented my ideas were, which helped me to start actually doing things, because for one thing, I realized that I had forgotten most of my (fragmented and peculiar) ideas, and even more so, there were ideas that I found important most of the time I eyed the activities on my TODO list. Still, even without this insight, I'd say one asks himself quite often "What I should do now" in terms of reading/watching a movie/etc., and to answer that TODO list is honestly pretty helpful.
> I noticed many people doing the same thing with "to do"/"to read" lists. They'll add items to their lists thinking they'll get around to doing them some day, not realizing that future me is probably just as lazy as present me, and if I were going to do something, I would have done it now.
Guilty as charged. That said, the primary purpose of my "to read" list today is to short-circuit my procrastination loop; when I realize it's high time to get back to work, I'll quickly scroll through the remaining 20 open tabs, put some on my "toread" list, and close the others.
I have a couple things written on a post-it note. Sometimes I lose the note. Nothing bad happens. The really important stuff will either get done or find its way back to a post-it note.
I've found that todo lists only work if they're put in context of larger goals and you have a system to repeatedly, frequently pop() the top of the list. It's OK (and common!) to have a todo list of 100 things, as long as you give yourself time to think about prioritization of the tasks. Someone on here recommended "Work Clean" by Charnas. It's a little fluffy at the end, but he does provides a structure with which to place and schedule tasks that I found pretty useful called Daily Meeze. It's just meta-planning (plan/schedule 30 minutes out of every day to plan/schedule). Super simple, yet effective.
This is a useful way to handle tasks. It sounds like backlog grooming in scrum. It's nice to just write down the various ideas you get, regularly prioritize them, then grab a few of them per sprint to finish and deploy to prod at the end of that sprint.
Too bad your idea to build that app won't disappear :D
I've found a way to combat this. I assign a "due in" value to each of my todo items, from 1 week to 3 months. Then every week, I visit all the overdue items, do at least one step to push it further, then push it out according to its "due in" value.
So high priority items get more attention and nothing will be put off indefinitely.
When it comes to masturbation narrowly defined, most people now accept that it is not harmful or sinful. Nor is it a sign of a failed sex life. I believe that we should have the same attitude towards more general forms of self-gratification.
If this was a form of cancer I would be Stage 4 and getting my affairs in order.
So after years procrastinating on a book, doing research and taking notes but not publishing one word I started blogging. I’ve only written 4 blog posts and they get decent traffic. I was surprised. I’m trying to apply “do the work” to other areas too.
I wonder about this. Let's say I create a really good blog about some niche subject, but I don't promote it in any way, so that no one links to it or even knows about it. In such case, if no page on the Internet links to it, will it even by indexed by the Google Search?
I've been quite prone to this, and one thing that's helped is building systems vs. goals, per Scott Adams[1][2]. If you read many stories of successful people, you see a pattern in having habits or systems that were built at some point that lead to those successes, as opposed to setting a specific goal and trying to plan around that.
> Whether you have a Tesla in your brain or a Tesla in real life doesn’t make a difference in how happy you are.
This quote from the end of the article reminded me of the famous chimpanzee experiment where two chimps were hooked up to a brain scan, one was given a banana to enjoy the other just allowed to watch, but both seemed to have the same "pleasure zone" of the brain light up.
The article makes the assumption the creator's desire is to grow+grow it. It's only good advice is that's true, if the creator just wants to make some scratch, whilst scratching their own itch, then it wouldn't be good advice for said person.
I always wonder if people like Mark Zuckerberg or Elon Musk daydream of their ideal future like most of us seem to do. They definitely seem to act on their vision more, but do they daydream as much as the rest of us?
Acting on your vision is easier for people when they have access to large pools of money. I'm not sure about Mark but Elon seemed like an entrepreneur when I read about his early adulthood. Not an inventor, just someone who found ways to make money. Then when he became rich he became a visionary.
> Acting on your vision is easier for people when they have access to large pools of money.
This is a highly oversimplified vision. It's true that Elon has way more money at his disposal. But it's also true that he had the guts to put all of it on the line for his vision.
If I was that rich (after PayPal), I would put money on the side that I would never touch, and then try the business thing with the rest of it. I think most of us would do that, or even retire at that point.
Putting all your money on the line (and let's face it, if you have millions, you fall from higher than if you only have $100) really shows how dedicated you are to your vision.
That's why we are talking about Elon here, and not about you or me.
You don't see that as a risk because it's not an outcome that you object to. Many people would see that as failure and thus anything that might end up with that outcome is risky.
He is a huge risk taker, it is probably the reason he is rich now. All the people I know in my life who have the most wealth got there through risk and luck. It sucks because I know I am risk averse and I know I shouldn't be.
NOTE TO ALL: The use of the word "mas...bation" will automatically kill your comment. Might want to censor yourself, as silly (and understandable, in most contexts) as it is.
The use of the "mas...bation" word also automatically meant I will not forward the link to co-workers or friends. So the author lost many potential readers from it.
But it most eloquently describes the problem. We shouldn't have to self-censor to get passed some prudish filter on a corporate network on which the reader is probably already not supposed to be reading for fun.
Funny how you can read something, mostly agree and then see an example and nope right out of the whole idea because the example tells you the author has an entirely different set of what ‘valuable’ is, compared to you.
Maybe doing the ‘hard thing’ of jumping straight into action is good in some cases... but, mostly, it’s not.
Plan first. Act second. Evaluate third.
If you miss any of the steps, or get stuck at any of the steps you’re doing it wrong.
I contend the authors supposition that most people get stuck on step 1 is wrong.
Most people I know get stuck on step 2, and give up without trying to iterate on what they were trying to do, because they didn’t understand that maybe step 1 didn’t come up with a perfect plan the first time around.
Sure, maybe it’s cool to have a step 0, which is ‘try it right now!’ to give you some idea & experience on how to get started.
...but the basic contention I this article; “the best thing to do is just to do something right now”; is wrong, and most modern learning & self development frameworks will back that assertion.
Isn’t there some famous fallacy thing about this being how terrible political decisions are made?
Bingo. Why not plan? Also why not day dream sometimes? Some of the best days I've had are also one of when I pause to take a stock. Once I just took a notebook (physical) and went to a park. It was the best planning day, helping me set future direction for next 6 months. Also Bill Gates is(/was) famous for taking reading/thinking retreats.
Also your whole comment also summarizes my take on the article.
The human mind is not a business. Fantasizing about the future is actually integral to the functioning of the human mind. It builds neural pathways and releases dopamine that makes you feel good about your choice, motivating you to execute.
Without the fantasy, the reality would never come.
No the article is saying don't ever waste time fantasizing because it's the same as writing new features in code that no one will use. It specifically calls out things like buying workout clothes before you work out, or getting a new journal before you start journaling.
Maybe you missed the point of the article. The author is describing a common issue where people have lots of ideas, plan them out in their heads and get the reward in form of pleasure (anticipation of success, power, beauty, anything). They don't imagine or plan actually doing the work, they plan for wonderful outcomes. They never do what's necessary and become quite frustrated, not knowing why. There was even psychological research into this phenomenon if I recall correctly , and it yielded the somewhat surprising result that this is a strong habitual behavior and thus fairly hard to change.
Because the risk is that you will never start working out or never start journaling, so your purchase / planning was a waste. Adopt good habits before you invest in them.
As a programmer, I find "fantasizing" important, as in thinking ahead. I'm working on a program, and I do from time to time imagine my software being popular, widely-used in the future, etc.
I actually find it useful to, instead of immediately acting, sometimes take a bit of time to ask: how do I want my UI to look? How are people going to use this software? What are some typical use case scenarios? I've gained valuable insight by daydreaming a little bit, and not acting immediately.
IMO, you need a mixture of both some planning and also actively working on the project. You can get stuck in fantasies, design something overly complex that you think will solve all use cases (but actually does many things poorly instead of doing one thing well). You can also fantasize about a project so much that you get bored of the project before you even really get started.
> releases dopamine that makes you feel good about your choice, motivating you to execute.
Dopamine can be motivating, but over a threshold it's satisfying, which is essentially the opposite of motivating.
I think what's really being warned about is that if you dream too much it becomes satisfying. If you allow yourself to experience the pleasure of fantasising about your future, then you lose the motivation to actually realise that future. Instead of training your neural pathways to more effectively improve your circumstances, you train your neural pathways to get to that satisfaction quicker by simply imagining and believing you will have done so in the future.
I'd like to submit the possibility that in a lot of cases dopamine is doing its exact job (which seems to be ranking your brain's predictions and facilitating learning of patterns) -- if you are correctly able to predict with high confidence the outcome of whatever you are wanting to do, then you'll end up not wanting to do it anymore (because you'd learn nothing from it -- and because the pleasure from imagining doing it is just as real). The solution is to attempt harder stuff, things that you can't right now predict, where outcomes are still uncertain, things that might bring you suffering and not just pleasure.
Fuck myself, literally. This is me for the past 20 years. Imagining myself writing GPL licensed software, in Clojure, using Vim through an actual (not emulated) Linux terminal, for the domain I have the most knowledge, making millions.
:%s/Clojure/IDEALISTIC_LANGUAGE_OF_12_YEARS_AGO/g for older projects.
I tried so hard to use Emacs, the pinky pain is real :) I know about parinfer but, oddly, Vim has better tools for navigating through parens et al out of the box.
Reminds me of 2017. All I did was use C++ again for a year. I finished two personal projects and worked on an opensource project for a month. Every before that was as you described.
This piece and its ilk are the real click bait of HN. Nothing new or interesting said here, just another “fail fast and early” piece that misses the bigger picture: namely, that unless you just want to make money—which is cool—failing fast and early is not what everyone is about. Finding a markov chain to a product is definitely a way to get there, if you just want to find some product, any product, that will sell to somebody somewhere. But okay, I’ve read this piece a hundred times. I get it. Please stop writing it, or at least please stop upvoting it.
Maybe it's coincidence but IIRC there's some scientific literature that suggests simply imagining success can trigger similar reward pathways as actually achieving success.
This in turn may sap motivation. (Not sure if this consequence is part of the science.) The remedy according to some sources is to avoid imagining success or even the end state of your project. To maintain perseverance, try to stay focused on the most immediate problems and potential future hurdles.
> The remedy according to some sources is to avoid imagining success or even the end state of your project.
Is it really the remedy? I agree the problem you state is real, but how does this, or all other possible ways to keep your eyes on the prize, the “remedy”?
Growing up I was on a competitive swim team, and one of the exercises we did before meets was imagining the whole race, imagining how we would execute our performance from start to finish. You would imagine the start, how you feel fresh and easy, and then the middle, as you begin to feel yourself tire, and then the end, when you’re exhausted but then the reward of finishing. It’s about the whole race, I think, and day dreaming about the end doesn’t have to be so bad.
In the personal development/emotional healing technique I've most used in the past few years, this concept is called "living in the future" and it's most certainly been a deeply ingrained tendency for myself and others I know, and is critical to overcome for one to make tangible progress in life.
A personal development coach I know trained me to stop talking to others about the successful things I plan to do or expect to do, the theory being that the subconscious/unconscious mind can't tell the difference between talking about them and actually accomplishing them.
190 comments
[ 5.0 ms ] story [ 247 ms ] threadI took his advice haha. I have 300 fully packaged signs to pick up this week. Excited to fix the supply chain issues and start shipping end of the week.
Last year, I forced myself to release something every two weeks -- even if it wasn't finished or was just a poorly-written blog post. I can proudly say it was one of the most productive years of my life[1]. Most of those projects won't see the light of day -- no one will care and no one will notice -- but releasing is far better than endless planning.
And just to really hit it home: this year I built Lofi (a small Spotify player replacement[2]) and I shared it on reddit[3] (and on HN). But if you read most of the posts, it's a whole bunch of angry people arguing about Electron sucking, about why the app is 100mb, about how C++ and Qt would be better, etc. etc. The difference between me and those people? I'm already working on my next project ;)
[1] https://dvt.name/2019/01/06/retrospective-stuff-2018/
[2] https://www.lofi.rocks/
[3] https://old.reddit.com/r/programming/comments/aufj4m/lofi_a_...
Out of habit I tend to check the comments here before reading the article, and um... I did a serious double-take between the title and your opening sentence. For about a second I just stopped and stared at the phrase, “even if it wasn’t finished” and just thought, “Wow... here’s a guy with high standards!”
Anyway, then I read on, sighed, chuckled, and read the (very good) blog post.
[1] https://github.com/dvx/lofi/issues/6
It's like a forum full of carpenters that are using Black and Decker tools to build houses.
Your desktop isn't magic either. Ever run a benchmark with slack turned on versus off? Try it out sometime. You'll be amazed.
Or the sizable portion of end-users who won't or can't upgrade past 2G; it's a pain to do that on a modern system, but it does work.
Okay, and if your apps used sane amounts of resources, then you could do that on <$1000 of hardware - or even <$100 on a Pi or used machine. Sure, on a programmer's budget/salary it's okay to buy expensive hardware, but it still adds up, and you shouldn't need it.
In that analogy the end result is the same, but the process to get there more complicated. In reality, the difference is between a house that has stuff like insulation and faucets that don't leak, versus than something slapped together in 5 minutes for $50 that costs 50 times more to live in, for as long as you live in it.
It's less effort for the programmer, more effort for every machine it gets run on, every time it gets run. And that stuff compounds in non-linear ways, too: The more data has to be read from disks, the more useless the disk cache becomes, the more data has to be shuffled around in RAM, the more useless the CPU cache becomes. Using gigantic frameworks for programs that use 0.1% of them, which still set up and maybe even poll for all sorts of stuff, not knowing it's not needed, is not "wrong" (certainly not ever when it's open source), but it's more wasteful for what it achieves.
I just checked, and my Directory Opus with 3 windows open, one of them having 2 panes, and all the custom buttons etc. is taking up 100 MB of memory. The list of features is huge. Another thing I have to think of is audio software. Sure, there's also VST that come with gigantic bitmaps or whatever, but generally, efficiency is king. They know their code doesn't run in a vacuum and they are dealing with customers (even when talking about free software) who pay keen attention to such things, to a degree unheard of and unstrived for here.
Sometimes I wish we could just completely freeze hardware development for 20 or more years (if it wasn't for improvements in energy efficiency) just to be forced to become better at programming again. Just look what in 2015 could be done with a machine from 1981: https://www.youtube.com/watch?v=hNRO7lno_DM ... What could we actually do with our current hardware? Who even knows?
You're also confusing premature optimization with skillfull use of resources. Not driving a car with the handbrake on isn't premature optimization.
[1] https://www.pcgamer.com/introducing-gameref-the-anti-cheat-h...
Thank you for actually shipping.
Thank you for actually being positive.
Thank you for being brave enough to speak about your experience.
We need more people like you in the world.
If you're ever in LA, let's grab a coffee.
I wish ..
The quote is from Ian MacKaye: "The best records are the ones that get made."
A stirring speech, and a good reminder to press on, and to press for results (just be careful not to reference it as an excuse to dismiss constructive criticism, or to play a martyr).
But let me just say this: after I built Lofi and got more hate than I would've imagined for what was really a throwaway project, a great dread came over me. What if I was new at programming? What if I was just a college or high school kid learning how to use Electron because I simply didn't know C++ or Java or what-have-you? I know that if I got this much hate in my teens or early 20s, it would've discouraged me tremendously from pursuing startups, programming, and building. I really hope you realize that your words can deeply affect people. I have thick skin, went to an elite school, wrote a book, I'm arrogant af, and couldn't give a damn about what you have to say, dear anonymous HN commenter....
...however, keep in mind that you might be negatively impacting an impressionable young person; or an underprivileged minority; or a total newbie. I hate the term "safe space" but we should all fight to keep HN as close to a Miltonian "marketplace of ideas" as possible.
I introduced a friend of mine to programming. He picked up pyret and released a cool little game with it. Instead of the community encouraging him, they shit on his code. Called it ugly, and pointed out a lot of nothings.
Consequently, the dude quit programming. He now considers it something the smart ones do. He agrees with me when I say those haters don't matter. But, the spark's dead.
I'm not saying we shouldn't give feedback. But feedback is different from nagging, complaints and bullying. A good way to give feedback correctly is the sandwich method.
Specific Praise -> specific critique-> specific praise.
I would like to think that such personal attacks would be downvoted/flagged into oblivion here.
Most of a what I code in my free time is 'useless'. Project Euler and the like.
When I think of building something and actually releasing it, my immediate impulse is that no one would use it so it'd be a waste of time. It bothers me a bit.
I released voiceaudiocheck.com a month ago and haven’t seen a single user.
I guess it helps them with the pain of sounding shitty on video calls, by telling them how to improve. I don't see a market for it at the moment because the problem it solves is so incremental.
Damn, I had totally forgotten that that's a thing!
> Second, contact some sites where this product might be useful for their users.
Yes, I had planned that but then got distracted with other projects... :)
Its the cornerstone ideology of most failed startups.
But, i don't want anyone getting the wrong idea. The vast majority of stuff released on the web these days, never ever sees any users at all. You'll be lucky if your web server even gets hit by actual users a couple times a week. and the vast majority that do, will churn.
The key question is why are you writing code in your free time? Entertainment? Profit? Personal Development?
I'd rather write code to solve an interesting thing that is entertaining to me than to work on things that nobody (including me) will use. Because I'd only do it as entertainment.
Drew Houston's Show HN post (Dropbox) that, you guessed it, got a ton of hate (on HN of all places). I don't believe for one second that money brings happiness, but a decade later, Drew's the one laughing all the way to the bank :)
FWIW, KDE Plasma already has something similar to Lofi that I use daily https://i.imgur.com/uVAnf7p.png . Works out of the box :)
Under the hood it uses MPRIS to talk to the Spotify Linux app. So it works with all native music players, and even YouTube running in your browser! https://www.omgubuntu.co.uk/2018/05/kde-plasma-5-13-features...
This is a typical style of web app development that is rightfully criticized: the average web developer thinks it's okay to offload their performance problems on everyone else as long as they reach their personal or company goals.
Pumping out many unsupported, mediocre projects isn't something to brag about either.
In the end, someone can always rewrite something that's successful to fix performance issues, but what's the point of making something performant (or focusing heavily on architecture) before you even know people want your product? Performance matters to a degree (after all, performance is a feature), but the product matters the most.
Which can admittedly get in the way of half-assing a start-up into life... and that's why many devs are not good business men. That's a feature, assuming we don't want all our sw to be complete crap.
Why is it not okay? He solved his problems under his requirement, if it doesn't solve your problem under your requirement, it's not his fault and he isn't forced to follow your requirement.
> Pumping out many unsupported,
Why you consider that bad? He is learning, he is building, he is solving issues. The fact that he keep doing this is bad? I only see positive in that...
I'm pretty sure it's supported as much as he need them to be. He is his only client. I'm pretty sure too that if anyone wanted theses projects to be supported, he would gladly accept to be hired by them with a compensation worth his time.
I just saw that he was even generous enough to give his source code, with a MIT license on top of that!
> mediocre projects
That's just means and uncalled for. You should really think more over this issue you seems to have.
* the software was released/published and the author's idea about what are the minimum requirements that should be fulfilled by any and all software apparently doesn't include efficient use of system resources (Electron) or at least some minimum support (many projects already gone, moved to the "next project", bragging about quantity).
* they are learning and building but they're learning bad practices which they'll naturally continue to make use of, if they will developing software professionally or already are. Perfect practice makes perfect, this doesn't.
I have thought about this issue for years. There is no overabundance of quality software in the world, the opposite is true. If every simple open source project is praised just for the very simple and frankly nowadays fashionable act of offering the sources, no wonder.
It actually sounds a lot like the concept of not telling people about dieting or whatever long-term task you're engaging in due to the dopamine rush from telling people rather than accomplishing things.
https://youtu.be/0sHCQWjTrJ8
Maybe this is just what he's playing with instead of putting together model kits, y'know?
It's quite possible to get lost in the weeds planning stuff with no forwards motion. It's also possible to make really, really expensive mistakes by plowing forwards. I've done both of those. There is an alternate reality where the friend has been looking for people to make this thing fast and cheap, and is now sitting on a pile of these things that he can't sell at a price point that will break even, much less make a profit, with an order of magnitude more money than he is comfortable losing sunk into them. And maybe that reality's Trevor just wrote a blog post talking about how this friend should have done their research first, what kind of idiot doesn't do their research?
I'm not saying forging ahead is always bad. I've done it a lot in the past. Sometimes it's worked out, sometimes it hasn't. And when it doesn't work out it is a shitload of hassle and stress and I can only take so much of that at once.
Been there, done that.
"Customers" that love the product, at the price point of the raw materials.
Charges that come at you from nowhere because you didn't hire an import agent that knows widget X has anti-dumping duties attached to it for the next six months.
Warehouses that look good until it rains and then your whole stock is ruined. This one was actually the best thing that could happen, because between the insurance and accounting the business finally broke even and I walked away from it.
Hardware is different to software. It's all downside all the way. The only thing I learned is that you should do the most pessimistic accounting you possibly can for sales and manufacture and then divide the first by 10 and multiple the second by 10 and you will be right for what will happen in the first year.
An excellent point which is often omitted in such articles. Finding the right balance between careful planning and plowing forwards is of great pertinence. I look at planning as a risk minimization exercise. Once risks associated with failure are minimized, I can then forge ahead. Hence, the time planning is a function of the project's risk profile, which can vary drastically.
However, the overall point of the article is still meaningful, it's something I find myself doing a lot - plan and think about a project but not actually getting started in any meaningful way. Obviously some amount of research and planning is necessary for everything, but doing that endlessly is the problem being described.
So, todo lists become a bit of intellectual masturbation in the sense of "oh I'm not putting this off, I'm definitely going to do it, since it's on my todo list!"
I have on my todo list (see the irony) to build a mobile todo list app where tasks will disappear if not finished in a while, along with some other bells and whistles (they'll all move to another screen where you can't remove them and they'll mock you for ever), mostly as an art piece on this exact phenomenon rather than a useful app.
I heard of businessmen who as a rule of thumb delegate or delete tasks after not being able to start within 3 days.
So it is matter of your system how you use your todo list
Guilty as charged. That said, the primary purpose of my "to read" list today is to short-circuit my procrastination loop; when I realize it's high time to get back to work, I'll quickly scroll through the remaining 20 open tabs, put some on my "toread" list, and close the others.
I've found a way to combat this. I assign a "due in" value to each of my todo items, from 1 week to 3 months. Then every week, I visit all the overdue items, do at least one step to push it further, then push it out according to its "due in" value.
So high priority items get more attention and nothing will be put off indefinitely.
So after years procrastinating on a book, doing research and taking notes but not publishing one word I started blogging. I’ve only written 4 blog posts and they get decent traffic. I was surprised. I’m trying to apply “do the work” to other areas too.
Do you mind me asking how you are getting traffic? Are you writing on your own personal website or on something like Medium?
Probably not. To fix this problem, you create a sitemaps.xml on your server and then give Google/Yahoo/etc. the link to it.
https://support.google.com/webmasters/answer/156184?hl=en
Being dateable and actually finding people to date are two very different things.
I've been quite prone to this, and one thing that's helped is building systems vs. goals, per Scott Adams[1][2]. If you read many stories of successful people, you see a pattern in having habits or systems that were built at some point that lead to those successes, as opposed to setting a specific goal and trying to plan around that.
[1]https://blog.dilbert.com/2013/11/18/goals-vs-systems/
[2]https://outline.com/TGYvt2
This quote from the end of the article reminded me of the famous chimpanzee experiment where two chimps were hooked up to a brain scan, one was given a banana to enjoy the other just allowed to watch, but both seemed to have the same "pleasure zone" of the brain light up.
Your complaint seems to be that the use of a sexual metaphor affects the ethos of the speaker in the eyes of some.
That metaphor is part of the message, regardless of whether or not you like it.
Post so your creations. I’d like to offer my valuable input.
This is a highly oversimplified vision. It's true that Elon has way more money at his disposal. But it's also true that he had the guts to put all of it on the line for his vision.
If I was that rich (after PayPal), I would put money on the side that I would never touch, and then try the business thing with the rest of it. I think most of us would do that, or even retire at that point.
Putting all your money on the line (and let's face it, if you have millions, you fall from higher than if you only have $100) really shows how dedicated you are to your vision.
That's why we are talking about Elon here, and not about you or me.
> Put off the correct, hard work for the easier, less effective work?
What's correct? How does that not conflicts with "future you" problem?
You know that any one who is having the "future you problem" is also doing that while thinking that they taking the correct hard work approach, right?
It's just one of those idea where you can just rationalize whether something fits the philosophy.
Better for you? Or for them?
Funny how you can read something, mostly agree and then see an example and nope right out of the whole idea because the example tells you the author has an entirely different set of what ‘valuable’ is, compared to you.
Maybe doing the ‘hard thing’ of jumping straight into action is good in some cases... but, mostly, it’s not.
Plan first. Act second. Evaluate third.
If you miss any of the steps, or get stuck at any of the steps you’re doing it wrong.
I contend the authors supposition that most people get stuck on step 1 is wrong.
Most people I know get stuck on step 2, and give up without trying to iterate on what they were trying to do, because they didn’t understand that maybe step 1 didn’t come up with a perfect plan the first time around.
Sure, maybe it’s cool to have a step 0, which is ‘try it right now!’ to give you some idea & experience on how to get started.
...but the basic contention I this article; “the best thing to do is just to do something right now”; is wrong, and most modern learning & self development frameworks will back that assertion.
Isn’t there some famous fallacy thing about this being how terrible political decisions are made?
Bingo. Why not plan? Also why not day dream sometimes? Some of the best days I've had are also one of when I pause to take a stock. Once I just took a notebook (physical) and went to a park. It was the best planning day, helping me set future direction for next 6 months. Also Bill Gates is(/was) famous for taking reading/thinking retreats.
Also your whole comment also summarizes my take on the article.
Without the fantasy, the reality would never come.
The article is discussing fantasizing that does not result in action
I actually find it useful to, instead of immediately acting, sometimes take a bit of time to ask: how do I want my UI to look? How are people going to use this software? What are some typical use case scenarios? I've gained valuable insight by daydreaming a little bit, and not acting immediately.
IMO, you need a mixture of both some planning and also actively working on the project. You can get stuck in fantasies, design something overly complex that you think will solve all use cases (but actually does many things poorly instead of doing one thing well). You can also fantasize about a project so much that you get bored of the project before you even really get started.
Dopamine can be motivating, but over a threshold it's satisfying, which is essentially the opposite of motivating.
I think what's really being warned about is that if you dream too much it becomes satisfying. If you allow yourself to experience the pleasure of fantasising about your future, then you lose the motivation to actually realise that future. Instead of training your neural pathways to more effectively improve your circumstances, you train your neural pathways to get to that satisfaction quicker by simply imagining and believing you will have done so in the future.
:%s/Clojure/IDEALISTIC_LANGUAGE_OF_12_YEARS_AGO/g for older projects.
Ouch, shoudn't it be Emacs? /s
https://www.oreilly.com/library/view/whats-your-future/97816...
https://www.amazon.com/Whats-Your-Future-Worth-Decisions/dp/...
This in turn may sap motivation. (Not sure if this consequence is part of the science.) The remedy according to some sources is to avoid imagining success or even the end state of your project. To maintain perseverance, try to stay focused on the most immediate problems and potential future hurdles.
But regarding:
> The remedy according to some sources is to avoid imagining success or even the end state of your project.
Is it really the remedy? I agree the problem you state is real, but how does this, or all other possible ways to keep your eyes on the prize, the “remedy”?
Growing up I was on a competitive swim team, and one of the exercises we did before meets was imagining the whole race, imagining how we would execute our performance from start to finish. You would imagine the start, how you feel fresh and easy, and then the middle, as you begin to feel yourself tire, and then the end, when you’re exhausted but then the reward of finishing. It’s about the whole race, I think, and day dreaming about the end doesn’t have to be so bad.
A personal development coach I know trained me to stop talking to others about the successful things I plan to do or expect to do, the theory being that the subconscious/unconscious mind can't tell the difference between talking about them and actually accomplishing them.