Ask HN: As a programmer do you have ups and downs and periods of intense doubt?

187 points by Madawar ↗ HN
Hi all,

Am a developer based in Africa and have developed small applications for the company I work for an airline ground handling company and have also created apps for sale on codecanyon.

Am a competent programmer not necessarily a good one but am able to get things done when under pressure, For example I made the codecanyon application at a previous job as an intern when we were required to comply with certain ISO regulations within a month. I did it as I had no way out. It has earned me approximately 250USD per month which in Africa is enough to pay rent but not be self employed.

The problem comes when I need to do something that I am 100% responsible for. For example create a SaaS app. The usual process goes like this Have an idea, Get excited, come up with all kinds of cool/new features that look marketable/useful, sometimes I go to the extent of buying a domain, when it reaches to implementation I get this crippling doubt on whether what am creating will sell/will be a profitable SaaS application. I am simple crippled by the fear of failure and abandon my wonderful idea. As a result I have numerous half baked personal projects. This projects do have their advantages as I discover new ways to do things that are very beneficial to my work projects but for my personal projects and personal life they are a dead end.

Do any of you experience this, do you just push it to the back of your mind and push on forward or is it just that am a coward?

62 comments

[ 5.0 ms ] story [ 120 ms ] thread
You're not a coward, you're facing the doubt that everyone else does. However, it is unhealthy to think that the SaaS you dreamed up will be successful, when so many others have failed...that realization that you've had, that there are advantages to undertaking projects that fail...that's worth holding on too...as while you may not frequently succeed at first, you can still keep learning the skills from building the failures that will be needed for a success.

Also worth realizing that the success of a project is not based purely on hard work and skill. A great amount of luck is involved.

Keep going.

If you build something and it fails, the experience you gain will be valuable - and a failed project is more valuable than an abandoned project - so even if you fail, you'll be in a better position you are in now! :D

Self doubt is normal - it's part of the creative process. But use it to be critical of your own work, but in a constructive way.

If the work seems daunting, remember the words of Dori on finding Nemo - Just keep swimming. How do you eat an elephant? One bite at a time!

One fundamental feature of programming (development, software engineering, whatever the name), is that you have to face the unknown.

If you already knew what problems lie ahead and their solution, you would already have programmed it, and then what use would it be to rewrite the program? Just re-use the previously written code!

So by definition, what you will develop, will be a program solving a problem with unknown dimensions and solution. You start by writing the code for the known parts, but while doing that, you have to live with the fear of the unknown that lies beyond the next procedure.

Performing specifications and analysis phases is a way to deal with this fear of the unknown, by drawing a coarse map. But often it's not possible to precise the map much better than labelling "Here be dragons" ahead (or worse, to hide the dragons with reassuring words, like Module X, or Component Y).

So be courrageous, plow ahead, and you'll be lucky, when you'll get close, you'll see that what you thought to be dragons was just a hill, and you'll find a solution to climb or circumvent it.

What you need to learn however, is how to deal with the complexity that emerges from discovering problems and solutions as you go: then you have to step back a little, and find simplifying abstractions, to refactor the work done so far, to get a simplier solution englobing all the problems seen so far, (and hopefully that will be found in the future).

In "Code Complete", the Steve McConnell describes that as the wicked problem of software development.
From my previous experiences one man show is very difficult. Especially if you dream big and have high goals (e.g. monetization, startup idea etc.).

I am now trying to involve at least one person to all my side projects. Even for small projects. There is great problem solving attitude - Divide-and-conquer.

If you can split problem to smaller parts , you can involve some other passionate friends who can participate and help you.

>> From my previous experiences one man show is very difficult. Especially if you dream big and have high goals (e.g. monetization, startup idea etc.).

It's been my experience as well. Pretty sad to recognize the limits to what you can accomplish alone. Sad but necessary.

True, but I think it force us to focus and put limits in time and features.

A solution can be to outsource : hire contractors to make all that is not your core project (ex design, content...).

Yes, as a dev you can do everything, but not with limited ressources (your time and money are precious!)

Especially time is most valuable resource. As you said outsourcing is solution. Almost all areas are so developed that is not in power of one man to be an expert in all of them.

