Ask HN: Have you rejected an offer to work on a project because of self-doubt?

I've definitely had self doubt, and have turned down projects because of it. However, as I got more and more experience, I realized, I probably should have taken on those projects. The project owners (sometimes) would have been better off had I taken the project instead of them going with somebody unreliable who thought they new it all.

What I would suggest, which is pretty much what I did, is to take projects where you 1) feel like you can add more than just your code 2) pick projects you think you'll learn from, 3) pad your deadline significantly.

There is no shame in letting the project manager know that you want to take some extra time to make sure you're doing the best job, or getting the most benefit of learning from the project. If the project is with a larger company, maybe you can even get feedback from a more senior dev as you go along.

I had one contract with a larger company, where I really thought I was in over my head, and I thought their CTO would either give me helpful advice when he reviewed my code, or would dump all over it. He took a look at the code, and basically just said "yeah, looks fine", which didn't really help me at all. Looking back on that project only months later, I know I would have done it differently, but they were happy with the end result, and that is really the most important thing. Can you make them happy with what you can do, and can you grow from it.

I also think a bit of self-doubt is healthy, I think the sign of a bad developer is one who thinks they are at the top of their game.

I've been transparent about the lines between my competencies and what i know more in theory. For me that kind of granularity has kind of helped filter offers.but I'm still relatively new in terms of full time employment programming and don't have any institutional instruction to speak of.

What about thinking of it in terms of risk / reward. Say in the (unlikely case) you completely fail to deliver... does it matter? Are they paying you? Can you structure the project so that you can do lots of small iterations and continually give them something which is useful?

On the plus side if you pull it off, which is probably more likely if you've been coding for a couple of years and have side projects already, then you'll have a public project to your name, and you'll learn heaps just through the process.

As for how I personally deal with self doubt. Badly ;) have heaps of it and find giving advice far easier than taking my own. I mean you'll never know unless you try right, and the only way to get better is to try & fail & get better a bunch of times. One book you may enjoy (short read) is called mindset: http://www.amazon.com/Mindset-The-New-Psychology-Success/dp/...

Good luck, and I say give it a go.

I had once early on where i got in over my head. Once i realized it I told them about it. Wasn't fun, but I'm glad for the experience, I learned a lot on many levels.

> more than once I was approached by people who wanted me to help implement their projects. But I have always refused just because I think I'm not good enough. [...] have you ever done that?

Absolutely. I'd say that 90% of the time that I've been offered consulting work, I've turned it down because I know it would require some skills -- web design, graphics, SQL, linux, ruby, C++, etc. -- which I know I don't have.

I have a reputation for being very good at what I do, and it is certainly true that there are some things I am very good at... but a large part of that is that I don't do the things which I'm not very good at.

> how do you deal with self-doubt?

If you're a generalist, there's almost certainly going to be someone else who is a better generalist than you. If you specialize, it's not hard to find a niche in which you are one of the leading experts in the world -- because the group you're being compared against is losing the 99.9999% of people who never looked at that particular niche. So I'd recommend looking for a niche; because once you're the world's leading expert on something, it's pretty hard to doubt your competence in that area.

self doubt will destroy you.

Impostor syndrome? Most people I know are affected from it.

Sounds like classic imposter syndrome. I've dealt with it at times myself. The best cure I've found is taking on a tough task, breaking it down to more manageable chunks, and completing them. Even after completing some tough projects, I still feel the fear grip me. I took a new job recently that required working with an unfamiliar framework and design patterns. Early on, I kept running into road blocks and thought for sure that everyone would think I couldn't hack it. Turns out everyone was actually impressed that I was picking up on things quickly. Just because you perceive something, doesn't mean others perceive it the same way. Go for it, and ask for feedback early (just don't get too hurt if they have something negative/constructive to say. Remember you can't be perfect)

All the time. I do consider taking it on anyway and learning what I need as I go, even if I put in some "unbillable" time though. I usually look into it to see how hard I think it would be to learn what I need to. Over time, you get an intuition for how far in over your head you can go.

I also remind myself that lawyers have no trouble at all billing clients for research into areas of law that they are unfamiliar with.

This is why when you are learning - which is the rest of your life, btw - you want to try to get involved in projects with a small team of developers, and do your best to do things outside of your current scope.

There is not much time to learn outside of work, and learning from studying is not the same as learning from real production projects. Learn by working with people with other strengths, helping each other.

As for your direct question - yes, there is nothing at all wrong with turning down something if you are sure you understand the skills required, and that you genuinely are not experienced enough. Good idea, actually.

I think you have to distinguish reasonable self-doubt from unreasonable self-doubt. If you genuinely don't have the skills required to do a job, it's reasonable to doubt your capacity to do it. Perhaps ask a friend or tutor who is familiar with your skills to help determine whether you're up to a particular job?

I have considered not accepting every job I've had since graduating college 10 years ago for this exact reason, and I have ended up being one of the top performers at each of those jobs, which has led to better job opportunities, each of which I don't believe I'm qualified for.

One thing you have to accept is that you will never know everything, and that's okay. One of the most important skills you can have is the ability to communicate effectively. Customers and coworkers don't expect you to know everything, and when you tell them that you are weak in some area and want to have your expert friend/coworker assist because you want to make sure you get this completed correctly for them, they see you not as an expert on all things, but instead they see you as something much more valuable: someone who they can trust to get the job done correctly.

