The failures in terms of not following my schedule:
– I only worked 12/16 hours of saltmines.
– I only studied Spanish on one day (Tuesday)
– I only published one article between Thursday-Sunday.
This week I tunnel visioned TheFleet project. Instead of doing 8 hour 45min well planned programming sessions, I did ‘mad scientist’ 12 hour sessions at the exclusion of other work. This was in part avoidance behavior. I knew I had to do other assignments such as writing my bi-daily articles, but I chose to stick with TheFleet. It was easy to bury myself in the project. I think it was correct to prioritize getting bots connected before I stepped away from the terminal. However, I may have been able to get something working in fewer hours had I gone about programming in a more structured manner.
A selection from a trilema article stuck with me this week.
You know why children under ~5 years of age fall so much ? It’s because they conceptualize the world as a static construction. Everything it sees is, to the infantile mind, as unmovable as scenery in a side scroller. Captain Comic isn’t going to push a ledge out of the way. Similarly, the toddler doesn’t expect any dynamic equilibrium in his environment, and he will step on a precariously balanced chair with the ease he’d step on granite bedrock. He sees it there, so it is there, so it will support him. Or a tank, really, or anything else. That’s the other thing, they keep building these towers that fall down because who could have predicted you can’t balance a fridge on a pickled olive ? They’re just as non-transparent, what magic is this!
The infantile mind doesn’t go away. It just withdraws. The knowledgeable derp is still very much a derp, he’s not become a man through spending his youth reading and thinking about things. On the contrary, he’s stayed a child. He doesn’t, on account of the painful bumps nature provides, expect mechanics to work like in a picture – but this doesn’t impede him from expecting economics, for instance, to still work this way. Because nature doesn’t provide any bumps he can recognize on that scale, and so there’s nothing to fix his toddler stupid.
The way I program reminds me of the infantile mind described above. Unlike the toddler, I know that some objects are in dynamic equilbrium. My method of ‘figuring out what is and what isn’t stable’ when programming is similar to methodically going around the room knocking each structure to see if it gives way. It takes time to run all of these tests, and I only gather data points instead of understanding.
Tying this back to programming, I spend more time running my code than I do rereading it. Testing is necessary, especially for TheFleet which deals with unknown responses from servers, but I need to find the right balance. It would be better to go for longer blocks developing before I fire off scripts and wait for their results. ((Each time I test against a network I have to wait a few seconds for a response. This interruption pauses my train of thought. Features such as re-connection put my script to sleep for ~60 seconds. When testing re-connection I would connect my bot, disconnect my computer from the internet, wait for the bot to drop from irc, and then reconnect my computer to check if the bot was able to get back into the network. Running this repeatedly was expensive in terms of time.))
I wrote an article about the problems of not making plans before embarking on a task. Yet I ignored my own advice and went on to do ‘incremental development’ the next few days. ((I fell flat on my face from this when trying to put together my computer.)) I am not sure what causes this cognitive dissonance. I think that although I know what I should do, I have trouble following through because of entrenched bad habits. It’s also possible I don’t fully believe what I said. Part of me still thinks, “you can’t know what problems you’ll have until you hit them, so better to leave the plan open and handle things as they come.”
Possibly not as much that you don’t believe what you said but simply that you don’t believe it is as useful as you say it is. It’s not about “knowing all problems in advance” so indeed, if that’s how you think of it, no wonder you don’t believe it, since it is easily shown false. The plan is not so that “every possible future outcome is covered” since that’s plainly impossible (and again, it ties in with “towards purpose”). The plan is so that you know what you are aiming for (and WHY and in WHAT WAY), so that you can tell at *any moment* where and how far you’ve got and so that you can *adjust* in a *controlled* manner when/if new information comes to light. Perhaps think of it this way: any plan is simply one reflection of your knowledge so far as to the task at hand. As such, it is quite often incomplete so as you progress and new information comes in, it can be changed/adapted to fit the gained knowledge. But there is very little (if any!) knowledge gained through pebble-testing here as everywhere else.
And talking of testing as “strategy”, did you follow the talk yesterday with Eric (lobbes) on bugs and testing strategies? The white box/black box distinction applies not only to code but to everything really and you seem to ~always go for black box (precisely what you describe there, pushing to see if it falls down) – possibly because it seems “easier” (less short-term effort). It’s not only more time consuming and in fact *less easy* in the long term but worse than that – it’s more misleading and overall a recipe for failure in the long term. So stop indulging in that and start aiming for actually increasing your knowledge.
Comment by Diana Coman — January 6, 2020 @ 7:50 pm
>> Possibly not as much that you don’t believe what you said but simply that you don’t believe it is as useful as you say it is. It’s not about “knowing all problems in advance” so indeed, if that’s how you think of it, no wonder you don’t believe it, since it is easily shown false. The plan is not so that “every possible future outcome is covered” since that’s plainly impossible (and again, it ties in with “towards purpose”). The plan is so that you know what you are aiming for (and WHY and in WHAT WAY), so that you can tell at *any moment* where and how far you’ve got and so that you can *adjust* in a *controlled* manner when/if new information comes to light. Perhaps think of it this way: any plan is simply one reflection of your knowledge so far as to the task at hand. As such, it is quite often incomplete so as you progress and new information comes in, it can be changed/adapted to fit the gained knowledge. But there is very little (if any!) knowledge gained through pebble-testing here as everywhere else.
I don’t kid myself thinking that one could ever forsee all problems in advance. I think I was/am adverse to plan building because going straight to the task is the “least resistance” path + I have some weak plan building skills. So maybe I _have_ lost time in the past by from the overhead of writing poor plans. Those weak planning skills are why yes, “I don’t believe it’s as useful as I say it is.”
The point that a plan is ‘a reflection of your knowledge so far as to the task at hand’ gives me a new perspective. I’ll go forward working on making better plans that tell (1) what I am aiming for (2) why I’m aiming for that goal (3) how I am going about accomplishing that goal – all while trying to summarize the knowledge I have about the goal/task.
>> And talking of testing as “strategy”, did you follow the talk yesterday with Eric (lobbes) on bugs and testing strategies? The white box/black box distinction applies not only to code but to everything really and you seem to ~always go for black box (precisely what you describe there, pushing to see if it falls down) – possibly because it seems “easier” (less short-term effort). It’s not only more time consuming and in fact *less easy* in the long term but worse than that – it’s more misleading and overall a recipe for failure in the long term. So stop indulging in that and start aiming for actually increasing your knowledge.
No I did not follow the conversation, but I will read it shortly and follow up with another comment.
Comment by Will Haack — January 8, 2020 @ 4:52 am
The follow up comment:
This was not my first time hearing about the white/black box distinction nor the first time reading that I should partition the input space and test the various partitions + their boundaries. (iirc white/black box testing gets discussed in SICP)
Yes, I agree I overdo black box testing in programming and everything else. I try to have a balance, but black box testing winds up being most of my time in part because black box testing is slow! (If you drive 120km, 1st 60km at 15km/h and 2nd 60km at 60km/h, you have not split your time between 15km/h and 60km/h “in half.”) Likewise I think to myself “I’m going to do a little bit of black box and a little bit of white box” – and then the slow black box portion takes up 80%+ of my time.
Comment by Will Haack — January 8, 2020 @ 3:13 pm