Whose Line of Code Is It Anyway?

You might know the game of ping-pong, aka table tennis. You might know pair programming. But have you ever thought of putting them together? No, we don't pass the keyboard by smacking it with a paddle. It's much less violent and more useful than that, as a technique to combine pairing and test-driven development (not really ping-pong) in a fun way.

This talk will demonstrate Ping-Pong Pair Programming, on a problem chosen by the audience, in a language chosen by the audience. If time allows, we will also demonstrate "Smart@$$" Ping-Pong Pair Programming, in which each dev tries to force the other into doing the actual hard work.

I can do this as a normal breakout session, or if you want, I could possibly turn it into a workshop.

Prior knowledge needed: only basic concepts of unit testing, as I will explain TDD and pairing (and ping-pong). Though there are a variety of languages the demo could be done in, all are fairly English-like and should be reasonably understandable to all devs.

Ideally this has two speakers (other one TBD), but I can alternately take a volunteer from the audience, or a series of them.

The concept is language/technology-agnostic, so it could go at an agnostic conf or one centered around any language. If your conference is about a language I don't know, I can probably learn it (and its typical testing tools) at least enough to pair up with someone who does, so I can still do the talk at your conference.

This has been submitted to some conferences, but not yet accepted (nor rejected), let alone performed. I have several potential co-speakers, and even if none of them are available, I could use a volunteer from the audience, or maybe multiple of them.

The rough outline so far:

- Very briefly recap what are ping-pong, pair programming (mentioning test-driven development), and TDD.

- Ask the audience what language they want us to work in, from among those (up to four or so) that my co-speaker and I have in common. (Or if I couldn't recruit a co-speaker, just those I'm ready to do.)

- Ask the audience which of a few different fairly simple functions to code up using this technique, or maybe additional suggestions. Candidates so far include "FizzBuzz response for one number" and "next state of a cell in Conway's Game of Life, given its current state and number of neighbors". We may do multiple if time allows.

- DO IT!

- Recap good/bad parts of that experience.

- If time allows, demonstrate "Smart@$$" Ping-Pong Pair Programming, in which each dev tries to make the other do the "real work", by writing a test that can only be made to pass that way, while also trying to *avoid* doing the "real work" by writing code that passes all tests so far BUT is even simpler.

Tight Genes: Intro to Genetic Algorithms

Yes, that's right, geneTic, not geneRic. Genetic algorithms are shortcuts to "evolve" solutions to hard problems, by mimicking real-world biological evolution. They find a "good enough" solution more quickly than precise calculation or brute-forcing your way through the entire solution space. Its randomness often reveals great solutions that humans probably would never have thought of, such as NASA's twisty ST5 spacecraft antenna, developed by a genetic algorithm in 2006!

This talk will explain the general concept, and then walk through some examples, explaining terms and pointing out tradeoffs and nuances along the way.

You will come away equipped with a powerful technique for solving problems that might otherwise be computationally intractable!

I have done this talk for several conferences so far, and am slated to do more soon. You can see the videos in my playlist at https://www.youtube.com/playlist?list=PLMrm16n64Buag1--3P3xf9KnrH330nrPc .

Agenda:
- What are genetic algorithms?
- Brief history
- Examples of pre-existing usage
- Walkthrough of using it to solve different classic kinds of problems (e.g., knapsack, traveling salesman, and/or others), pointing out terms, tradeoffs, nuances, etc. along the way
- FAQs
- Conclusion/recap
- Q&A

TDD like a Viking: Brewing Mead with JavaScript!

You've probably heard of TDD (Test Driven Development) by now, but do you actually do it? Do you know how? This talk will explain the benefits of TDD, and show you how simple it is to do TDD in JavaScript. (Plus, what mead is and how it's made!)

Join me on the adventure of making some simple calculators, in JavaScript, to plan and blend batches of mead. You will come away much better equipped to write high-quality code, in JavaScript or any other language. (And to brew your own mead! Sorry, I’m not giving out samples.)

This won't be live-coded, but I will show the progress at various stages, including the code, the tests, and the web pages that the JS works on.

Bug Magnets: Booby-Traps in your Code

Have you ever inherited code, made a simple change, had it completely fail to work how you thought it would, and spent hours hunting down a subtle bug in your change? It might not be entirely your own fault! The previous developer may have laid one or more booby-traps for you to step into. (Then again, that may have been "past you"!) This talk will help you spot many kinds of such traps before you trigger them, and avoid laying them yourself (or others).

There is code, so of course each one is in some specific language, but most of the concepts are language-independent.

Agenda:
- What's a bug-magnet?
- Famous real-life examples, like Apple's goto-fail
- Other bug-attractive common situations, like complex code or lacking tests
- Less well known examples
- Theoretical examples I haven't actually seen
- General advice
- Tools to detect them and maybe suggest alternatives
- Wrapup

