Hacker News new | past | comments | ask | show | jobs | submit login
Writer's Block, or the Wantrepreneur Blues (indiehackers.com)
88 points by fazkan on Sept 11, 2017 | hide | past | favorite | 51 comments



Quit your job. Make it real. Fear is one of the best motivators.

Unfortunately this is bad advice for most people, because the truth is most people don't have the full skillset required to own a business. Maybe they could learn it if they apprenticed under an entrepreneur or in an executive role, but I'm honestly not sure.

I own a business with studios in New Orleans and Atlanta, but I worked in the real world, went to grad school, and then came out and immediately went out on my own which is easier for a lot of reasons.

I also think a series of fortunate and somewhat unreproduceable events led me here, strangely enough involving Gabe Newell, though I'm sure he wouldn't remember.

I honestly don't think reading a bunch of books telling you how to be an entrepreneur are helpful or real at all. In fact I would describe them as more of a stalling tactic.


> most people don't have the full skillset required to own a business

i agree with your post but i never miss an opportunity to be pedantic -- reality is nobody has the full skillset to run a business -- in my mind it's really just a bunch of intangibles like vision (goal setting), determination, ability to take staggering amounts of abuse, ability to work insanely hard when it's necessary, and ability to know how to hire an expert in matters you are not skilled or experienced in, which means the ability to clearly communicate and know what to ask for through deductive reasoning.

most people have NONE of those skills, because working a normal job doesn't require any of them. zero, zip, nada, zilch. a high functioning professional has like 2 or 3 of those things. i would guess less than 5% of the general US population has those characteristics in the large amounts required to start a business from scratch, and most of the time that talent is channeled into something like e.g. investment banking or corporate law or being a surgeon.

on top of all that, the ability to take a financial and social risk is just too much to handle for most people. they just won't do it. period. you might as well ask them to sprout wings and fly.

but that's why starting a business has the potential to be so god damn lucrative -- basically, nobody else is doing it relative to the demand the overall economy generates.

i also agree that the only way you're really going to get anywhere is if you quit your job, or were fired. the slow drip of a paycheck is the biggest obstacle.


  financial and social risk is just too much to handle for most people. they just won't do it.

  nobody else is doing it 
People tend not to try because they cannot embrace the intermediate feeling of "I f*ing suck at this."

When you embrace that you are not very good, you become the master. It is a tautology.


I feel like that's the step I'm on, and I really hope you are right.


> Slow drip of a paycheck haha that's brutal

Yeah I wish I could quit my day job of working in a restaurant, drives me insane the yelling/ego bs I have to deal with. Granted I'm not "better than them" sucks can't escape reality. Got a "great gig" relatively where I am actually getting paid hourly as a contractor getting paid the same (less actually with regard to taxes) to my restaurant job.

I think it's funny as an intermediate developer I have no idea what business to make/run yet there are people that can do these "marketing/subscription" things "call to action button" and they just need some site and some theme/template to do it, some coding Joe like myself to change something and boom they're raking in some monthly recurring revenue haha.

Speaking through experience working on UpWork

edit: the rates matter and having a product matters, there are fixed amount of hours in a day and even working somewhere "that you like" if the rates aren't great it still doesn't make you a lot of money.


I agree with you. I came close to doing that a few years back. I still hold on to that product idea, because I still think it's great. I took 6 weeks off and told myself I'd work on the project for a while, full time.

I got so much done, but honestly, probably not the right work. I wrote a ton of code, got the site up and running, and started working on the real nuts and bolts that would make the thing great. Hit a snag, and realized that I had no income, no partner, no publicity, and 6 digits of student loans to pay back. Golden Handcuffs, as it were.

I probably should have started with gauging interest, finding some help, and maybe looking for potential investors. But I'm a software engineer....coder's gonna code. I didn't know how to do any of that other stuff, but I can sure as hell write a program.

I'll probably buckle down on my next idea. Or the one after that. But one of these will go well.


This is bad advice for most people because, regardless of business skillsets, these kinds of one-sized-fits-all prescriptions don't take into account human diversity.

