alecbenzer

Been at 2 series A/B startups for the past ~3.5 years. It was a really fun 3-6 months followed by 3 very not fun years.

My N is low, they were both non-Bay (NYC) startups, maybe some startups are fun, maybe I'm really bad at picking startups, but I think a startup's culture is often as much or more of a crapshoot than the startup's business.

Was at Google before, and it was fun for only a bit as well, but definitely not as actively non-fun as my last 3 years has been.

AFAIK the 90 day thing was more of a legal thing than something the companies themselves wanted to enforce?

What makes you say this is 80:20? The thing that got him out of the funk was fixing a minor UI issue:

> Once he asked me "Father, what is this thing in the list of things I can order?" ... "This is atomic bomb" .. "Oh, I want to order it" .. "No, we don't even have it researched" .. "But, why is it in the list then, it doesn't make sense" ... "Hmm, you are right, it doesn't, I might actually fix that." So I opened Factorio source code after a long time, and made the change, that the filter and logistic request selections didn't contain things yet to be researched (unless you force-unlock it in the settings). I made a change to Factorio, and it felt good, and I started to want more, this is how I got from the lowest point.

He didn't get back into it because the problem was particularly meaty or interesting to work on. It was a small piece of work that nonetheless allowed him to feel like he had impact. Because he was connecting with someone who was actually engaging with and getting joy from what he was building (and it might have helped that the person was his son).

I guess it's possible that what initially put him into the burnout was working on tedious things that felt like they had no substantial impact (though nothing in the post really indicates that IMO). But, that doesn't mean that this isn't burnout. Burnout is exactly caused by a felt loss of control and/or impact.

> Not only does that seem relatively simple

I haven't thought about this too deeply, but I think "simple" is overstating it. Being able to turn on versioning for any table by basically just pushing a button seems really powerful.

There's application-layer stuff like paper_trail for rails that can do this for you, but you're stuck if your language doesn't have a good one.

Building it into the db also means that any out-of-band direct edits to the DB also get tracked.

Can't tell if serious...

but BeSt PrAcTiCeS

I meant expand on how those things make code easier to understand, not why unit testing causes you to adopt them.

Yes but discovering those hypothetical defects is usually less important than discovering the actual, currently present defects.

Compared to integration testing and end-to-end testing.

> Loosely coupled code is also easier to reason about and easier to refactor.

Can you expand more on this? I think this is where the author would disagree.

E.g., how is the code easier to reason about or refactor having introduced a location service interface that has only one one implementation?