I'm pitching a book on Big Data Analytics and Data Engineering, and the proposal worksheet has a field that says, "Author public speaking samples (YouTube, etc.)."
I am a practicing data engineer, and I don't do any public speaking as part of my job. So, if I want to do this, it looks like I need to get some experience in public speaking, record it, and use it as proof that I don't freeze up and run away at the sight of an audience.
Running through examples of public speaking, I found Susan Etlinger's What do we do with all this big data.
This talk is engaging and short (12 minutes!). First, she introduces her theme that data requires context by juxtaposing Aldus Huxley's future vision as trite and Orwell's vision as big brother and establishing her philosophy that it is neither. Here theme takes a quote from Ronald Reagan "Facts Are Stupid Things." Next, she makes the theme that data, as facts, require context to have meaning.
So, a talk must have a theme. If I were to give a talk about data to a group of computer science students, what could I have as a theme?
A Strawman Theme: Leave a trail for others to follow.
So many times in my career have I had to pick up a complex project inherited from another engineering team or company. What does it mean to leave a digital trail for a future engineer?
Document why you did things in source code and wiki pages
Use build scripts to document how to compile everything
Record meetings of doing deployments and troubleshooting
The pro is that following another's path is a common experience for a software or data engineer. The con is that sometimes it isn't worth it to repeat another's mistake. The secret to being an excellent engineer is knowing the difference.
A Better Theme: Understanding when to Reuse and when to Invent
I've been at startup companies that think they have a good idea and invent something that gets them a few customers but eventually stall progress because the concept is not good enough. Data companies, in particular, have this problem because data products are subtle. Poor design in a data model executed by well-intentioned and technically proficient engineers can amplify the deeper issues. Then, as complexity layers on complexity, the problem becomes more extensive and complex, and the engineers develop more complex processes to resolve it.
Technical proficiency won't always help you. You need to be able to return to the basic concepts and decide whether the underlying foundation is sound. You can keep building, or the underlying foundation is unstable, and any development wizardry built on top of the foundation is not helping but, instead, adding to the problem.
I have some time now to think about it, and I'll return and come up with my speaking sample. Who knows, I may even pitch it to give at a group of computer scientists who might find my experience valuable.