Jun 29, 2009

Programmer's workout

There was another metaphor concerning the programmer's skills development, which I personally feel is quite sound.

We had this discussion with the fellow programmers, about learning new programming languages and technologies, and generally doing the work which is not just something that you are not really get paid for, but also you don't get any visible benefit at all from doing it. You don't produce any measurable value.

As in, for example, writing a throw-away code in some new programming language just for the sake of learning that language itself.

The notion of "throw-away code" turns out to be more painful than it could be expected: quite often people get extremely personally attached to their designs, algorithms, code, and time spent on some certain activity in general. So, how come one can even remotely be attached to the throw-away "garbage"?..

That takes different forms and flavours: one feels sorry that he had spent years in the university studying something which does not seem to help to find a job, others are reluctant to get interested in anything outside their own area of expertise ("we don't have time for that, it's not our job"). In the case of programmers, in particular, it often turns out in discarding any kind of mentioning related to the technologies, programming languages, libraries, development methodologies, practices which appear to be unrelated to their job.

That's not just cognitive biases in action (which I wholeheartedly confess in being affected by myself), but also pure and perfectly reasonable human behavior, which does it's best to optimize the actions taken by the human being.

So, why would one voluntarily do anything, which is deemed to be discarded almost instantly?

Now, here is where comes a programmer's workout metaphor into action.

Consider yourself going to the gym, and spending some hours per week there, doing the exercises. What you do there, that "weight's pumping" is nothing else as taking heavy things at one place and lifting them up many times during some period of time, just to put those weights back to their place in the end.
So, without any doubt, whatever happens there is:
  • boring
  • hard
  • time-consuming
  • does not give any visible outcome in the end (those weights end up in the original position).
What's the point, then?.. What is the point in doing something, which is barely enjoyable, and gives no visible outcome immediately?

The stock answer would be that benefit is invisible, long term, and whatnot.

But I honestly think that there really is no point, unless you can tune yourself into the state, where you can consistently come up with short-term achievable goals, and furthermore have the feeling of the success every time those goals are achieved.

So, you've pumped up that thing 12 times two days ago?.. what about adding a couple of kilos on top today and do the same? What about going an extra mile?.. Can you spend 10 more minutes in the gym today?.. You can't?.. Well, it's fine, who cares, there's always next time to try again.

You make this small game out of seemingly boring endeavor, and then eventually, unnoticeably you get to the point where you get used to the process and you start to like it.

You start to enjoy it.

And then, what happens next? The forementioned long-term success comes, that's what happens. You don't really feel it "suddenly coming". At that point it's already with you, and it's hard to tell a difference. But it's there. You see it when you start looking at your old photos. Or at your old code, for that matter.

And even if it does not do it that soon - who cares, that was just a game, right?

So, you get a positive outcome out from doing those throw-away exercises, producing the value from nothing.
What really happens is building a solid background, be it physical or intellectual.

The only problem is that this building can be very routine and hard.
In this case helping yourself into making it a game can help a lot.

Jun 21, 2009

Pragmatic Thinking&Learning by Andy Hunt

So, the book was on my wish list for a while, and then I've suddenly bought it.

And read.

 Fortunately, it's not too big and not too mind-pressing, so it did not fall a victim to my occasional bibliomania (yes, I've bought a few other interesting books, some of them still not finished, such a shame). It was a good read, overall.

Sometimes very insightful, even though sometimes it was giving impression of the text being added just for the sake of keeping the format of the book (which otherwise could be a good article).

 The style is very accessible (which is pragmatic trademark), there are anecdotes and humorous remarks here and there, which makes for easier reading.
...a controversial study done in the United Kingdom noted that if you constantly interrupt your task to check e-mail or respond to an IM text message, your effective IQ drops ten points. By comparison, smoking a marijuana joint drops your IQ a mere four points. Whatever you do, please don't do both.
However, some things are abused a bit, in my opinion. For example there is too much fuzz around Dreyfus model, or around brain's L-mode/R-mode. To the extent, that sometimes it gives an impression of the marketing speech, rather than revelation, which most of the pragmatic bookshelf books traditionally are. Still, I think the book was a good money investment. Interesting points I've got from it:
  • There is no golden rules to follow in the software development, everything should be considered in the context, i.e. which systems are there, how they interact (in explicit or hidden ways).
  • The role of "subconsciousness" in the problem-solving should not be underestimated (that's w.hat is called "R-mode"), as it tends to see "the big picture", and has generally access to much bigger amounts of knowledge.
  • Experts, the ones which are true masters of their profession, rely deeply upon "intuition" to take decisions. Intuition, as ephemeral as it might sound, is nothing else as the ability to access all the knowledge and experience packed into non-linear way deep inside one's mind.
  • One does not just "switch to R-mode" to solve complex problems. It's proper interaction/switching between L/R modes what is important.
  • One can "train" oneself to operate more efficiently on the knowledge access inside the brain (this includes developing of the R-mode).
  • It's not only that learning constantly is important, also the way learning happens matters a lot. There are ways to make cognition more effective, such as mind maps, collaborative learning, exploration, playing, engaging metaphors and analogies etc.
  • It's important to maintain diversity in the personal skills, trying to learn thing which might seem "irrelevant" to one's profession.
  • Stress kills cognition, positive thinking is important for being able to use the brain effectively.
  • Failure is important and inseparable part of the learning. One has to embrace failure as the opportunity to gain the experience and to stretch the boundaries of the cognition. On the other hand, it should be safe and non-expensive to fail as often as possible (because stress kills cognition).
  • In the 5-tier Dreyfus model (novice, advanced beginner, competent, proficient, expert) applied to the programming skill, most of the people are on the advanced beginner level.
  • Software documentation is not as important, as documenting process.