Up at 5AM: The 5AM Solutions Blog

Be an Expert

Posted on Wed, Oct 07, 2009 @ 12:52 PM

As I think about the good technical colleagues I've worked with over the years, one common quality they all share is that they are or were all experts at something: maybe a file format, Javascript regular expressions, Hibernate, or a build system. It could be big or small, relevant to a current project or merely a source of curiosity and fun trivia, but my good technical people always seem to be an expert–and add to their expertise list over time. What's the relationship between expert and good technical colleague?

I want to take a moment to define expert as I'm using it here. Calling someone an expert is a relative judgment. I may an expert among one group but a relative neophyte for the same topic in another. When I talk about "the expert," I mean the person that is the go-to for answers. The person that is recognized as authoritative for the group. Generally the expert either authored a bunch of relevant code in the past, or does reviews of the code now. They can answer easy or normal questions from memory. For obscure questions, they either know from past experience, point you at a relevant section of the docs, or solve the problem because they get fascinated. An expert is not an encyclopedia, nor do they know everything. But they know more than you.

All is a strong term. Are all good technical people experts? Maybe not, and I think this may be a distinction between coders and software engineers. In the normal course of coding we encounter problems no one in our local group has seen before. Solving the problem at hand gives the person experience, but not expertise. How someone generally reacts after solving the immediate problem separates good from not-so-good, experts from non-experts. Good software engineers (note: not 'coders') generally add extra unit tests or comments, go and investigate to see if the problem has a general solution, or take a few extra minutes to read up on existing documentation. And I think the most critical thing, the one that makes you an expert: communicating that knowledge back to the team. Look it up: the best way to learn is to teach. Two things happen by communicating back to the team. 1) You internalize the knowledge, and 2) Everyone else knows you know.

So, good individual software practice means communicating back to your team, and the act of communicating well makes you an expert.

GET OUR BLOG IN YOUR INBOX

Diagnostic Tests on the Map of Biomedicine

MoBsmCover

Download the ebook based on our popular blog series. This free, 50+ page edition features updated, expanded posts and redesigned, easier-to-read maps. 

FREE Biobanking Ebook

Biobanking Free Ebook
Get this 29 page PDF document on how data science can be used to advance biorepositories.

 Free NGS Whitepaper

NGS White Paper for Molecular Diagnostics

Learn about the applications, opportunities and challenges in this updated free white paper. 

Recent Posts