3 ms·

""" But I do think that you can improve your resilience to interruptions if you: Come up with a solution to a problem before you start writing code, and think

""" But I do think that you can improve your resilience to interruptions if you: Come up with a solution to a problem before you start writing code, and think about which parts of the system that solution will impact. Divide the solution you came up with into small chunks, so you can take them one at a time. """ That may be true, but I think it comes at the cost of taking more cumulative time. I can either knock out this feature in three hours, or I can spend an hour breaking it into six half-hour chunks.

Jaruzel 8y ago
This approach is known as 'Top Down'[1] and was VERY popular in the early days of system and program design. When I started my career I encountered a beardy-sandal-wearing systems programmer[2] , who 100% believed that there should be more comments than code in a program. His approach was to use the comments to write out long-form exactly what the program would do. He would write the whole solution as 1000's of comment lines, from start to finish in one big comment block. Once he'd done that, he'd then start again at the top, and split the comments at a natural point and insert real code to reflect the 100 or so comments above it. At the time, I thought it was a crazy way to do it, and even now I wouldn't do it. But it had it's upsides. His code was really easy for others to maintain, and it was also fundamentally self documenting. --- [1] http://dept-info.labri.fr/~strandh/Teaching/MTP/Common/Strandh-Tutorial/top-down-programming.html http://dept-info.labri.fr/~strandh/Teaching/MTP/Common/Stran... [2] Ironically, my beard is now WAY longer than his ever was.
bonniemuffin 8y ago
Proper Prior Planning Prevents Piss Poor Performance I'd estimate that planning out a 3-hour task would take no more than 10 minutes-- why would you need a whole hour to plan something that's only going to take 3 hours? And in my experience, most of the time, those 10 minutes spent mapping out the plan will end up saving you more time in the long run, as you realize some critical assumption about the work was wrong ("oh I don't actually have to do X", or "oh I'm missing this key dependency and need to loop in team Y").
egypturnash 8y ago
> I can either knock out this feature in three hours, or I can spend an hour breaking it into six half-hour chunks. The first option carries more risk. Let's say you spend an hour building up the mental model of what's going on and what you need to do in your head from scratch. But you get interrupted ten minutes after that, and lose it all. You've now spent 1:10 with nothing to show, and will have to spend another three hours starting from scratch. Total time, assuming you don't get interrupted next time you try: 4:10. Whereas if you'd spent an hour planning, and then gotten interrupted ten minutes into your first half hour of working, you will have lost at most maybe ten minutes. Total time, assuming no more interruptions: 4:10. And then you start again the next day, and another interruption comes in an hour and a half. The you who requires three uninterrupted hours to do this just blew 5:40 total and still has 3:00 of doing it from scratch staring them in the face. The you who spent an hour chunking the problem into smaller tasks? Whatevs, you spent 2:30 getting solid progress, wasted 0:10 of work, and still have 1:30 left to do. If you can control your environment and minimize interruptions to, oh, one every two or three days? then not spending that hour up front to break the problem down into smaller chunks is workable. But if you're going to have some kind of interruption at least once a workday, then you may never get those three solid hours you need to actually figure out what needs doing, and do it. (This is of course a very rough model that assumes a programmer who loses all mental state upon an interruption, leaving absolutely nothing behind, be it half-written code that they could later use to reconstruct where they were going in somewhat less time, or a source tree in a completely broken state that will require even more time to fix...)

Jaruzel 8y ago

This approach is known as 'Top Down'[1] and was VERY popular in the early days of system and program design. When I started my career I encountered a beardy-sandal-wearing systems programmer[2] , who 100% believed that there should be more comments than code in a program. His approach was to use the comments to write out long-form exactly what the program would do. He would write the whole solution as 1000's of comment lines, from start to finish in one big comment block. Once he'd done that, he'd then start again at the top, and split the comments at a natural point and insert real code to reflect the 100 or so comments above it. At the time, I thought it was a crazy way to do it, and even now I wouldn't do it. But it had it's upsides. His code was really easy for others to maintain, and it was also fundamentally self documenting. --- [1] http://dept-info.labri.fr/~strandh/Teaching/MTP/Common/Strandh-Tutorial/top-down-programming.html http://dept-info.labri.fr/~strandh/Teaching/MTP/Common/Stran... [2] Ironically, my beard is now WAY longer than his ever was.

bonniemuffin 8y ago

Proper Prior Planning Prevents Piss Poor Performance I'd estimate that planning out a 3-hour task would take no more than 10 minutes-- why would you need a whole hour to plan something that's only going to take 3 hours? And in my experience, most of the time, those 10 minutes spent mapping out the plan will end up saving you more time in the long run, as you realize some critical assumption about the work was wrong ("oh I don't actually have to do X", or "oh I'm missing this key dependency and need to loop in team Y").

egypturnash 8y ago

> I can either knock out this feature in three hours, or I can spend an hour breaking it into six half-hour chunks. The first option carries more risk. Let's say you spend an hour building up the mental model of what's going on and what you need to do in your head from scratch. But you get interrupted ten minutes after that, and lose it all. You've now spent 1:10 with nothing to show, and will have to spend another three hours starting from scratch. Total time, assuming you don't get interrupted next time you try: 4:10. Whereas if you'd spent an hour planning, and then gotten interrupted ten minutes into your first half hour of working, you will have lost at most maybe ten minutes. Total time, assuming no more interruptions: 4:10. And then you start again the next day, and another interruption comes in an hour and a half. The you who requires three uninterrupted hours to do this just blew 5:40 total and still has 3:00 of doing it from scratch staring them in the face. The you who spent an hour chunking the problem into smaller tasks? Whatevs, you spent 2:30 getting solid progress, wasted 0:10 of work, and still have 1:30 left to do. If you can control your environment and minimize interruptions to, oh, one every two or three days? then not spending that hour up front to break the problem down into smaller chunks is workable. But if you're going to have some kind of interruption at least once a workday, then you may never get those three solid hours you need to actually figure out what needs doing, and do it. (This is of course a very rough model that assumes a programmer who loses all mental state upon an interruption, leaving absolutely nothing behind, be it half-written code that they could later use to reconstruct where they were going in somewhat less time, or a source tree in a completely broken state that will require even more time to fix...)