I'm right with you -- My first introduction to a programming language was dedicated to pointers, stacks and heaps, and memory allocation. It was hard to grasp why any of this mattered when there was nothing tangible to chew on.

I wish in hindsight I had started writing more high-level code, built something, and then was introduced to these concepts as they became relevant.

 

I think that's why so many people struggle to learn programming. I actually found myself going back to the concepts I was "taught" years after college because all the code I had wrote gave me enough context to understand those concepts.

We need to redefine what would be considered "basic knowledge". The "basics" should really be a certain amount of experience actually doing something. Understanding what happens behind the scenes are the advanced topics.

 

What the.. that’s too high a bar to cross..

 

My experience learning to code was slightly different than the typical CS program so may not apply directly, but I think has some merit in a certain sense. I went through an electrical and computer engineering program in which computers and software were taught from the ground up - literally. How do computers work? Well switches (transistors) are either on or off, etc. How are those used productively? To do things like add numbers, evaluate logic, etc. Ok, so when I say add these two numbers, I now know exactly what is happening in the machine. This progressively builds up to start learning higher level concepts/abstractions and along the way languages (c to java and so on). You start at the core and grow outward. This ensures you are always building on top of a base foundation of understanding, rather than having to dig through the confusion of lower abstractions. This may or may not apply to many whom never will leave high level languages built for web development, but still may be useful (not a web dev so don't know).

One valuable thing in this approach and maybe in the 'current' approach you mention (depending on how its done), is an understanding without mystery. When the computer spits back error messages at me or does weird things I (generally) understand why because I have working mental models of what the computer does - sure you abstract at certain points (I definitely don't think about transistors or gates), but I have the tools to be more self-reliant. Usually growing outward helps by starting with a smaller domain that a student need's to understand (something you are effectively describing here). In this case it is enforced by the tools rather than arbitrarily. To your boolean operator example, in my case we only had AND and NOT, so you learn the two that exist and then learn how to combine those into more complex operators.

I do completely agree with getting students excited early on in the process. Being able to have successes, no matter how small, is key to being motivated to continue the process. CS and learning to write code is hard, so feeling capable is important. This can be done starting with core concepts at low levels. I wrote a game in assembly my first semester of school. It was crap but I felt accomplished as hell and knew completely how it worked!

Thanks for the article - great read!

 

That's actually a very good point. Most CS education does not start with hardware so a lot of it does seem like mysticism at first.

I actually learned how computers work at that level (though in my 4th year of college) and I found it very interesting. However, I don't think it's necessary to know for most web development these days. It would be for more advanced computer science work, but most programmers don't work on products that require that kind of programming.

 

I've been coding for almost 10 years when I started studying CS the first time. Having that much experience, I wasn't motivated enough to make my degree (had a good job anyway). A few years later I made a new attempt and it turned out that both, my experience from coding and from the first CS courses, were a big advantage.I learned and understood much more of the CS theory.

Don't forget: If you choose to become an IT professional, learning will never end. If you stop learning, you'll soon stop being a professional.

 

Agreed! I had a professor in college who said "There are developers with 30 years of experience, and then there are developers with 1 year of experience repeated 30 times."

 

This is easily one of my favorite posts on this site. I don’t know how it took me so long to find it!

 
 

The analogy is in the art world, learning how to grind and mix paint versus learning composition and perspective.

 
Classic DEV Post from Aug 9 '18

How do you style components with React Native?

Styled components are great for React, but do they work with RN?

Beekey Cheung
Beekey Cheung is a software engineer with a large amount of enthusiasm for economics and a passion for education. He loves mentoring other programmers and is currently building an application to te...