Exposing your ignorance while learning a new discipline takes courage, humility and vulnerability. In fact I strive to do this in my posts; it is this blog’s raison d’être.
Having the courage to say “I don’t know,” or “I don’t understand this” is absolutely necessary to grow in one’s learning. As the saying goes, ‘no pain, no gain,’ and growing more often than not involves some measure of pain.
To elaborate more on this important point, I find the more I learn, the more I find I really know diddly-squat. Diddly-squat is a quaint American-English Southern colloquialism for jack-shit. The Classical Greek philosopher Socrates had it right, to paraphrase Plato’s interpretation of his words: ‘the more I know, the more I know nothing.’1
The part in Plato’s Apology of Socrates2 which really rings true to me from beyond the centuries is where Socrates, after having visited the politicians and poets, found them all wanting in knowledge. He then visited the craftsmen.
Socrates found that the craftsmen had knowledge of their own craft, but that they subsequently believed themselves to know much more than they actually did.3
This particular statement recalled a blog post I had read a few months back, written several years ago but still relevant. I happily managed to dig it back up, ‘How Developers Stop Learning: Rise of the Expert Beginner’ by Erik Dietrich.4
In it Erik describes the advanced beginner: someone who has surmounted the initial difficulties of learning a craft and is now able to tackle more complex rigorous problems. The familiar idea here is of progressing from beginner to intermediate, and ultimately to expert and master level of experience.
However, after achieving the advanced beginner phase, the expert beginner risks getting caught in a loop of their own making. They voluntarily or subconsciously cease to improve, in his words,
“because of a belief that expert status has been reached and thus further improvement is not possible.”
To bring it this home to my post, the expert beginner does not routinely expose their own ignorance, either because they are simply unaware of it or are too afraid of the consequences. Another possibility is they are under the Dunning–Kruger5 cognitive bias, mistakenly assessing their ability as much higher than it really is.
This was the concept in Erik’s article which I recalled when revisiting Socratic Ignorance. In order to progress in learning, you must routinely step back to recognize you are ignorant on most things; in fact what you know is minuscule compared to the big picture. Once this humbling fact is accepted, one’s mind is able to continue to seek out the fuel necessary to burn brighter.
On the side of the mentor, once the student through sufficient willpower, courage, and trust has exposed their ignorance on a subject, then effective teaching and learning cycles can occur.
Remember to be brave and expose your ignorance. Your path to learning depends on it.
Thanks for reading.
Please forgive my butchery of Plato’s interpretation. I am not a Classically trained scholar. ↩
A huge gulf exists between dabbling with code and really getting at the heart of a problem using dedicated computational thinking. This gap marks the main difference between the beginner and advanced learner of code.
Well, what is it?
Computational thinking is the often overlooked but vastly important ability to see beyond individual tools such as frameworks, editors, even programming languages. It entails understanding how to go about logically resolving a specific problem in a progressive and incremental manner much as a computer does.
Breaking down problems like this is second nature to long time programmers, and in my humble opinion it is one of the most important skills to learn as a beginning learner of code.
Realizing the importance of how to go about thinking computationally was a great leap forward in my coding education and opened the door to more advanced computer science concepts such as algorithm efficiency, Big O notation, and understanding how to RTFEM1.
OK, but how do I think computationally?
I can attempt to relate computational thinking to physics (putting my Uni degree to work!) There is a method called the free body diagram2, which shows a body, (whatever the subject of the particular problem,) being worked upon by all external and internal forces. The purpose of the diagram is to illustrate and calculate what will happen to the body given a set of known circumstances.
Similarly, in computer science we can think of the program as our body, and the environment/system as external forces. If we visualize all the external and internal forces on our ‘body’, then we are better equipped to predict future reactions. More importantly, we can more quickly find and explain errors when our predictions fall short.
This to me is the essence of computational thinking, an almost Zen-like philosophical approach to programming, which does much to explain the benevolent stereotype of the wise UNIX sysadmin for whom no error message is entirely inscrutable.
You know the type: after struggling with a certain problem for a while you seek the guru’s advice. With a simple hand wave over the keyboard and a twinkle in their eye, they make the problem disappear.
This is computational thinking in action. Much like a good magic trick, there is nothing mystical happening but the combined power of great experience. The goal is to one day also achieve such a level of mastery that makes debugging look like magic.
So I should “Be one with the machine”. Got it.
Computational thinking can be seen in a pristine form when we take a look at the basic rules of the UNIX philosophy3. I won’t go into too much detail right now on each rule; suffice to say this reading material should be required for anyone who is starting to learn to code.
If there seems to be a lot of Zen Buddhist philosophy wrapped up in many computer science concepts, specifically in programming, it is due to this tradition based in practice which has been passed down over decades.
These concepts are not so much rigid dogma as they are principles proven over time to facilitate the creation, communication, and maintenance of code. These concepts are not etched in stone; if any of the accepted statutes were to one day become inadequate, then it would be our duty as pragmatic programmers to revisit, modify or throw out the tenet if it no longer serves our need.
The reason to be fluid is evident. We have seen paradigm shifts in the past, and we will continue to see them in the future. Machine Learning, AI, quantum computing and more new fields will require many of the same principles which have served us in the past, as well as introduce new methods.
Computational thinking will continue to be valuable since it is such a fundamental way of how we program and solve problems using these marvelous devices called computers.
Google’s PageSpeed Insights is a simple and fast diagnostic tool that provides some very interesting and often revelatory suggestions for the front end developer.
Since we are in the business of optimizing all the things, I thought it would be fun to run this website through the tool.
The good news
My site is performant on mobile and desktop as expected for a static site. Browser caching and minifying of assets were both suggested actions that are quickly and easily implemented.
The not so good news
Unfortunately the mobile user experience score suffered slightly due to some tap targets or links that were too small for comfort and my footer was named as an offending element that falls “outside the viewport.” The report stated: “The page content is 421 CSS pixels wide, but the viewport is only 411 CSS pixels wide.” These were easy “Consider fixing”-designated issues and the tool even gave helpful suggestions on how to achieve it.
The devastating news
Significantly decreasing my score on both the desktop and mobile versions was the fact that there was blocking JavaScript on the page above-the-fold, (a term borrowed from print newspaper publishing. Shout out to my time at The Daily Texan for teaching me that one.)
This issue was given an ominous “Should fix” designation in red. I was supremely humbled and after quickly stepping through the five stages of grief, I took a look at the improvement suggestions.
As I suspected, it turned out the blocking JavaScript is my totally cool and awesome comment system, which, as is JavaScript’s wont, loads up asynchronously. This has a noticeable effect only when there are a large number of comments to load from Firebase, which completely makes sense.
While I ponder how to reconcile this issue and perhaps make a change in the future, I am satisfied that it is not a tremendous deal-breaker. My pages load on mobile and desktop just fine and dandy. However, I found it really great to know that this marvelous tool exists. Thanks Google!