Fear is a terrible motivator for many people: rather than providing a productive boost of energy as it does for some, for others it provides an unhelpful dose of anxiety and negative stress which is at best counterproductive.


If you are crippled by fear owning your own business is probably a terrible idea.


Or one could start a business part-time and only switch to it full-time when/if things are going well... which is what the Warby Parker founders did and now they are either CEOs of or are on the board of a unicorn start-up.


You have to take risks owning a business. Even when your business is big you have to do scary, risky things.

Making almost any product or expanding your business involves large upfront costs and then hoping it is profitable. When you look at CEOs you think its all rainbows but I assure you it is not.


I also disagree with some of the points in the Original Post. We need a balanced risk profile (Adam Grants Original).

But I would also say that there is no one size fits all solution to this. There is no checklist, which if followed guarantees success. On the other hand, the same reasoning goes for not following a checklist at all.. Its like balancing intuition vs logic.

Atleast thats what I think for now, based on the limited experiences that I have had. I might change my mind later..:)


That is a tempting idea but health insurance can be cripplingly expensive when not on an employer's plan, and with the uncertainty surrounding the US healthcare system right now, sometimes it just doesn't make sense.


There's a really simple gimmick I use to get myself to do work. Set timer on phone for 20 or 30 minutes. Until the timer goes off, I won't intentionally engage in any distractions, just my project. When the time is up, I'm free to go do something else if I want. Sometimes I will stop working. Many times I will have got engaged by whatever I was doing and will keep going for a few more hours.

Even if I stop, 20 minutes of undistracted work is actually pretty significant, so it's win/win


The pomodoro technique is very useful. Check out the app Forest, it's kind of a cool app for this technique.


I have done a ton of successful side projects, one of them even turned into a great and growing business for me.

As a former musician the concept of jamming seemed like a great way to think about side projects.

In other words in my experience the best you can do is not even think about your side projects as projects (as the require process) but rather as jam-sessions.

Hopefully you have hundreds of little ideas to explore not just one (if you have that one big idea you should probably turn it into a real business, quick your job and maybe get funding)

The worst thing you can do is to worry about process (buy domain name, spend time on logo etc)