Multi-Talking (no, that's not a typo) with Genaver!

How can a speaker quickly generate a version of a talk, to fit in a given time length, have various options chosen for parts that vary between versions, and so on? Genaver to the rescue!

*Genaver* (Gen-A-Ver) is a small piece of JavaScript I wrote, to generate versions of a talk, with pieces chosen on the basis of various parameters, and even content constructed from variables. For example, assuming you have actually created the necessary content, it can create a version with the introduction in Japanese, the code in Ruby, and fitting in 45 minutes, or with the introduction in Portuguese, the code in Elixir, and fitting in 30 minutes, just by changing parameters.

This is the story of how that came to be, including finding the need, other options I explored, how I settled on this way, how it works under the hood, where to find it, and how you can use it too.

This is suitable mainly for conferences about kluges, hacks, jury-rigging, workarounds, silliness, and so forth, such as GambiConf.dev, !!Con, or SIGBOVIK. But, it could be useful for other conferences, mainly JS-focused ones and others on creativity in general, just to show some of the fun things you can do with JavaScript. (For geeky values of "fun".) It would go well preceded by my other presentation on conference speaking, "You Wanna Say Something?" :-)

Agenda:
- Why I needed something like this
- How I came to this implementation
- Walkthrough of the code
- Demo: string equality matches (as human and programming languages), and numerical order matches (as the min/max time a speech needs to have in order to include a given piece). Maybe also other features I will have added by then. :-)
- Where to find it, how to use it, other such practical matters
- Conclusion

I have done this at one conference so far, GambiConf 2023 in São Paulo. The video is at https://www.youtube.com/watch?v=CJtFPdvBcj8 -- but it's in Portuguese. :-) (I could certainly translate it to English, or even French, with a bit more lead time.)

Object Oriented Programming: You Keep Using That Word . . .

Many developers keep using the term "Object Oriented Programmer", but the guy who actually coined it doesn't think it means what they think it means. This talk recaps both sides, compares and contrasts them, and makes recommendations for each based on circumstances.

Agenda:

- Quick recap of what we now call OOP
- Where did that come from?
- Overview of Alan Kay
- Circumstances of his coining the term OOP
- What he meant
- Actor Model and other implementations
- Advantages and drawbacks of each, re dev, testing, etc.
- Recommendations when to use each
- Summary/Conclusion

ACRUMEN: What IS Software Quality Anyway?!

Without a good definition of software quality, you'll have a tough time achieving it! This talk introduces ACRUMEN, my simple yet fairly comprehensive definition, that you can use with any tech stack, for free. It stands for the idea that software should be Appropriate, Correct, Robust, Usable, Maintainable, and Efficient. (Come to the talk to see what the N stands for!) I will explain why we need a definition, and how to apply this one, then explore each aspect in turn, including further nuances and immediately useful tips on how to _achieve_ each one. You will come away better equipped to analyze the quality of anybody's software, give precise feedback on its shortcomings, teach the next generation of developers how to produce high-quality software, and most importantly, improve the quality of your own software.

This is aimed mainly at intermediates because they've realized how important, _yet fuzzy_, software quality is, while juniors usually haven't yet, and seniors have usually already developed their own approach to quality. However, juniors can generally understand the ideas _when pointed out_, and seniors can still benefit from a different point of view, plus they may still be struggling to put their approach into words so as to teach it to any juniors and intermediates they oversee or mentor. Even non-techies will benefit from having a more precise vocabulary to tell us exactly _how_ our software sucks.

I've given this talk before at several conferences and Meetups, and am slated to do more soon. The latest video is at https://www.youtube.com/watch?v=5iJGC01ApSc (from Frontrunners DC 2023).

There is deliberately zero code in this, to emphasize that "code quality" is just a part of the overall picture of "software quality" that I am addressing -- and that the concepts are completely technology-agnostic (unlike some other definitions).

Agenda:
- Why do we need a new definition?
- What’s in this one?
- Basic FAQs: How do we use it, how can we quantify it, and is ACRUMEN always the right order?
- Explore nuances and tips for each aspect in turn
- Further FAQs if time allows, such as other good definitions I've found
- Conclusion

I would like to do this as an inspirational/motivational plenary keynote, but could also do it as a regular conference session.

Kill All Mutants! (Intro to Mutation Testing)

Would your test suite still pass if the tested code was changed? If so, you might have gaps in your test suite, unreachable, redundant, or otherwise ineffective code, or both!

Mutation Testing reveals these cases, and provides some guidance about how to fix them. This talk will tell you what mutation testing is, how it works inside, how to use it, where in your process to use it, and its benefits, drawbacks, and history. There will be multiple examples, and a list of tools for many popular languages (and some others).

