Dear tech wizards,
How do you stop and start work? That is, how do you pick up mentally a project where you left off? Notes? Saved tabs? Reminders?
@Shufei for daily work I don't do anything. I just remember. Weekends got to be annoying at work though. I was spending half of Monday getting back up to speed. To help that I started writing myself a note for Monday. At first this was a text file, but eventually I just sent myself an email. It was nice cause if I got sick or something I could forward it to someone in my team.
So yeah, bulleted summary email to myself.
@Shufei for a project I touch infrequently I use Todo lists and README files that describe what I'm doing and where progress is. I keep those in the repo. If it's in GitHub, I sometimes make myself issues with ideas or questions to explore.
@Shufei I'm working in a windows environment and a pothead so...
Extensive notes in notepad++ tabs.
Make full use of the split screen functionality as well.
Usually i keep one overall todo list for my whole project on one tab. And then have the sections broken up into smaller tabs where i'm getting more nitty gritty for individual tasks and note keeping and scratchpadding.
If i'm leaving off in the middle of writing something more complex, i usually leave myself detailed notes.
...though i'm in the process of messing with how that all works.
some thoughts that'll fit in a post here:
- paper notebook that goes with me everywhere
- vimwiki with a diary entry for every day
- piles of command line history
- every project should have a README that'll be useful when i come back to it
- lots and lots of bookmarks (i use pinboard)
- tag the shit out of everything that allows for it
@Shufei I usually have three or four things I'm working on (not counting helping others, interruptions, basic operational things, etc.). These get different workspaces/desktops with their own terminal and browser windows. This helps me switch and maintain context at a sort of basic level.
I take notes irregularly. I am pretty good about making a note of something I recognize as tricky or esoteric that I won't easily recall.
Project documentation is a primary method I use for design and it can help create enough context in my brain that I remember state.
I have a daily task list I review every morning which provides me a starting framework for the day, reminds me what I've been working on, and has me set out goals for the day.
@Shufei What works or doesn't work for you?
@Shufei I keep per project logs. And I pepper my code with FIXME and NOTE.
Furthermore, my boss knows I spend the first hour reading whatever I wrote the previous day.
@Shufei I keep a dot journal for all development tasks that I'm working on -- different spreads for different projects.
I got this out of Test Driven Development: By Example by Kent Beck. I keep a bullet list of each thing that I do in the project. Before I do it, I write it down. Once I've done it. I cross it off. If something pops into my head that I need to do, but isn't what I'm working on right now, I put it down.
Next time I resume the work, I've got a nice list of next-up items to work on, and a log of what I was working on up to that point. Skim back a few lines to remember where I was and then jump back in.
@Shufei what's your context? I work on 4-8 projects at a time in my position. Anything I need to remember to do I write down. If it's more complex I write a short explanation of what the challenges are and what I think my next steps are.
I go through a lot of sticky notes this way.
I try to always have consolidated list of things I'm keeping an eye on so I can quickly prioritize what's next
@Shufei discover a git stash 3 layers down 6 months later
@Shufei Different workspaces for multiple projects, usually one text document for each project with notes (also paths, IDs, etc) and then copious code comments. Like... lots and lots of code comments.
@Shufei I tend to keep a small text file within the project (called .todo) where I dump everything I'm going to do next. It usually starts as a rough outline ("refactor this", "implement that"), and those items acquire more details as I go ("don't forget to check if foo used elsewhere", "refine bar's docstring"). Whenever I finish something immediate and have a minute or two, I look into .todo file to understand where I am and what's already done.
The secret is to not overthink it.
@Shufei Oh, and this same file is used for odd bits of knowledge copied and pasted from Slack, useful links (which are simply deleted if proved not to be useful).
@Shufei the more security aware have different VMs for different projects. Makes it natural to keep things separarte and optimized for that project/job/context/identity
@Shufei amnesia, panic, scramble through email for clues.
@Shufei def todo lists.
When you are still in the zone, but is getting tired, stop everything and update your todo list. With tasks in order or groups. And then stop.
Next day, start from it, and treat it as your boss. I’m order or pick a group.
I write my todo list on README.md to keep me honest.
@Shufei One thing that I try to do (but don't always manage) is to leave a broken test for the next thing I wanted to work on.
@Shufei I keep TODO (low priority) and FIXME (urgent) comments in source; big picture stuff goes at the top of the main source file. Atom has a TODO-tracking package that lists them all.
Sometimes I use a history.txt file, or Trello if I'm working with anyone else. Often there's a design document and I can take my next task from that.
@Shufei the best advice I ever got, and which I have adopted, is to make comprehensive inline note-taking part of the work. Coding? Use comments and inline docs to track what I'm thinking (I can remove and collect them during cleanup). Writing? Leave notes in margins or inline ((inside doubled parents)), etc.
Interruptions now make me lose far less internal state and I get far more done
"I appreciate SDF but it's a general-purpose server and the name doesn't make it obvious that it's about art." - Eugen Rochko