This sir, is the ultimate rule for following up side projects. I think this even applies to life in general ( Only in life's case its more like jazz music, you are improvising all the time, enjoying the process)


Very insightful. Jam session also sounds better, less like work and more like fun. Easier to justify (to yourself and to others) if it doesn’t go anywhere, and less pressure.


Yes Side projects should normally be measured by you don't want to go to bed because you want to do just one more thing rather than you can't go to bed because you need to finish some thing. It should be purely driven by desire.


Jeez, I wish I could verbalize things like this because they are so insightful. Thanks for that. It makes sense, but I'd never think to phrase it like that, and hence it doesn't seem apparent that's what I want in my side projects. But the abstract gut feeling is essentially that.


Step 14: Find out in a couple years that someone else took the same idea to fruition and succeeded.

When that happens I'm sad that I didn't fully pursue it, but happy that someone did.


Back in high school I had an idea for a video game that I really wanted to make, but didn't because I was focusing on learning to program instead. That was probably the right decision, because that time investment I made during those years has really paid off for me.

The game was a two-genre mashup between two very different genres, that I thought I could pull off blending together. (I still kind of think it could be done, whether or not I still think I could do it alone is a different story...)

A few years ago, someone came up with exactly the same genre mashup, and in fact the main character looked extremely close to what I had in my notes.

I was thrilled about it because I didn't just want to make it, I wanted to play it. Someone else did the work and took the risk of making it for me, and I get to fork over a few dollars and play it myself! Sure I wanted to be the one to make it, but if it existed at all that was huge.

I'm a millennial, so the first thing I did was go look it up on YouTube. And what I saw was incredibly disappointing, didn't do any of the things I was hoping it would, and frankly I didn't even bother to go buy it and play for myself. It didn't look like it had that fun factor, and it didn't do either genre justice.

Still makes me sad, and if I were to go into game development as more than a hobby, doing that game right is top of my list.


In games ideas are almost never original. I used to work with a designer who said if you think what you are doing is new you probably haven't been paying enough attention. But ideas matter very little and execution is golden. So I wouldn't worry too much if someone tried your idea.


I build things and throw them away all the time. Great to try out an idea or new technology.

Often I'll leverage the knowledge into a client project or proposal.

I don't get mad because I could never take all the things and build them into their own companies, and someone who made it successful also made 100 decisions along the way that I might have made differently.


The key is to reduce the friction of getting features out on the open web and getting feedback from real users. have just one generic domain that can be repurposed to any idea. Attach it to a static ip on aws do or up cloud as an example. Use a rad framework like rails django or laravel and launch a permanent hello world by pushing to github. Now find a small group of users that have a problem you can solve. Spend an hour a night adding a page to your site and gather feedback. Rinse and repeat. The key is to have a basic ci/cd pipeline setup at the outset. Then iterating on ideas becomes much more easy.


Forgot to list:

"Tell your friends about your brilliant ideas."


I'm at the point where I don't do that any more, to avoid the shame of being asked about it later and having to admit I haven't worked on it in months. Some people say they find having others know about it to be a motivator, but that hasn't been true for me.


I don't tell others either. Not right away. Telling someone is almost as good as it being finished. You have gotten that sweet social reward and pat on the head for being clever.

If I don't show anyone until it's real in some way then I have to make it happen if I want that sweet social head pat. Obviously that's not the reason I do things but I do find telling people can undermine my motiviation a bit.


Serious question for those in software development, Have you ever had a debugger/problem solver's block? how do you get over it?


It happens all the time. Usually, you get past it by taking a break. I can't count the number of times I've solved the problem I've been stuck on all week while showering or driving to work. Sometimes you just need your brain to slow down and stop over thinking everything.


I’d just add that enough sleep is paramount. It’s happened that I made no progress on a problem late in the evening, and then easily solved it the next morning. Or worse, that I made some progress in the evening, and then realized in the morning that a much more elegant solution is possible.

It’s not the same as what the article is describing though, because debugging and problem solving skills automatically get better with experience, and through the course of normal work.


I have kind of the reverse reason for not telling people: they just kind of shrug and ask "how is that different from ________?" I explain how it's fundamentally nothing alike and how my approach solves some really hard problem, but it's too late: the second-guessing myself has started.

Much better to build an MVP before ever mentioning it. Maybe they'll still shrug, but happens a lot less often.

I've also tried to stop buying domain names and instead just putting them all on a personal website.

But when I find that awesome name that is still available, I'm powerless to resist buying (I tell myself it's an "investment".)


I think you replied to the wrong parent comment?


Sure enough.


I've been stumped countless times. It can be demoralizing at times, but I've always found a way through. Some things that help:

- Break the problem down into smaller pieces. Analyze/Attack each piece.

- Try to attack the problem from a different angle.

- Step back, explain the problem to someone. Sometimes just explaining yourself helps highlight your assumptions, and can help you re-arrange your approach.

- Keep at it. Keep trying different things.


I totally agree with this, the bug catching block, occurs because we are not sure if catching this bug will solve our problem at all.

Also this helped me a lot in making things dirtier, use some form of version control system (must). I cannot emphasize more on this. this is to bring you back to the original problem state, which is most cases is simpler than you think.


It seems that as I am getting more experienced (older :) its easier to think about all possible things that can go wrong and build up a bigger than necessary model of the problem. Cant recall how many times the problem turned out to be smaller than I originally thought it'd be.


- Keep trying to fix it. Keep going.

- Go through, line by line, testing your assumptions about what the code should do.

- Re-read all the documentation about any libraries you're using, do you really understand what that function is doing?

- Ask someone else to look at the code (if there is someone), often they can see obvious errors that you're brain is now bypassing.


>Ask someone else to look at the code...

Yeah this, sad as it may be getting external help or another perspective is a possible solution.

