

This is excellent article on enshitification, some of the factors that can lead to it, and ways founders could think about it to hopefully avoid it. What it doesn’t seem to talk about is how Tailscale intends to avoid it, now and in the future.
This is excellent article on enshitification, some of the factors that can lead to it, and ways founders could think about it to hopefully avoid it. What it doesn’t seem to talk about is how Tailscale intends to avoid it, now and in the future.
The joys of distributed algorithms. You can now get more errors, more quickly than before!
I remember writing a chat system in assembler, for DOS, using, IIRC, IPX networking. When it went wrong, one or more machines would just freeze, with the string “NETWORK ABEND” in the middle of the screen.
I should fork vim and call it ‘death’, so I can shout “give me vim or give me death!” any time someone suggests a different editor.
That has unironicaly made me nostalgic for the days when the web was a place of experimentation, joy and just a bit of crazy.
That depends on your team composition. Decoupling story points and hours means that the points indicate the complexity of the task; each developer might take a different amount of time to deliver that depending on their ability and expertise in that part of the system. The points give you a simple metric to show how much complexity the team have left to deliver, and tasks get assigned to whoever is best placed to deliver them at the time.