Lightning Talk Reflections

Created on November 12, 2023 at 11:35 am

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

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 TIME 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 PERSON about the hacker mindset, an example from industry (see below) and then some examples from Dstny ORG . 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 CARDINAL slides to 16 CARDINAL , 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 TIME ?”. 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 DATE . 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 DATE . 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 PERSON (Part of the interviews from ‘Aardvark’d: 12 Weeks DATE 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 DATE (think 386 CARDINAL era), you want to make a 3D first ORDINAL 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, FAC Doom and Quake PRODUCT .

The Game Engine Black Books ORG 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 PERSON ) = 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 ORG hardware you needed to understand the hardware architecture, including the 50 CARDINAL 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 CARDINAL 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 FAC to any heights and angles the designers liked.

One CARDINAL interesting point about BSP ORG 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 ORG ’s YouTube ORG channel is fantastic at explaining some of the techniques used in game engines. Creating a Doom-style 3D engine in C ORG is worth the 19 minute TIME run time. Be warned though, you’ll probably want to start programming in BASIC after just a few minutes TIME

Connecting to Connected... Page load complete