The online whiteboard of Kristofer Palmvik
In my experience, it’s still possible to be a “high performing engineer” at 80% effort. In fact, it’s easier, because you’ll be less likely to make silly mistakes from stress, and you’ll be in a position to jump on the kind of high-impact tasks that deliver outsized returns.
LCP measured when including soft navigations is slightly faster on 25 of 43 sites. The typical change is small, but some sites see massive changes: Blocket’s LCP goes from 1.1s to 0.5s and SJ’s drops from 4.1s to 1.4s
Two things are going on in the collaboration world that are making this problem worse. First, people are becoming less collaborative. AI has this magical way of convincing everyone that they are auteurs who just need to be unblocked so they can realize their vision.
In the end, we only need to challenge our identity if we mistake programming for writing code. AI finally allows us to separate the two. And that’s where all those years of experience transfer the best: knowing not only what to build but how to build it well.
Hiring someone is expensive. It usually takes at least 6-9 months for someone to learn a new job. And at least 18 months to get really good at it. That is a significant investment. A learning review for an employee departure would bring manager(s), HR representatives, hiring manager, hiring interviewers, possibly team members, and others into the same room to explore questions like these
I’ve managed maybe 100+ engineers over the last 20 years and I can tell you: whatever this mythical “it” is, a large fraction of the it’s it was absoTOOTely about it’s code. Who are these crazed engineers that didn’t care about the code??? And how did they get hired??? I just don’t believe them.
We already know how to do this. It’s a fairly ordinary SDLC, made explicit enough that an agent doesn’t have to guess the important parts. Write down what good looks like, settle the product decisions and system choices that matter, then let one Builder build. Before believing it’s done, get a fresh reviewer to read the spec and actual diff, and have QA open the actual product and try it. Real failures go back to the same Builder. You still decide whether to ship.
I don’t believe that durable software engineering is going away. In fact, the total amount of durable software seems likely to expand enormously in the future, thanks to the incredible capabilities we have with AI. But there’s also a whole new world of Disposable Software, and we have to learn to support it, embrace it, and differentiate it from our durable systems.
Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped. If you deploy your system, but your manager or VP or CEO is very unhappy with it, you did not ship. (Maybe you shipped something, but you didn’t ship the actual project.) You only know you’ve shipped when your company’s leadership acknowledge you’ve shipped.
Making your team happy is not the job. Someone who can’t handle disappointing their direct reports or making them upset will never be an effective leader. Frustrating people and telling them “no” is part of the job, because growth is hard and part of your job is to challenge people. How they feel about this is under their control, not yours.
We should be spending some of our productivity gains on things that seem like slowing down: meetings, design reviews, conversations. These ways of maintaining alignment, sharing knowledge, and creating human connections are, in my opinion, more important than ever to creating good outcomes at scale.
The problem is not simply where people work. The problem is whether the organization has created the conditions for good work to happen without relying on proximity to compensate for what is missing.
There is one angle here that we can talk about that most other places won’t: whether hosting the livestream would violate the platforms’ own rules — and whether they’ll simply ignore (or rewrite) those rules to do it anyway. While it’s probably perfectly legal in the US to stream the execution, it still might violate the various platform rules that most sites have set up for themselves.
A vibe coded app is, in human hours, not only a few days old but closer to two or three years old. If a brush engine or transform tool works badly after the human equivalent of three years of development that is a demonstration of bad planning or an AI model not doing a good job.
Image editing, vector illustration, video, photography, PDFs, motion graphics and page layout. Native, open-source apps from the ArtCraft team, built in Rust and free to use.
It’s well known that Boston needs to decline many applicants who actually qualified, since it doesn’t have permission to add runners. Long-time readers know the mantra: Tell me what constrains you, and I’ll tell you where your strategy should focus. Hyrox went indoors, which removes weather, road closures, and permits in one move.
5320 links collected between and