Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A trick to reaching flow: Leave your work broken

census.dev

Post reply on HN
Print view View original

161–170 of 196 posts

Re: A trick to reaching flow: Leave your work broken

#161

Post by The_Colonel »

zxexz wrote: post #135
adastra22 wrote: post #126

Earlier quoted context omitted.

What editor configuration are you using that saves undo history like that?

I’m not who you’re replying to, but I hope my input will be helpful. I just use Jetbrains IDEs on projects with the IdeaVim plugin (integrates so well with the IDE, it’s pretty much my only must-have plugin for any software, beyond uBlock Origin), and Vim for external files (scripts, etc., or when I want to use a specific plug-in for editing). By default IntelliJ (PyCharm, GoLand. any Jetbrains IDE…) has a pretty lar…

Intellij's local history saved my ass a couple of times.

Its git features are also quite comfortable. Very nice diff, I like very much the "Show history for Selection", live git annotate (with GitToolbox plugin). I don't often do rebase, but when I do the interactive rebase is also very helpful.

Re: A trick to reaching flow: Leave your work broken

#163

Post by The_Colonel »

augment001 wrote: post #24
JohnFen wrote: post #6

I've been using this "trick" for many years. An old mentor taught it to me, but he called it "park facing downhill". The idea is to leave the workday with the work in a state where there's an obvious and easy task to start the next day with, like parking your car facing downhill so that gravity will get you rolling before the engine is up to speed.

As an engineering director years ago I had the rule that engineers hours were 10am-6pm, and I'd walk around the office at 6pm and send people home. I'd get complaints that I was making people stop when they were in the middle of something, and I'd just say, you can carry on with it in the morning. It worked extremely well. Engineers just wanted to get on with their work as soon as they arrived in the morning. We'd ha…

> As an engineering director years ago I had the rule that engineers hours were 10am-6pm, and I'd walk around the office at 6pm and send people home.

Honestly, forcing people to any particular rhythm is a pretty bad idea unless things go out of hand.

Sometimes I'm in the mood to continue on the problem, and sometimes I'm too tired and would rather leave by 4pm. Why shouldn't I be able to decide?

Re: A trick to reaching flow: Leave your work broken

#164

Post by pl90087 »

withinboredom wrote: post #155
ozim wrote: post #146

Earlier quoted context omitted.

Still if you worked on something whole day you should have commits that someone could pick up. Let’s say that last note of the day does not have to go to repo. But I would expect some commit chain that would be useful produced and pushed.

Personally, I very rarely push commits unless I’m about to open a PR. A coworker fell off a ladder and broke both his arms. We had to look at his commits to figure out what he had gotten done. It was worthless. Absolute trash. His finished code was always top notch, but his WIP code … trash. It was easier to ignore it and start from first principles than to try and pick up where he left off.

If your philosophy is to do a PR at least every few days then the negative impact of this was likely negligible, especially comparing to have a fellow dev being out with having broken arms for a few months.

If you do PRs every few weeks then that could be a bigger issue. But then this should be a lesson to just not do that. Merge small steps often. It has tons of advantages.

Re: A trick to reaching flow: Leave your work broken

#165

Post by pl90087 »

augment001 wrote: post #73
yuuuuyu wrote: post #67

Earlier quoted context omitted.

That could backfire. Maybe they were in the middle of something hard that's difficult to pick up from. To use the metaphor, perhaps you would be forcing them to park uphill.

> Maybe they were in the middle of something hard that's difficult to pick up from. Certainly some of them said that, and I had to push for them to leave anyway. I also feel like that when I’m coding myself sometimes. But I think the of times when it’s actually true are vastly outnumbered by the times when it’s just an illusion, and it was obvious from the velocity and energy level that the policy worked.

If it's predictable, then everybody can prepare for it too and ensure they are in a downhill configuration when 6pm comes by.

Re: A trick to reaching flow: Leave your work broken

#166

Post by pl90087 »

augment001 wrote: post #75
yuuuuyu wrote: post #69

Earlier quoted context omitted.

