Posts

Showing posts from 2025

Analyzing a stack allocation overflow error

I had an interesting delve into a curious bug recently (C++), and I'm going to write it up here, just in case it's interesting to anyone else. Note: Some of the early stage debugging was done by others as well in parallel (although I did all the late stage debugging); I'm simplifying somewhat by just focusing on what I did, though. The issue started with unit tests failing. Not just random unit tests, though: around 2/3 of the unit test projects started failing to run (which technically doesn't appear as "failures", so it wasn't noticed immediately). Once this was noticed, it was traced to correlate to a recent change to run the UT's for the Debug|x64 build (vs the previous Debug|x86 build). But this was just the starting point for the analysis, when it got effectively punted to me ("benefits" of being one of the most senior devs, and often the last resort for hard problems). So, initially, I looked at the cause of the failures to execute; it...

The Story of PayPal V2

I was reading The Founders recently (https://www.amazon.com/Founders-Paypal-Entrepreneurs-Shaped-Silicon/dp/1501197266); I was interviewed for this book, fwiw. There's a section in "PayPal V2", the internal effort to rewrite the aggregate website which was ultimately scrapped when Elon was ousted, but obviously the book glosses over a lot of the technical details (for good reason, as these would be not very interesting to most mainstream readers). However, if you're reading this, I'm going to assume you might be more interested in the nitty gritty of this project, and since I had a first-hand perspective, I'll write more about that aspect here (and if you're not interested in this, then perhaps skip this post). To understand the build up to this, though, I'll need to cover a bit of internal history, from my perspective. The Preconditions Technology base Confinity and x.com had very different technology bases, which went well beyond even the approach to...

Thoughts on "extra code" in a codebase

A bit ago (around 5 years at this point), a relatively senior manager said something interesting to me, in the context of a software company. I had just started working in a new area, effectively, and this person was a senior director in charge of all software development efforts for that part of the company. He said (and paraphrasing, to be clear): "we want to ensure that we do not have any extra code in the codebase which is not needed for what we are shipping". This struck me as somewhat odd at the time, and still resonates as counter to how I would run a software organization... and in this blog post, I'm going to try to explain why, as best I can. To start with, I suppose, this is not really a sentiment which is expressed much within smaller organizations, which had comprised the majority of my professional career to that point. In a small company, you're just trying to ship products that people want, and/or optimize your time to market, and rarely have the time ...