
Ask HN: Have you rejected an offer to work on a project because of self-doubt? - joeclef
Hi, I&#x27;m a third year CS student. I have been coding for a little over two years. I have worked on a few side projects. 
Recently,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&#x27;m not good enough.<p>So, I wanted to ask the HN community: have you ever done that? how do you deal with self-doubt? Thank you!
======
cperciva
> 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.

~~~
jpgvm
This so much.

While I love to learn new things I do so on my own time.

My clients only ever see the expert because I only ever agree to do things
that I know I can do better than almost anyone else they can hire.

This is in my opinion one of the most important things in building a
successful consulting reputation.

If you choose your niche well you will never need to look outside of it until
you have ramped up your skills for your next specialisation.

~~~
toyg
_> If you choose your niche well you will never need to look outside of it
until you have ramped up your skills for your next specialisation._

... or until your niche dies out. This is my situation at the moment: my niche
is very profitable but likely on its way out in a year or two. Related fields
are either very boring or much less profitable. If I had stuck to a more
generalist career, I'd have made less money for a few years, but maybe my
employment would have been a bit more secure in the long run.

Ah, the vagaries of IT life...

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

------
patrickdavey
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/...](http://www.amazon.com/Mindset-The-New-Psychology-
Success/dp/0345472322/)

Good luck, and I say give it a go.

~~~
ayrx
This exactly. It's good to have _some_ doubts but at the end of the day you
learn a lot by simply trying, regardless of success or failure.

I think it's very important though, that you learn to accept criticism.
Learning from constructive criticism is key to improving.

------
azurelogic
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)

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

------
owyn
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](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.

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

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

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

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

------
kmoe
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?

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

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

------
ovatsug25
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!

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

~~~
swartkrans
I think the resolution to impostor syndrome is to recognize that you have more
things to learn and to try to challenge yourself all the time, and also find a
mentor so you can get feedback. If you have a good team or a good manager you
should be able to get this kind of help. Your employer can only gain by you
getting better, and this kind of motivation for self-improvement is the best
kind of attitude to have. Even on the rare and off chance if it somehow turned
out you don't have the skills people thought you did, if you have this kind of
attitude, you should come out ok.

Also never be afraid of saying "I don't know" or "I don't understand". If
someone is explaining something to you, and they mention a concept you aren't
familiar with, have the courage to ask them to explain it to you. I have never
been criticized for saying "I don't know." In fact it builds trust,
credibility and confidence.

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

------
fsloth
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 something wrong or you have diacovered a
niche.

Try not to fall into a narrow and cushy niche that does not have market value.
The individuals who fall into these are called expert beginners. Learn to
separate these from the true experts early on, try not to become an expert
beginner and you are well set.

------
carucez
self doubt will destroy you.

