Do People Still Flowchart Their Code

Just wondering if anyone still flowcharts their code? Does anyone write pseudocode anymore? Does anyone sketch and take notes about their ideas before diving into writing the actual code? Do schools still teach these skills and this way of thinking.

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.

I work with hobbyists, not computer science or tech students. These folks are just normal people that want to make LEDs light up or control a motor. We hang out for an hour or so every few weeks. So maybe my perception is skewed and, in the science or trade schools, they still use decision charts and diagrams and such

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.

Also find me on:
FACEBOOK -or- INSTRUCTABLES -or- YOUTUBE

Follow @tangoofthegeeks

PauseWaitDelay - Coding in Visual SpaChinglish

I just confused a group of new programmers. I tried to introduce them to Microsoft's MakeCode. It's a cool new online visual programming environment that is both simple to use and powerful. The program's creators went to a lot of trouble to make it fun and easy to learn.

I, however, managed to make it seem complicated and confusing - "My work here is done."

To be fair, it was an impromptu session so I had not prepared or practiced in any way. I just pointed them to the site, not intending to teach anything, much less hold an hour long spontaneous lesson. But they all seemed really interested, so I jumped right in. Who needs to plan or prepare - just start talking, right?

At left is the MakeCode IDE using "Pause." The center shows the Arduino IDE using "Delay." And at right is the Scratch environment using "Wait." The commands all accomplish basically the same thing, they just use different wording. I'm not at all confused, are you confused?

It wasn't that bad really, I don't think I scared them away. But I noticed the occasional blank look and realized I was using the wrong term sometimes. And I did get surprised by the odd (to me) ways that Microsoft tweaks the Arduino programming environment.

Or maybe the  new kids were simply overwhelmed and didn't actually notice my gaffs - but I did.

See, I use all kinds of programming environments, so switching between them feels natural. Sure, I forget which environment I'm in sometimes. But to me it's like using a new TV remote control or driving an unfamiliar car. It takes me a while to make the change mentally and I'll reach for the shifter in the wrong location, or hit power button instead of source.

Or maybe it's like when I try to use my high school Spanish and I get stuck so I blurt out an English word because I can't conjugate well. Or when my friend's grandmother has to use English because her grandson doesn't understand her in Chinese. Living in a multilingual culture is awesome, if somewhat frustrating at times.

So it's no big deal, but I feel bad for any confusion I caused. The new coders probably expected a precise and concise lesson. That's what programming is about, right - precision? Instead, I gave them a scrambled introduction to multiple variants of IDEs. In fact, I kept calling it MakeBlock instead of MakeCode - I can't even keep the vendor names straight.

Another example: The Arduino IDE uses "Delay" to specify how long the program should wait before executing the next command. But MakeCode uses the word "Pause" while Scratch uses "Wait." They all do the same basic thing. But me using the words interchangeably probably didn't make things easier for new programmers. A month from now they will think it's funny. But it was bad for a first experience.

(At least I didn't talk about whether time is measured in seconds or milliseconds, or the difference between wait, timer, rest and beat...)

Like every IDE that attempts to simplify a complex task, the MakeCode environment has some quirks. It creates variables of a certain type without labeling their type, then allows the variables to get plugged into slots where they don't belong. My example is the RGB values being considered "strings" in certain commands, but "integers" in other places (or maybe the other command casts the strings to integers).

No big deal to me, I'm used to dealing with var types so the error code at least made sense to me. I figured out a way around it. I'm comfortable troubleshooting conflicts, that's part of coding. But me fumbling around surely made the process look more difficult than it really is. That's my fault because I made assumptions that weren't true. Every environment is different and I was poorly prepared.






Oh who am I kidding, I can't keep all the quirks straight for one environment, much less five. I fumble around until I remember how this IDE works, or I just find a way around the so called issue. And that's part of the appeal of a drag-n-drop system like MakeCode or Scratch. You can wander around and explore options quickly without all the tedious overhead of setup. So maybe it was a good lesson and showed the new kids how to just keep playing until you have figured it out.

We'll see if any of those fledgling coders come back. They seemed excited and entertained, and they promised to practice at home (MakeCode is web based, so they can carry the code anywhere). One even said they were going to buy a Circuit Playground from Adafruit to practice on. So maybe I didn't make it seem too boring or complicated after all.

They might never ask me for help again, but I sure hope we have some new programmers beginning their journey. And MakeCode is a pretty good way to start.

Also find me on:
FACEBOOK -or- INSTRUCTABLES -or- YOUTUBE

Follow @tangoofthegeeks