I thought I had to figure out this recursion and someone's like "You don't need recursion at all..." Oh...

Stack Overflow (have a lot of banned accounts), Reddit... sucks making an ass of myself but I get over the block


As someone who's been told my several people my debugging skills are impressive, I reflected on this a little bit and here what seems to work for me :

1) know your debugging tools. IMO this is imperative, as you're going to set probably thousands of breakpoints over your career, and use the continue/step functions millions of times. I personally use the eclipse integrated debugger. The "back-in-time" debuggers have proven too slow for the kind of product I work with.

2) Try to find a case that does the right thing. It's always useful to be able to compare 2 use cases, even though it might be a bit overloading at times. It might also help you understand what works and what doesn't, reducing the potential target area. And it'll give you a test case. Too many people write the test case after having "fixed" the bug, but end up using either a test case that was working to begin with.

3) make assumptions. Don't dig into every function on the code path. Step over a function, knowing what result you'd expect if the function was doing the right thing and what you'd expect if it was doing the wrong thing. If it's doing neither of these, either you don't understand the function/product as well as you thought or the previous developer didn't help you. If it's doing what you believe is the right thing, don't worry about that function. Move on.

4) Don't go for the long winding code path. If there's 2 ways a function could fail, you might want to go down the easiest to prove/disprove rather than the most likely to fail. If you can prove the bug is in the small path, you're basically done. If you can prove it's not, then you can start going down the rabbit hole. If you can't prove either way, maybe try to assume the bug is further down the execution path.

5) keep track of your previous assumptions. I like the eclipse debugger because I can see all my breakpoints at once, even when they span files. I can also deactivate some without losing their location. Sometimes, you'll have to go back to your previous assumptions, either because they were wrong or because your brain is trying to process too much information.

6) that brings me to something that saved me so many times : Don't hesitate to restart from scratch. It'll never be really from scratch. When going through the metal process again, you'll remember why you mad that assumption, you'll see paths that seemed curious but that you ignored. You might be able to cleanup a lot of the breakpoints you deactivated but didn't delete. None of that is wasted time

7) take a breath. Sometimes, I physically feel odd. A ball in my chest, my head goes heavy, I have some sort of anxiety attack. I've decided to think all those are just a sign my brain is getting overwhelmed. Take a breath, get some water, take a short walk, and go back to 6. You might have made a wrong assumption, or you're just trying to keep too much data in your brain. Just restart and get back to where you were again. Usually you'll be much faster the 2nd time than the 1st time, and faster the 3rd time, etc.

8) if you find a solution that's like "if value is one specific value, then return", you're probably on the right path but you're not fixing the whole thing. Which means you or someone else will be doing exactly what you did. If it's you, you'll just get frustrated. If it's someone else, they'll probably do a worse job than you, or hate you for your hack, or just add one more hack to yours. Dont start the nasty if statement. Sometimes it's what you need to do, but that's pretty rare in my experience.

9) if a sudden idea sounds completely absurd, unrelated to the current code path at end, or stupid but is overly easy to test, drop everything and do test that idea. Because you still have all your breakpoints visible, restarting from scratch won't be that long, but the stupid idea might save you a lot of time. An example from no later than yesterday : After debugging something that seemed impossible, we realized we were simply not connecting to the right database. Stupid to no point, but super easy to test and gave us the right answer right there. Feel free to laugh at yourself, but don't blame/shame yourself or the person you're helping. Just tease them/you a bit and move on.

10) don't hesitate to debug using printf. I know it's frowned upon in certain circles, but if a specific line is being hit hundreds of time by your smallest test case, hitting "step" or "continue" every time will prove too long. I personally print something along the lines of "MOLYSS 10a : this is what I'm doing and here's the value of the variable I'm interested in : ". No one else in the entire company should be printing anything starting with MOLYSS, so it's super easy to grep my logs for it. If you think a code path is very unlikely, just put "WTF" in your printf output, so you know you need to understand why you're printing it in the first place.

