loading...
The DEV Team

What is an analogy or visualization of a coding concept that really helped you understand it better?

graciegregory profile image Gracie Gregory (she/her) ・1 min read

The format of DEV's first official podcast, DevDiscuss, begins with an interview and ends with commentary from the community.

With the season two premiere coming out soon, we want to know...

What is an analogy or visualization of a coding concept that really helped you understand it better?

Answers can range from beginning to advanced concepts!

If you'd like a chance to be featured in an episode, please send us a voice memo on this topic OR leave a comment below by Wednesday, August 12 at 5 PM PT (8 PM ET, 12 AM UTC).

Details on how to participate

  • Call our Google Voice at +1 (929)500-1513 and leave a message 📞
    Send a voice memo to pod@dev.to 🎙

  • If you don't want your voice recorded, just leave a comment here and we'll read your response aloud for you 🗣


✨Subscribe to DevDiscuss✨

Don't miss this recent episode from season one of DevDiscuss:

>>Get a pack of FREE laptop stickers when you review DevDiscuss on Apple Podcasts!

Posted on by:

graciegregory profile

Gracie Gregory (she/her)

@graciegregory

Content Manager @ DEV. "You know what this sentence needs? An Em dash!" - Me to me

The DEV Team

The team behind this very platform. 😄

Discussion

markdown guide
 

Some time ago someone explain concurrency using a cooking analogy. Instead of repeating what I was told, I'm going to leave this wonderful article right here.

 
 

Was learning C recently, and confused about the concept of pointers and what their point (forgive the pun) even was. Someone described it as giving someone a copy of your house instead of giving them just your address. Really helped.

 

Hey @kewbish ! This is awesome! Would you be interested in sending us a voice recording of this so we can feature you on the related episode of DevDiscuss coming up soon?

 

Ah, definitely. I'll go try to figure out Google Voice now 🤔

Yay! Thank you so much. DM me if you need any assistance!

 

Seeing Regular Expressions drawn into their finite state machine graphs (just circles with arrows between them).

That it's just moving from one state to another based on matching a character. And all regex could boil down to a language of four things:

  1. c match any literal character (like c)
  2. | or operation (match this or that)
  3. * loop
  4. () group

The rest of it mostly being helpful sugar.

 

Do you have link of that?

 

Here's a graph generator; if you want to visualize what I'm talking about: regexper.com/#a(b%7Cc)*d

The explanation of the concepts came from a university course though... maybe I should do an article about this so I can link it as an explanation of what I'm talking about...

 

One analogy that applies in more than one ways - Plumbing

  1. Input - process - Output
  2. Fork - Join
  3. Modular applications - Many plumbing components coming together
  4. Performance bottlenecks - Something stuck in the pipe. The same ideas apply in debugging and fixing them.
  5. Monitoring and Instrumentation - Water meter
  6. Queuing - FIFO, back pressure, throttling
  7. Load balancing

I think we can go on and on.

 

We are just plumbers, the fluid is json.

 

Hi @mhshankar84 ! Any chance you might want to submit a voice recording of this analogy so we can feature your voice on the DevDiscuss podcast soon?

 

Hi Gracie, sorry, just now saw your reply.

Do you still have time for the podcast?

 

I shared this one awhile ago on a different post because it helped me when I was learning how to use map, reduce and filter.

map-filter-reduce

 

First things first, Julia Evans is IMO great at this. jvns.ca is her website. She writes "zines" with illustrated technical concepts, and they're great.

Anyway, the most helpful analogy I encountered as I was learning was to think of an interface like a light switch.

  • Hides complexity from the user
  • Exposes methods to the user (e.g. lightswitch.turn_on()
  • Is extensible
  • Is intuitive

Credit: I first came across this description in Data Structures and Algorithms in Python by Goodrich, Tamassia, and Goldwasser

 

I saw this tweet recently and thought it was a good clear visual explanations of JavaScript array methods

 

The Fiscer-Yates shuffle explained beautifully by none other than the creator of D3, Mike Bostock. It's an old article but I still remember the first time reading this and my jaw dropped; simple but effective!

 

More general, in my first degree program (SysAdmin focused, not dev), from the worst professor I've ever had except this one thing:

"This stuff is going to come at you and not make sense, you're not going to understand how it fits, and then one day it's going to dawn on you and all come together. It will be a gradual process, but the 'aha!' moment won't feel like it."

IT-wise, that was crap, because the program was a cakewalk (I just got the degree to prove that I knew what I already knew - I was valedictorian, and my cords are more meaningful to me tying up my GF with them than any sense of accomplishment I felt wearing them on the walk up to accept my degree from a school president I didn't respect), and I was basically giving up on an IT career and moving laterally into dev (formally, I'd already freelanced for years) by the time I graduated...

But I was ramping up my backend development at the time, and things did finally click for me: Frontend and Linux SysAdmin I already knew (not taught at school), backend, database, what there was of DevOps at the time, all of it suddenly began to make sense in the macro and micro.

 
 

The box model is an awesome analogy, a long time ago when i was learning css, thinking in a div (and other elements) like a box really helped me : )

 

A really great analogy i use to differentiate between when and when not to use parallelStreams in Java.

For example if i am searching for my car keys in a room full of 100 people and i know for sure that my car key is under one of the chairs , and 100 people are sitting in the room(1 person/chair):

Lets assume for each person to look under their table it needs 1 second.And suppose i find my key in the 10th chair.

So i have two options:

1) i tell each person one by one to look under the table.

So it will take 10 seconds and 10 people to find my key

Thus time=10seconds

Resources used-10 men

2)i tell all of them to simultaneously look for the car key

so it will take 1 second to search the key

but 100 men

Thus, time=1second
Resource-100 men

Thus this is the very same case with streams vs parallelStreams.

We should always remember that parallelStreams may give better results but also comsumes huge resources.

Hope this analogy will help others!

 

One thing that really helped me understand optional unwrapping in iOS was the box analogy, particularly by using Schrödinger's cat. At runtime, you don't know what value an optional property will hold, whether it's nil or contains a value, until you actually call it. And you can either do it safely, by nil-checking it first, or implicitly unwrapping it and hoping it doesn't blow up in your face.

 

I remember coming across a tool like this grid.layoutit.com/ for CSS Grid.

I understood the grid a little before it, now a little more ;)

 
 

The visualizations from RxMarbles are always helpful to checkout new operators.

 

...my university professor, about recursion: "you don't have to think about it too much, if it feels it's going to work, it probably will" :)