Add post about teaching C series

.gitignore

@@ -1,2 +1,3 @@
 .hugo_build.lock
 public/
+private/

content/blog/teaching-c-reflections/index.md

@@ -0,0 +1,69 @@
++++
+title = 'Reflections on "Teaching C My Way"'
+date = 2025-01-31T00:55:19Z
+author = 'Ethan Marshall'
++++
+
+It nearly always takes quite a shock to the system or severe inconvenience to actually get me off my behind and to start working - so that should probably tell you something about the state of educational C programming videos when I tried to do it myself.
+
+> If you are here looking for video IDs, please see [here](videos).
+
+Let's face it: nobody makes languages like C nowadays for a reason. Computer science and software engineering have moved on from a time in which raw control and performance are emphasized over all else to instead prioritizing ease of computation and protecting the user from himself. This isn't necessarily a bad thing. It is usually considered nowadays that so-called "low level" languages like C are sharp, dangerous tools that only trained professionals should be allowed to use.
+
+{{< figure src="angle-grinder.jpg" caption="Here we see the average developer trying to write a C program" >}}
+
+Now, this is usually the place in the blog where I begin to defend C and talk about how great it is. This time, though, I can't. The modern developers are right. C code, especially critically important C code, *should not* and *cannot* be written by just any developer. The be a good C programmer nowadays, you need to know exactly what you are doing, be confident in the way the language works and have been instructed by somebody who knows where you will slip up and catches you before you fall.
+
+This is where I believe I failed.
+
+## How to Teach C
+
+On reflection, I think that the most important quality in somebody trying to teach C is **clarity**. The concepts and ideas of the language need to be expressed as clearly and as simply as possible without skipping over such detail that the edge cases and unintuitive behaviour are omitted. These are arguably the most important details, as any C programmer will tell you.
+
+When teaching C and its constituent parts, I think that grounding the design of the language in the underlying technical details is a good choice (and one that I tried to stick to when doing my own series), but overwhelming the learner with large amounts of technical detail which do not allow them to write working programs will simply discourage them and make it less likely for them to get the concepts right in the first place.
+
+{{< figure src="complicated-workspace.png" caption="&quot;So Timmy, we have to push the base pointer onto the stack to start a new frame before we can print Hello World. Any questions?&quot;" >}}
+
+On a related note, pacing is extremely important in education. If the student does not feel as though he is making adequate progress by following the tutorial, he is likely to sack it off as a bad job and try something else. Going through mountains of technical detail might feel rigorous and thorough, but the reality is that most of the details won't be going in anyway. If you dwell too much on unimportant details without giving the students anything concrete which they can use to get results, they are just going to quit.
+
+Finally, an important quality in any person who is teaching *anything* is to be **100% clear on the subject you are teaching yourself!** If you have any misconceptions or false assumptions in your mind when you are teaching, you will inevitably pass this on to your student like some kind of insidious mental disease. This is another area where I, evidently, fell down in my series.
+
+## The Failure of &quot;My Way&quot;
+
+So, looking back at the series as a whole, I think I can identify numerous areas in which I violated the points made above. First and foremost, I didn't understand the language well enough to be teaching it. I had been writing C for many years and had written some fairly significant projects in it, spanning thousands of lines of code. What I underestimated, however, is how large of a jump there is between the level of understanding required to be technically competent and technically competent enough to teach. As mentioned earlier, most people can harbour certain misconceptions or slightly inaccurate mental models of something that they know about which are unimpactful enough to permit them to still get by without correcting them. However, upon being subjected to even the slightest questioning, inaccurate mental models will come crumbling straight down, leaving both the student and the teacher very confused.
+
+{{< figure src="bad-teacher.jpg" caption="You laugh, but there has probably been somebody who thought this was how this worked" >}}
+
+In the Teaching C series in particular, a number of my own mental misconceptions were exposed by questioning from commenters. A particular example which I always remember is about my way of teaching about buffers and pointers, which I chose at the time to lump together into an episode (due to poor reasoning which will soon become clear). Commenters questioned as to why there was different syntax for declaring buffers and pointers if they were the same (as I claimed in the video), and why C would not allow them to declare a pointer with an array literal as a value when they *could* declare a buffer with that value. I had to experiment with this for myself before realising that I had made a classic error. Buffers in C will *decay* down to a pointer upon use external to their own local binding (for example, if passed as an argument or assigned to another variable). However, that does **not** mean that buffers and pointers are equivalent.
+
+{{< figure src="yt-comment-question.png" caption="This commenter first alerted me to my threadbare understanding of buffers" >}}
+
+Under the hood, they work similarly, but they have very different semantic meaning in the language. Whereas a pointer holds a memory address to an arbitrary location, a buffer represent multiple copies of a particular data type which can be accessed in bulk. Declaring a buffer is essentially requesting to the compiler to reserve you space for a certain number of a type to be stored. You cannot overwrite the memory address contained within a buffer variable, as this value is fixed when the compiler reserved the space. Operations on buffers are implemented as operations on pointers, but, in reality, no pointer is actually stored when you declare a buffer. You *can* do this with a pointer, as it is intended to point to any piece of memory.
+
+These were facts that I *sort of* knew before doing the series. However, in day-to-day programming, I never had the chance to properly explore these concepts properly. So, upon attempting to teach them, my misconceptions and failures in understanding were laid bare.
+
+## Those in Glass Houses
+
+The most embarrassing part of all about incidents like that detailed above (which was by no means unique) was that I essentially started the series by having a dig at a Tutorialspoint article about getting user input in C. To be completely fair to me, the article in question was horrific, teaching the very worst practices in C and then writing it off as "not production code" and "just for the tutorial", which begs the question as to where exactly they store the *production* version of the tutorial. Or do they just think that people are learning C so that they can write the same shoddy, crash-laden program over and over again for fun without improving?
+
+This may actually be the case, in fact, as Tutorialspoint is a perfect example of an Indian "achievement generating" website in which the lowest hanging intellectual fruits are drip-fed to people who want to be able to say that they have "studied" something or "taught themselves" something, when the reality is that they don't actually want to learn and instead just want to have these things to put on a CV.
+
+{{< figure src="indian.png" caption="Hello Saar, welcome to dis tutorial" >}}
+
+You notice this all the time on the internet: you will be researching a topic in mathematics or physics and find that a suggested search term always appears with "JEE advanced" tacked on the end. In case you don't know, the JEE is sort of like India's Gaokao or pre-university aptitude test. The issue I take with this is that the terms are always broad topics like "angular momentum" or "energy conservation". These are broad topics with lots of interesting material on them. Are these people interested in them? No. They are interested in the possible problems they could encounter in the "JEEt Advanced™" exam so that they can have a shiny high score. They have no interest in intellectual self-improvement outside of that which is mandated by the exam they take.
+
+This is sort of the same problem you find with websites like Tutorialspoint. They don't actually want to teach the material to a high standard. They just want to churn out large numbers of articles with the bare minimum contained content so that they can boast about how many languages they host tutorials for.
+
+The issue with my criticism of websites like Tutorialspoint is that I then went on to make many of the same mistakes their tutorials did. Of course, I think I can probably say that my intentions were a damn sight purer than their, but the point still stands: if you are putting out intellectual material onto the internet, I think you have a certain duty not to mislead those who read it, in the same way that a teacher has a responsibility not to badly teach his students.
+
+## Pacing
+
+{{< figure src="screaming-wojak.png" caption="Oh god, the pacing" >}}
+
+There is no excuse for an introductory episode to be over an hour long. My terminal waffling condition has since improved, but please send thoughts and prayers, as the situation is still borderline critical.
+
+## Conclusion
+
+Looking at all of the above, I think we can conclude that if I am ever to try anything like this again, I need to be better prepared and to think things through a little further. I'll also need to make sure I am 100% watertight on the material before trying to teach it and ensuring that I have a concise plan on what exactly will be taught and when. In retrospect, however, I don't really know why I suddenly decided I would enjoy tutorial making. One of the few things I was dead set against doing when I started a YouTube channel was tutorial making, and I've come back around to that position: I really don't enjoy the concept. I can't see myself re-attempting anything like this in the future.
+
+Teaching C might have been a passable first attempt at a tutorial series, but, for all the reasons I outlined above, I don't think that's good enough. That, along with various other things, contributed to my decision to partly take the series down. If you choose to watch it after reading all of the above, best of luck to you.

