I do everything I can to see as many talks as I can as often as I can in the field of software development. Yup... That's an opening sentence with a whopping three "cans" in there. That's how important I think these talks are. The field of software development is difficult, frequently changing, it's relatively young, and I would argue that there are few if any types of schools or training programs you can go through that will really make you anywhere near being an expert. There is no graduate school that will make you a rock-star developer. If you know of one, please let me know!
The experts of software development are made through hard work and passion, frequently at night and on weekends. We code all day to make a living, but we don't always get to spend the time researching the very best way to do something, sacrificing that level of quality for a faster time-to-market. We see workarounds and hacks throughout production code because of this very problem. Some developers commit this code shamefully, others don't yet know enough to be ashamed. A select few have the depth of understanding and knowledge (both technical and domain) required to architect and code an application or service that is, for lack of a better term, "as good as it can get". I wish I was one of them, and it is my eternal "lofty goal" to become one.
What is a "lofty goal"? It is an ideal. A dream. It is an unrealistically high-standard to which we strive, knowing full well that we will almost certainly never complete the journey. The beauty of it is that you will likely find yourself on the path of continuous improvement as you reach for your goals. "Shoot for the moon. Even if you miss, you'll land among the stars." (Norman Vincent Peale)
Side-note: Yes, yes, yes... I can already here some of you cursing my name, pointing out how Peale's famous quote about shooting for the moon makes no sense when examined literally, and so on. Have fun cursing me, because I'm using the quote anyway.
Now that I've run off on a couple tangents, let me get back to discussing technical talks. There may be several motivations for giving a talk. Money, exposure, notoriety, forcing yourself to learn something better, etc. For me, the number one motivation is to level-up your audience. My goal is to have attendees leave my talk with at least a nugget or two of information that helps them improve as a developer. Wrapped up in that goal is a desire to make you, the developer, feel better about yourself, your career, and your future. Therefor, anything I do or say as a speaker that makes you feel worse is directly antithetical to my intent.
In consideration of the above, here are some things I avoid saying in my talks:
These are just a few examples I just saw happen in a few different talks recently. The egos of software developers ranges across the board: We have the over-confident know-it-alls, who probably do not actually know it all, down to the frightened developer who suffers from a massive case of imposter syndrome. As usual, the truth lies somewhere in the middle. Those who berate themselves about how little they know are likely not giving themselves credit for the things they know quite well. The ones who think of themselves as superstars, virtuosos, or technical saviors are quite likely turning a blind eye to the multitude of things they don't know.
If I've taken the time to come to your talk, it's because I want to level-up and improve my skills. I want to learn something new. It is my goal to learn about what I am not doing so well, so that I can do it a little better next time. I don't want to be told that I'm so bad that I should leave the field. My inner-voice says that to me plenty... I don't need yours added to the choir. Thanks, though.
I have made a metric shit-ton of mistakes and errors throughout my software career, and I'm quite sure I will continue to do so until I kick the proverbial bucket. I celebrate failure, and I try to fail as quickly as possible to move through bad ideas and come up with that good one that gets the job done, and does that job particularly well. I have broken builds. I have broken unit and integration tests. I have corrupted databases. I have created race conditions. I have unintentionally created infinite loops. I have attempted to implement design patterns, and not realized for months or even years that what I did was insanely flawed. I have checked in non-compiling code and incurred the wrath of a team full of more experienced developers (it was my first time using version control... ever).
I'm willing to bet most speakers have made some fairly epic mistakes as well, some more incredible and costly than others. What I believe best serves our audiences is to help them realize they are not the only ones making mistakes. They should be more aware that they are not at all alone, and we all struggle with things when they are new to us. Don't lambaste us for our mistakes or even our ignorance. We've come to your talk to try to make fewer mistakes and be ever less ignorant.
Let's go out there and write some code. Let's make that code the very best we possibly can, and as we learn about things we've done in a not-so-great way, let's refactor it to better patterns and practices. I am a huge believer in assuming positive intent: Every single line of code I write is done to the very best of my current skill level, using the best tools I have available. Assume that every single face in your audience does the same. They are there to improve... So let's help them do just that.
Go give a talk, and help another dev learn something you struggled through!
Jon Bachelor: This geek goes all the way to 11.