I've also done this a lot, as has everybody. My experience is that there are two problems.<p>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.<p>The other is that I <i>really hate</i> 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 <i>really boring</i> part. It's much more fun (and therefore faster, and resulting in better work) to spread the creativity and the boredom out more equally.<p>The two are probably related, and it's not inconceivable that I have ADHD.
> Delivers change because, in a work context, a task only “matters” if something is different because of the work.<p>I think maintenance tasks may require more effort / more expansive qualification when it comes to the meaning(s) of "something is different".<p>I think the topic of "breaking down tasks" could very well be its own book genre or even podcast genre. My experience with self-help and organization titles has been that the activity of breaking down tasks is a sort of known primitive human operation that many authors assume their readers to have. However, my own personal experience and the accounts of others I have heard while participating in group sessions is that breaking down tasks can be very difficult and provoke emotions of avoidance and despair.<p>The most broadly relevant advice that I have come across when it comes to breaking down tasks is to keep breaking things down until I am 90% certain that I can successfully complete the task. The certainty here would vary on how much self-confidence an individual has and their risk tolerance, so some people may break down tasks to 70% certainty of success.
Software development cannot be managed like this. This sort of task break downs come from classic management training. The problem most people are unaware of is software development is more a creative activity than anything else. Yes there are serious technical aspects to it but since the problem is virtual and not bound by any real world limitations, like how civil engineering would be, there isn't one optimal solution. Trying to define the solution before the problem has been properly examined would only limit the final output. Most of the exploration only happens when people actually start coding.<p>Not having a well defined final output and time is not very relevant for software, mostly because there is no per unit cost. Most managers do not realize this is they are not from a software engineering background. A versatile product can be sold to many different customers without additional development costs.<p>But since most companies are managed as factories, all the processors will ultimately create a very limited product targeted at a specific customer. What the big tech companies have avoided is this .
Being a career long engineer, I'm not unaccustomed to breaking down huge projects into smaller things that can be parallelized, plotted in time, etc. We have to do it and get better at it.<p>But honestly, I think what holds most of us back is a better ability to just don't do that. Take that thing you want to make, and instead of planning out all the pieces, just make the tiniest possible thing that could possibly be of value. Using this example, just start with "Today" and the 4 buttons. Make a thing that shows your 4 buttons of exercise you will click on each day. You can probably make that today. No streaks or freezes or calendar view. Those are all great ideas, and you'll get to them. But you need momentum. And you'll probably decide you don't even like that calendar view in a few days. I think more projects need a kick in the pants of just do something small. Get it done today. See what the next task is from that point because it's probably not what you thought it ought to be during the planning phase.<p>This also isn't exactly easy either. It requires some thought and discipline and find the smallest thing and commit to shipping it without distraction. But it's also something good to practice at.
Breaking down work works great until the breakdown is unknowable. Things like research, that require creative experiments to POC things that are not known apriori. That’s when task breakdown breaks down.
This gets a lot of teachers - the task is so ingrained in them that the only part they consciously understand is the trivial bit that everyone already gets. Breaking down a task and estimation are almost equivalent - once the breakdown is done, assigning estimates to the chinks of work takes a few minutes as anyone with a few years experience has some standard estimates for small tasks. In my experience I break down a task by biting off chunks that I can estimate, then ask for opinions on anything I can't.<p>Although I don't even believe the real path to mastery is the task breakdown. Anyone can come up with a bad breakdown. The real point of mastery, which he didn't talk about here, is identifying when the evidence suggests a task breakdown is incorrect enough to cause problems and communicating that / doing a re-estimate [0]. And being comfortable that it will happen so not getting stressed up front putting out a schedule that is likely to change. Managers generally want an accurate roadmap up front. This is them asking for the impossible. IMO Good management is about flexibility and understanding that the expected nature of the work changes as time passes and developers learn.<p>He has a little example at the end. Ponder that if someone had come to him with an accurate estimate ("you can do this in a few evenings as a plane trip") he'd have rejected that as too risky. That illustrates that estimating isn't even about accuracy, there are many unspoken factors here around risk management, expectation management, task familiarity, etc, etc.<p>[0] <a href="https://jacobian.org/2021/jun/8/incorrect-estimates/" rel="nofollow">https://jacobian.org/2021/jun/8/incorrect-estimates/</a> - he has a post on the topic
A lot of the "never taskers" in this comment section seemed to have never worked with the juniors I have.<p>These are good, new software folks who genuinely don't know how to stand up basic functionality because the space is new to them. In my experience they want tasks they can learn from and excel at, leading to growth.<p>I think the thing that you absolutely must keep in mind is process overhead is a continuum you tune to your team. No one in the NBA is going into a huddle and getting instruction on how to throw a ball mid game, but the kids in third grade are. Both styles of planning and coaching are appropriate to the team at hand.
I don’t know.<p>I think that’s the main truth about software engineering. Maybe an open source version of that Streak app exists and OP is re-inventing the wheel.<p>I think the brain doesn’t like task list. It may be pleasant to do, but most of entrepreneurship or coding is exploring.<p>And a task list blocks you from exploring.
The biggest problem I have with splitting tasks is reluctance to do duplicate or unnecessary work. Breaking down tasks into smaller tasks means you <i>must</i> do duplicate work. The trick is to minimize it.<p>If you try to make no unnecessary work, you'll end up having to do everything at once.<p>Example: you want to refactor a program with two modules A and B where B depends on A. The least wasteful way of doing it is to refactor both modules together. But it's also the riskiest and hardest to estimate.<p>The broken down way is to refactor A and <i>adapt</i> B so that it works with the refactored A. After that you would refactor A, which would then risk making the adaptation effort very short lived.<p>If you want to do zero throwaway effort, you often can't break down the task. I have 20 years of experience and I still often find myself reluctant to do throwaway/temporary job in order to divide work. Instead I find myself doing multi-week efforts with zero yaks left unshaved.
Maybe I’m just lazy/undisciplined/a cowboy but having to break things down into “pointable” tasks feels like busy work just so management can “see” progress.<p>I mean, thinking through a problem you’re trying to solve before starting makes sense, and having rough milestones is important - but a majority of the time there’s so many unknown unknowns that fully breaking it down is totally useless, if not impossible.<p>If I spent the same amount of time it took me to break a project down just working on figuring out a solution or building it, it’d get done way sooner. At least, that’s how it feels.
Does anyone have a better article on this? This is ok, but it seems like there are better - I would love to share with my team.<p>These are things I always share with them:<p>On code reviews: <a href="https://mtlynch.io/code-review-love/" rel="nofollow">https://mtlynch.io/code-review-love/</a><p>On simplicity: <a href="https://grugbrain.dev/" rel="nofollow">https://grugbrain.dev/</a><p>On SOLID (even though we use Python now): <a href="https://www.baeldung.com/solid-principles" rel="nofollow">https://www.baeldung.com/solid-principles</a><p>I would love to have a "standard" article for planning.
This reminds me a bit of the old "Write a story about the task. The nouns are objects, and the verbs are methods." method of OOP.<p>I never warmed to that.<p>However, this is not that, and I think it's an important skill. I started my professional life as an RF technician, and we learned how to do this, almost immediately. We used things like signal generators and oscopes.
What's missing here is who this breakdown should be shared with. There are three levels of breakdown and the details of lower levels should never be revealed to higher levels:<p>1. The "business" level. There are no "tasks". There are only needs and desires. Things like "a user can log in and press a button". These should not be broken down further than the smallest unit of deliverable value. In this example, there's no point estimating "user can log in" because it delivers no value on its own. A good rule of thumb is these should be described using descriptive language, <i>not</i> imperative, so not e.g. "implement log in procedure".<p>2. The "team" level. It's OK here to break down those things into "user can log in" and "logged in user can press button". That's because you know they can be <i>implemented</i> independently. But there's still no point <i>delivering</i> them independently. Don't tell the upper level about this breakdown. They are always really eager to know, but they don't need to know. Use this to calculate your estimate for level 1, but said estimate should be a single aggregate. Implementing these in parallel with multiple devs adds no extra overhead because they are completely independent.<p>3. The "developer" level. This is where you finally have "tasks" and imperative language. Things like "add button to form", "implement 2FA" etc. These tasks are naturally heavily dependent on each other and it's highly likely they'll be done in a completely different order to whatever you write them down in.<p>If you decide to distribute these tasks among developers then you increase the coordination overhead between devs. Think of it like a multi-threaded application. It's always more efficient for a single developer to do everything if possible (less overhead), but it might nevertheless be necessary to split it up due to time constraints, differing skillsets etc. It's just like we'd like to have one single 80GHz general purpose CPU, but in reality we have to make do with 16 5GHz cores split between performance and efficiency cores etc.<p>Given that the tasks are highly likely to change and evolve, there is not much point putting in loads of effort to break things down. Do it only when it's necessary, or when it helps you. It's necessary when you need to split up the work between developers. It's helpful when you think of more tasks during your work and you don't want to break your stack. Every developer should have a way to quickly take notes in a way that doesn't break flow, things like "ensure API accepts float input". This is stuff you'd never think of before you get your teeth into it.
I created tasktree.co for myself to help with this! It’s so easy to get overwhelmed when faced with a big task, and actually forcing yourself to just break it down helps a lot.