Git configs that make sense, PostgreSQL architecture made simple, and 13 engineering laws that hit too close to home
This is a long read but worth it if you have just started working on Postgres and want to know the Postgres internals at a high level. I really liked the MVCC section where the author has done a great job of explaining it in simple words. The Index section also provides a good summary of various types of indexes and use cases where they are suitable. Overall a great read.
👉 Read the entire post here
Even Git’s core developers don’t use it stock. They tweak a bunch of settings to make it sane — like showing the full diff when writing a commit message (commit.verbose = true) or sorting branches by most recent commit (branch.sort = -committerdate). This post breaks down the must-have git config changes that make Git actually usable — no aliases or shell hacks, just vanilla Git made better.
👉 Read the full post here
The AI hardware war is heating up. NVIDIA’s grip on the market isn’t just about raw GPU horsepower — it’s the stranglehold of CUDA and an unmatched software ecosystem that keeps everyone else playing catch‑up. AMD’s throwing in high‑VRAM contenders, Intel’s making a comeback with Gaudi, and Big Tech is rolling out in‑house silicon. Even scrappy startups like Groq and Cerebras are taking swings.
But here’s the billion‑dollar question: Can anyone actually challenge NVIDIA without first replicating its biggest moat — its software stack?
In this breakdown, I unpack:
Whether you’re building AI in‑house, or just trying to make sense of this fast‑moving landscape, this read gives you the map — and the minefield.
👉 Read the full post here
Parkinson. Conway. Zawinski. Hyrum. Sturgeon. Goodhart.
No, this isn’t the cast of a bizarre startup sitcom — it’s a powerhouse lineup of mental models every software engineer and manager should have in their toolkit.
This post walks through 13 laws — from famous ones like “work expands to fill the time” to lesser‑known gems like “with enough users, even your bugs become features.”
Each law comes with real‑world engineering context, why it matters to you, and in some cases, a painfully accurate xkcd or comic that will hit too close to home.
Warning: Once you read this, you won’t be able to unsee these laws in action in your own team.
Whether you’re managing engineers or still pretending you don’t need a manager, this one’s worth your time.
👉 Read the full post here
Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
Personal projects won’t prepare you for this. Open source won’t either. Working in large, mature codebases — millions of lines deep, over a decade old, with hundreds of contributors — is a different beast altogether.
The biggest trap? Writing “clean” code that ignores legacy conventions. It feels good in the moment but silently makes everything worse. In big systems, consistency beats cleverness. Always.
Before adding that API endpoint or auth check, stop. Dig through the minefield. Reuse helpers, even if they’re ugly. Stick to the established weirdness. Why? Because that weirdness hides decades of edge cases that your neat logic will walk right into.
This piece by Sean Goedecke is a must‑read for any engineer working in (or dreading) legacy code. From testing strategies in unpredictable environments to being ruthless about deleting dead code, and resisting shiny new dependencies — this is real talk from someone who’s spent 10 years in the trenches.
If you’ve ever thought, “Why not just rewrite it?”, read this first.