I've become increasingly comforted by writing lists down. This might not seem unusual, but it's not something I used to do, so it is unusual for me. 

Each working day, I write out a list that outlines what I've done in the day, not what I'm planning to do, but what I've done throughout the day, almost like a timesheet. It's not as granular as a timesheet as it's not an hour-by-hour account but merely a casual outline of what's been done in the day.

For example, I write down what progress I've made in some certain task, specifically for example, what its current status is, what's left to do and if there is anything of interesting about it, such as any observed obstacles etc.

Ultimately, I'm left with a trail of bullet points that outline my activities.

There are a few reasons why I do this, but the first is that I need to report on my progress back to my team on a daily basis. I tend to do a lot of research and investigation-type work, where outcomes and the rationale need to be documented so that I can accurately inform my team about what I've found. If I write it down, I won't forget. If I don't forget, I've got more to discuss, and ultimately having more useful information to discuss means the discussions are more meaningful when I have them. So that's the first reason. 

As a side note, I have found that people are very much interested in what happened during my activities, i.e why I did what I did, what the issues were etc. I think this is probably true of any team, but something I didn't realise until recently.

Interestingly, I am usually less interested in what happened and more interested and what the result is/was. I'm not embarrassed to say, that I've learnt that people like to know what happened along the way, they are actually interested in the nuances that otherwise I'm not. I think this is an important aspect of social communication, particularly within teams that share a common discipline such as Software Engineering. Making list allows easy recall of these types of nuances that occur during the day.

It also turns out to be a useful way to account for when things go wrong, but it's certainly not primarily used for that. For example, if I need to develop a feature within an estimated time frame, say of 3 days, then anything that occurs during this time which makes achieving that less possible, must be raised immediately. Having a trail of rationale is useful to remind others (and myself) that certain things cannot be done due to entirely reasonable but unforeseen circumstances, however, if these are not reported, it will appear to indicate that you've been unable to achieve the requirement of your work, i.e that you're lacking, which is not the case in these circumstances. So that's the second reason.

