I just uncovered this book review on William E. Shotts Jr., The Linux Command Line: A Complete Introduction (No Starch Press 2012) I left as a half-done draft months ago. In it, I found a long collection of thoughts on learning programming from books and what common problems are. The book review will still follow at some point, but these are some of the examples of common problems with ‘computer books’. The typical computer book: a long detail-rich, reference-like read I like the Intro to the Linux commandline a lot, but also found that it was very long in pages but the content isn’t super dense. So it was a very long read and I’m always ambivalent about books which are reference-like and super-long. I am a person who likes to read and even I put off reading this book for a long time. I read a chapter every morning while having breakfast. Some chapters I just skimmed because they didn’t contain
learn programming
How to improve at programming when your current position doesn’t require it & Online Learning Resources
fHave you ever felt like you would like to get better at programming, maybe even get a position involving more programming some day but the fact that you currently don’t really need it at your current position seems to hold you back? This post is for you. Daily practice is key for improvement You need daily practice if you actually want to improve. You already need daily practice just to keep your skills sharp during a time where you don’t need to use them. Also, if you don’t even have programming skills yet, you probably are too tired after work to sit down and work on a private programming project for a meaningful amount of time. But you should. Programming is a skill which takes a long time to learn. That is, if you want to reach a decent skill level. This means that you have to start regular practice long before you actually need that skill or need to
Didactical Reduction, Part II
In my first post on didactical reduction, I argued that reduction of learning materials to meaningslessness can be detrimental, that teachers should trust in their students’ ability to learn and rise to a challenge. In this post I want to discuss ways of reducing complexity which actually makes sense. The gist is: reduce unneccessary detail, not difficulty. Build complexity in a carefully chosen progression. Telling the difference between unnecessary detail and challenging complexity In my post on why programming classes fail and learning ‘algorithmic thinking’, a main example was that students starting out programmig don’t need to know about data types. I will stick with this example here because I just think it illustrates my point so well. The skill to learn I discussed in the post really wasn’t the ‘vocabulary’ of your first programming language, but ‘learning programming’ means successfully communicating with a computer and in order to do that, you need to develop the skill of algorithmic thinking. This
Why most “learn programming” classes, books and attempts fail
This seems to be a bold claim. Let me explain… There are two reasons why I think most introductory programming classes fail ant that is a) because they never actually teach prorgramming (i.e. “algorithmic thinking”, not the syntax of one concrete language / “your first language”)) and b) because they bombard students with tons of complicated subjects which are not necessary at the beginning, so nobody remembers or understands them anyway. But they confuse the students and distract them from what they really should learn like how to interact with the machine and basic flow control. Use a visual language (like Scratch for PC or Catrobat for mobile devices) and thank me later. Algorithmic thinking When we want to learn or teach how to program, we first need to define what programming is. Like in a human language, knowing the words and the grammar is not enough – knowing a language means “knowing how to communicate using that language”. For
read more Why most “learn programming” classes, books and attempts fail
LaTeX Ninja'ing and the Digital Humanities 