11) know what a race condition is. Learning to recognize one when you see one has saved me many times. These are often extremely hard to prove, but fixing them might just be about adding a dependency or a synchronized block.

12) feel free to be proud when you found something. No one will pat your back, so you got to do it yourself. It's one of these skills that few people see but that are crucial and that can make you the person to go to for tricky/urgent issues. And when Sev0 always end up on your plate not because you're responsible for the bug but because you're the most reliable around, it gets noticed.

I'm probably missing a few things, but I think if you can do all that, you'll probably be better and faster at debugging than many people around you


I like the triad he breaks it down into. Here's the tricks I try to get over missing one leg of the tripod:

    > Energy and Direction, No Time
I have a wife, kids, pets and work full time so this is my default state. Things that help:

1. Get off my damn phone / reddit / twitter / whatever. Consuming media on the Internet is junk food for the attention span. I have had way too many evenings after I get the kids in bed where I think, "I'll just unwind on my phone for a few minutes and then work on something." The next thing I know, it's three hours later, every animated GIF and cute kitten link on Reddit is purple, and I'm filled with regret.

I trying now to break my habit of consuming stuff on the web. It's ultimately not satisfying. A little news-reading is important, but any more than fifteen minutes a day or so is wasted.

This frees up an astonishing amount of time.

2. Get better at working on things in small pieces. I'm writing a book right now that's projected to be about 200,000 words. It builds up two implementations of the same programming language, and each implementation is spread across multiple chapters, so the book is highly intertwined.

