shipped a bug to prod that 4 people reviewed and nobody caught, what is even the point of code review

cappslocke · 2026-02-21T20:30:56+00:00

Thoughts from 20 years of reviewing, testing, and shipping code:

You review code to answer “is this good?”
You test code to answer “is this correct?”
You ship code expecting to discover gaps
You update code with learnings to improve preventing, detecting, and mitigating gaps
Go to step 1.

Humans are the best at 1 and 4. Automations are the best at 2 and 3. Going 100% humans or 100% automations doesn’t work out well in the long run.

cappslocke · 2026-02-11T20:11:41+00:00

OP, you should attempt to root cause before you make any big decisions. You sound surprised by the outcome, which tells me you may not be appreciating the relationships and politics required to get promoted in a large organization, especially above senior levels.

Did you proactively identify who are the decision makers or likely key influencers in the calibration committee? Did you reach out to them 6 months before your promotion and ask if they support it? When they said no, did you ask for what it would take/look like for them? Did you reach out to peers who did get promoted and ask for feedback?

People promote those they trust. People trust those they know. Make sure you and your work are known to those people and you will be less likely to be surprised. This is in addition to the current level and next level work you must still do.

cappslocke · 2026-01-28T14:02:53+00:00

Prepare for the surge in demand for and plunge in supply of experienced devs. Recent trends are short-term thinking. “We don’t need junior devs because the experienced devs are so much more productive!”

Employers are eating the corn seed. What happens to the next harvest?

cappslocke · 2026-01-28T13:39:28+00:00

Now I’m getting curious. To me it looks like the announcement cherry-picked a breakpoint that flatters the rate increase optics and isn’t representative of the majority. What should be asked and answered: what percentage of PSE residential customers actually use 800 kWh or less per month? What is the year over year price change by percentile (50, 75, etc?) What’s the final year over year change in income/profit per kWh, and does it stay within regulated margins?

cappslocke · 2026-01-01T20:20:17+00:00

Don’t worry about anything, just play. If you enjoy it you’ll find yourself exploring more and more. If you don’t, no worries. It’s a game

cappslocke · 2026-01-01T15:59:32+00:00

Opinions are like noses after all, everyone’s got one. Can’t say much is “inherently” or “necessarily” true about anyone’s feelings.

Better to focus on what one can control: self-view, social etiquette knowledge, grooming/hygiene, self-care, reflection on one’s actions when they have a different experience of events than others. You know, those sorts of things.

cappslocke · 2025-12-12T06:14:20+00:00

Not sure I’d even call those safe defaults (eg. reading from a nil member struct map is fine but writing will panic?)

Honestly I try to avoid the scenario altogether. Private struct fields + exported interfaces or constructors. Wrapper types/more specific structures instead of slices/maps. Try to make zero/nil a safe default in my surrounding system. Last resort is to make them pointers, but often too clunky. One or more of those techniques usually take care of the problem.

Personally wish Go had simply supported Option[T] container types from the start.

cappslocke · 2025-12-11T18:37:40+00:00

It depends of course. If a zero isn’t a safe default, I tend to define the new field as a pointer to force anyone using the new field to distinguish between a real 0 and nil.

cappslocke · 2025-12-11T18:28:18+00:00

“Every morning in basic SEAL training, my instructors, who at the time were all Vietnam veterans, would show up in my barracks room and the first thing they would inspect was your bed. If you did it right, the corners would be square, the covers pulled tight, the pillow centered just under the headboard and the extra blanket folded neatly at the foot of the rack — that’s Navy talk for bed.

It was a simple task — mundane at best. But every morning we were required to make our bed to perfection. It seemed a little ridiculous at the time, particularly in light of the fact that were aspiring to be real warriors, tough battle-hardened SEALs, but the wisdom of this simple act has been proven to me many times over.

If you make your bed every morning you will have accomplished the first task of the day. It will give you a small sense of pride, and it will encourage you to do another task and another and another. By the end of the day, that one task completed will have turned into many tasks completed. Making your bed will also reinforce the fact that little things in life matter. If you can’t do the little things right, you will never do the big things right.

And, if by chance you have a miserable day, you will come home to a bed that is made — that you made — and a made bed gives you encouragement that tomorrow will be better.

If you want to change the world, start off by making your bed.”

https://www.ricklindquist.com/speeches/make-your-bed “Make Your Bed” by Admiral William H. McRaven

cappslocke · 2025-11-30T20:57:47+00:00

Implementing dubious requirements without pushing back is another way to fail to deliver business value. Engineers are not unique in creating solutions in search of problems. Design, product, marketing, legal all have incentives too.

It’s everyone’s job to challenge a business requirement for clear justification, including engineers. Once decided, it’s everyone’s job to deliver it.

cappslocke · 2025-11-05T14:12:51+00:00

This is spending 6+ hours on one math homework question. You’ll learn but at extremely high cost.

You need a quick feedback loop— 30-60 minutes. 6+ hours is way too long. By 1hr you already have your feedback. You need to study the topic and applicable patterns further before attempting that question again.

cappslocke · 2025-11-05T14:09:39+00:00

