The online whiteboard of Kristofer Palmvik
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.
Rebuild is a sprint for European social platforms. Connecting the entrepreneurs, the pioneers, the investors and the digital leaders building the next generation of social platforms.
I wish the AI coding dream were true. I wish I could make every dumb coding idea I ever had a reality. I wish I could make a fretboard learning app on Monday, a Korean trainer on Wednesday, and a video game on Saturday. I’d release them all. I’d drown the world in a flood of shovelware like the world had never seen. Well, I would — if it worked.
Barring legal issues, it’s better to be transparent up-front about re-organisation. This should include the rough process you intend to go through and a rough timeline. Being transparent shows that you respect people, allows you to recruit help, and avoids the “this came out of nowhere” problem.
Han arbetar en hel del med ingenjörer och personer intresserade av ny teknik. Han betonar risken med att generalisera, men tycker ändå att det bland dessa finns en överdriven vilja att låta tekniken driva utvecklingen, snarare än användaren.
A “feature” is never just a button or a feed; it’s a nudge in a complex human ecosystem. When we optimize for convenience or connection, we often trigger second-order effects that are difficult to unwind.
The answer isn't to retreat to 2002 and plain text files for agents to parse. It's to build what actually solves the problem: content infrastructure that AI can read, write, and reason about. You shouldn't build a CMS from scratch with grep and markdown files. You probably shouldn't have to click through forms to update content either. Both of these can be true.
5165 links collected between and