At a recent company away day I gave my first lightning talk. The constraints were it needed to be 5 minutes and at least loosely related to technology and/or the work we do at Dstny.

How’d it go?

My topic was the hacker mindset and it didn’t go super well if I’m honest. I ran over at 9 minutes which was disappointing but in hindsight totally predictable. I’ve prepped plenty of presentations and chats before, but never something so short. I just had too much content!

I originally started with a few slides consisting of a quote from Paul Graham about the hacker mindset, an example from industry (see below) and then some examples from Dstny. At this point I should have tried a dry-run to check the timings and then adjusted as required. Instead I slept on it and in the morning decided it wasn’t interesting enough and added in more examples. That was definitely a mistake.

I ended up going from 3 slides to 16, which contributed to the entire pace of the talk feeling a little rushed from the start. Have you ever come out of a meeting and thought “that could have been said in 5 minutes?”. Well, this was the opposite of that.

I think my overall takeaway is that a lightning talk needs the same amount of preparation as a standard length talk, possibly even more if your talking style errs on the verbose.

A preview of the content

For those wondering, here are some of the non-work talking points I had, either on slides or in note form as stories I wanted to share…

I like reading programming stories from the 90s. It’s the point in time where the tech is new enough that I understand and relate to the stacks, but old enough that the limitations devs had to overcome are novel to think about today. These historical examples I find help inspire me to cultivate the hacker mindset.

We often think of a hacker as someone who is clever and sneaky and does things they're not supposed to do... which could also be a description of an innovative solution to a problem.

Paul Graham (Part of the interviews from 'Aardvark'd: 12 Weeks With Geeks')

So the hacker mindset is being clever, thinking outside of the box, perhaps in ways that you’re not supposed to, all to find innovative solutions. I would add to that quote that it is also via deep technical knowledge.

Introducing id software

Picture the scene, it’s the early 90s (think 386 era), you want to make a 3D first person shooter which has never been done before. Also you don’t have any good references or open source libs to start from, you’re building from scratch pretty much! id software was formed in this period and made all sorts of super successful games including Wolfenstein 3D, Doom and Quake.

A typical 386, designed more for the office than gaming.

The Game Engine Black Books are really well put together and show how the games were built. There are various examples in the books of the hacker mindset in action.

Here is an easy one. sin and cos lookups were expensive to do at runtime, but a requirement for the game. The game devs get around this problem, not by caching the values, but by pre-calculating the values in a lookup table. Better than that, as memory is super limited at the time they only do it for sin, as cos(x) = sin(x+90), and that halves the amount of space required.

Aside: This shows a classic programming relation, for fast retrieval you spend time storing, or for quick storing you spend time retrieving.

A more hardcore example is understanding the graphics modes of the time. To get the most out of the VGA hardware you needed to understand the hardware architecture, including the 50 internal registers controlling the behavior. This is what led to mode Y and mode X, unofficial but useful ways to get better performance and visuals out of the display hardware.

Needing to know about 50 registers to reach unofficial modes of operation? That’s a nice hacker mindset piece of work.

DOOM has yet more examples. An exercise for the listener/reader, go look up Binary Space Partitioning (BSP) and how it enabled the game engine to be able to move from right angles only in Wolfenstein 3D to any heights and angles the designers liked.

One interesting point about BSP is that it came via academia. The hacker mindset encourages not just deep technical knowledge about your interest/field, but also interest and curiosity in adjacent areas.

Further Reading

For those that aren’t really familiar with these games, DOOM in particular has a very large following and has been extensively ported. Check out Can it run DOOM? for a deep dive into the dedication and creativity around programming the game!

Bisqwit’s YouTube channel is fantastic at explaining some of the techniques used in game engines. Creating a Doom-style 3D engine in C is worth the 19 minute run time. Be warned though, you’ll probably want to start programming in BASIC after just a few minutes…

Dev