You might expect that to require a ton of mental state and lot writing sessions to work on. Nope. I usually work on it less than an hour a day (which, granted, means it's going to take forever to finish). I rely on a test suite, Git, a log, and notes to myself to make it easier to pause and resume work on it and break it down into small pieces.

3. Decide what not to spend time on. Our natural tendency is to want to say yes to things -- new projects, new hobbies, new outings, new toys to play with. But since time is finite, each of those means cutting out something that's already in my life. I try to be more cognizant of that and proactively choose to not invest time in things I don't want to be doing right now even if I would like to.

    > Direction and Time, No Energy
For me, this is usually laziness or analysis paralysis. Some amount of laziness is OK -- nothing wrong with some chilling and self-care. Relaxing feels good, but I find it doesn't feel as good as the satisfaction of accomplishing something, so I try to remember that.

Analysis paralysis is my personal demon. I try to remember that anything is generally a more productive path than getting stuck and doing nothing. If I'm stuck because I don't have enough information to pick a path, walking down one path is a great way to get that information, even if it requires some backtracking later.

    > Energy and Time, No Direction
For me, this is usually analysis paralysis at a larger scale. The kids are finally out of the house and I've got four hours of free time. What project should I work on? Oh, God, I can't pick. Again, I try to force myself to pick something because any choice is better than no choice.

I don't personally often have the vague "I don't know what I want to do at all" problem I hear a lot from bloggers. I think many of those are coming from people who want to be a certain thing (author, entrepreneur, successful open source project lead, etc.) and don't want to do a certain thing (edit paragraphs, make sales cold calls, reply to bug reports for five hours).

They want the reward of the cachet associated with the identity but either don't want to or don't know how to do the work to get that. Personally, I'm generally more motivated by the process than the product, so I don't fall into that trap very often. I don't have enough self-discipline to spend time on things when I don't enjoy the basic mechanical process of it.


> I have had way too many evenings after I get the kids in bed where I think, "I'll just unwind on my phone for a few minutes and then work on something."

There's a hack for this which I find works, just go to sleep at 8pm or 8:30pm instead right after the kids. Wake up at 4pm-4:30pm (yes I need a full 8 hours every night, not negotiable), you'll have much more willpower to tackle your side project in the morning before your kids wake up.

Given the choice between reddit and side project, reddit will win. Given the choice between reddit and sleep...it's much easier to pick sleep even if reddit is more tempting.

In the morning you have 2 choices, reddit vs side project but you just invested effort in waking up at 4:30am, side project it is...

Edit: I actually see sleep as a precondition of productivity so sleeping is a 'productive activity' for me.


> eddy_chan 1 hour ago | parent | on: Writer's Block, or the Wantrepreneur Blues

> I have had way too many evenings after I get the kids in bed where I think, "I'll just unwind on my phone for a few minutes and then work on something." There's a hack for this which I find works, just go to sleep at 8pm or 8:30pm instead right after the kids. Wake up at 4pm-4:30pm (yes I need a full 8 hours every night, not negotiable), you'll have much more willpower to tackle your side project in the morning before your kids wake up. Given the choice between reddit and side project, reddit will win. Given the choice between reddit and sleep...it's much easier to pick sleep even if reddit is more tempting.

That's a great way of thinking about it.

p.s I think you mean 4am.


> Wake up at 4pm-4:30pm (yes I need a full 8 hours every night, not negotiable), you'll have much more willpower to tackle your side project in the morning before your kids wake up.

This is the exact tactic used by a friend studying PhD with five young kids. She got the PhD in four years.

Also if you do a lot of manual labour - gardening, stacking shelves whatever - sleep becomes the obvious choice.


> There's a hack for this which I find works, just go to sleep at 8pm or 8:30pm instead right after the kids.

Yes!

I'm not consistent at remembering to do that, but fairly often I'll crash super early as soon as the kids are in bed. I get up at 6:00am specifically to give me an hour or so of me/project time in the morning. I could probably get up a little earlier, but it's hard.

The downside is that it means sacrificing evening time with my wife, which is also critical. And I try to exercise twice a week, usually in the evenings. And I work on my book every day, so if I didn't get any writing done in the morning, I have to stay up after the kids are in bed to do that.


That last bit... I completely agree with. Innovation is driven by emotion. In my case, it is usually frustration that the thing I wish existed that doesn't yet exist. I then make it for myself. I write a patent application for it and it's granted, but I don't make enough money to pay the maintenence fees. I do the project and it's successful, but I can't pay for advertising or whatever to keep it afloat for the few years it would take for it to gain enough traction with enough people. Or I get people to agree to a service trade and they don't up hold their end of the bargain which is sometimes video recording and editing, sometimes assisting, and sometimes other things I don't have the resources to do myself. I think doers without money are trapped in a cycle too.

I don't understand writer's block—or at least I didn't until I read your last couple of paragraphs. I'd never thought of that problem before and I appreciate your laying it out so clearly. I do think it is important to enjoy the basic mechanical process of creative whatevers, especially if those whatevers are business ideas. As an artist, I generally think of an idea as great if it is one that is not justified by the labor it takes to produce it. These ideas are what art is all about for me. Take an Andy Warhol or a Sol LeWitt or a Peter Halley... or any filmmaker who has a crew for example... they have the great idea and hire others to execute. Others are inspired to execute because your idea is great or because they are in great need of cash. Either way. I don't know how this works in business, but I thought I'd offer another perspective in the interest of sharing and learning. Thanks for your comment. It made me think about why someone would want to be a fill-in-the-blank enough to try to go through these motions and fail because they just want the identity. But then there is a solution there-- those people need to think about why they want that identity, and if in fact, that identity is actually desirable and why. I think their answer and a tweak and motivation might be found there.


"3. Buy a domain name (this step is crucial)"

Fantastic


This part is easy for me. I have a ton of dead domain names. The rule that if you have skin in the game or money in the game, then you'd be motivated to complete the task. That doesn't work for me. Maybe for a little bit. But essentially stuff like this is a sale technique.


It's easy for everyone. The "this part is crucial" was sarcasm :)


Ah, I didn't read the article. Probably should have done that.


> Energy and Time, No Direction

I tend to just buy one of the books I have on my list and dive into that. Then I don't need direction, I just keep turning pages and take notes.


I gotta say, I just bulldoze through and get the damn software built at great personal cost in a whole range of ways. I always complete the project.

The hardest thing is not writing the code - although that is extremely hard - the hardest thing is building something people want to use.




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

Search: