So, I wanted to ask the HN community: have you ever done that? how do you deal with self-doubt? Thank you!
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.
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.
... 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...
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.
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 think it's very important though, that you learn to accept criticism. Learning from constructive criticism is key to improving.
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).
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.
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 also remind myself that lawyers have no trouble at all billing clients for research into areas of law that they are unfamiliar with.
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.
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.
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.