I recently received a note from a journalist colleague I quite respect. It was interesting enough to share with you. He writes:
Based on your long history of hands-on experience with tech: Do you constantly (or maybe just regularly) find yourself not knowing something about it? The reason I ask is I am almost always on the edge of my knowledge base when writing for clients.
I've never been a techie or a programmer. I was a journalism major in college, so I know this forms a large part of the challenges I face keeping up. But, when I see a resume like yours, I wonder how universal this experience is even for people who have spent their careers deep in the tech woods.
I often joke that it's not the years or the miles, it's the lines of code. That actually provides an opening to answer the question you asked. The thing is, to give you a full answer, I also have to share some of my personal philosophy, experience, and thoughts about lifelong learning.
After all, once you realize you don't know everything, the next logical place to go is how to learn what you need to know. Since discovering you don't know something is a constant experience in this rapidly changing world, learning, too, needs to be a constant practice. And with that, let's talk.
It is true that I have a technical background. I was fortunate enough to attend college for a computer science degree. But let's be clear: I learned to program on paper tape and punch cards. The technology we have today is nothing like what I learned in college. Heck, back then, networks were a new idea.
What engineering school taught me, more than anything else, was how to learn. Virtually no skills-based education I picked up in school is current today. There is very little demand for FORTRAN and Algol programming, for example. Since then, like most developers, I've had to learn everything on the fly. Almost anyone who has lived with technology has had to do the same.
Almost every day I face the fact that I don't know something I need to know. Some of the topics are areas I'm generally comfortable with. For example, since I knew a good deal about databases, diving into big data wasn't a huge leap. Other things, like 3D printing, I knew nothing about. I had no initial skill at building pretty much anything. I'm a software guy, so working with physical objects in meatspace was new to me.
I write briefing papers and give webcasts for ZDNet's parent company, I teach at Berkeley, I give advice (for whatever that's worth), and I write about my hands-on projects tinkering with new technology. These all require me to learn new domain knowledge constantly.
Most of that requires picking up knowledge and developing expertise without a lot of prior experience. This summer, for example, I'm starting a Drone Solutions Discovery Series. The gotcha? The closest I've ever gotten to flying a drone was crashing a radio-controlled helicopter repeatedly into my garage door until I shredded the propellors and was told to step away from the dangerous toy by my wife. So, yeah, there will need to be some learning. Hopefully, more learning, less bashing.
If you looked at my bio, you'll see that I've got something of a reputation as a cyberwarfare expert. That wasn't a career choice. One morning, I woke up to a few million machines, bots, hammering on a little photography website I ran. At the time, I had a co-located machine at a service provider. They weren't willing to do anything to help, so I had to build my own defenses. It was a very stressful, unpleasant experience, but I learned.
Over the years, I learned more and more, and eventually wrote a book on White House technology and network security. But all of that was acquired incrementally, with a lot of reading, a lot of listening, some guesswork, and the largest peer review network in the world: Our readers.
In fact, a lot of my learnings have come from stressful, unpleasant experiences. I learned a lot about Exchange servers when my server crashed very, very hard. I spent almost two weeks desperately trying to recover all our email, tapping into every resource, asset, and person I could whine at. It was, as they say, another frick'n learning opportunity.
But here's where panic can give way to best practice. Over the years, I've developed a set of personal best practices that help me get up to speed relatively quickly.
First, let's understand there's a difference between a passing familiarity and deep understanding or even expertise. I have made it a practice to try to get a passing familiarity with a lot of topics. I spend a few hours each morning reading tech, business, and global news to make sure I have some clue what's going on.
When I encounter a topic I know nothing about, I make sure to do a little reading on it. For example, when I first encountered Chef and Docker, I didn't grok either of them. But since it was clear they were "things," and it was also clear I didn't have a clue about them, I spent an hour or so reading up. At the time, I didn't need to know about them for work or for any project. They were just terms I was unfamiliar with, and, as is my practice, I took a little time to do a bit of learning.
That quick familiarization pass is really important, because regularly learning even a little bit about stuff you encounter, but don't know, builds over time to some level of actual broader-based knowledge.
Since then, I've had to write about Chef and Docker in white papers, so that initial hour of basic familiarization gave way to days of learning. A few days may give me a decent understanding, but it does not create expertise. I am still far from an expert on these topics, but at least I know what they are and what they do.
I've taken deep dives into other topics. Earlier, I mentioned 3D printing. When I first started working with 3D printing, all I knew was that it seemed cool. I had never even seen a 3D printer in person. That was 18 months ago, and since then, I've written about 30 articles on the topic, and built a bunch of projects. As with Chef and Docker, I'm still not an expert (there's a lot of materials science and industrial design required to be an expert), but I definitely have a far better understanding than the day I opened the MakerBot review unit I was sent.
There are days when I wish I could crawl back under the covers and assume the fetal position, rather than pick up the project I'm supposed to work on.
There are some areas I do have some deep experience with. Programming languages -- and what makes a programming language function -- is one area. Another is content management. I built and operated my own content management system for my publishing company, and so I developed some very, very, in-depth expertise over the course of about 15 years. Most of us have deep knowledge in some areas, and shallow knowledge in others. That's natural. It would be odd otherwise.
One key to my learning practice is understanding just where my knowledge level is. In cybersecurity, for example, I'm quite capable of scaring the pants off admirals and generals, but stopping a sophisticated attack is something that's probably beyond my skill set. I was recently asked to write a white paper for a CBS client where they wanted a very deep expert in their specific technology, and I had to decline. I knew I wasn't that guy, and wouldn't be even if I studied up for a few days.
Also, don't let the fear get to you. There are days when I wish I could crawl back under the covers and assume the fetal position rather than pick up the project I'm supposed to work on. But that's just emotion. I know that I have the ability to learn, and I know I have the discipline to work. When I have scary days (more often than I'd like, honestly), I know that if I'm diligent and work hard, I'll generally get the job done.
I also use tools to keep track of it all. I wrote an article sometime back about my workflow, and a combination of careful filing, note taking, and tracking helps me stay on track. If I had to rely just on my memory... what were we talking about?
For me, a big life challenge was going from a relatively bright, unsocialized nerd to someone who could work and play with others. That took a long time, a lot of cajoling and patience from the amazing woman who started as a business partner and became my wife, and the toleration of my employees, team members, and employers over the years. While technical skill and understanding is important, I've found that not pissing off the client is a way more valuable skill (learned that the hard way, for the record).
I'd like to tell you that I'm super-well adjusted and everything goes smoothly, but that's not the case. I'll admit that I'm far better adjusted now than I was earlier in my career, but that's just because I've spent a lot of time attending the school of hard knocks. I've made enough mistakes to have something to learn from. I won't go into detail here now, but I'm like a lot of people who seem like they've always been relatively successful. Getting here was rough. Sometimes, really, really rough.
This is proving to be a long note and probably sounds a little self-serving, so I'll end with one of the biggest lessons I've learned, one that I've only learned in the last decade or so. The past does not foreordain the future. Stuff -- good stuff -- I never expected would ever happen did indeed happen. I used to have a very negative world view.
As both a geopolitical analyst and a programmer, looking for the bugs comes with the territory. But I've learned to never say never again, simply because it is actually possible for good things to happen. It is actually possible for some dreams to come true. Had you told me that when I was younger I wouldn't have believed you. But my life did improve. I got both the girl and the muscle car.
There's a lesson here. The reality of what comes true never turns out exactly as you picture in your dreams. You have to be open to opportunities, be willing to roll with them, and be flexible enough to change your view of what you want based on whatever your new reality happens to be.
The bottom line is simple: Knowledge and expertise don't just happen. It's a matter of constantly learning, trying things, doing stuff, making mistakes -- lots and lots of sometimes embarrassing mistakes -- and sticking with it. The only surefire way to fail is to give up. So, don't give up. Read everything you can, as much as you can. Think about what you read. Use critical thinking skills to filter out the garbage from the nuggets of gold.
Then, go forth, try it out, and do your best. That's all any of us can ever do.
You can follow my day-to-day project updates on social media. Be sure to follow me on Twitter at @DavidGewirtz, on Facebook at Facebook.com/DavidGewirtz, on Instagram at Instagram.com/DavidGewirtz, and on YouTube at YouTube.com/DavidGewirtzTV.