The online whiteboard of Kristofer Palmvik
Instead of copying the Spotify model, or model from another random company (e.g. FitBit, John Deere), grow your own Agile model. It is the only long-term path to success. Instead, focus on the things that Spotify had going underneath the hood
We identified a misconfigured Supabase database belonging to Moltbook, allowing full read and write access to all platform data. The exposure included 1.5 million API authentication tokens, 35,000 email addresses, and private messages between agents. We immediately disclosed the issue to the Moltbook team, who secured it within hours with our assistance, and all data accessed during the research and fix verification has been deleted.
Large language models are not neutral mirrors of the world. They systematically privilege wealthy, Western, and data-rich places while marginalizing much of the Global South. This project demonstrates that ChatGPT consistently ranks places like the United States and Western Europe more positively and portrays poorer regions as less desirable.
The most important teams in a B2B software company are engineering and sales. Full stop, no exceptions, no further questions. You’re either building the product or selling the product, and everything else is secondary at most.
Lambros distinguishes between two kinds of “brilliant jerks.” The first type is difficult but ultimately valuable: highly capable people who may be abrasive or “spiky” yet can be managed productively with the right structure. Then there is the second type, whose brilliance comes at the expense of others and who damages teams and relationships wherever they go.
I have a lot to say about this, but we are packing it up into something a bit more digestible, so I’ll just leave you with a few core beliefs that I think will be increasingly important in the age of AI.
The fundamental thread through all these roles is strategy. I believe strategic thinking will be the new constraint with AI. Strategy is not goals or vision statements. It is a clear path to achieve those goals. And it is always best done in a group with diverse perspectives.
A computer can never be held accountable. That’s your job as the human in the loop. Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That’s no longer valuable. What’s valuable is contributing code that is proven to work.
In my experience, when people are given accountability but not the reins to drive change, they disengage. Why pour your soul into something when your best ideas get vetoed by someone who isn’t even in the room? I’ve felt this sting myself early in my career. After six months of pushing boulders uphill, I stopped feeling responsible. The failures weren’t mine. They were the system’s.
Every name you choose shapes how easy or hard the future will be for yourself and your team. When tempted to accept vague or confusing names, remember: that choice echoes through dozens of files and months of development. Name it like your future self’s sanity depends on it. Because it does.
Don’t wait until you have another offer to communicate what’s not working. Don’t wait until your last week to document what you know. Don’t wait until you’re burned out to manage your energy strategically.
Top of the list, invariably, is communication skills. The best developers work to understand and be understood clearly and effectively. So much of what goes wrong in software development can be traced back to poor (or no) communication. Written, verbal, aural. They have good comprehension, they can articulate complex ideas simply to different audiences, and – most importantly – they actually communicate.
If I had to prioritise which ones to start with, I’d go with the start: Start at agreement and Give options. Both are really easy to do and are ‘quick wins’ so to speak. I’d then recommend to start experimenting with some of the techniques I shared in the cognitive dissonance section like reframing things as questions.
When team members are safe, can learn and adapt, share a common purpose, understand and support each other, and stay accountable to one another, you’ve got a healthy team. But a team only becomes high-performing as they create and maintain virtuous cycles that continuously improve health, allowing everyone to grow.
With stacking we’re introducing a lot of processes and tools. These obfuscate problems that we can solve at the level of people and how they work together. These can be harder to address, but the value in doing so is incomparably larger. Trunk based development doesn’t have all the answers, but the questions it gets us to ask are the right ones. And in my book, when it comes to software engineering, a good question trumps a complex answer every day.
Sarcasm can be hard to convey in writing but I hope you get the point of this article. Personally, I will not try to fix Apple’s bad design decisions in the websites I build. I will not follow any of the “advice” I just gave. Apple themselves are not following it either. I actually think the talented folks at Apple did their job as well as they could given the constraints of Liquid Glass™. So much thought went into it. It’s just a terrible idea for a design language in the first place.
Boring AI features are reliable AI features that feel invisible to users - they just work. Read only what you need. Constrain with clear rules. Act with structured outputs and safe tools. Explain what happened. Start with the smallest useful feature. Use the patterns that fit your use case. Monitor everything. Improve based on real user behavior, not theoretical performance metrics. The goal isn’t to build impressive AI demos. It’s to ship features that users depend on every day.
A collection of small, simple, single-task tools, mostly designed to help neurodivergent people with tasks they find overwhelming or difficult.
Every organization carries culture debt. The healthy ones pay attention to it. The unhealthy ones discover it only when the cost becomes too great to ignore.
5170 links collected between and