The online whiteboard of Kristofer Palmvik
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.
Interview synthesis is cognitively challenging. It takes time. And that's time that many teams simply don't have. That's why I'm not surprised to see so many teams turn to generative AI for help with interview synthesis. But this worries me.
I'm glad native JSON importing feature exists, but it should be used with care, and not as a blanket replacement for fetch()ing JSON.
Turning a feature on doesn’t guarantee people will use it. Adoption depends on motivation, action, and recovery when things don’t go perfectly. This one banner illustrates three lessons product teams can apply right away.
Answer a few simple questions to explore better ways to make group decisions. There are lots of group decision-making models. Explore each and find one that works well for your group's needs and circumstance.
In order to [thing], I’m choosing [x important thing] even over [y important thing]. This tool can come in handy for both work choices (should I choose to optimize for speed, or quality?) AND for personal decisions (like choosing a new role).
Individual work does keep individuals as busy as possible. It does so at the expense of having clear status, rapid completion, and reliable schedules. Also, though, you have individuals too busy to help or teach each other. This means each person needs to self-train in their off-time or just make do with what they already know. There is precious little on-the-job training.
This all means that I value a strong coupling between skills and individuals, and I don’t see the kind of “Superhuman” AI engineer who can wear every hat having very much purchase beyond the earliest prototyping stage of a project. I think it’s a good idea to walk fast in the opposite direction, diversifying teams and deepening niches.
Time, and CSS, have rolled forward, and guess what? There is more this year than there was last. At least in this somewhat arbitrary list of “things Chris thinks are valuable to know that are either pretty fresh or have enjoyed a boost in browser support.”
We like to know someone cares (for real) for what we do. Not because they want to catch us red-handed (when we've screwed up something), but because it means that what we do TRULY MATTERS.
I sometimes sense traces of arrested development in how organizations behave. Cameras stay off in remote meetings, microphones are muted by default, and people raise their virtual hands instead of speaking freely. Silence follows every “any thoughts” question, and meetings end with the familiar “alright, back to work” comment. Leadership may speak warmly about autonomy, yet always with the authoritative constraint that “it requires clearly defined boundaries”.
How can I trust someone to deliver a proper solution if (s)he can't express it in an objective, clear and unambiguous form first? Unfortunately, the writing skill in the vast community of software developers is pretty much extinct. As it is essential, it has to be rebuilt and embedded into our work cultures: by setting up good practices, active coaching, highly visible role models & examples.
In all of these cases, AI “works great” for person 1, and is a burden to person 2. Person 2 could: see their time wasted, be forced to explain themselves for words they didn't use, risk being fired or worse. It may have legal consequences.
1. Write a list of the test scenarios you want to cover. 2. Turn exactly one item on the list into an actual, concrete, runnable test. 3. Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them)- 4. Optionally refactor to improve the implementation design 5. Until the list is empty, go back to #2
Worshipers from all the world's major religions are experimenting with chatbots. But Hinduism, with its long tradition of welcoming physical representations of gods and deities, offers a particularly vivid laboratory for this fusion of faith and technology.
When I have free time, I often find myself asking: what can I do with my website today? I suspect many other people passionate about their websites will ask this question, too. This post is an answer to that question for its readers.
A couple of days ago I enjoyed reading James’s list of things to do on your website and, as he suggests by the end, I thought of a few more to add to the list. These are things I’ve either already done here or thought about doing but decided not to, or plan to eventually do.
5120 links collected between and