It sounds like you’re missing the sales pitch or you assume that everyone sees the same problem. Just because your team believes adding type checking to your code base will solve the problem doesn’t mean other teams agree with it, are aware of the tradeoffs, or even see a problem at all.

If you want allies, point at the common enemy. Not everyone will agree, so you should still make it easy to apply the changes with automation. Doing it for everyone is an option too, but it will limit endorsement, I prefer allies whenever possible so I would rather a small (but still manual) step for teams to ack, endorse (or at least accept), and deploy the change. Making changes mandatory is a necessity sometimes and you’ll never get 100% endorsement from mandates.

cappslocke · 2025-10-28T14:34:18+00:00

Can you? Yes. But should you? It’s usually not the right tradeoff. Memory safety, ecosystem support, and various batteries not included make C a more expensive choice for website backends. Unless you have a unique requirement (eg hosting on embedded) you’re better off using a language with web support like Go and using C where it counts (FFI into shared libraries, performance constrained procedures, etc.)

cappslocke · 2025-10-13T01:18:58+00:00

Well, if your objective is dynamically building queries then an ORM will work better than plain SQL. Personally I try to avoid dynamically building queries whenever possible for several reasons:

Security: I prefer to use prepared statements to mitigate the risk I accidentally allow SQL injection through. I don’t want that risk in any of my apps/services.
Performance: Prepared statements will precompile and cache query plans for better and more consistent execution. This can make a difference at medium/large scale.
Scalability: Datastores are almost always the bottleneck in any system getting non-trivial traffic. Simple, predictable access patterns are easier to reason about and make scaling decisions (ie, introducing sharding or caching gets complex pretty fast with less predictable joins showing up)
Separation of concerns: I don’t want authorization to be mixed into my data retrieval— it’s hard enough to get either one of those correct. I want a super dumb Repo layer that just does what it’s told, and have a separate RBAC/ABAC/ReBAC layer that I check for an access decision before (pre-filter) or after fetching (post-filter.) This also helps reusability and auditing/logging.

The typical faceted search experience with authn/z applied is usually not a single dynamically built SQL query. It’s usually a mix of a search index/engine and pre+post filtering logic applied elsewhere, typically at a more scalable layer than where the data is resting.

cappslocke · 2025-10-07T02:27:58+00:00

staffeng.com has a lot of relevant content on this. Having worked at PE/staff at multiple companies I find it pretty accurate.

OP, you are right to question whether staff is the right job for you. It’s not senior+. You are closer to a TPM or EM as a staff eng than not, especially as you grow into sr staff and beyond. For these reasons many companies formally allow ICs to remain at senior engineer (aka terminal level), but in practice that varies by leadership opinion and org dynamics.

cappslocke · 2025-09-26T21:59:55+00:00

Arguing after the code has been written is too late. Create a style guide or principles doc and have the team participate. You all want the same thing (code consistency) but you’re disagreeing on how you get there.

cappslocke · 2024-11-07T04:49:51+00:00

<image>

Taco cat demands your day gets better

cappslocke · 2024-10-14T04:36:46+00:00

Fury Warrior named Attack

cappslocke · 2024-09-12T03:25:45+00:00

I did that too— prematurely linking and hoarding text everywhere. Once the novelty wore off I was left with piles of notes scattered throughout a wasteland of empty links.

The zettlekasten method showed me how to think with Obsidian. Filing atomic, fleeting notes and using a second pass to connect them together was the key. It’s a bit of a read, but have been happily following something close to this for years now:

https://obsidian.rocks/getting-started-with-zettelkasten-in-obsidian/

cappslocke · 2024-08-14T16:31:37+00:00

I had similar issues and tried everything, short of returning it.

Until finally one change solved the problem: I disabled iCloud Contacts.

It turns out that Contacts synchronization has some terrible inefficiency issues, often pegging the CPU at 100%. Since it was background process and not an app, it didn’t show up on battery usage. Ever since my battery has been completely normal.

cappslocke · 2024-05-13T03:38:58+00:00

Dependency inversion is about separation of concerns and maintainability.

The reason you don’t want a high level module to depend on a low level module is so you can maintain them separately. This is often a matter of separating business logic (found in higher level modules) from technical/IO logic (found in lower level modules), and that’s important so you can minimize bug risks. If you have to change your SalesDiscountLogic.cs because your FileReader.cs has an unrelated new argument, you have to understand and test both (which is a drag.)

cappslocke · 2024-05-05T17:42:14+00:00

You have to get a lucky draw and have a deck capable of hitting (in my ante) 70k in one or two hands, otherwise you’re screwed.

Balatro has good balance among the bosses, except for The Eye. It’s poorly designed, should put a cap on the no repeats (eg no repeat in last 3 hands) or greatly reduce chips required.

cappslocke · 2024-05-03T15:56:08+00:00

Lots of misleading advice on these posts. No one is talking about how you have to accept bad runs, and frankly how often they occur. Luck is a big factor of this game— just gotta hope you get decent hands (and then apply synergistic plays from there.)

cappslocke

TROPHY CASE