4 ms·
The things I've benefited from most are not tools but practices. - Question the work Always be questioning whether the thing you're doing really needs to be d
by Joeri 6y ago
The things I've benefited from most are not tools but practices.
- Question the work
Always be questioning whether the thing you're doing really needs to be done. Is there a way to not do it? Is there a way to do something better instead?
- Park downhill
Before putting a project or incomplete task away, make notes of what the next thing was that you were going to work on. This lets you bypass that 10 minute orientation getting back into the project the next time you pick it up.
- Keep a single todo list outside of your head
You can only have one master, so keep a single todo list in order of priority. Whenever something pops up on your radar, put it on the list in the right spot and immediately forget about it. Check the todo list a few times a day to make sure you're working on the right thing, and whether you need to communicate that something low on the list won't get done in time. Aggressively try to weed out the list and remove as many items as possible, preferably by not having to do them (by reassigning, by replacing or by reprioritizing).
Benefits: (1) not forgetting to do any work, (2) free up your mind to focus on work instead of meta-work, (3) clear priorities, (4) detect early when work is going to get delayed.
To combine this with park downhill I either keep the per-task notes on what to do next right in the list (in a details field of the todo item), or I keep it somewhere else and have just a single top-level item "finish X" in the master list.
- hamandcheese 6y agoRe: questioning the work... I’ve found that there’s a certain threshold (that is surprisingly high, sometimes) where it’s easier and faster to just do something low value than it is to convince everyone else involved and reach alignment that it isn’t a valuable thing to do.
- jikciraz 6y agoRegarding the todo list, I find that having a text-format todo list for the current day can provide structure and sense of accomplishment (especially at the end of the day). After completing a task I would put a checkmark emoji in front of it. Such a list can also bring me back on track after a lunch or a mentally-demanding task. If I know that I won't be able to do a certain task today, I put it in advance for the next day's todo list. Not completed tasks will roll to the next day. Plan for May 11: - Contact Person 1 regarding Thing 1 - [checkmark] Review Pull Request 1 made by Person 2 - Implement Thing 1 from Feature 1 - Read Email 1 from Person 3 Plan for May 12: - Implement Thing 2 from Feature 1 - Investigate Thing 3
- dd82 6y agoThis is similar for me, except I integrate that into a daily log via a running google doc. Lists off the tickets I did, meetings, conversations and action items to follow up on. We have two week sprints, and sometimes around retro its really easy to forget things that happened the week before that would be useful to call out.
- nicoburns 6y agoApple notes is surprisingly nice for this style of todo list if you use a mac.
- LeonB 6y agoYou can access your apple notes on a windows computer too, either by visiting iCloud.com or downloading the iCloud app from the Microsoft store.
- zests 6y agoThis is the use case for why I started using org mode.
- darekkay 6y agoThis is also perfect for a Daily Scrum, as you know exactly what you've been doing the day before.
- tren 6y agoI like taskade to manage this. I'll use the weekly Todo list template and it works well
- dugmartin 6y agoSemi-related to “park downhill” is something I do at the end of the day if I’m still working on a piece of code - I’ll write a simple next task in a non-comment so it breaks the syntax. Then the next day I can dive in and “fix” the code which, at least for me, helps get in the groove.
- zylepe 6y agoAnother variation: leave a failing unit test that will pass when you implement the next thing you were planning on doing.
- toomanyrichies 6y agoThis is like the coding equivalent of Ernest Hemingway's "stop writing in the middle of a sentence" strategy for overcoming writer's block: https://news.ycombinator.com/item?id=3335637 https://news.ycombinator.com/item?id=3335637
- Scarblac 6y agoAlso: don't question the work. Sometimes it's already a compromise between too many people who questioned it, and nobody wants to discuss it any more. Sometimes the questioning is more work than actually doing it. Sometimes you get a reputation of only being in the way. Make sure the work has been questioned thoroughly, but that doesn't necessarily mean by you.
- dan_can_code 6y agoI agree with this to an extent but I feel you should always ask yourself 'why'. 'why is this feature valuable to the user?', 'why has this functionality been chosen over another?' etc. At the end of the day the work you are doing has an impact on opportunity cost - if you at least internally question the work you are doing, you can potentially lower the opportunity cost and therefore help the business. However, if you are part of a team of people who consider these things before the work gets to you, I agree it can be counter-productive to question it.
- darkerside 6y agoI love that last line. I think sometimes developers can feel like they can be the hero, stopping the business from going down the wrong path simply because nobody else asked the question. They may even be right! But question your motives. Are you asking questions and throwing up roadblocks to make yourself look and feel important? Or is it purely to make the best business decision? That's not a leading question. Honestly, both of those goals can be important and effective. But if your goal is to actually effect business change, you'll probably have better luck talking to a product person offline and having the idea come from them.
- neillyons 6y agoI guess this means "park facing down hill" as opposed to "park down the bottom of the hill" which is what I first thought it meant but doesn't make as much sense. lol