As another side note: me being able to discuss obstacles or significant events that occurred during an activity, which may impede my task delivery is important, not only because it provides feedback to my team and helps reset expectations, but most importantly, it informs them about empirical circumstances of the world around me, and this brings in new information. All this information is gold because it provides context and situational awareness. Sure, it justifies not only my position (I've documented the rationale and outcomes) but provides a wealth of circumstantial evidence of the actual world around me, information that was not known during planning. This is what my team finds so very interesting, and perhaps quite rightly, i.e having more information about things they did not know before. Obstacles and nuances are such sources of delightful information.

Typically, I find obstacles all the time and they never seem significant to me because I always have them. I am so used to obstacles that they are normal and my default reaction is to circumvent the obstacle and move on. I basically discount obstacles, they are not important to me. However, in light of what I've just said about what they bring in terms of informing the wider community about the actual world around you, they are indispensable. So, the trick with writing lists down, is I can use them to inform my team of the world as it's happening around me (or to me). So, that's the third reason.

The thing about obstacles is I know they will inevitably vanish as I deal with them, so remembering obstacles, reporting on the details and informing my team about them, for me, is challenging, but is increasingly insightful to the team and recently has become incredibly insightful to me too. This is not because I find obstacles interesting (I still don't), but because they remind me how far I've come in whatever it is that I was doing. This is an important psychological feedback mechanism and makes writing lists become more than reporting to the community but reporting to yourself. So, that's the fourth reason.

With a little bit of reflection, what I have found, is that generally for me, with time (even after a few minutes after completing an activity), the degree of perceived utility or usefulness of that activity diminishes significantly. What this means is, at the end of the day I feel less productive, as the sum of diminishing utility is well, diminished utility. From a personal and psychological standpoint, this realisation is significant. Using lists provides a feedback mechanism that helps assure me that I have made progress, and that my efforts have been significant and that they are useful and important. Otherwise, this seemingly fading sense of importance can leave me feeling... unaccomplished and annoyed with my progress.

So, it brings me great comfort in recalling what I've done. 

I also wonder about other aspects that might contribute to why making lists is so comforting to me. For example, it's well known that externalising thinking through note-taking relives the cognitive load on your memory, and I think that knowing that I don't have to remember something, but that there is still an artefact that represents that something, also comforts me. 

I think this is the fifth reason.

Since Itchy legs and tracksuit bottoms, I've been keeping to my exercise routine. I sometimes alter at which times I go. Recently, as it's getting colder and the mornings darker, I've opted to go for a run after work, sometimes I go during the day. Most of my work keeps me focused on my laptop, and coding takes a large portion of my time however this is what I prefer so I'm very lucky to be able to do it every day. 

I've been thinking recently about abstractions, generally.

For example, an abstraction is a mechanism that reduces the details of something such that it appears simpler and less complex. I've been thinking specifically in terms of the reduction of complexity in software as the introduction of abstractions to simpler components, which when you collectively interpret all the resulting abstractions, it yields the same result as what the complexity that came before it did, but now it's just represented as a composition of simpler abstractions.

This is specifically relevant to design patterns as they are a cognitive abstraction themselves of a design idea, which has been reduced into its bare essentials without any verbosity or detail about anything else that doesn't affect the idea itself.

The problem with abstractions is that if you need an idea of what they are, or why they are present, it's difficult or nearly impossible to determine without details that are now missing from the abstraction itself. Details that would tell you about what the abstraction represents are gone which is counterproductive.

So in this case, you might need the complexity it explain the abstraction and that is the paradox itself. In this situation, you must know something about the abstraction first to appreciate or understand why the abstraction exists. So in this way, prior knowledge is essential and so abstraction is useless or very difficult to use/appreciate/explain if it is not recognised first. 

And when you think about design patterns, research has shown that inexperienced developers cannot fully appreciate design patterns if they have not come access to them before or they are not easily identifiable. 

This brings me to my main topic: teaching kids using abstractions.

For example, someone somewhere down the line said to me that the derivative is the rate of change. Someone else later taught me and said to me that it is the tangent to the curve. Someone else said it's the velocity, and that it's the rate of change of distance. Then, it was the change in y over the change in x or the ratio of the change in the function.... You can't teach like this, but sadly this is how we are taught. 

The problem is all these terms are forms of abstractions, and they are all subtly different and thus they are not accurate learning representations, so if you use them at different times in the learning process, it's difficult to accurately explain the detail they represent because the different abstractions are somewhat confusing too, and you need the details when you teach.

Teaching should pretty much always remind us what the details or essence of the abstractions are...otherwise we'll forget and end up thinking in abstractions and never fully realizing what those abstractions actually represent...we'll just know how those abstractions work or are defined - which is not the idea, the idea is to represent the detail simply...but now, you don't know the detail that makes up the abstraction and you're just playing with abstractions now... You've lost your way.

It makes me wonder however if the pursuit of detail is actually a personal journey, where it's up to you to figure out what the details are from abstractions that are thrown at you? Should the kid be saying to himself, wait I don't understand this, I need more details and figure out the details? This is how it ultimately ends up though I think - you either decide you want to know the details or you decide you don't. If you don't (or are not sure if you know what you want), you'll get stuck in the myriad of abstractions and formulas and memorization techniques to get you by through school. And by you must get, because as a society we've mandated that you deal with this education we want you to have. I wonder if that's fair or what's better?

If you aren't exposed to abstractions, you won't be in a position to be confused by them and determine if you want to figure them out. So you potentially need this conflict, and perhaps that's why we have what we have in the education system. Kids being taught math/science/computers - some kids get it, some kids don't.

I'm not sure if it's the kids' fault for not wanting to know the details of the abstractions but there shouldn't be anything wrong with not wanting to know something, there is nothing wrong with not being interested in something, but ultimately they are actually punished for not being interested in the things that our education system demands. They will ultimately become stressed out in exams, learn stuff they don't want to learn or are not interested in learning, they'll get poor grades and comparisons of intelligence will be made - all because they were not interested in some particular area of learning. 

Anyway, this system of needing to become interested...or else, is what causes a lot of abstractions being used to simplify things so that they can cope with this uninteresting thing they have no choice in learning, or can be easily dealt with if you're not interested in the details. Ultimately you're either in the camp of you became interested, you figured out the details or you endeavoured to understand it or... you never did and are now stuck in the system that demands from you what you don't want to give, or know how to give.

I'm not sure what the solution is.

Coming back to the derivative example, I bet many people aren't told why calculus was invented and what problems it solves now that could not be solved before it was invented. If people were told that before calculus, it was impossible to draw a tangent to an arbitrary curve (other than a circle and a few other shapes) and that calculus lets you determine the target line to any curve anywhere and anyhow...that might make a student more interested in why it was impossible in the first place, and why you might want to actually do that.

Secondly, if people were told that it can determine the exact measure of the change in a constantly changing thing at any time while it's changing, they might think wow that's pretty cool if it can be done (because it sounds bizarrely difficult).

Thirdly, if they were told that before calculus you could not measure the area of a space that is bounded by curves, like a squiggly square or giraffe shaped cookie cutter but you now can with calculus, perhaps they've think ok maybe I'll determine why this is useful. 

I was taught by using abstraction, I don't think it helped me, but equally, I don't think I knew what I wanted to know, detail or otherwise and I think I just joined the system.

That's why I wonder if it's a personal journey to figure out the details, whether is a dedicated choice to set out and conquer the detail.

In a way I think it is because without that choice I would not have come to the detail:

The derivative is a measure of an angle that a tangent line will make with a curve, where the curve represents the constantly changing thing, and that the point on the curve that the tangent line hits, is the exact time that the constantly changing thing changes to a particular value, and that the angle measurement (ie the derivative) accurately measures the change to that value in comparison to changes to other values at other times. So now you can compare changes. The rate of change can be measured as this angle measurement.

 Interesting.

These are a collection of the mind maps I've put together over time for certain projects. I find them quite interesting to review from time to time...

{gallery}mindmaps{/gallery}