Writer's Block, or the Wantrepreneur Blues

> 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.

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.

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.

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..:)

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.

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

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.

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)

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.

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.

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.

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'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.

- 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.

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

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.

> 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.

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.