{
  "$type": "site.standard.document",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreibgfl7j7g36y3jzlomtoathtxjvarpuont3s4hy3pbp5t5qrr4oli"
    },
    "mimeType": "image/png",
    "size": 214233
  },
  "path": "/notes/sean-on-becoming-unblockable/",
  "publishedAt": "2025-12-30T00:00:00.000Z",
  "site": "at://did:plc:aes3lokiqtv63fk62nwnjeuf/site.standard.publication/3mnin5cnq2q2a",
  "textContent": "Do whatever it takes to have a stable and reliable developer environment. I don’t think it’s possible to overstate the importance of this. The stability of your developer environment directly determines how much of a workday you can spend actually doing work. For instance, use as normal a developer stack as possible. At GitHub, most development is done in Codespaces, a platform for server-hosted dev containers. You can connect to a codespace with almost any IDE, but the majority of people use VSCode, so I use VSCode, with as few plugins as possible2. I think a lot of developers are too focused on their personal “top speed” with their developer environment when everything is working great, and under-emphasize how much time they spend tweaking config, patching dotfiles, and troubleshooting in general. Fix developer environment problems as quickly as production incidents. If you can’t run tests or run a local server, don’t half-ass the troubleshooting process - focus on it until it’s fixed. On the flip side, don’t treat it as a leisurely learning experience (say, about how MacOS handles Dockerized networking). In many circumstances you’re probably better off tearing down and re-creating everything than digging in and trying to patch the specific issue. Tons of other great advice in here too.",
  "title": "Quoting Sean Goedecke on Becoming Unblockable"
}