I was tagged in the tweet below and for good reason. I have feelings on the topic of learning how to software develop...
Plugging my friend @weberswords who has great advice on the subject https://t.co/gLL6q8OJKb
— Valerie Roske (@enginerdlinger) July 18, 2020
Full disclosure for those who don't know me, I'm a self-taught developer with a past career as an educator. I still consider myself an educator. I hold a valid license and even have my administration endorsement so technically I could be an assistant principal.
I made my transition by reverse engineering a plan from job postings. I searched for "software developer" and then researched and learned a series of topics that seemed to make sense. I read and wrote code (often that was terrible by my standards today) and built random things. That's the TL;DR but in reality there was actually a lot of pedagogical planning that went into how I chose to learn what I learned and what activities I did in order to reinforce that learning.
I noticed some things along the way let's start with...
Computer science vs. software development
One of the things someone could do with a CS degree is become a software developer, but the skills needed to be a software developer and the things one learns as a CS major are practically two different skill sets. I say practically because there are definitely positions and companies that need folks to understand algorithms, data structures, and big O notation. I'll even agree that you'd probably be a better developer if you understand those things. However, it's not requisite for most software developers despite what coding tests and whiteboarding in interviews will tell you (assessment - that's another topic altogether).
That divergence shows in the types of tutorials and practice software devs have available. Places like Codeacademy and Treehouse teach the basics of a language as well as how to build a thing. Places like Code Kata, Code Wars, Edabit, and Hackerearth are obscure, abstract exercises that speak in Ns and Ts. Learning to decipher that is a skill in and of itself. There are abstract concepts that come up in software development especially in books that explain languages and in documentation, so it is important to have strategies for how to grapple with it.
How to get better at the abstract
What does this mean from an educational perspective? Going back to the original question, what would help someone get better at those abstract things?
For one, it's a firm foundation in the not-abstract things and a human being with experience to help guide you through. For example, let's talk about teaching a 7 year old multiplication/division...
If you give a 7 year old six packets of ketchup and ask her to divide them into 3 groups she'll likely be confused as to how to start. That's because the idea of a "group" is an abstract one. As adults, we've built a schema around this concept; it means 'things that are associated.' We denote groups by putting them in close proximity to one another with an understanding that the negative space between those things is the boundary separating each family of items. Sometimes we even put them in the same container like with our forks, knives, and spoons. To a child, the concept of "group" is relatively meaningless because it's an abstract concept (this is especially true for people with ADHD or executive functioning challenges). However, if you give a child 3 bowls and say, "Put the packets into 3 groups," it's now a task requiring far less cognitive load because there isn't any imagination required. Put the ketchup packets in the bowls. Over time the bowls can be removed because she can imagine the bowls. There's a concrete experience upon which to anchor that knowledge.
A dev example
An example of this would be the concept of N. The aforementioned Hackerearth practice problem mentions N. I remember first encountering N and, after going, "I'm sorry what?" reaching into my background knowledge grasping at whatever I could. The best I could come up with was x. I remembered in algebra solving for different letters a lot so I thought that might be what N meant. That was an incorrect assumption.
It took asking my roommate who was going to school for CS at the time to clear up wtf N was. His explanation was that N is some number we don't know.
Me:
That cleared up nothing. How's that different from x?! It was the next thing he did that actually helped me anchor the abstract concept to some background knowledge. We can pick a number to be a placeholder. When we would work through problems he would often suggest starting with a small number in place of N to test out my solution. Instead of N, let's just say 5.
Anchoring the abstract concept to not only my previous knowledge, but a concept with which I have automaticity reduces the cognitive load.
automaticity: the ability to process without occupying any or too much of the mind
cognitive load: the amount of effort required by the brain to process information
This is the same thing we did with the 7 year old by providing the scaffolding of using the bowls to divide the groups. By adding the bowls she wasn't trying to grapple with the idea of what groups are along with the task of sorting the items into groups.
Back to N...
The original statement:
The index of an array of size N can range from 0 to N-1.
Substituting 5 for N:
The index of an array of size 5 can range from 0 to 5-1.
Simplified:
The index of an array of size 5 can range from 0 to 4.
Put into my own words:
An array 5 units big can have an index range from 0 to 4.
Now the abstract becomes anchored to something more concrete and I have an example to draw on the next time I see N. The other part of this is that I had a person with more knowledge than me to help guide me through the process. While developers are stereotyped as people who are lone wolves lit only by the glow of their Retina display living in their mom's basement, that is probably the worst situation for learning and learning quickly. Teaching is the best way to reinforce your own learning and building a PLN (professional learning network) that you can go to for suggestions, advice, and help is essential in any career.
You do it.
How could you take other abstract concepts and anchor them in some more concrete background knowledge? Try this with something like the React Lifecycle (one of my favorites) or functional programming. What more concrete or common knowledge or metaphor can you anchor those abstract concepts to in order to help lower the cognitive load for the person learning it? I'd love to hear it in the comments or a tweet.
I'm thinking this will be the first in a series. I have a lot more I want to talk about and this is a lot longer than I thought it would be. I also want to talk about vocabulary as a barrier to understanding, the curse of knowledge, assessment, and the lack of resources for intermediate learners.
