I find one of the most helpful things a person can do when tackling a difficult subject/situation is to try to come up with accurate generalisations of aspects of the subject or situation. This process can strengthen the person’s understanding of the matter at hand, and, if they are successful in this practice, they will also end up with something that can help them remember for the long term.

Last year, one of the courses of the Master of IT degree I am currently doing asked the students to justify that they had an understanding of programming. Here is part of the answer I provided, which was the result of the generalisation process described above.

> To learn to program is to learn how to structure logic to shape data in ways we want, because, similar to how woodworking is about working the wood, how pottery is about working the clay, and how painting is about working the colours, programming is about working the data.

> Learning more programming patterns is arguably more important than learning more programming languages, because languages are merely tool, and knowing how the tools work does not equate to knowing how to program.

> The architecture of an application is equally if not more important than the actual code, because the architecture describes how an application does something meaningful, and code is for realising what the architecture describes.

> Programming languages may be seen as made up of:

– core language rules (including primitive data types) by which alone should allow all functionalities of the language, though complex tasks may require an unreasonable amount of work;

– builtin libraries (including composite data types) which generally include abstractions for non-specialised common tasks and vastly reduce work required for complex programming tasks; and

– external libraries which generally include abstractions for common tasks in specialised areas.

By taking this three-component view, I was able to determine learning priorities when picking up a new language.