"Any fool can know. The point is to understand."
I think Einstein was onto something when he uttered these words. Knowledge has become easier to obtain than ever before. With supercomputers masquerading as phones in our hands, watches that know where we are, what music we enjoy, and can read us books, and an Internet that can deliver to us details of an event that occurred halfway around the world mere seconds ago... knowledge is everywhere.
But understanding? That's where things get tricky.
I believe that understanding is more than knowledge; that it's knowledge applied, knowledge with context. Further, I believe the way that humans best move from knowledge toward understanding is through personal experience, and especially through stories. This is the model that was followed for thousands of years, when skill was passed on from a master to an apprentice.
Unfortunately, this model is difficult, and not well-suited to most learners; masters are hard to find, expensive, and rarely take on apprentices. This is even more the case in technology. But what is at the core of the master-apprentice relationship? Shared experience; the telling of stories from one to another; the growth not through raw facts, but through applied and supervised knowledge.
This is what I do. This is how I teach, and why I tell stories: because I believe that any fool can know; but that the point is to understand.
Traditionally, this is where you'd learn about my credentials and my previous work experience. On many websites like this, a contracted professional writer would regale you with my qualifications, convincing you to email me immediately with your next teaching or programmatic need.
But that's just not how I think, let alone how I work.
My qualifications are informed by a lifetime of teaching, even when I didn't realize it. I started reading at 4, and by the time I was in elementary school, I was "writing" instruction manuals. I still recall the carefully illustrated guide to solving the Rubik's Magic that I put together in 5th grade. You see, even back then, there was just something that called to me about the art of transmitting knowledge, and in particular being creative about trying to do it effectively.
In high school, I taught myself to program. (Turbo Pascal was the first language beyond Basic I learned; anyone remember the book with the Porsche on the cover?) Shortly after, I began teaching the programming class to my peers. Before I graduated, I was teaching two different periods of computer classes–mostly because the actual teacher liked to drink at lunch and showed up loaded most afternoons! Still, I was learning what worked, and what didn't. I was teaching, and learning to communicate through story and context.
I followed my programming talents to college. I had a full scholarship to Texas A&M University in College Station, Texas, and I was off to study computer science. But I was far more interested in music (the best songs are stories!), the legendary and fabled Aggie Bonfire, and the college girls that seemed to know way more about life than I did. (Now they must have some interesting things to teach, right?) I continued to breeze through school, explained everything I learned over again to anyone who would listen, and created some stories of my own that are best told over a drink rather than on a website.
I eventually chased my love of music to Hardin-Simmons University. So much for the Texas A&M scholarship! But I was after interesting days, not a degree. At Hardin-Simmons, my music degree became secondary itself as I met the beginning of my great life story: my wife. That, as it should, changed everything. Now–with a new context–I needed a job. I finished my Bachelor of Science degree in Computer Science and took my first job at Nextel Communications.
Over the next 10 years, I worked in technology, primarily at telecoms. But I never could let what I loved most go: I was not just a programmer and systems administrator; I was the guy who could explain to marketing why the website wasn't launching on time. I was the guy who could translate customer requirements into user stories. I was the guy who could talk... and I talked all the time. And then I found out that people would pay you to write about technology, which was just another form of teaching and telling stories for me. I wrote the bestselling technology book Java and XML, followed by a number of other books for O'Reilly Media, and eventually joined that company.
Most recently, I returned to my developer roots, and spent nearly 8 years working with NASA's Earth Science group. Never have I spent more time teaching, translating, and explaining what one group's words meant to another, and ultimately telling the story of what NASA is doing through a flagship website and eventually a massive, organization-wide cloud platform. And no matter how much I learned about Amazon Web Services (AWS) or EC2 or lambda, it was always the storytelling that was most interesting; even better, it was always the storytelling that seemed to interest most clients. I could speak to them, in a way that they understood, and that was a good thing (TM).
Now, I teach and tell stories full-time. I record AWS certification courses on video and write exam prep books in a way that's actually helpful rather than rote memorization. I build websites, small and large, most often for clients who have their own story to tell to their users. I write books on what I've learned and how to tell stories the way I do.
Interested? Let me know. I'd love to hear your story, and perhaps help you tell it to the world.
I can't really say enough good things about working with Brett I always feel like there's a strategy being formed while still [remaining] agile enough to shift and change course if need be. He's a great communicator, written and verbal.
/ Satisfied client /
I've sat in more boardrooms and meetings than I can count, and watched managers and clients talk right past talented and engaged developers. I've watched those same developers try to explain–valiantly, with great technical depth–why a certain requirement can't be met, or why costs can't accurately be estimated. I've also taken the online courses that everyone takes for cloud certification, I've read the books on running efficient meetings, and I've led dozens of teams full of high-performers, some that hit every deadline, and some that seemed to miss every one.
In short, my experience is practical.
Sure, I'm formally educated, have worked within highly regulated governmental agencies, and signed more contracts than I care to admit. But ultimately, the way I communicate comes from actually communicating–sometimes successfully and sometimes with ... less than optimal ... results.
In other words, when you work with me, you know that I'm not espousing untested theories and hopefully hypotheses. I'll tell you what I'm doing, why I'm doing it, and give you actual real-life examples of situations that have informed my approach.
Practical experience. Why would you accept anything else?