Ask HN: Picking up where you left off strategies? | Hacker News Reader

Ask HN: Picking up where you left off strategies?

7 pointstmaly8 comments

I often start to learn something new or start on a new project and then a fire drill happens. I have to drop everything and context switch.

When I get back to the learning or the project, there is some friction to picking it back up where I left off.

What strategies can you suggest that would help speed up the process of picking something up where you left off and being able to hit the ground running?

View on HN

At work we have an asynchronous standup meeting every morning. I found it pretty hard because I spend the intervening time thinking about other things and my memory isn't 100% clear about where I was last night.

In contrast I am often really engaged with what I am doing at quitting time and have a very good idea what I am going to do next.

I reconcile this by writing my standup report with sections titled "I did..." and "I plan to..." at the end of the day with the expectation that these won't align 100% perfectly.

This is not only good for explaining to the team what I am up to but it in the morning it helps me get back up to speed.

For side projects I:

(1) use a limited range of tools and get into good habits when it comes to setting tools up. For instance you can get driven crazy with Python if you don't have good habits with venvs. Doing a side project to "learn a new programming language" is an almost certain way to make a project that accomplishes nothing else. I use the same tools I use at work as much as I can.

Almost everything I write has a configuration file in a ".something" directory in my home directory, since I've made it a habit it is easy to clone my code on a server or another dev machine, create a new instance.

(2) I write a lot of runbook documentation and I'm also disciplined about project setup. Sometimes I dread bringing a project out of mothballs after 9 months but time and time again I find my docs, follow them step by step and I up 'n running pretty fast.

Great answer.

> (2) I write a lot of runbook documentation and I'm also disciplined about project setup. Sometimes I dread bringing a project out of mothballs after 9 months but time and time again I find my docs, follow them step by step and I up 'n running pretty fast.

I'm trying to get better at this.

  cd ~/workspace/project && git status

and I have a bunch of stuff from 2 months ago that I haven't committed and have no context on so I waste a bunch of time trying to figure out what I was doing.

do you use any specific modules for runbooks or just simple scripts?

I've never been a fan of chef, vagrant, puppet, ansible and tools like that. They don't relieve you from the responsibility of knowing how to sysadmin and knowing bash so I don't find them worth it.

Ideally my "runbook" has text instructions to download and run a script, otherwise it has more steps.

The hierarchy of tools I'd use for automation is:

  * bash
  * python
  * java

An unusually complex one I built constructs and tears down systems in the cloud that do some work, such as booting up a AWS instance that contains a database server, building a large database, then making an AMI. The Java program sets up the instance and the resources the instance needs and writes a bash script that the instance runs when it boots up. When the instance is done doing its thing, it posts a message to the Java program that shuts the instance down, makes the AMI, etc.

I use virtual machines that can be paused. I can freely go to different tasks without too much friction.

You should also document all steps that got you to a certain point, so they can be quickly recreated.

What's the timescale you're talking about? It's completely different to pick up a project after 3 hours VS 3 months.

On shorter timescales, I think it makes most sense to just... not break off. Obviously you can't always control that, but I've found it's better to schedule several hours reserved for deep work, rather than try to fit it here and there.

For anything longer, basically it's documentation. One approach that works well for me, is creating a new Notion page for each project, and keeping short status + next steps at the top, so whenever I come back to it I can easily see where I've been.

If it is several months, and there was a lot of setup knowledge one has likely forgotten, how do you handle those cases?

I keep notes as I work, so it is easier to know what I was doing before, or grepping how I solved that problem that happens every 6 months.

For programming, using a strong type system has had a similar effect in being able to dive into an old codebase. I am thinking specifically of Elm lang, but with Typescript as well.

EDIT: grammar

Reply on news.ycombinator.com