The online whiteboard of Kristofer Palmvik
A professional is expected to finish the work neatly and clean up after themselves. Leaving a mess behind is not only rude, it makes future work harder, adds more work for someone else, and can even be dangerous.
Dependency cooldowns are a free, easy, and incredibly effective way to mitigate the large majority of open source supply chain attacks. More individual projects should apply cooldowns (via tools like Dependabot and Renovate) to their dependencies, and packaging ecosystems should invest in first-class support for cooldowns directly in their package managers.
Most applications don’t fail because algorithms are hard—they fail because our models allow states that make no sense in the domain. “User without email but verified”, “order that’s both shipped and cancelled”, “sum < 0”, “modal dialog both closed and active”. These states should be impossible from the start.
Concrete thinkers zero in on tangible details. They take things at face value, prefer clear steps, ask “how” and “what,” and anchor on specifics like flight times, budgets, or examples. Abstract thinkers reach for concepts and patterns. They ask “why,” connect ideas across domains, and zoom out to purpose, meaning, and future possibilities.
Easily back up, organize, and manage your photos on your own server. Immich helps you browse, search and organize your photos and videos with ease, without sacrificing your privacy.
When teams produce code faster than they can understand it, it creates what I’ve been calling “comprehension debt”. If the software gets used, then the odds are high that at some point that generated code will need to change. The “A.I.” boosters will say “We can just get the tool to do that”. And that might work maybe 70% of the time.
The idea of making impossible states impossible basically means that situations and questions like these should never come up. It means that you design APIs that make a clear distinction between the possible states of a component. This makes the component easier to maintain and to use.
GitHub no longer uses toasts because of their accessibility and usability issues.
In my time observing managers, one observation seems to repeat again and again: good managers write well, and bad managers write poorly. In fact, the best managers I’ve ever seen were not just good writers, they were terrific. And the worst managers I’ve ever had were not just bad writers, they were uncommonly bad.
Nobody is going around saying that having more than one doctor treating a patient is crazy or inefficient. I wish that software organizations who turn up their noses at pairing and ensembling would open their minds and see the huge benefits.
I’ve seen teams with world-class tooling still struggle to deliver quality because they lacked trust, shared ownership, or psychological safety. And I’ve seen scrappy teams with minimal resources ship robust, reliable products, because they communicated well, embraced feedback, and held each other accountable.
I had originally planned to write a proper deep-dive series walking through a handful of features I worked on in .NET 10: complete with design notes, trade-offs, and the fun weird corners. But, as happens, other things got in the way, and .NET 10 ships tomorrow, so I’m running out of time to cover everything. So instead of a whole series, I figured I’d just dump it all out in one big post. Let’s start with one of the bigger features.
Here’s what works for me: a simple, repeatable structure that I use every single week. It’s based on the popular People, Product, Process format (which I also use for measuring engineering productivity). I’m going to give you the exact script I use, the Notion setup, and some ideas for how to handle each section.
The evaluation revealed what happens when you rethink fundamentals. SolidStart, SvelteKit, Qwik, and Marko represent different architectural priorities that push boundaries in ways the dominant frameworks cannot. Competition drives innovation. These alternatives show what’s achievable when mobile web performance is the primary design constraint, not an afterthought.
Most human economic activities release greenhouse gases into the Earth's atmosphere. We use satellites and other remote sensing technologies to spot these emissions activities
This post isn't a theoretical lecture; it's a practical guide based on experience and evidence. Let's explore how each of these eight wastes shows up in software development, and how to spot (and stop) them in your team.
Zed's goal is to make your codebase a living, navigable history of how your software evolved, where discussions with humans and AI agents are durably linked to the code they reference and always up-to-date. It's an evolution beyond version control that incorporates not just the code itself, but also the background information of how and why the code got into a particular state—context that AI agents can query to make more informed edits, understanding the assumptions, constraints, and decisions that shaped the existing code.
So how are you systematically checking that the output your product spits out is good? Smart product/AI leaders have been shouting for months about how AI product managers need to get good at building evals (Lenny Rachitsky, Aakash Gupta, Teresa Torres, Hamel Hussain & Shreya Shankar, to name a few). So I’m shocked to see how many AI product builders have not thought this through, and leave it at a random vibe-check every now and then.
The engineers leaving know something executives do not. They know which technical decisions are failing, which processes waste time, and which management practices create disengagement. This information exists within the organization but does not reach executive level through normal channels because hierarchies filter information and middle management has incentive to suppress bad news.
The rise of AI prototyping tools is a reminder of what design truly involves: not just arranging pixels or chasing fidelity but interpreting context, establishing priorities, and creating nuance. The real work of design remains in the judgment, empathy, and intent that only human designers can provide.
5131 links collected between and