When results are desired and there are deadlines, i cant afford wasting of time with trail-and-error approach for example with gui design. Even its interesting area.

This is also called opportunity cost. Famous footbal player will not cut his lawn even he knows how to do it (besides he dont wanna do it). He focus on more important things. And this important things helps him earn more money and outsource other things. And (sadly) money is root of everything.

After few years i have found out that dealing with issues during side projects increase my value in my proffesional life. I have experiences what can go wrong, where can be possible bottlenecks, which issues are just warnings (almost nobody is interested in) and which one are errors and have impact to business. This helps me a lot to take better jobs and contracts.

Sometimes you can't outsource. If it's a small personal project and you can't pay anyone to work for you. It it doesn't smell like a hot startup, nobody's going to be attracted by equity either.
Sure. You are absolutely right. If its personal project for fun or learning and there is no one (except of) you waiting for results then outsourcing has no sense.

I was talking mainly about projects with commercial intentions.

Yes, I've had similar periods of doubt when considering ideas for my personal projects, though never to the extent you've been experiencing.

In general, doubt is a healthy thing. It allows you to weight the decision and the consequences before blindly jumping in and possibly making a terminal error. Without doubt as a balancing mechanism, humans would be acting on a rush and we would be living in anarchy and chaos.

That said, however, there is a limit as to what you should allow your doubts to do. Speaking of your personal projects, it is normal to have an idea, initially consider it great, get excited about it, then in a few days sometimes weeks/months to cool down with regard to it. This is in principle the necessary process. You need to let your ideas prove themselves before you act on them.

But then when you're convinced this is a solid idea, which has a potential for market acceptance and the real need it can satisfy, then it's time to put your doubts in the back drawer and decide whether you go with it or not. The idea may be great but too big for you alone to handle it, in which case you start to look for outside help. If it's small enough and you can pull it off alone, then do it. In the past I had ideas I began to work on to realize later their scope was beyond my abilities to complete them so I stopped them unfinished. I choose not to think about them as failures, but as painful but valuable lessons which taught me things I otherwise would never have learned. Then in the future I would not make those kinds of errors in judgement again.

Fear of failure is also a cultural thing. Certain cultures are very much averse to risk taking and failing where the society looks down on those who tried something unconventional and did not succeed. I don't know if it applies to your situation, only you can tell, but at least you should be aware that this may potentially be affecting your perception of reality.

No one starts a software project with an official warranty letter from some authority stating that it will work. You simply recognize its potential, you believe in it and that should be enough to keep you going. That's how the mind of an entrepreneur works.

Of course. Because we spend most of our time fixing our own bugs, no other profession confronts someone with their limitations and shortcoming as much as computer programming does.

But a cheesy pop-culture reference rings true here:

Q. "Can a man be brave when he is afraid?" A. "That is the only time a m an can be brave." -Game of Thrones.

Getting excited, coming up with features, buying domains, feeling doubt, questioning my sanity... I consider these all normal stages of product development.

Try thinking of them as road signs. They indicate you are getting closer to your destination. If any of these road signs are amiss, then start worrying (and check your pulse to make sure you're still alive).

> This projects do have their advantages as I discover new ways to do things that are very beneficial to my work projects but for my personal projects and personal life they are a dead end.

Absolutely I experience this and I expect most programmers have a few half baked or in-progress projects laying around.

You are focusing on the wrong aspect (the half done part) and not on the very beneficial part - learning for future projects. Keep those half done projects organized and in version control so that you can come back to them later. Better yet, license them all as BSD and put them in a public repo. Then if you need them for work 1) they can't be exclusively co-opted by a company even if they are used there (after all you built them on your own time) and 2) others can learn and contribute.

If you are definitely not coming back to them be sure to tag them as abandonware so people aren't expecting bug fixes.

As everyone else has said - the doubt is normal. My advice would be to try and strip the product into parts more & tackle them one by one.

Creating a total product end to end in one go, that's scary. Creating a user model, easy. Creating an authentication level on that model, easy. And so on. Take it one step at a time.