There is value in knowing your limitations. If you know you can't complete a job on your own, and you can't line up the right people to assist you, then it's a wise move to pass. Like the important/unimportant-urgent/nonurgent quadrants (from the 7 Habits book), there are the competent/incompetent-secure/insecure quadrants which let me say that I am completely incompetent when it comes to brain surgery, and I am not the least bit insecure about it. I am also very competent at my job, but ironically I am somewhat insecure about my ability to do that job.

I am a generalist in my field, and I think part of the tradeoff is, there are always people around me who know more than me in some areas, but in return, I always know I can get a new job in about a day. If you take the generalist path, it's important not to get into adversarial pissing matches with the specialists. Win them over as friends and it's of mutual benefit. As a generalist you have exposure to more opportunities, which you can throw their way, and they will be glad to help you when needed. And by "help you", I mean paying them to help you (usually).

I've programmed for 14 years and have 8 years of professional experience as a software engineer who is slowly entrenching in his niche -this is my personal philosophy to career management, ymmv:

What has worked for me in dealing with self doubt has been to separate my private self from my professional self when performing self evaluation. The professional self has a specific skillset with regards to the field, a specific capability to finish projects and specific market value. This is my public interface to the job market, my employer, and my co-employees when not at a coffee table, so to speak. I evaluate my situtation professionally with regards to this professional self. This creates certain detachment and alleviates emotional baggage (which I do have).

When figuring out where to professionally head next I evaluate this from the point of view of career risk and career opportunities. Projects are a one way to evolve your professional self, and they include opportunities as well as risks.

Given your situation, I would respectfully suggest a similar strategy in managing risk as with stocks. The risk of failure should come with some comparable advantage, and as you age, reduce the level of percieved risk. Be prepared to accept high risk projects early if they have some obvious percieved advantage to you.

The good part about risky projects is that if chosen correctly, they provide almost always the best benefit to you regardless of their outcome - experience.

There is good risk and bad risk, and you need to learn identify these. Bad risk is usually associated with some classical thedailywtf scenario with all the horrors of legacy software attached. Good risk is associated with scenarios that have some obvious advantage - i.e. usually learning new skills, making connections, and so on.

Reald world risky scenarios are usually a mix of these two.

Unless you are in a really precarious situation I would claim that professionally you are still in a situation where you professinal portfolio can endure quite a lot of risky situations. If you fail now you are just considered a bit wet behind the ears, a decade from now that would labeled as ineptitude.

Most of all, software engineering is a hands on craft. There more varied your experience, the better.

If you have self doubt in a perceived positive risk scenario I would advice you to dive in. But this is important - you must not give up, no matter what, you must finish the project. The result can be as hacky as necessary to fulfill you feature list (don't worry, as you gain experience you will find better ways to solve the specific feature) but it must become complete unless terminated by client. Strive for simple solutions.' Keep it simple stupid' should be your first approach in all scenarios.Complexity will happen any way, no reason why yoy should add any.

Do not burn yourself out. If you do not have the time for a project don't do it.

Like suggested, one way to make yourself a good career is to foster domain specialty in some niche that you perceive has long term traction. Specifically, what this might be, it's really hard to say. Generally, I would suggest to steer away from only specific vendor technologies towards either some abstract yet practical discipline (e.g. cryptography, computer graphics and so on) or a specific real world application domain (sensor software for heart rate monitors, for instance). Which is best for _you_ it is very hard to say.

Trying to find something that everybody around you is not doing and that sounds interesting would probably be a good start.

Declining projects for some perceived opportunity cost that is related to bad risk is a good choice.

How to find your niche? Hard to say-But as an example: The deeper you dig into some specific area, you start to identify the missing pieces , the gray areas and zones where there are lots of obtuse papers and dusty tomes but wikipedia seems strangely bereft of any practical advice despite your acute technical need. In this case you are doing so...

It depends how much they pay and how tight is the deadline. Actually most of the times I work on stuff I don't know but I want to learn.

Never. You should try it. Admit you don't have the skills when you tried out and failed. Or get the skills right in the moment when you need them. But NEVER say you don't have the skills for anything.

I don't know if this is really self doubt, but as a consultant I don't like to take on work in areas where I am not an expert.

I spend lots of my own time learning new technology, but I don't like to accept tasks when I have to spin up while billing time.

As someone else here pointed out, it is very nice to be well known in technology niches.

I didn't think I was good enough to do the backend so I applied for an internship doing something else. They later asked me to do the backend and I even taught some people a few things! Just go for it!

I got hired straight out of college to build a credit card processing system. I had NO idea what I was doing. I was copy/pasting code out of the Stevens Unix/Networking books and working 100 hours a week. This security flaw: http://seclists.org/bugtraq/1997/Nov/58 happened and I remember patching it and shipping a new version while the entire C level staff of a publicly traded company was standing behind my desk.

Yeah, it was stressful. I learned a lot though, not just from the coding under fire, but from that experience AND the aftermath (after the company tanked, you talk to the same C level guys and realize they appreciated the effort and many of them are good friends still).

I want to be coding and building stuff for the rest of my life. If you find it fun and enjoyable now, you'll always have people asking you to build stuff. And then the business side can take over (like... is this a good idea or not) but to be honest you don't even have to worry about that either, because it's not your problem. Code stuff, build stuff.