Or it could be that you had a brilliant idea for the rest of the sentence, but the strict rule prevents you from writing it down, and next day you can't remember it and chase it all day and still be unsatisfied in the end. Either because of lost time or because you couldn't remember/recreate it, or even both. I suppose it just goes both ways. Try not to finish sth so that you don't have the somewhat hard task to star…

> A strict timing rule does only help if you are statistically more often at a point where it's easy to pick up again. I doubt that you are though, so I'd try a more concious approach than a clock. Although I disagree with you when it comes to corporate policy, I basically agree with you at a deeper level. I think that being able to be completely asynchronous about how and when you work, while also being unafraid and…

I like your attitude towards this.

One should try to create a study to investigate the effects better.

As alternative to "6pm you guys all go home, period.", there is likely a difference between "6pm you all go home, but if you really must finish sth, I'll wait until 6:30pm to pull the plug" and "go home whenever you want" (which may end up being 8pm or 10pm and in a game theoretic setting may lead to later and later time).

Re: A trick to reaching flow: Leave your work broken

#167

Post by pl90087 »

ambicapter wrote: post #110
yuuuuyu wrote: post #69

Earlier quoted context omitted.

Or it could be that you had a brilliant idea for the rest of the sentence, but the strict rule prevents you from writing it down, and next day you can't remember it and chase it all day and still be unsatisfied in the end. Either because of lost time or because you couldn't remember/recreate it, or even both. I suppose it just goes both ways. Try not to finish sth so that you don't have the somewhat hard task to star…

> A strict timing rule does only help if you are statistically more often at a point where it's easy to pick up again. I doubt that you are though You really think so? You think you spend the vast majority of your time at work doing things that are so complex they're hard to pick back up 12 hours later?

That's not how I read the comment. Between the "easy to pick up from here" (downhill parking) and "hard to pick up from here" (uphill parking) there is the most likely most common "indifferent" (parking flat). The main theme of this article is to try to always park downhill. So, an interruption that is anything than parking downhill is to be avoided. The claim is that you spend the vast majority of your time at work not facing downhill. Intuitively, that makes sense.

Re: A trick to reaching flow: Leave your work broken

#168

Post by adastra22 »

senbrow wrote: post #131
adastra22 wrote: post #126

Earlier quoted context omitted.

What editor configuration are you using that saves undo history like that?

Any decent editor if you don't close it/hard power off the workstation.

I was assuming he meant something persistent.

Re: A trick to reaching flow: Leave your work broken

#169

Post by dybber »

riemannzeta wrote: post #129

“Stop in the middle of a sentence, leaving a rough edge for you to start from the nest day – that way, you can write three or five words without being “creative” and before you know it, you’re writing.” — Cory Doctorow

Also known as Hemingway’s hack:

“The best way is always to stop when you are going good and when you know what will happen next. If you do that every day you will never be stuck. Always stop while you are going good and don’t think about it or worry about it until you start to write the next day.”

- Ernest Hemingway

Re: A trick to reaching flow: Leave your work broken

#170

Post by sanitycheck »

withinboredom wrote: post #144
barefeg wrote: post #139

Earlier quoted context omitted.

I also write in the code what I was doing so the code doesn’t compile. My only issue is that I don’t trust my computer, for me, if it’s not pushed in Git then it can disappear at any moment. If the work is not too important and I could easily re-create it from scratch the next day then I’ll leave it in my local Git. But if it’s important then I also want to push it.

The failures I've experienced in 20 years of spending ~8 hours a day with one: - SSD failure within moments of getting started for the day - backlight failure - mouse/keyboard failure - human failure (spilling coffee on the computer) Each time, I was out of commission until I got a replacement or the computer repaired and someone else had to pick up my work. If your computer becomes a brick, it doesn't really matter…

I've had all these plus PSU failure, network adapter failure, OS post-update self-destruction and more.

I push code a couple of times a day. If something goes horribly wrong I just pick up another computer, pull the code, and continue working while I wait for a repair/part for the main computer (or for an OS to reinstall).

If your computer becomes a brick, just use a different computer.

Post reply on HN