content/blog/teaching-c-reflections/videos/index.md

@@ -0,0 +1,20 @@
++++
+title = '"Teaching C My Way" Archived Video IDs'
++++
+
+Before watching these, please read the accompanying blog post which explains the reasons they are unlisted and the caveats that should be considered attached to this series.  Aside from that, enjoy :)
+
+* **E01** - https://www.youtube.com/watch?v=snvlA_FTNPY
+* **E02** - https://www.youtube.com/watch?v=IC9mlCKQcAA
+* **E03** - https://www.youtube.com/watch?v=9LGGc0Jpo7U
+* **E03.5** - https://www.youtube.com/watch?v=maE3cEwg7U4
+* **E04** - https://www.youtube.com/watch?v=hKSVcjsxg8w
+* **E04.5** - https://www.youtube.com/watch?v=HLVjoTHeeiw
+* **E05** - https://www.youtube.com/watch?v=dnuE7kvoGPk
+* **E06** - https://www.youtube.com/watch?v=ig3HIwKhVKY
+* **E07** - https://www.youtube.com/watch?v=9qhngN0mun4
+* **E08** - https://www.youtube.com/watch?v=7UPTepoH7jo
+* **E09** - https://www.youtube.com/watch?v=cwrlgWd8C1o
+* **E10** - https://www.youtube.com/watch?v=9C7Q-s-j_M0
+
+*Entries with an episode number ending in ``.5`` are addenda and appendices.*