Submitted 1 year ago by xilliah@beehaw.org to programming@programming.dev
https://en.wikipedia.org/wiki/Law_of_triviality?wprov=sfla1
Does this hit close to home for you too?
I often find myself skirting around the actual meat of the issue, solving minor, simpler issues around it. Finally I must consciously decide to move in, and as a producer I knew would say - slap it in the face and drag it over the finish line.
well yes, but I don’t think it’s necessarily bad to go about it like you described, as long as you know that you’re not actually using the smaller issues to procrastinate on the big issues. Tackling the smaller issues first can help you to understand the bigger issues better, both consciously and subconsciously, so as long as it doesn’t actually matter in which order they’re done, I think it can be more effective to do the smaller ones first. That all goes out of the window of course if you’re using the small issues to avoid having to think about the bigger ones
This happens all the time. I feel like a big reason people don’t like meetings is that they tend to involve a lot of bikeshedding.
Ohhh ya exactly this. I often said that we should have a list of top 5 issues and focus on them. You can guess what happened.
jadero@programming.dev 1 year ago
I found that starting with a “critical path” analysis was very useful. Basically, identify which components or activities need to be at least somewhat functional in order to deal with a different component or activity.
This gives you a list of problems you have to solve in the order they need to be solved. That is, there is no point spending time on writing to disk until you’ve figured out what you’re writing to disk and how your going to collect whatever needs to be written.
Virtually every critical path will have some easy stuff on it that needs to be in place before the hard stuff. That gets you (or at least me!) in the right frame of mind and builds momentum towards the goal. I’ve often found that doing the work leading up to the hard part made the hard part easier, at least partly because there is now a concrete problem ready to solve instead of a nebulous wondering how to approach it.
Note that if you try this approach, make sure that you avoid the common practice of building “placeholder” stubs for anything other than components further along the critical path than your current position. Even with that, I found little value in stubbing something in before I was actually getting close to the point of needing it in order to continue working.
Note that this process doesn’t mean it’s not appropriate to go ahead and identify where the dragons are and check to see if you have what it takes to slay them. Back to my example of writing to disk, if you’ve never written anything to disk before and it looks scary, it might be a good idea to create a completely unrelated toy project to learn and practice that specific skill. After all, if it turns out to be impossible to write to disk, there is no point starting a project that requires it. I find that these toy projects are simple in the sense that there is only one thing to worry about, so you’re already doing the easiest thing available.
xilliah@beehaw.org 1 year ago
Preach