I’m trying to unpack some of my own experience and dust off a few ideas that might be useful for my own students.
Someone recently sent me a link to a 99u article titled You Don’t Need To Learn To Code + Other Truths About the Future of Careers. There is a lot of angst about whether one should or should not learn to code. Actually this is part of a larger narrative about educators being clairvoyant enough to know what their students should require for the (unknown, perhaps unknowable) future. I see a lot of educators go, “They need to know how to do this… and this… and, of course, this too!”
Suddenly the list of things one needs to know is huge. Much too long in fact for the time allocated to any particular educational setting. While it probably is true that we need to know more things than we have in the past, it is possible to dive too shallow and too wide. This approach doesn’t seem to produce much except anxious and neurotic students.
According to 99u:
If becoming a programmer is appealing to you, great. But seeking employment based on any one “hard skill” is an outdated way of thinking.
Is coding a hard skill? I don’t think so. Infact what we might simplistically call “coding” is actually a whole range of skills.
- Problem solving: What do I need to do? How will I achieve it? What are the individual steps towards solving this problem (remember, computers will take you completely literally)? How will I explore possible solutions? How will I plan the program? Will I use flowcharts? Will I use a Nassi–Shneiderman diagram? Will I use pseudocode? How will I decide upon the best solution between a number of possibilities?
- Logic and Structuring: One of the best reasons to learn to program is not for the ability to be able to program, but rather for the ability to be able to think in a logical and structural manner. Whether you’re writing a set of instructions for a computer or a culinary recipe for a home chef, you need to work out the order in which things need to be performed in. In project management and in code, some things are dependent on other things, and getting the sequence right is vital!
- Writing code: Code is a language, as English is a language. What we refer to as ‘grammar’ could also be considered ‘syntax.’ Learning code syntax and language conventions is often the most gruelling aspect of learning a new language. There are special characters aplenty. There are semi-colons, dollar signs, parentheses, brackets — all kinds of things, really. Though consider why we use punctuation in written communications. We offer all kinds of clues on how to read the text we provide, and it is much the same for a coding language. We write to be understood by readers; we write code to be understood by computers.
- Debugging and testing: Does it work? If not, why? Did we leave out one of those meaningful special characters? Did we make a typo? Which line does it first break on? Was something about our solution more fundamentally flawed? Is the computer giving us the result we asked for, rather than what we thought we asked for? How are we going to fix it?
- Refactoring: We generally think of refactoring at the code level — making the code more efficient — but it can work at a solution level too (perhaps our first solution wasn’t as eloquent as it could be, perhaps we know things now that we didn’t before). How can we make our code more usable — indeed more reusable?
- Communication: I put this skill last, but in truth it is imbued in all of the other skills too. We need to communicate our ideas. We need to articulate them. We need to share them with our co-workers, our supervisors, our teachers. We need to be open to feedback. We need to be able to justify our solutions.