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.
It's true that a company can't issue ISOs if the termination window is more than 90 days, they have to be NSOs instead. IMO the downside of the NSOs (pay tax immediately upon exercise instead of at next year's tax deadline - ISOs don't actually change the amount of tax that is due, just the timing of when you pay it) is small compared to the very real risk that your options will go poof if you don't have the cash to exercise and pay tax if there is a termination event.
No, by law ISOs just convert to NSOs at 90 days. Startups themselves decided to expire them, there is nothing preventing them simply allowing them to change. You get worse tax treatment, of course, but at least you get to retain the ability to participate in the upside.
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.
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.
Had no idea until recently that MariaDB supported this out of the box. Does anyone have experience using this? How does it compare to https://github.com/scalegenius/pg_bitemporal ?
I'm serious. Of course you don't test that language operations work, but you're testing that given method does what it's supposed to do. In this case your method sets value for property on model. It doesn't matter you're doing it via assignment - you could be doing it by any other ways. You want to test that for given model after calling that method your models property will change to given value. This way, if you'll change the implementation of setValue your test will still succeed. If it'll start doing something else, they will fail. And of course, this method can be used in your feature tests, so those will start failing too (but that's beside the point, I guess)
Of course it's also a balancing act - should you immediately write test for this? I try to.
Suppose you have a unit that makes a couple of api calls to set itself up, then performs a computation, then does some sort of storage. Thinking about how you would test this might lead you to an inversion of control approach, and you might isolate side effects. The storage provider might get passed in, both to make it easy to mock, and to reduce coupling and surprise.
Mainly it reduces surprise. If you call an interface with implicit dependencies, you won’t know if why it’s breaking without debugging and making sure it sets up its dependencies properly. If you call a testable interface with explicit dependencies, you can mock out those dependencies to debug parts individually.
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.