"The beginning of wisdom is to call things by their proper name." - Confucius.

"The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary." - Alan Perlis.

The problem in the beginning is not knowing what I don't know. I have the concept in my mind, but I can't map it to discipline terms. One solution for this is to shed light on the unknown by exposing the known to people. A sort of impulse response characterization.

An example would be, for an unknown function, to give the function's input and the desired output.. and ask people what sort of thing can do that and what is it called. The more experienced will recognize what the person is trying to do and give options.

It also can mean, for a known function, giving the input, the output, and what we expected the output to be.

For example, I began learning Python and I think this was the first question I asked on the mailing list ('Why is an instance smaller than the sum of its components?') because the behavior was odd to me:

https://mail.python.org/pipermail/tutor/2015-February/104098...

A few methods that served me well:

- Having toy projects I'm playing with: This ensures I have problems beyond my skill level, and prompts me to think about solutions. Ugly solutions that make me say "Can't believe I'm writing this". This is a signal that I know that what I'm doing is wrong and I don't know the right way to do it yet. What I know is this can't be right. Get code reviews:

https://mail.python.org/pipermail/tutor/2015-April/105199.ht...

Mistakes are for programming proficiency what muscle fiber tears are for muscle growth. Not making mistakes rarely if ever means writing perfect code and almost always means no growth. I wish I've had tons of side projects for this is what makes people good. I dearly regret this.

- Roaming through documentation.

- Always thinking "meta": I have a running process looking at design and simplicity in general and a canonical way to approach writing well. This is interdisciplinary and would get you flagged on Stack Overflow. Yet, I find this of paramount importance.

I remember struggling, frustrated, thinking "If there's clearly good code design, and bad code design.. It means there's a universal "thing" code can either fail or succeed at abiding by.. A sort of pattern good code follows and bad code violates. Similar to what Blaise Pascal said about beauty.. What is this thing called? What are the rules that all good programmers know but are somehow impervious to me?"

When I found out there was such a thing called "design patterns", I smiled in a "of course there is" because my formulation of the problem contained both words. Why didn't I simply look for that expression.. (I was looking for good software practices, good taste, etc).

But having side projects is the most important. I'm both blessed and cursed for I started programming at 9 and by 15 I was "improving already compiled software" and in that period, I was exposed to BASIC (GWBASIC, QBASIC, Visual Basic for DOS and Windows), x86 Assembly, C, Pascal/Delphi, C++, so this makes it slightly easier.... The curse is that I haven't used that edge keeping at it so I haven't become good (I didn't have internet, English is my fifth language and there was no one to talk with about this stuff where I live. It was solitary and isolated).

I think it would be great to try to design something in a team, like think of a real product and get the whole class to work on delivering it. I think having a go at making software as it would be made in the real world is one of the best exercises to get good at ... well, making software as they will make it in the real world.

Runners run and deal with sprained ankles, golfers golf and deal with winds, swimmers swim and deal with water in their nose, but somehow coders do fizzbuzz. I think a curriculum that offers a taste of the real world would do more good than harm.