3 ms·

Nothing great has been achieved by teams where people shut down their brain after 6pm. Why do you think that the only options are: 1. Thinking about work

Nothing great has been achieved by teams where people shut down their brain after 6pm. Why do you think that the only options are: 1. Thinking about work or 2. Shutting your brain down If I want to go hack on some Clojure after work, when the day job is in Python, then what's wrong with that?

Galanwe 4y ago
> If I want to go hack on some Clojure after work, when the day job is in Python, then what's wrong with that? That is of course perfectly fine, but to me that represents a not-so-ideal fit between your interests and your job. Realistically, you will spend more engineering time on your job than on your hobby project. From my experience, that means my out-of-working-hours projects tend to be driven by needs or limitations I encounter at work. I then find it more optimal to embrace and leverage that relationship between during-working-hours and out-of-working-hours projects. This is the best of both worlds, you get work on more green field projects, have flexibility to choose what you work on, under the constraint that it solves something for your job, but under the assumption that your side projects are anyway often inspired by work, it's a fit by construction. Let me give you an example: Some years ago I used to manage some high performance computing cluster, with storage nodes attached to compute nodes as the jobs were very IO intensive. We used glusterfs, which at the time got acquired by RH and maintenance stopped. Me and a coworker started to dig into glusterfs to solve our issues. We spent months reading the code on our free time, reading papers on distributed filesystems, fixing issues in our fork (hoping that RH would pick up maintenance after the transition). That's an example of an out-of-working-hours project, inspired by work, that got used at work, and thus counts as work, while still being very interesting. This is just an example, but overall I kept that mentality and have been doing that kind of things for more than a decade. You just need to find the right job where you have 1) interesting problems to solve that inspires you to do more 2) the freedom to push your projects 3) the drive to work out of office hours to prove that your projects are worth it and push them. All the colleagues I have respect for do the same. And someone that does not have this spirit, for me, is not someone I want to work with.
- quanticle 4y ago
  That is of course perfectly fine, but to me that represents a not-so-ideal fit between your interests and your job. If the day job were Clojure, I'd be hacking in Python in my spare time. Or some other language (Rust, Haskell, etc.). Or not even hacking at all, but reading a book, or doing something else. The entire point of having hobby projects for me is that they're not what I'm working on during the day. They're an opportunity to broaden my horizons. Me and a coworker started to dig into glusterfs to solve our issues. We spent months reading the code on our free time, reading papers on distributed filesystems, fixing issues in our fork (hoping that RH would pick up maintenance after the transition). That just sounds like a lot of unpaid overtime to me. It sounds like you enjoyed it, but I'd find that experience absolutely miserable. Working intensely on a project is great, but I need time where I'm thinking about something completely different, otherwise I burn out fast.

Galanwe 4y ago

> If I want to go hack on some Clojure after work, when the day job is in Python, then what's wrong with that? That is of course perfectly fine, but to me that represents a not-so-ideal fit between your interests and your job. Realistically, you will spend more engineering time on your job than on your hobby project. From my experience, that means my out-of-working-hours projects tend to be driven by needs or limitations I encounter at work. I then find it more optimal to embrace and leverage that relationship between during-working-hours and out-of-working-hours projects. This is the best of both worlds, you get work on more green field projects, have flexibility to choose what you work on, under the constraint that it solves something for your job, but under the assumption that your side projects are anyway often inspired by work, it's a fit by construction. Let me give you an example: Some years ago I used to manage some high performance computing cluster, with storage nodes attached to compute nodes as the jobs were very IO intensive. We used glusterfs, which at the time got acquired by RH and maintenance stopped. Me and a coworker started to dig into glusterfs to solve our issues. We spent months reading the code on our free time, reading papers on distributed filesystems, fixing issues in our fork (hoping that RH would pick up maintenance after the transition). That's an example of an out-of-working-hours project, inspired by work, that got used at work, and thus counts as work, while still being very interesting. This is just an example, but overall I kept that mentality and have been doing that kind of things for more than a decade. You just need to find the right job where you have 1) interesting problems to solve that inspires you to do more 2) the freedom to push your projects 3) the drive to work out of office hours to prove that your projects are worth it and push them. All the colleagues I have respect for do the same. And someone that does not have this spirit, for me, is not someone I want to work with.

quanticle 4y ago
That is of course perfectly fine, but to me that represents a not-so-ideal fit between your interests and your job. If the day job were Clojure, I'd be hacking in Python in my spare time. Or some other language (Rust, Haskell, etc.). Or not even hacking at all, but reading a book, or doing something else. The entire point of having hobby projects for me is that they're not what I'm working on during the day. They're an opportunity to broaden my horizons. Me and a coworker started to dig into glusterfs to solve our issues. We spent months reading the code on our free time, reading papers on distributed filesystems, fixing issues in our fork (hoping that RH would pick up maintenance after the transition). That just sounds like a lot of unpaid overtime to me. It sounds like you enjoyed it, but I'd find that experience absolutely miserable. Working intensely on a project is great, but I need time where I'm thinking about something completely different, otherwise I burn out fast.