I originally wrote this as a response to some comment, but it applied to multiple different threads, so I figured I'd post it top-level instead: I found a job

I originally wrote this as a response to some comment, but it applied to multiple different threads, so I figured I'd post it top-level instead: I found a job where I worked remotely and people legitimately cared about what I accomplished over weeks and months without even seeing how long I worked each day. I took full advantage and worked weird but not particularly long hours. Counterintuitively, this helped me do more: I wrote maintainable code with fewer bugs, so, once I had a solid foundation, I could do experiments and add new business logic fast. Based on code I've seen on other projects, it's not hard to imagine a different codebase doing the same thing where a one-day feature in my world would have been a two-week feature instead. Now I'm sure you're thinking to yourself that I'm exaggerating, but I've absolutely seen teams and projects with this kind of productivity delta. It's always hard to convince people about counterfactuals, but in software "slow is smooth and smooth is fast" is absolutely true. If you take your time and avoid unnecessary deadline pressure up-front, you will average substantially less time on new logic and debugging. The difficulty, of course, is that when you do this right it looks like you're solving easy problems while the team that coded themselves into a corner and constantly have to fight fires look like heroes burning the midnight oil. (There's the cult of overwork again!) It helped that I ended up contrasted with somebody who took on a lot of responsibility only to strew overcomplicated garbage across multiple parts of our codebase. The rest of the team took a depressingly long time to recognize the problem, but it eventually wasted too much of everyone's time to ignore. I am not sure that anything short of a painfully tangible demonstration in this vein would convince people without direct experience that the dynamic I'm talking about is real and important! Anyway, working reasonable hours actively helped me do better work and I am convinced this is true for most software work and most people. As a bonus, it worked out pretty well for me, I got promoted. I still have reasonable hours but the work is now far more people-oriented which means my impact, if anything, is even less related to my hours! What I'm realizing is that if you're a manager and you want to build a resilient and productive team, you actively do not want your ≈staff engineers and data scientists working anything that even resembles long hours! But that's a post for another day... The moral of the story is that it's possible to find teams which legitimately care about output rather than input, which will let you have a solid salary with great hours. Unfortunately I still have no idea how to evaluate teams on this axis as a job candidate; I just got really lucky stumbling into this particular job. I'm not sure how to reproduce that for future roles (always looking for suggestions!), but at least it's nice to know that such teams do exist.