Technical Confidence

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/technical_confidence.htm]

I was talking to a friend about confidence with technical skills. Here's a brain dump of my thoughts:

Technical skills are good, but when working with people we need people-skills too, like confidence and leadership.

Knowledge + Experience will drive up confidence

Some people view confidence as a Darwinist "survival-of-the-fittest, no-one pushes me around", self-empowering ordeal. I think that's crap. Rather, I view confidence as a service to your coworkers - by being confident (and having the track-record to back it up), you can give you coworkers peace-of-mind as they know that you will solve the problem, and they don't need to worry about it.

What confidence is:

• Knowing what you know and acting it out
• Giving people the peace of mind that the buck stops with you. You can be confident even if you don't currently know the answer IF you know that you can figure out the answer, and no one else has to worry about it.

Confidence Is not:

• Arrogance
• Never admitting you're wrong
• Bluffing people

Ideas to practice confidence:

• Work on extracurricular projects that you care about. This gives you both experience and knowledge in a potentially new area. If you only do what is required at work, you'll be funneled into a very narrow skillset.
• List to yourself the reasons you should be confident in something, like (1) I know the material, (2) I've done this before, (3) I've run this idea past others
• During dead times (waiting in line, driving, walking) practice interview yourself. As yourself "what are ways to make a WebForm perform faster, how could I solve this testing problem, why is a DataReader better in this case than a DataTable, etc..."
• Teach & Publish - teaching others will make you more confident.
  • Writing your own blog
  • Writing online articles (anyone can submit articles to www.CodeProject.com)
  • Teaching a class, or just volunteering to provide free mentoring at a local college
  • Submit a component to the open-source community
• Look at leaders in the field and see what they're doing. For example, read MVP Scott Mitchell's online resume. Wow.
• Get connected with the community. This lets you know of new concepts and trends in your industry
  • Read other developer's blogs
  • Check out forums to see what common questions there are
  • Visit a user group
  • Try to attend a trade show, focus on meeting at least 1 speaker.
  • See the latest books out in the bookstore.
• When talking, give a direct answer, avoid space-filling "Um", "well", "maybe", "Perhaps", "I'm not sure of this, but...". Uncertainty is okay (it's actually inevitable given how much stuff is out there), but always follow it up with a certain action plan. Compare these two answers to the question "Can C# handle operation overloading?":
  • "Um, I think so, I heard of that happening somewhere, but I don't know"
  • "I'm pretty sure, but I will quickly verify that in the C# specification".
• When asked an interview question, don't just reply with "yes" or "no", but expand. This (1) demonstrates that you're pro-active, (2) keeps the ball in your court (you get to talk about what you know, instead of them following up asking questions you might not know), (3) gives you the chance to tie in other knowledge. Which of these sounds more confident to the question "Do you have experience with C#":
  • Yes.
  • Yes. I have three years of C# experience. I know C# very well.
  • Of course. Over the last three years I've built many applications with it. I especially like how it's type-safe, especially with delegates. Most of my blog entries use C# code samples because it's such a clean language.