I work with new programmers on occasion. People know I can code so they ask me for help with their projects. I'm happy to do it, but sometimes it's difficult for me to understand what the new coders want to accomplish. I don't mean the details, I'm talking about the most basic tasks the code needs to perform.
When I ask them to sketch the logic flow or write some pseudocode they... well... they are completely stymied and confused. In fact, they seem genuinely insulted. How dare I imply that they are so dumb and their projects so simple that it needs to be thought about or sketched out before they start typing.
I don't really know how to respond because I always sketch, pseudocode and flowchart anything more complex than the most basic of programs. But I'm a very visual thinker and I see the code-flow as blocks, objects and streams. I see those visual images in my mind. So putting those ideas onto paper seems natural to me.
And when I was learning to code, the professors often used graphics and pseudocode to explain concepts and communicate their intention. It was the way technique they used to outline the tasks and express their expectations.
These techniques made specifying functionality much easier (for me) and helped abstract the tasks to a level where I could concentrate on the underlying requirements before I began typing. Since all the teachers used them, and there were predefined shapes and symbols to represent universal tasks, I just assumed that this was a normal way of operating for coders
Okay, so this is way overdone... but it's a good example. |
But it's been years since I've met a coder that bothers to use these methods. When I try to explain a process using (to me) standard symbols, people totally freak out. They have never seen diagrams used and they think I'm making it up. I've tried to explain that it's a time-tested way of communication, part shorthand and part map.
Even if you can hold the entire program in your brain, charts and diagrams are a good way to explain the program to people who do not have direct brain-to-brain access to you mind. Although the new coders seem to appreciate the diagrams I draw to explain actions and concepts, not one single new coder has ever even tried to learn or use the techniques. So I've given up - maybe I'm just weird or too old or not very smart..
However, I've noticed that the new coders take a lot longer to get the hang of basic programming structures. They bang away at the keyboard, frantically changing words without (so it seems to me) understanding the basic tasks they are trying to describe with all that typing. Any new language completely confuses them. It's like they see no similarity between the languages because they concentrate on memorizing syntax rather than structure.
I've tried to explain that the flow-charts and pseudocode work for any language. You can code the same functionality shown in the pseudocode or diagram using C-Arduino, Java, Python, Basic or PHP. But that concept, that abstracted flow and process, is foreign to them.
I've admitted I'm not very smart and explained how diagrams help me keep the program organized. Maybe I should take the opposite approach and tell them only the really smart people know how to use pseudocode and diagrams, we just keep it hidden from mere mortals - make the process more appealing and less a sign of weakness.
Maybe it's because all the movies and TV-shows featuring coders always show the hackers typing furiously and magically knowing the structure of massive chunks of code. The media never shows people charting and diagramming, that's just boring. And they never show people learning to code, only the genius wizards. Well I'm not a genius or a wizard, so I still sketch programs on a regular basis.
Also, none of the tutorials on YouTube use sketching, pseudocode, flows or any other visual communication methods. All those really smart teachers just start typing without ever planning anything in advance. I'm skilled enough to follow them. But I still have to literally "draw myself a picture" before I start any complex coding task of my own design.
Don't get the wrong idea. My flowcharts are just a bunch of lines and squiggles - definitely not the standards defined in the plastic templates with all the shapes and line types. My pseudo-code is sparse and unreadable to most people. But it helps me get results quickly and helps me find errors in my logic more easily.
The drag-and-drop programming environments are super popular (MakeCode, AppInventor, Scratch to name a few) so the visual tradition is definitely still alive. The "Hello world" introductory projects are becoming increasingly spectacular. Amazing hardware and software libraries make basic tasks very easy to accomplish. Everyone loves that instant success and I love to see how many people are willing to start. But so many people drop out when they are required to conceptualize and create a program from scratch.
Yet somehow, the new coders I work with never make the connection between structure and words. They can all set up a simple loop and a couple of test conditions. But anything more complex and they bog down and drop out. It just seems too complicated and they can't keep it all straight in their head - but they won't sketch it out either. If they just keep typing and changing stuff the larger structure will magically start working just like it does in the movies. I laugh and cry at the same time.
So I'm just wondering if maybe teaching the old fashioned methods of flowcharting and pseudocode could still help new programmers succeed, stay interested and stay motivated. I don't have the answer. I only get a couple of hours per month with the group, maybe five minutes a month with any individual. I'm not a teacher or a mentor, but it still bothers me when I see people struggling and know their are tools that have been proven to help people in their situation.
Maybe if there were more examples of smart people using diagrams and pseudocode, some alternate coder heroes for me to point to, maybe I could guide new programmers towards the time-tested tool set that helped become a better programmer.
No comments:
Post a Comment