6 ms·
I've also done this a lot, as has everybody. My experience is that there are two problems. One, it turns out I never ever end up doing the actual steps as I pl
by Scarblac 3y ago
I've also done this a lot, as has everybody. My experience is that there are two problems.
One, it turns out I never ever end up doing the actual steps as I planned to. After a few I have new insights, realize I forgot something, see an easier way, I don't know -- the plan is never followed.
The other is that I really hate working like this because it seems all the creative effort of thinking about how to make something is put in the first part. And then, the rest is still most of the work, but it's the really boring part. It's much more fun (and therefore faster, and resulting in better work) to spread the creativity and the boredom out more equally.
The two are probably related, and it's not inconceivable that I have ADHD.
- suslik 3y agoI am somewhat like that myself. I do formulate a plan and break down tasks in advance, but I give myself an absolute right to change and modify it at will whenever new ideas come to light or just because I'm feeling like it.
- Rygian 3y ago> the plan is never followed The plan not being perfect and prescient is part of the plan. Next time you plan for same or similar activity, your future plan will be better. The Project Managers even have a mantra: "fail to plan is plan to fail."
- Scarblac 3y agoAnd Eisenhower's "plans are useless, planning is essential", of course. I know. But for me it's very easy to overdo it. Give me interesting chunks of about a week or two, with a tight deadline, and I'll do my best work. Remember, Linus wrote Git in two weeks. And there was no project manager in sight.
- baliex 3y agoOn the Linus point, I'd bet there were countless months where he was bringing ideas together in his head and planning how he'd do it before actually finding the time to sit down and write it.
- deleted 3y ago[deleted]
- sanderjd 3y agoIt would be interesting to know whether he had devised some kind of project plan ahead of time. But I suspect not. I'm sure he had been thinking about the technical details of what he wanted to build - which yep, we all like to do that! - but I doubt he bothered to break down a set of approximately-ordered 1- to 3-day work units, which is what many of us struggle to be good at.
- arnorhs 3y agoWhenever you talk about breaking down tasks, estimations etc, those usually are for multi-person teams, and/or projects that have some specific budget or something. Of course if you are exploring or building your own projects and/or don't have any other accountability, you wouldn't start planning that.. unless you are really into planning in and of itself. But as soon as you have a boss and the boss asks "how long? who does what? where do we start?" - you have to have some framework. I also have a very high aversion to "conforming to the system", esp. when these systems seem arbitrary or are overly rigid .. but systems in general need to be simple and flexible. Productivity systems are there to help people. I don't think the author intended for this to be like a detailed recipe.. but more like an example of how he approaches these things, which can hopefully help others have their own ideas.
- fmbb 3y ago> But as soon as you have a boss and the boss asks "how long? who does what? where do we start?" - you have to have some framework. Why? Does it work? Is it productive? Is it better than not doing that?
- zarathustreal 3y agoSuppose it doesn’t work, it’s not productive, and it’s worse than not doing it. You still have a boss asking these questions. Any answer you provide constitutes a framework.
- sanderjd 3y agoWell, one answer you can try is to push back on the concept of providing status updates. For many (but not most) high-trust individuals working on many (but I think not most) kinds of projects, that's totally fine. (Ideally it is an expectation set much earlier on than the point where a status update is being requested, though.)
- RandomLensman 3y agoOn average: yes, yes, and yes.
- ncphillips 3y ago> I never ever end up doing the actual steps as I planned to I do the GTD thing of only thinking about the _next_ action, not trying to think of every action.
- earth-adventure 3y agoSeriously asking : how? I can't cheat my brain into not automatically seeing the next steps after that and the cascading relation between the all. Within a second or less.
- OJFord 3y agoA related if not the same thing I've been trying to do, especially with some DIY type work, is that it doesn't matter, deal with that later, just get this done thing for now. I.e. not somehow trick yourself into not thinking about it, but just think who knows if/when I'll actually get around to that, for now just do this. Don't worry about optimal order. If the skirting doesn't look as great as it could because I fixed and painted the doorframe first, only painting the wall and rest of skirting later, meh who cares, if it turns out to be that noticeable maybe I'll get around to giving it all another coat; in the meantime at least I got it done, not stuck in 'analysis paralysis'.
- chrisweekly 3y agoTangent: I can't recall where I first heard "plans are worthless, but planning is essential", but there's definitely some truth in it.
- mlrtime 3y agoCertainly holds true for having a baby. You can plan all you want and it is essential... however you'll quickly find out that most of your plans are in your newborns' hands.
- chrisweekly 3y agoYes! Also Mike Tyson's famous "Everybody has a plan, until they get punched in the face."
- madcaptenor 3y agoFor babies, everybody has a plan until they get pooped on / thrown up on.
- crucialfelix 3y agoDwight Eisenhower, who also created The Matrix.
- wting 3y agoFor clarification, "The Matrix" refers to the urgency vs importance decision matrix and not the movie: https://asana.com/resources/eisenhower-matrix https://asana.com/resources/eisenhower-matrix It's a framework to prioritize important tasks instead of falling into the agency trap, akin to prioritizing meaningful strategic tasks such as product development and tech debt instead of fighting fires.
- wting 3y agoAnother perspective is that planning is a breadth-first traversal of the solution space, and coming up with a path to the solution. When reality hits and the path is often wrong, one can switch to other paths quickly since the graph was created ahead of time. It's writing the table of contents for a book before fleshing it out. Without planning, a depth first traversal is a high risk endeavor in the likelihood that the that path is wrong but backtracking and creating the graph is comparatively expensive and susceptible to sunk cost fallacy. Depth-first traversal is writing the book a chapter at a time without a table of contents in mind.
- suriyaG 3y agoI'm a person who hates lists and plans for personal tasks. But, am learning to love them. Because as I often realize, things get missed in the myriad of things to remember. The plan to me is just a way of reminding my future self what I thought of as ideal output in the past. Instead of infinitely changing my plans and chasing fireflies
- sanderjd 3y agoThat's slightly different, IMO. Writing down things that need to get done as you think of them is not the same as writing down a plan.
- rapind 3y agoI make lists and break tasks in to smaller tasks, however I rarely reference these lists. They basically end up in the void. The act of making the list gets my juices flowing and reminds me of the side effects / bigger picture of my current challenge. Realizing this also helps me avoid yak shaving over list making tools, since I could care less about even saving the lists! I keep a folder of text files in any project I'm working to hold my lists, but tbh it's unnecessary to even save them.
- M2Ys4U 3y agoSometimes planning is more important than having a plan
- sanderjd 3y agoI see this a lot in this thread (and have heard it a number of times before), and it sounds intuitively right to me, but could you give an example of when and why that is the case?
- rapind 3y agoWriting an idea down just seems to reinforce it and makes you flesh it out. I think it engages your brain differently, but I’m no neuroscientist.
- sanderjd 3y agoEven if this is right (and I definitely think there is a lot of truth to it!), planning is not the only kind of "writing down ideas to reinforce and flesh them out" activity. Is it the most valuable one? And is this the only and best way to reinforce and flesh out ideas, or are there other ways that might be even better, like creating prototypes or just actively fiddling around with different approaches and possibilities? In my view, it isn't that there is no value in pondering the detailed sequence of work it will require to accomplish something over the next three months, it's more that I think beyond a horizon of a few weeks, most of the other things I could be doing with that time usually ends up seeming more valuable, to me.
- igortg 3y agoHoly... It still amuses me how much HN comments brings the reality to these kind of articles. > the plan is never followed. Sometimes it's even worst. As we add more tasks during execution, at the end, these tasks get twisted with the ones you created while planning. Then we end up with a messy list of undone tasks that aren't really required anymore (because they were created without having the full context, that only happens during the execution).
- ramijames 3y agoThis is an accurate and insightful way of looking at work. It touches on something that I've been considering a lot lately: I love programming, but I hate doing it in a work environment. The fun thing about programming is that it is a flexible, flowing, and creative endeavor. You make things up as you go; it is an organic experience. In a work environment, this organic nature is removed mainly because there is a need for oversight and accountability.
- swah 3y agoI also can't get myself to do it seriously for my own tasks, but when I had to do it for a jr colleague I found out... yeah, breaking it down its hard, as hard as coding - then you get most of the hard work already done, and coding the solution becomes trivial. Chances of false starts go from 80% to 20%. (A few times there is prototyping involved but I won't share that with non-devs, since they don't seem to get it.)