One of the first assignments we were given during coding boot camp was to write out the instructions for making a PB&J sandwich. No code, just the steps.
"But WHY?," I asked (always the trouble-maker).
Because it would help us understand how fastidious computers were when it came to incomplete or ambiguous instructions, the reply went. And it was good practice to break a task most of us assumed to be exceedingly simple into its component parts.
At the time, I figured that meant I could ignore pseudo-coding if in my mind I already had a clear picture of what I wanted to build, and how.
I was wrong.
Also, hubris is a terrible, terrible drug.
Here's what I'd learned about the importance of pseudo-coding in the three short months of building progressively more complicated apps:
It helps you understand what it is you're actually trying to accomplish. Before writing a single line of code, you should have the equivalent of a movie's tagline for your app.
Breaking it down into its component parts is just the first step. The end goal should be to simplify, simplify, simplify. Can you bundle the logic for some steps into a single function? Can you further break down others, so you don't slip into the nesting hell of if statements conditional on other if statements conditional on other ifs? Can you arrange your logic in such a way that, should a step become redundant later on, it can be easily removed? Pseudo-coding is where you figure those things out. (Something, something, global variables suck.)
Clean code is fast code. It's also easier to maintain. If you don't focus on it in pseudo-coding, sooner or later you'll be refactoring your code instead (cleaning it up once it's written). Pseudo-code the heck out of that bad boy, and you'll be thanking yourself later.
Other people will thank you, too. Clean code is easier to read, and easier to build upon. Plus, keeping some of your pseudo-code as comments is a neat way of explaining your thought process to anyone who might want to use/improve your code (and to yourself later on, once you've forgotten why you decided to do something a certain way that now seems to make little sense--and that's okay, you've probably learned a lot since).
With good pseudo-code, you're 75% there to good documentation. Good documentation is king. It's how others decide how useful your app might be, and how to implement it for their needs. Get that right, and your stuff will be far more likely to get cloned. Which is how you become GitHub-popular. (Which is the best kind of popular, obviously. Now go write that darn README.)
Top comments (1)
Good stuff! I think that pseudocode is too often underrated.