guina's comments

HN isn’t letting me edit my comment so here’s some additional stream of consciousness from me.

There’s definitely trade offs to sharing types, especially if the API and clients are in different languages. If your team is small enough and has enough context on API changes it’s probably easier to maintain different types. But if it’s large or spanning multiple teams it might be better to rely on tooling to share or generate types. It’s always about trade offs.

IMO the question to be asking is “how do we reduce risk of second and third order effects of changing the API, regardless of whether the change is intentional or accidental.” In your model, any clients consuming the API would have runtime errors if there are breaking changes because the types/data structures are maintained independently. These runtime errors might be tough to debug. Hopefully you know there are breaking changes coming so you can prepare for when the API change is deployed. If it’s a regression then maybe you get an incident. In the shared type/data structure model the error happens at compile time because the rest of your app doesn’t know how to consume the breaking type change. You know what broke because now your client won’t compile. There may still be runtime errors if the API was deployed after the latest client deployment, but generally it’s easier to surface where the regression/change happened because the types are shared.

I think many people prefer the compile-time error surfacing.

There’s definitely trade offs to sharing types though, especially if the API and clients are in different languages. If your team is small enough and has enough context on API changes it’s probably easier to maintain different types. But if it’s large or spanning multiple teams it might be better to rely on tooling to share or generate types. It’s always about trade offs.

I mostly agree with you but want to provide a little disagreement.

It’s not a dream job everywhere for every person. Not everybody is able or has the ambition to put in the work needed to be a top earning or top skilled developer. And even if you are a lot of the “dream” aspect of the job will depend on what country you live in, even in a remote-first world.

But if you’re in America it’s one of the last professions where the American Dream is still possible.

It’s a trade, so the better and more experienced you get the more money you can demand if you’re ambitious. Software also scales better than any business so your work can have an incredibly high level of impact.

I’d argue a vast majority of the “productivity industry” is ironically just procrastination.

I can’t really force deep thinking for myself. Instead it comes spur of the moment when I’m away from my work. A solution to a problem or a compelling idea will pop into my head, and when that happens is when I’m in the headspace to think deeply.

This is a little different from Flow states I get into when I’m _already_ working. Usually in my work Flow states I’ve already had my spur-of-the-moment-deep-thought and now I’m just implementing in a Deep Work state.