I have read the book Grit by Angela Duckworth. It brought some obvious (or not) things to my attention:

1. To really get better at something you need to challenge yourself, try more difficult things, not just repeatedly do what you are already capable of. (my words, not a quote from the book)

If you think of an athlete, a high jumper, this seems very obvious (you are never going to jump 2.00m if you keep practicing 1.50m all days).

2. Mastering something is about allowing yourself to dig deeper, getting more depth and seeing more details (than a novice).

If you think of a sports commentator (making remarks about subtle technical details in figure scating or gymnastics), this also seems fairly obvious.

What are programmers told to learn
I often hear advice to programmers about how to learn and work. I would say it is mostly about trying new things:

• Learn new programming languages
• Learn new tools and libraries (that simplifies things)

While these are obviously good things to learn it is neither very challenging nor very much going deeper. And when it comes to tools and libraries that simplify things you perhaps trade deep understanding for easy productivity.

It is not very often I hear the advice to try to solve a hard and challenging problem using tools you already know very well. And it is also not very common that I hear the advice to go into very intricate details about anything.

Programmers seem to value, or be valued by, knowledge about things allowing them to find shortcuts or ready building blocks:

• Libraries and frameworks – to write no code, less code or avoid writing difficult code
• Different programming languages – to pick a language that makes it easy
• Patterns and methodology – to avoid difficult technical analysis and design
• …and soft skills or course

All these skills are quite easily described in a CV. But none of it is particularly difficult or challenging.

What is truly hard about programming
To implement a correct solution a programmer needs to:

• Understand the problem or problem domain correctly (and perhaps completely)
• Come up with a solution and software architecture that can actually solve the problem
• Go through the labour of correctly crafting the required code
• …and this is or course done iteratively, learning and adapting along the way (because getting everything right fom the beginning is often impossibly hard), so you need to make incorrect/insufficient decisions that lead you in the right direction for now

This can perhaps be called problem solving or seniority in a CV, but problem solving is a rather abstract cliche and seniority is often measured in years more than anything else. Also it can appear to be covered by things like requirement analysis, patterns, TDD and agile. But these things are about how to plan, facilitate and manage the difficult things. You can know a lot about TDD, without being able to correctly write test cases that describe the problem domain correctly, and without being able to implement an algorithm that solves the problem sufficiently well.

A balanced training
Back to athletes. Golfers (lets call them athletes) used to not be very fit. Then came Tiger Woods. Since then all (top) golfers go to the gym (to be able to compete). To me, this is like you can be a good programmer but if you don’t know git you are simply not very competetive.

But golfers spend most of their time mastering their swing (or in the gym, or with a shrink). They don’t also do horseback riding, pole jumping and run marathons. Or if they do, they at least don’t think it is key to becoming a better golfer. But when it comes to programmers this is often what we do: learn a new language, a new framework or a new service. Like it would significantly make us better (even though it is no challenge at all, just some time spent).

No similes (or metaphors) are perfect. Golf is not programming. Most programmers don’t aspire to be among the best in the world. But I think the question is worth asking:

Do I, as a programmer, have the right mix of hard/challenging practice and trying/learning new stuff?

Learning in the workplace
In our workplaces they don’t want us to work with things that are so challenging that we might very well fail. That is a project risk. And IT projects fail far too often for anyone to be satisfied. It is not at all strange that organisations want us to work with things that we know and otherwise they want to mitigate the risk by making things easier. But do we learn this way? And do we, 5-10 years down the road, reach our potential and develop the capabilities that would benefit us the most?

Is there a genuine conflict because making things as easy and productive as possible on one hand and improving skills on the other?

For whom do we learn?
I don’t know if programmers who challenge themselves and become masters with deep knowledge are rewarded for it. I don’t know if most organisations even want such programmers. I already hear the complaints:

• No one else understands her code (but if the problem was THAT hard, what was the poor master going to do?)
• She is just inventing things instead of using standard tools
• She is not following best practices

Also, who will ever know what a great job such a programmer does? It is like:

1. This integration routine is unstable and too slow, can you try to fix it? (lets say it is very hard)
2. Master fixes it in 4 days
3. Some suspicious comments: yeah sure?!
4. After the next week no one ever remembers and its just taken for granted that it works the way it always should have

Don’t do as they say they do, do as they do!
I can’t back this up, but I have the feeling that the best programmers we know are people who challenged themselves with insane projects. But what we hear is that programmers are valued by the number of technologies they know.

I would think that smart organisations know how to identify and appreciate a master. And I think master programmers eventually find themselves in those smart organisations. But I think it happens mostly below the radar.

Example: git
Before git there was subversion (improved on svn) and a number of commercial version control systems. These were, like all tools, both appreciated and hated and using them was best practice.

Now Master Torvalds was not happy. He challenged existing technologies and designed and wrote his own system: git.

However, what I find fascinating here is that he wrote git in C. People complained about it of course. But git was fine because Torvalds

1. deeply knew the problem domain,
2. designed git very well,
3. implemented it in a language he mastered.

It is like, you can’t argue for implementing a system like git in C, but in the end git could not have been better (smaller, faster, more portable) if it was implemented in any other language.

I guess for the rest of us the question is always:

1. should we use a proven solution and take the easy path?
2. should we invent our own solution possibly using the crude tools we master?

But if we are never arrogant enough to go for #2, how will we ever grow to be able to go for #2 when it is really needed of us?

The Hard Way
There is a (somewhat infamous) book series and online courses about learning to code the hard way. Many programmers like C/C++ perhaps partly because the fact that it is difficult and even a bit unsafe is fun. I think somehow JavaScript has the same appeal in a different way.

Many hackers seem to be struggling with the impossible even though it is hardly worth it from a rational perspective.

I sometimes entertain myself with Hackerrank.com (especially Project Euler). Some challenges are truly hard (so I have not solved them). Some I have solved after weeks of struggle (often using Lisp or C). I used to judge myself, thinking it was an absolute waste of time. On top of everything it made me a bit stressed and gave me occasional sleeping problems because I could not stop thinking about a problem. I am about to reconsider it. And perhaps it is the really hard challenges, that I fail to solve properly, that I should focus on.

Conclusion
I have left a number of unanswered questions in this post. I don’t have answers. But I think it is worth considering the question: do I reach my potential as a programmer the way I try to learn?

Update: Cynefin
A colleague made we aware of the Cynefin Framework. I imagine many of us encounter problems of all levels: Simple, Complicated, Complex, Chaotic. When we encounter a more difficult (Chaotic) problem we need to identify the problem as such and feel comfortable working with such problems. That requires training and experience, not just with Simple and Complicated problems, but with really hard problems.