You will come away equipped with a powerful technique for making sure your test suite is strict and your code is meaningful!

On the submission forms, I usually pick "advanced" level because it's an introduction to an advanced topic. If forms mean the level *within the topic*, it's more introductory.

I have given this talk many times before, and am slated to do more soon. You can see videos in my playlist at https://www.youtube.com/playlist?list=PLMrm16n64Bub8urB-bsyMyHiNPMLG7FAS

Agenda:
- What is mutation testing?
- Why isn't test coverage enough?
- What are its pros and cons?
- How does it work (overview *and* details)?
- Simple example (finding and fixing bad test)
- Complex example (finding and fixing bad/missing test)
- Complex example (finding and fixing redundant code)
- FAQs as time allows, such as: history, why is it so CPU/RAM intensive, where to fit it into dev process, why change code in only one way per mutant, can it help assess the quality of single tests, can it help if we don't have tests yet
- Wrapup
- Q&A

Lastly, if your conference has workshops *afterward*, consider having me do this talk *plus* having Markus Schirp do a workshop, at which I can help convey the concepts to the students.

Ruby Gotchas

Rubyists love its Principle of Least Surprise, but Ruby can still be surprising -- not always in a good way.

This talk is about Ruby’s lurking “gotchas”, so that you can avoid being “gotten”. They range from basic differences from most other languages or common sense, to ones that often catch even expert Rubyists. You will come away with an awareness of specific things to watch out for, and a "Spidey-Sense" of some general kinds of things also likely to be dangerous.

This has been done before at some Washington DC area Meetups, but long ago (over a decade), and not yet at conferences.

You can see the old slides at https://bit.ly/RubyGotchas -- but my slide style has changed a lot, and I intend to reformat it into the illustrated story of a new Rubyist encountering many of these gotchas (there won't be time for all of them, and many have been fixed) one by one.

When I did it I only had a couple years of Ruby under my belt, but several longtime Rubyists told me there were things in it that they didn't know about!

Drink like a [...] Viking: The History and Making of MEAD!

This talk goes over the origins of mead (as far as anyone really knows, in several places, some not usually associated with it), some of the many varieties (including some bizarre modern ones), and the basic process of modern mead-making on a home scale. You will come away with the knowledge you need to get started making mead to impress your friends at your next Twitch-streamed D&D game, or your next Skyrim game!

This is currently about 40 minutes, and can be trimmed down to about half an hour, or lengthened to about an hour. There are slides, and for performances near me I can bring other visual aids. However, I will almost certainly not be able to give out samples. The current full title is "Drink Like a Chinese Egyptian Eritrian/Ethiopian Filipino Finnish Greek Indian Lithuanian Mayan Nepalese Polish Welsh Xhosa Viking: the History and Making of MEAD!" :-)

You Wanna Say Somethin'?

Would you like to present a talk at a conference? (And probably get your ticket paid for, plus maybe your travel expenses, possibly even with some extra?) Does the thought scare you -- or excite you? Maybe both?

You'll need a message, and to know how to find conferences accepting talks, submit yours, create it (yes, you can submit "vaporware"), and deliver it -- and what to do afterward. This talk will help you with most of that. (There's much more about public speaking than I could tell you in this time, so there will be a list of other resources.)

Meanwhile, come to this talk to find out how to figure out a good topic, organize your thoughts into a speech outline, create slides, find images for them, find conferences accepting submissions, and craft, submit, and track your submissions and presentations. Before you know it, you'll be gallivanting all over the world as a speaker... or doing it remotely if that's your preference.

This is applicable to non-technical conferences, but the vast majority of my conference-speaking experience (but not all!) is at tech ones.

Agenda:
- Why you might want to present at a conference
- Why you might NOT want to
- Very basics of Public Speaking, and some resources
- What's different about *conference* speaking
- Finding a Topic
- Finding Conferences
- Choosing Conferences
- Tracking Your Submissions
- At the Conference
- After the Conference
- FAQs
- Wrapup

Why We Prepend

Did you switch from an object-oriented or imperative language, to a functional one, and find it hard to adjust to prepending to lists instead of appending? And wonder why? It all makes sense when you know what's under the hood. This five-minute lightning talk will show you what that is, and why it's done that way.

Test your Docs, and Doc your Tests

Do the examples in your documentation get out of date? Are the examples in your tests hard to understand? Do you wish you could combine them? In some languages, you can! This talk is about doctests, as used in languages such as Python and Elixir, using documents with real tests embedded.

This is intended to be a lightning talk of about ten minutes; I might be able to chop it down to five if needed, or stretch it out to fifteen or so with examples from additional languages but I think that would get boring.