141–150 of 196 posts
Earlier quoted context omitted.
I don’t usually leave notes, I just leave the last thing I looked at in whatever arbitrary failure state it was in, unsaved, with whatever undo history I stopped at. If the errors aren’t immediately obvious, a couple cmd-Zs is usually all it takes to jog my memory and at least start retracing my steps
What editor configuration are you using that saves undo history like that?
Earlier quoted context omitted.
6pm? Man, I’m so glad I didn’t work for you. That is late.
This is big generalisation. In South Europe leaving at 6pm is early. Most of the people I know have standup after 10h30 and do 1h lunch breaks.
Earlier quoted context omitted.
I don’t usually leave notes, I just leave the last thing I looked at in whatever arbitrary failure state it was in, unsaved, with whatever undo history I stopped at. If the errors aren’t immediately obvious, a couple cmd-Zs is usually all it takes to jog my memory and at least start retracing my steps
What editor configuration are you using that saves undo history like that?
https://stackoverflow.com/questions/2985050/is-there-any-way...
It really saves the whole tree, not just the path that was active at the time of exit.
If I need to stop in the middle of something, I’ll often write directly in the source code, at the point where I stopped, exactly what I was working on and what to do next. I don’t comment out these instructions to my future self so when I sit down next, the project won’t even compile.
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.
- 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 what you thought you wanted to do next.
If I need to stop in the middle of something, I’ll often write directly in the source code, at the point where I stopped, exactly what I was working on and what to do next. I don’t comment out these instructions to my future self so when I sit down next, the project won’t even compile.
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…
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.
For about 18 months I commuted to work through public transport and I had to adhere to bus/metro timings or risk reaching home couple of hours late and earn the wrath of family. This meant two things 1) I drastically cut down on non-productive tasks while at office and 2) I often had to get up from desk with solved but half-finished work. So when I reached work the next day I didn't have to think what to do, I had an extremely well scoped work to start the day. It's as if a chef walking into kitchen finds all the cutting/dicing done and recipe laid out in front, he just needs to start cooking.
The net result being it was perhaps the most productive period of my career and it coincided with the hyper growth phase of the startup I was working for.
I've heard about the idea in this post often in other contexts (e.g. writers stopping in the middle of a sentence), but I've always been the type of guy who likes everything to be clean when I stop for the day. But that does indeed make it very hard to know where to start the next day (or even worse, two weeks later when coming back from vacation). Sometimes it takes me days to get back into the work and it doesn't feel good.
I will definitely try this out.
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.
I like that expression, but this could also mean leaving things not broken, but in a ready state for the next phase.
Personally I don't like logging off with things broken. I like logging off with things in a good state so I can jump in next time knowing everything up to this point is good.
Ohhh, this makes sense. I must try that. Up until now I was doing the exact opposite - trying to finish the task or at least drive it toward some clean state. Mainly to not block others if I am close to completion.
Ditto; I remember reading somewhere to try and finish the day on an accomplishment, so that you've got a pleasant taste in your mouth about the project. Given how long ago it was, though, maybe the article was about personal projects instead of work.
This is the way. I can't believe people are actually endorsing leaving things broken as a positive way to end the day. It's a hard disagree from me on that idea.