Here are a few ideas from my side:
-
Revisted talk "X More Ineffective Coding Habits of Many Programmers". In one of your interviews, you mentioned that you do a lot of code reviews. I'm sure you've noticed recurring code smells. I am also sure our audience is not immune from them. If you could compile a list of "the worst habits" and provide solutions, the attendees would be happy.
-
You pay a lot of attention to words and language. I've watched all your talks, and whenever you show the code, it "speaks for itself," and has a high signal-vs-noise ratio. A talk that shows developers how to write code that speaks human/domain language and gives a good reason for doing so can make developers rethink how they see and write code.
Ideas/suggestions are welcome.
I think number 2 is a great option. I have a talk that I've done a couple of times, but that I want to further update that's on metaphors and communication in code. Alternatively, I have a talk that overlaps with that, but is more focused on meaning in the code, and is a talk I've been looking for an opportunity to update (it was originally a DDD talk).
Metaphors We Code By
The abstract nature of software and its development mean that we employ many metaphors to talk about it. We talk about software as architecture, engineering and craft. We describe issues of code quality in terms of debt. We name our classes and UI elements after objects in the physical world. Metaphors are everywhere in software development, but often they are unquestioned and misunderstood. In this talk we'll look at how and why we use metaphors, when they help us and when they mislead us, and how to make better use of them to communicate intent in code.
What Do You Mean?
The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — its discovery, its formulation, its communication. It's the basis of our naming conventions, of domain-driven design, of our conversations about product requirements.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, that doesn't mean we're necessarily good at it. Let's talk about what we mean.