“If you can’t explain it to a six year old, you don’t understand it yourself.”
– Albert Einstein
As a developer, your customers or clients – both internal or external – come to you because you understand something they do not. You understand how to architect applications on the web. You understand the tools that you use, you have a deep understanding of your technology stack.
I had a boss one time that insisted that because he had a copy of PageMaker installed on his computer, he could publish a magazine. I mean, how hard can it be to use a piece of software that a cost over $2,000? Right? He thought he understood, until he actually fired it up and tried to put together his first edition. Yep, you know the rest, after about a week of fiddling around, he hired someone with a deep understanding of how PageMaker worked, and how to get things done with it.
As a professional developer, you are the expert. You are expected to know not only the buzzwords, you have to understand the concepts behind them. You can’t just say “Cloud”, you have to understand what it means in relationship to your client. It is your job to understand these things just as it is your client’s job to understand what they need the application to do. You cannot help people solve problems with technology if you don’t understand the technology yourself.
This doesn’t mean you have to know all the answers. To the contrary, some of the worst developers are the ones that won’t admit that they don’t know all the answers. You don’t have to know all the answers, you do have to know where to find all the answers.
I interviewed once with a company that expected me to know all the answers. As I sat in the conference room, my interviewer walked in with a stack of old-school computer books. You know the kind, the ones that were sold by weight. By that standard, these were some of the most expensive books I had run across. Each book had dozens of post-it notes sticking out the top. He sat down, opened the first book to the first post-note and proceeded to ask me a question about what was being talked about in the book at that point. Of course I did not know the answer. I was honest with him and told him I did not know exactly and described how I thought I could figure the answer out. He then moved to the next post-it note.
Long about the third post-it note, I stopped him because I could see where this was going. I explained to him that we could go on this way for a bit, but the chances were very good that I didn’t know the answer he was looking for on any of these questions. The thing I did know is where to find the answers should I ever need them. I could feel the recruiter who got me the interview crawling under the table.
The point was that I was not a walking encyclopedia. I did however have a good understanding of the technology that they wanted me to work with and knew how to fill in the gaps in my knowledge when necessary.
By the way, they called back and wanted to hire me. I decided however that it wasn’t really the kind of place I wanted to work and I was lucky to be in the position to be able to pass on the offer.
It’s ok not to know all the answers, as long as you know where to find those answers. Sometimes you will find the answer on Google. Sometimes, you’ll use IRC. Sometimes, you’ll ping that weird guy you met at a conference last year who said drop him an email if you ever needed help. Whatever works for you is the right way.
However, without a deep understanding on the technology stack you are working with, you won’t understand enough to even start to find the answer.
Invest your time in learning your tools as you spend time looking at new tools. Understand what you are working with so that you can help others create awesome.
Until next time,
I <3 |<