Learning: Some How-Tos

Tell me, and I will forget. Show me, and I may remember. Involve me, and I will understand.

– Confucius

So far we've investigated why learning is important to software developers, and what we should be learning. We've looked at some learning models and uncovered many valuable facts about the way the brain stores, processes and retains information. But that's all been background. We've not yet actually put any wheels on our boat, and looked at the practical tools and processes that will help us to learn better.

Now it's time to rectify this omission.

Manage your knowledge portfolio

The pragmatic programmers describe a vivid and potent metaphor for learning – they talk about your knowledge portfolio. Consider your current working set of knowledge like a portfolio of investments.

This metaphor beautifully highlights how we should manage the information we have gathered, carefully investing to keep our portfolio current, and bringing in new investments to strengthen it. Consider which items you should retire from your portfolio, to make room for other things. Be aware of the risk/reward balance of the items in your portfolio.

Some things are common knowledge, but a safe investment to hold – they are low risk, easy to learn about, and guaranteed to be useful in the future. Other investments are riskier – they may not be mainstream technologies and practices, so studying them may not pay off in the future. But if they do become mainstream then you will be one of a smaller set of people experienced in that niche, and so able to exploit that knowledge more. These higher risk knowledge investments may pay much greater dividends in the future.

You need a good spread of risk and a healthy range of knowledge investments.

Purposefully manage your knowledge portfolio.

The angle of approach

Whenever I look at a topic in programming (and by now, I've written about quite a few in my columns and my book), the essence of success always seems to be determined by a single issue. And in the field of learning it seems as clear as ever: to be successful at learning you have to adopt the correct attitude. Your attitude towards learning will directly determine the quality of your learning.

We saw previously how mental state can affect performance, and the social psychologist Carol Dweck's research into the affect of mental attitude on ability to learn: that those who believed they could learn did so far more effectively than those who thought they couldn't. Self-belief is an incredibly important attitude.

We must take responsibility for learning – it is something we must do for ourselves, we cannot expect others to make us learn. We must adopt an attitude of continuous learning, never believing that we know it all or that we know enough – there must always be a hunger for new knowledge, a driving curiosity. This couples with humility; again recognising that we don't know everything and that we can learn from anyone and anything.

The most effective tool in learning is to care about what you're learning, and to be prepared to invest effort in order to learn. Dweck wrote about this in her book Self-Theories: Effort is one of the things that gives meaning to life. Effort means you care about something, that something is important to you and you are willing to work for it. If you are prepared to invest effort into learning about something, it not only shows that you value the topic, it means that you intend to and desire to learn.

Coming next: some practical mechanisms to improve your learning.

This is how we build software

My tongue was planted firmly in my cheek when I drew this little masterpiece. (Click on the image for a larger version.)

It originally appeared in the June 2010 issue of ACCU's C Vu magazine as part of my regular software development column.

Learning: A review

It's been a while since I wrote a blog about software developers learning. Previous postings have investigated learning models, the mechanics of the brain, how, why and what to learn, and more.

There's more to come, but let's just take a little refresher of some of the points I've raised so far:

• Learning is a basic human skill. We can all do it. We do it all the time.
• Our learning is too narrowly focused. Consider a wider sphere of reference. Draw inspiration from other fields.
• Learning is hard work. It doesn't come for free. But you don't get a reward without an investment.
• Learn to learn. That's why I'm writing this series! The most effective learning is done on purpose and planned to maximise effectiveness.
• The left brain/right brain split We need to employ all of our available brainpower to make our learning maximally effective.
• Personality type affects learning style Understand how you best learn and exploit that to your advantage.
• Memory fades Unless you refresh your knowledge by using it, your memory of it will become unreliable.
• Memory grows Constant stimulation is required to maintain growing mental capacity.
• Mental state effects learning Cultivate a positive attitude towards learning. Otherwise you may as well not bother.
• Learning models Certain models can help us classify levels of expertise and plan how to gain it.

Shortly I will describe at some very practical techniques to help improve our learning capabilities.

Eulagise: Adding a EULA to a DMG

My code projects usually include a release script, a shell script that does something like this:

• cleans the build tree,
• rebuilds the project,
• runs the unit tests (stopping if they fail), and
• packages the project.

It's that last step I'm concerned with here. On Mac OS packaging usually involves building a DMG disk image. Automatically creating a DMG isn't entirely straightforward in a shell script. In fact, it's not straightforward at all. It took me a while to master the process; I bastardised and tweaked part of the Audium build process to perform this feat of engineering.

A recent requirement was to add a EULA to the DMG. If you're a Mac user then you've probably seen them once or twice. They look something like this (this isn't my one, for client confidentiality purposes).

The EULA appears when you double-click the DMG file, if you agree to the EULA then the disk image opens. If you don't agree, then, well you can work out the rest.

Something so simple, and so standard, must be easy to add. Right?

I hate to spoil a good story, but it's a bit tricky. Don't worry, the story has a happy ending.

It's not an easy task because:

• The EULA has to be in a very particular format.
• The EULA has to be added to the resource fork of the DMG.
• You can only add resources (i.e. the EULA) to an unflattened DMG object, use the Rez utility to add resources, and re-flatten the DMG.
• There are no clear and easy docs on the subject. (That I could find.)

Of course, being a script we want this to be automated, rather than a clicky-draggy process. There are programs that'll do clicky-draggy. We have to rule those out.

Ideally we want a script that takes a text file as input and the DMG to attach it to. Magic invisible elves inside the script do the rest.

I spent some time writing my own script, hitting a number of obstacles each time around, and then research pointed me towards the Seamonkey build system. Seamonkey has a script here that can do it. Hurrah! The script also creates the DMG in the first place, setting icons, volume name, etc. Sounds great, except that it does all the other stuff rather badly. Or at least, less well than the script I already created.

So I removed all the other cruft, and paired Seamonkey's script down into eulagise. Eulagise is a simple (ish) script to add a EULA to a pre-existing DMG. You use it like this:

./eulagise.pl --license MyEula.txt --target MyDiskImage.dmg

Simples.

You can get the script on gitorious here. I hope to neaten it up, and remove all the extraneous cruft shortly.