Filed under random

Presentation slides - Intended Consequences

DC4420 Presentation: Intended Consequences

Faithful to habits, I found myself with a presentation at dc4420. Lessons of usability and search for sanity gave rise to a talk on how deal with conflicting auditing demands.

The talk was geared towards industry long-timers who have, for reasons only marginally in their control, found themselves appeasing externalities and ticking boxes. I wanted to highlight that hope is not lost.

You can find the slides here: Intended Consequences

Evolution of debugging prowess

Evolution and progression of debugging prowess

When things break in mysterious ways, developers tend to go through a familiar series of increasingly demanding steps. As experience, skills and even personal networks grow, we can find ourselves diving ever further in the following chain:

  1. "It must be in my code." -- hours of debugging
  2. "Okay, it must be somewhere in our codebase." -- days of intense debugging and code spelunking
  3. "It HAS TO be in the third party libraries" -- days of issue tracker excavations and never-before-enabled profiling runs
  4. "It can't possibly be in stdlib..." -- more of the same, but now profiling the core runtime libraries
  5. "Please let this not be a compiler bug" -- we become intensely familiar with mailing list archives
  6. "I will not debug drivers. I will not debug drivers. I will not debug drivers."
  7. "I don't even know anyone who could help me figure out the kernel innards."
  8. "NOBODY understands filesystems!"
  9. "What do you mean 'firmware edge case'?"
  10. "Where is my chip lab grade oscilloscope?"

How far have you found yourself?

Engineering challenges at elsewhere

Engineering challenges at Smarkets

A few days ago I posted a long-in-the-making article about the common engineering problems and constant challenges at the $dayjob blog. There are a number of repeating themes and questions that come up when doing interviews, so I figured I might as well answer them all in one place, and with sufficient detail.

After all, why not?

Presentation slides - Professionally Paranoid Infrastructure

DC4420 Presentation: Infrastructure Design For Professionally Paranoid

I gave a surprisingly long presentation in April at the dc4420 monthly event. What was supposed to be at most 40'ish minutes followed by short Q&A ended up taking more than an hour thanks to lively discussion during the different segments.

This was an overview of infrastructural design constraints for a betting exchange, especially focused on finding practical ways to address the regulatory demands. At the cross-section between gambling and FinTech the environment comes with some fairly unique externally imposed requirements.

The slides are a revised version of the presentation material, designed as better suited for distribution.

You can find the slides here: Infrastructure Design for the Professionally Paranoid

Presentation slides - size_t Does Matter

DC4420 Presentation: size_t Does Matter

I gave a short presentation in October at the dc4420 monthly event. The talk was about the simple theory and practice behind hash extension attacks.

You can find the slides here: size_t Does Matter

Quoted on the Finnish Phoenix

BBC on the Finnish Phoenix

Well that was unexpected. BBC just quoted me.