Yes and it is normal. It is very hard sometimes and you need to push through that. I abandoned lot of projects in the past because of this: now I push on and usually things work put actually as long as you persist.
> As a result I have numerous half baked personal projects.

Every decent developer has dozens of half-baked personal projects. Some get finished, some don't. All eventually get abandoned.

They are never a waste.

If you go through your codebase, you will find that you re-use code and techniques that you learned on your next project. This is how we learn.

I second this! I have never done a project that I fully regretted or gone to a job wishing I had stayed at a previous job. While I have gone to a job that I hated almost immediately, I still didn't see returning to the previous job as a viable option.

Every new venture I take, I feel I couldn't have done without the accumulation of all my past experiences (both professional and nonprofessional).

Where you are is also a function of where you've been, which can be hard as the human mind sometimes likes to dwell on regret.

The root problem with the SaaS project example is that you should be aware that, in general, many people are involved in projects like this. If you want to push it alone it is obvious that the number of tasks will be much bigger than when you are an employee. This kind of projects require a different approach and if possible one or more collaborators.
What you're experiencing is entirely human, and I would venture all developers experience this at given points, unless they are just working through a queue of bugs in a backlog tracker or some such. Now, being a software engineer, I'm not really interested in working harder or just telling myself to get over it. I'd rather use software and a process to hack my own behavior to keep pushing forward. Here is how I've had a little success with this.

For a given product, I have a Trello board that tracks the entire machine I am trying to create. (A business is a machine that accepts money and/or time as inputs and outputs a sufficiently interesting amount of more money: the profit.) I'll have lists like Lead Generation, Conversions, Upsells, and Churns. Every project I want to work on within the product needs to fit into one of those lists; it's an easy way to remind myself to not build or work on things that don't matter.

Within the lists I have cards for initiatives. These are the projects I would assign to an executive if I had a team of VPs. For example, "Launch ZenDesk with help articles."

Within the cards I have checklists of specific milestones or tasks. "Sign up for ZenDesk." "Add CNAME."

When I don't have much energy after a full day's work, I can look at my cards and find something I do have the energy to take care of. When I'm wide awake and excited after a good night's sleep, I can add more tasks or initiatives to the Trello board, but the lists help ensure the initiatives are actually pushing the business forward.

Finally, I'd look for projects within your product that make sense to open source. One, that makes the projects easier to use on future projects; two, you can show them off when trying to get work in the future; and three, it gives you a really nice sense of satisfaction and a milestone you can point to along the way of building your product.

The thing you're describing is not unique to developers.

What I do is just forget about the potential consequences of failure (OR success) and just make the thing. If it works and takes off, great. If not, oh well, at least I spent time doing something I love.

(comment deleted)
I'd argue what you are experiencing is not fear of failure but fear of success. Steven Pressfield wrote a fantastic book that addresses the problem you describe called "The War of Art". I highly recommend it to read, it will show you at least what you are feeling is very human and can be overcome.
I spent about a year alone building a fairly complex server tool. Some days were great. Many were hard. I'm 40 now, and have enough experience with myself and software that I got it done and enjoyed almost all of it. Here some things that worked for me.

* Kept the initial push of code very simple, and doing something useful from day one. The software needed to always "work" so that I could be adding features, tuning or bug fixing. If it wasn't working, I was UNHAPPY.

* Tried to ship every day

* Which meant I was disciplined about drilling features down into coding efforts of about a day.

* I kept a notes.txt file, and wrote down any ideas and thoughts; features would get drilled down into component steps, and I would work through them one by one.

* I resisted all urges to 'rewrite the whole codebase', this would have kept me from having working code for weeks, an absolute no go.

Overall, I'm happy with what I (and later a friend) built. It took discipline, but the discipline is just there so that I could do mostly the fun stuff -- build something new that people thought couldn't be built.

The worst two weeks for me were a terrible bug-hunting expedition that ended with filing a compiler bug. I was tetchy and annoyed the entire time. For me at least, I like having working code that does something useful. :)

> The worst two weeks for me were a terrible bug-hunting expedition that ended with filing a compiler bug.

That actually sounds like incredible fun to me. :) And you likely did end up with useful code after the experience, just not in the project you intended to work on. ;)

