Codeslinger

One of the cool things about ChatGPT is the ability to gather and aggregate data about various things, and present such data in a relatively objective format. It's not always totally correct (see: "stochastic parrot"), but it does a reasonable job presenting well-stated conclusions with supporting data, particularly when the conclusion is already pretty well-known. Below is the prompt result from asking the LLM if the H1-B visa program is being used as-intended, or if it's being abused to effectively underpay US workers (with an ancillary focus on Zscaler, because that's my current employer, and I didn't know if they used H1-B visas at all before querying for this).

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...

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...

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 ...

Allow me to posit a hypothetical. Imagine you are at a company, and someone (perhaps you) has just completed a project to implement some complex feature, and you have been tasked with ensuring the implementation is documented, such that other/future developers can understand how the implementation works. For the sake of argument, we'll assume the intent and high level design have already been documented, and your task is to capture the specifics of the actual implementation (for example, ways which it diverged from the original design, idiosyncrasies of the implementation, corner cases, etc.). We'll also assume you have free reign to select the best tooling, format, storage, etc. for the documentation, with the expectation that all of these are considered in your work product. Note: This is, in my experience, a not uncommon request from management, especially in larger companies, so it seems like a reasonable topic for general consideration. Let's see how it plays out, look...

One of the more insightful conclusions I've reached in my career, if perhaps also one of the more controversial opinions, is that you should always say "no" to code freezes (at least in an optimal development methodology). This isn't always possible, of course; depending on where you are in influence and decision making, you may have only some, or effectively no, input into this decision. However, to the extent that you are prompted with this question and have some input, my advice is to always push back, and I'll elaborate on this below. The case for code freezes I've heard a number of different justifications for why people want code freezes, and these desires come in a few forms. Some examples: We need a code freeze We need to defer some code changes for a bit, just until... We need to hold off on this going in because... We have a release schedule where no changes go in during this period etc. Typically, the justification for the ask is achieving some desi...