Coding == Programming?
Translating terms to tame technical tomfoolery
Have you even seen a great white shark about to attack? Broaches the surface… Eyes rolled way back into their heads? Mouth agape? Strange sense of impending doom in the air?
Yup. As a developer you’ve seen this look.
It happens every time you try to badly explain what “development” or “coding” or “programming” means, or how one thing is connected to another in programming land.
You probably end up getting lost in some rabbit hole and then some argument with another dev pops up about “technical correctness” or some dogmatic standpoint arrived to after years of miring in a tar pit somewhere.
The problem is, it’s entirely our fault. Techies I mean. We are the source of and ironically solution to all of our problems.
The next time you watch Shark Week, just imagine the shark is being told what a toolchain is for hotloading front-ends in a dev context. Then note the glassy eyes.
It all starts with a question
A tech-curious friend of mine recently asked me about how TECHIE_TERM_A was related to TECHIE_TERM_B.
And hoo boy, every one of those type of questions is loaded (and then overloaded). We’ll end up going up, up, down, down, left, right, left, right, B, Eh, select?, start!
The reason we techies seem to fail at explaining things are a few fold (note: I’m painting with a really broad brush here, this may not apply to all techies you encounter):
- Most techies don’t want to ruffle your feathers. We talk to machines in machine languages all day (and for some of us, by choice, all night too). There’s something in development called a “context switch”, it’s when something stops doing what it was, stores the current arrangement of things, and then does something else until finally returning. When developers try to communicate with other humans, we have to context switch. If we’re deep into something, sometimes we forget (because it’s expensive to context switch) and we can come off as robotic or blunt. “BAD COMMAND OR FILE NAME”. Forgive us, we are imperfect squishy things trying to do work that requires a level of perfection, exacting precision, and absolute rigorous correctness (often under duress) that as humans we’re not actually built for. We’re fuzzy logic things trying to do machine things for machines. It’s a head trip.
- Techies don’t remember how hard it was to learn to wherever point they are at now. We all arrive from different paths. Some from self-guided experimentation, college, university, online learning, ancient tomes. We have one thing in common, we’ve tried and failed at many many many things. We forget that failure is a very effective teacher. So much so that when something “just works”, we really don’t trust it and ask “what did I screw up silently this time?”
- Most techies learn from other techies, and have to ride the line between “the dev is keen on learning!” and “this dev doesn’t know squat!”. It’s pretty common for us to walk away from a conversation and then google a whole laundry list of things we didn’t understand or newly found out about.
- Most techies really do want non-techies to understand what we do. We love what we do. We think it’s awesome, and we want you to think it’s awesome too. (I personally want every single human to be friends with the machines and be able to play try-catch.)
- Most techies have a hard time boiling it down to make sense for humans because there’s so many really delicate and intricate things to know and it’s constantly shifting like walking on a sandy beach. Sometimes waves come and wash away everything you thought you knew. And now you’re at square one again.
- Most techies suffer from some degree of impostor syndrome, because deep down we know that when the power goes out, there’s only so much we can do (cultivate your human skills techies! It’ll take 10 years to replace all the transformers if a CME hits us the right way).
Remember your roots. Learn how to start a fire with flint and steel. Learn to write a program in assembler. You must nurture the digital and the analog. One can’t exist without the other.
But why!? Explain it in user_pref.language!
Because it’s honestly magic, and we techies understand just enough to get by and build you all magical things that don’t fall down. But the corollary is, it’s baud rammed magic, and we barely understand it all end-to-end anymore. We always are afraid of the edge case we could have missed. That hard drive that could fail. The machine that runs our code that we’ve never actually touched in person.
We have a term called a Heisenbug, no I’m not lying, its a real/not-real thing.
We have rubber-duck-debugging, because why wouldn’t you talk out loud to yourself about the code you yourself just wrote so that you can critique it find mistakes berate yourself agree with yourself thank yourself for the input and then continue fixing bugs.
Because that is the model of a normal human operation right?
Weasel.headTilt(“?”);
I think we’re all coming at this the wrong way. Everyone is either in a Dunning-Krueger or an Impostor-Syndrome, so I want to strip it way back.
Let’s learn what the words mean together. I’m going to assume you know as much as me, which is to say:
“You know you a lot about a lot, and you know that sums to a goose toque above nothing compared to what there is left to learn out there.”
So let’s get started:
I’m going to focus on the common word “Coding”. We all know someone who codes. Let me help you understand what that might mean.
When you Code, you’re also Programming, and Developing. Because they’re the same thing. Just different eras. “Tubular man!” vs. “Dat sik bruh!” vs. “100”
Why so many words? Because variety is the spice of life. Also, to sound cool.
When you Code, you’re writing Code. Code is written in a Language.
Now things are going to get dicey.
I know, you’re thinking: But I use language every day, I might even be bilingual or trilingual! It’s not hard.
True.
But at the base of it, all human spoken language is built on top of noises we can make. So the root of it all the same, at least if you aren’t human.
Languages as far as programming goes, are the written spells and incantations that make machines do machine magic. But let’s stop for a sec.
Put on your machine-hat.
Machines have a language too, one that they talk to themselves with. Like your own inner voice that tells you to do things like “dont hit the snooze button”, “you should eat vegetables”, “jumping out of this plane is a good idea”.
Machines, at their very heart (the CPU, Central Processing Unit, the thing that instructs things to do things on a machine), speak in “machine code”. Which really is bunches of 1s and 0s in chunks that mean things. These 1s and 0s actually represent the amount of electricity flowing through certain parts (the “logic gates”, like AND, OR, NOT, NAND, and more!). But this gets into “digital systems and circuits” and one of my friends in electrical or computer engineering would probably give you a better answer.
For background I studied Software Engineering at the University of Waterloo. When I enrolled, the program wasn’t even accredited yet. We were split between the faculties of Math and Engineering. We wore yellow hard hats and pink ties. We’re the weird middle children of the technical world. But that means our role is as an integrator and bridge between the worlds. We are generalists, who know when to seek the advice of more capable wizards.
It’s pretty much like a plinko machine of marbles, just moving at near the speed of light, plugged into your A/C socket.
In the early days of becoming friends with machines (just like we did with canines), humans would speak to machines in a language as close to theirs as we could manage. Punch cards, “assembly”. These were the basic instructions the CPU knew how to respond to (SIT, STAY, BARK!), or in this case (LDA, JMP, CMP).
With these basic instructions (and the machine having memory and storage it could lean on to remember and recall things). We were off to the races.
But imagine every time you wanted to talk to your friend, you needed two hours of labor intensive seriously mentally taxing work to get them to say hello… you’d find a better way.
This is basically where all coding/programming/anything-tech languages (and a lot of tools) are born. Out of a need to let the human be lazier and just get to the good stuff.
That sounds strange right? I’m typing this at 2am (editing the next day at 11pm) and I’m telling you developers are lazy?
Yes. The LAZIEST. But that’s actually just our human DNA’s survival program expressing itself in a mental context.
To survive the human is the most efficient at using or storing resources as the environment demands. We adapt to suit it. Eat too much today? No problem, let me store that for you. No food today? No problem, let me convert some storage to fuel! (Note: some of these root programs can go awry in modern life, we rarely have to worry about tigers eating us, but that causes us to react to paper tigers in the same way)
Developers do the same thing. I don’t want to repeat myself when I code. DRY is a thing we do. Because it’s easier to handle mentally. Every new language you see is just trying to solve the problems of an older one. Type less. Do more. Easier to test. Easier to maintain and change. Human comforts.
So we have Binary 1s and 0s, Assembly which is only a small step away, now it’s time to make this more accessible to humans.
But wait. It’s nearly 2020.
Most of this stuff really started taking off in the 70s. That’s like 50 years of progress. It’s really intimidating to come at something with that much behind it. Sometimes it’s a bit like someone saying “I want to try out some surgery! I have this cool idea for a bionic arm!” then a surgeon looking them over with a quizzical look.
But we should never dismiss optimism and keen interest in nurturing a new developer, coder, programmer, or techie. The truth of the matter is, we need you. We need everyone. And we need everyone to build good, stable, solid code.
The days of doing it alone are gone. There’s almost no system out there you can truly say has no one else involved. It’s all built on the shoulders of giants. And some lone humans too, who are giants themselves. Without them, I am nothing.
So here’s how I’m going to start:
I’m picking n = 10, and since I think in Zero-Indexed that means you’re getting 11. Yes. Even the way we have to thinking about basic counting is different. Also the meaning of undefined, null, NULL, Nil, None, “”, … and on. Don’t even get me started on what a string means.
All of these bits below are just tiny snapshots to get you started. And when you don’t understand something, do what I do. Wikipedia for the basics and language, Google-fu to find what the chatter is, Stack Overflow to see what people have tried. It will take bravery and time, but I promise you can do it.
Procedural vs. Object Oriented
This comparison is about how a program is structured and how it behaves. You can think of procedural like having a list of instructions on how to get to a cabin up north, whereas an Object-Oriented approach would be more like having a navigator with you that knew the directions and you could ask them where to go next.
Client-Side vs. Server-Side
This one is about where the action is taking place. Client-side means with you, in front of you. On your device, on your browser, on your computer. The thing you are touching is doing the legwork. Server-side is more like the mainframes of old. You only ask it things, it does the heavy lifting and lets you know the answer.
Cloud vs. On-premise
When you hear cloud, remember that it’s all just machines. Clouds are like a crowd of machines all working together to do something. They can help each other out or work independently. But ultimately they’re the machines that someone else owns and operates. Like an apartment building. Just with really good infrastructure and talented folks making it hum. On premise just means physically in a building you can access yourself. There’s an actual computer (or group of computers) doing something. A human you might bump into at the coffee machine might even have seen it.
Interpreted vs. Compiled
This comparison is about how code is digested and used by machines. Some languages are ready to consume just as they are, and the machine can just read them line by line (interpret them) and do things with them. Like grapes and cheese curds, you don’t need much more than that to get started. Compiled is more like making a hearty stew. You wouldn’t want to eat the raw meat or the tough veggies followed by a shot glass of spices. Some languages need a bit of cooking to be palatable to machines. Some say compiled languages are faster, which can be true of stews as well — you might be able to extract more nutrients from cooked food. This isn’t a hard and fast rule, but nothing in developer land is.
Syntax vs. Semantics
How you say something vs. what that something means. Syntax is like grammar and punctuation and word selection and verb tenses. Semantics are the meanings of things. Just remember, just because the syntax is correct, doesn’t mean the semantics are. “Bark, wire eloquent. Ride dromedary quit left constabulary!” syntax is fine, but it’s doesn’t mean anything. Except maybe sleep, who knows.
Presentation vs. Logic
How a think looks vs. how a thing is wired. If you were to look at a cat for example. The presentation layer has a bunch of different styles applied and visual components. Like the calico style or the black-cat theme. I like the orange-tabby-runt variant. The logic layer on a cat is things like “when detect(‘scurry’) => attack!”, “when detect(‘food can opened’) => kitty_panic!, rush_to_kitchen!”
Strict/Strong Typing vs. Loose
Generally not the right words to use here, but common enough you hear them used to refer to the following. The actual things to think about are static typed and dynamic typed. This refers to when the machine knows what kind of things it has to play with. It can also represent how pedantic the language is. But this part gets fuzzy, and very technical. To boil it down. If we were statically typed people, and I said I was going to give you a vegetable, and I was thinking about giving you a tomato… you’d reject it hard before I even started get it from garden, because a tomato is a fruit, and you were expecting a vegetable. You will not accept what you haven’t been told to expect. If we were dynamically typed, you’d only reject it once it was in your hands, and only if you really couldn’t stomach it. But you might just use the tomato in ways you shouldn’t.
Frontend vs. Backend
This is often mixed up with client-side and server-side. Frontend refers to the parts of the thing you can touch and interact with. The things you see, knobs, dials, screens. Backend refers to the guts of a thing, the pipes, the insulation, the memory and recall. Most applications have a front+back end, and live in environments either entirely client-side, server-side, or a mix of both.
Java vs. JavaScript
Java is to JavaScript what Frank is to Frankenstein. One probably works in an office, the other in a lab (or cemetery, whatever floats your canoes). Only similarly named due to a marketing decision. We won’t argue if it makes sense. Because it doesn’t. Java is usually what makes sprawling enterprise applications do their thing. It’s coca-cola vs. pepsi opposite is probably C# (arguments can be make for C++ too, but don’t get sucked into these kind of debates with techies. It’s like asking a Star Wars fan about jar jar binks. Or debating the intricacies of canon in the marvel comic universe. Passionate people are a little nutty at times.). JavaScript is basically the lingua franca of web site interactivity. It’s a language that has low barriers to entry, hence it’s wide adoption. But it also let’s you get away with a lot, which can lead to developing bad habits. But like a kitchen knife, it’s how you use it.
Web Service vs. API
Very similar, just a specialization of the other. A web service is just an API with a wrapper that lets it work on the web. Web services usually have an agreed upon industry standard convention (REST, SOAP, XML-RPC) so you know what to expect and how to talk with it (idioms, slang, etc). All web services are APIs, not all APIs are web services. APIs can communicate in basically anyway you want, web services have more defined roles.
XML vs. HTML
The ML in this case stands for “Markup Language”. When you use a highlighter on a paper to find the important bits, you’re marking it up with the “Highlighter Paper Markup Language”. Now anyone who looks at that page knows where the important bits are. That’s what HTML is, a bunch of text highlighted with different colors to signify different things. Things like where to put the title of a page or where the list of things are. The HT is Hyper Text. Which really refers to the ground-breaking idea of having a “link” on a document that took you somewhere else. The web used to just be grey pages with blue, red, and purple links. What if you wanted to mark something up, but didn’t want to have it be a web page? You do that with XML. All the benefits, without any of the preconceptions. HTML has a bunch of things that let it be understood as a web page (devs call these things tags/elements — which are different from #tags… why we love using the same word to mean different things is a mystery), XML just lets you markup any text with a syntax that allows you to extract the semantics of it.
Where the heck do I go from here?
No joke, wikipedia and youtube:
3 years of computer science in 8 minutes:
https://www.youtube.com/watch?v=ReVeUvwTGdU
https://en.wikipedia.org/wiki/Programming_paradigm
https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languages
Trust me when I say, there is a huge iceberg under those links. But you might like it.
You’ll only know if you try { it } catch(error) { and keep going! }
Until then, Weasel.out()
