Every developer wants to be taken seriously. We want to be credible. But what makes someone credible?
I've seen a lot of devs who think that being credible means:
Sending out a link to a guidelines document
Keep referring to your last project (that no-one else on your current team was on) as that perfect project
Throwing out buzzwords
Never admitting that you're wrong
The problem is that all of these require little effort and don't really help anyone else. They don't distinguish the speaker - anyone can send out links, bluff about a former project, or throw out buzzwords.
I think a much better way to see if some is credible is if they:
Have experience in the problem domain
Have work products they can point to (i.e "I made this website", "I wrote this tool")
Can accurately predict what will happen (not "try this", but rather" do this and you'll get that")
Have a reputation of being correct (including other credible people who will back them up - i.e. "good references")
Can point to the official source (not "I heard on some blog that...", but rather "The MSDN reference spec for C# 2.0 says ...")
Are willing to invest their own resources into the approach or product (i.e. dogfood it). If someone won't even put their own resources in, then they probably don't believe in the approach.
You can't easily bluff these things. For example, your prediction either comes true or it doesn't (if it's ambiguous, then it's a bad engineering prediction); you either have a concrete product you can show people, or you don't. I think every industry leader you find does these things - they have tons of experience and products, make accurate predictions, have a reputation that precedes them, they write the official source, and they dedicate their lives to their cause. Now that's being credible.
No comments:
Post a Comment