[defer]

Yeah, I mentioned it because I see peers doing different things to be productive during compilation times while newcomers will stare at compiler output. Some will jump to writing documentation, take care of issue management, work on some other ticket entirely, etc.

[spoiler]

I'm vastly oversimplifying the issue (also I'm not a doctor), but didn't studies show that this type of multitasking is bad for our mental health and increases the likelihood of burnout?

[simonh]

Not a doctor either, just going on articles I've read on this. The sort of multitasking that causes those problems is when both tasks need frequent attention. If you can essentially leave a task alone for several hours, with some sort of notification if there's a problem, that's fine. Even things that don't take much attention but are ongoing tasks, like doing the ironing, are fine depending what else you're combining it with.

[defer]

This resonates. I usually wrap my long running commands in something that sends a push notification when they finish so that I don't jump around seeing if things completed or failed. I find the distraction of the push notification less disrupting than continually checking for completeness.

[jfoutz]

osx comes with a command "say" which is a text to speech tool. I'd do things like make && say "build complete" || say "compile failed" with different voices I thought were funny. generally worked great.

One day, I stepped away and had a particularly intimidating voice say "your build has failed" and apparently knocked out my headphones. I came back just in time to hear that, and see a couple coworkers jump at the sound.

After that, I was much more consistent at disabling sound when I stepped away. I got a little teasing about that day, but generally it worked great.

[scns]

This is possible in Linux as well. The program is called speech-ng IIRC.

[boogies]

espeak-ng / espeak. But notify-send(1) mitigates the potential for scaring your coworkers.

[mrlemke]

I use espeak and it works on Termux too.

[defer]

I used a similar approach before working mostly remote, now I just curl to pushbullet to get the notification wherever I might be working.

[spoiler]

This is actually a great idea. I've used from-cli-notifications for things that I knew would take hours, but for coding related stuff I always think "it's not that long." So, I would immediately go into "active attention multi-tasking" and then recheck if the compilation tab finished, and then decide from there where to shift my active attention, without giving it some breathing room.

Lately I've actively tried not to do that (it's a hard habit to break, and I still feel guilt sometimes), though.

[spoiler]

This makes sense about moving your active attention to different object(ive)s. I think I slowly stopped doing "active" multitasking and switched to this low-attention multi-tasking once my burn-out got worse. FWIW: I don't think multi-tasking on its own caused the burn-out either, it was a combination of a few things probably.

[defer]

It's certainly possible, I honestly wouldn't know. Anedoctaly, I find it worse on my mental health to just sit around waiting for things to finish.

[jfoutz]

fast cycles are liberating, because it's easy to just ask the compiler or your testing harness if you're doing the right thing. I can't speak for the parent, but in my experience, typing isn't the hard part.

With slower cycles, I think more about how much to try before submitting work. Some times I feel comfortable pounding out quite a bit of code. Other times, I know there's some subtlety so I need to double check things. I don't want to stumble on forgetting a const declaration, or something silly like that. Iterations are slower, but you can spend time in flow thinking harder about each loop.

Although, sometimes, I do just stare at the console waiting for feedback. That's usually a good time to go to the bathroom and maybe grab a snack.

Not necessarily multitasking. Just being careful about what plates are spinning, and which I can set down or pick up between steps.

[zozbot234]

> fast cycles are liberating, because it's easy to just ask the compiler or your testing harness if you're doing the right

Type checking is still a very quick part of compile, so it can still support a "fast cycle" workflow if most simple errors are detected via incompatible types. You just need to go all-in on type-driven development, rather than simple reliance on unit tests.

[jfoutz]

ah, I alluded to that with "ask the compiler".

but yeah, types are great. Quickcheck is great too. But you'll have to pry my oracles from my cold dead hands. Computers show me over and over how stupid I am. Yeah, if I have a regression, I'm adding a specific test for that.

[ModernMech]

> newcomers will stare at compiler output.

I know at least for me, I sit in quiet contemplation and think while the project is compiling. I expect the context switch of going between writing docs and writing code on every compile would be too much for my brain. Is it managers making you feel like you need to be doing something else while your code is compiling? I guess I just never felt like I was being unproductive while my code was compiling.

[aaaaaaaaaaab]

I just browse HackerNews.