haha. Or just a reminder not to use go tip.

It was satisfying to fix, very satisfying. But probably not the two week build up.

Never surrender. I could write more here, about my startups which are less than successfull and I keep trying, other optimistic bullshit. This is all crap, just never surrender.
I think your fear is good ! It forces you to test the business, not the techno.

Have you checked the leanstartup and customer dev methods ?

The goal is to quick test and fail your assumptions.

Because you need true users to continue your project.

Fake it before you make it ! ;)

Failure can be very valuable experience.

You might fail at making money / market share but gaining the experience of how and why you failed is very valuable information.

Failure is great business knowledge it makes you wiser and dealing with it makes you stronger.

If you don't fail a few times you might make an avoidable error on the next app, which could have succeeded.

Just don't take it personally, learn from it and grow as an entrepreneur - sometimes the time is just not right.

Maybe you'll pivot and only discover a winning formula by failing at your initial idea.

By taking something forward you will encounter others on a similar journey, your professional network is a very valuable asset.

Fail fast; fail often. Only then will you be truly ready to win when the right idea and right moment coincide.

Yes, it's perfectly normal. If you can, find a programming buddy. That will help you across these humps far more quickly than you can do on your own, in fact you may no longer even notice them.

Fear of failure is best dealt with by successful delivery.

A story from the dark ages (pre-internet).

I'd landed a contract to pioneer the automated digitization of passport photographs and the printing of those photographs on credit cards. Unfortunately, this project was way above my skills at the time and every day I regretted taking the job. But, day-by-day my knowledge grew and at some point I started to see a way out. In the end it took almost two years from start to working prototype scanner / printer but my self-doubt was dealt with on the day the customer took delivery of the first machine. As long as you are making progress (even if it is slow) you'll get there, if you give up then that's the end of the line.

So don't give up, just keep plugging away at it. And if you can, find that buddy. It's more fun that way anyway.

This is normal. I'm feeling it right now with what I want to do.

In my heart and mind, I _know_ I can do it, but then the doubts and fears rush in. I totally understand the feeling you're going through.

I just finished _Art & Fear_ by David Bayles and Ted Orland which is a fantastic book about creating stuff. Nearly all the advice applies to software developers.

Don't give up.

Success isn't binary either.

Release your project (Some success!). Make some sales (More success!). Market your project to get more sales (Success!).

You probably won't get fuck you money on the first day, but with enough marketing, maybe you'll be able to quit your job within the first year.

You pretty much nailed it on the head. Fear of Failure. Why exactly are you afraid of failing? Who are you worried about being embarrassed to? This is what you really need to work out, because who cares if you "fail", at least you tried, and the beauty with programming projects is that you learned along the way.

You need to stop worrying about it being a success, and instead concentrate on making as good a product as you can, for your own education and pride. Imagine you are going to submit this along with your next job application instead. You want to showcase your programming abilities, not in your abilities as an entrepreneur. Change the focus of WHY you are starting this project, maybe even assume that it won't be used at all except to show any potential employers what you can do.

For me, lots of failure, some moderate success, hang in there. You always learn from anything you do
Definitely I have similar fears and a harddrive full of half-finished code, so you're not alone. Some of it I feel is just natural creative process. Famous painters like Monet often painted over canvases and didn't finish work - we know the masterpieces, but the process is dirtier and less organized than we imagine sometimes.

One thing that comes to mind as an antidote is to market-test your ideas before writing much/any code. This has the benefit of helping you prove the idea without wasting time on it, AND get you a group of people waiting for your thing so that you can be motivated to finish it. If you read some of these entrepreneurial bloggers (Pat Flynn, Tim Ferris, etc), they talk about this in detail better than I could. Depending on what the idea is, go to forums related to the topic and get some credibility by helping people. Then ask around about your idea or pitch it as "coming soon". (Don't be dishonest and say it's built when it's not). Set up a quick MailChimp or SurveyMonkey form, blog, etc. to start a discussion around your product and get an core group of interested potential customers. Try not to be biased one way or another - if there's a market and you think it could earn an income with reasonable effort do it. If not, don't.

Now, why have I done that and _still_ not finished this idea....