Studying programming by writing glossaries

Katie - Feb 18 '19 - - Dev Community

While I can relate to the phrase, “I don’t know what any of those 30 words mean … it feels like too much to ask about all of them,” a study trick from grad school has greatly increased my ability to “fake it till I make it” in these situations!

I recently stumbled across the incredibly informative Julia Evans, so I searched for podcasts to see if I could learn more from her in a wrist-friendly way (yay, laundry; boo, programming).

Turns out she’s another “do something besides hurt your wrists” programmer, as I learned in episode 16, “Blogging is Shipping,” of Greater Than Code – it’s the origin story of her fabulous teaching cartoons!

But what really caught my attention in that episode was this conversation:

  • Jessica: “As a senior person, I might hear somebody say a sentence about joins in PostgreSQL, and I might hear one or two terms that I don’t know.”
  • Julia: “Right.”
  • Jessica: “And those I can ask about. It’s different when I hear eight terms I don’t know.”
  • Julia: “Exactly. Yeah, I think this is something that happens really often to junior people, is they’ll be like, ‘I don’t know what any of those thirty words mean,’ like, ‘it feels like too much to ask about all of them.’”

The number 30 really caught my attention, because I’ve been here before, and my approach to deal with it has helped me “impostor” my way into a lot of interesting career opportunities.

Too Much Vocab? Write Glossaries!

When I took “Programming 101” and “Operating Systems 101” in grad school, I found that the easiest way to “grok” the onslaught of confusing material was to pretend that I was in charge of writing a glossary for a textbook on each vocabulary word I found overwhelming.

When studying for my “OS 101” midterm, I realized I’d done this for an average 25 vocabulary words per class.

This approach arose while I was studying for “Programming 101” by reading the first chapter of our recommended textbook, Objects First with Java by David J. Barnes & Michael Kölling (PDF here). Here’s the “glossary” I wrote that first week of class:

Term Definition
Object One specific instance of a class
("My old car that is parked at home in my garage")
Created from class definitions (learn to write them well)
Naming: Lower case
Class A category.
All objects of a particular kind
("Car")
Naming: Capitalize 1st letter
Instance "Object."
Used to emphasize membership in a particular class
Method "Operation"
Defined in a class, used on an object
Objects can call other objects' methods
Invoke/Call What you do to a method, to communicate with an object
(which will usually do something)
Signature A method's header. Provides info about the method
Parameter An additional value a method might require
(Method) (Parameter) (Data) Type What kind of data can be passed to a parameter
Defined in a class (int, string… even "an object of ___ class")
(Method) (Parameter) (Data) Name A hint about the meaning of the data
(Method) Return Type What type of data a method returns
Defined in a class
("void" = nothing)
Field Where an object stores data
Defined in a class, inside an object
(Object) (Field) (Data) Type What kind of data can be stored in a field
Defined in a class
State All the (field) data values of an object together
Source code Defines what fields and methods a class has, and what happens when a method is invoked
Compilation Comes between saving source code & creating objects with it

By the way, “Objects First” is an excellent book – particularly its first few chapters – for learning about object-oriented programming. Its accompanying IDE, BlueJ, really helped reinforce the concepts.

I might have misunderstood the backstory, but I believe that BlueJ and Objects First were designed to be accessible to middle schoolers and high schoolers, kind of like Scratch was designed for kids, and in my opinion, it has the same “aha!” effect as Scratch.

(For proof that Scratch is great for adults, see Harvard’s CS 101 series – it totally starts off teaching 18-22-year-olds known for their ability to follow complex material with … Scratch. You’re never too old to learn from kids’ tools.)

My notes from OS 101 don’t format well in Markdown, so here’s a screenshot of a few vocabulary terms from week 1:

Vocabulary notes from Operating Systems 101 defining Design, Computer System, Embedded System, Operating System, and Kernel

Career Impact

I can relate to the “it feels like too much to ask about all of them” sentiment (which, for context, was said during the podcast as part of excellent advice to learn from people who barely know more than you so you’ll only have to deal with a few new words at a time).

On the other hand, when you do get slammed with 30 vocab words at once, if you have any chance of recording them all and studying them later, do it!!

I can’t tell you how much it’s helped me to be able to ask colleagues systems architecture questions.

Increased Collaboration

I don’t typically program for web sites (the top-nav on this blog took me a week and I still haven’t managed to install a tag cloud), but when I want to ask my colleagues on the web team how one of their projects might impact the data flowing into a database I write code against, it helps to know that REST and SOAP are ways of structuring information during an HTTP transmission of data over the internet.

My constant drive to research and memorize every set of “30 confusing terms” I encounter has been vital to my ability to translate between “business user” and “tech expert.”

For example, here’s an e-mail I wrote to a power-business-user demystifying the “API” they’d heard was being developed for their CMS+CRM:

Hi ___,

Here's technical architecture of this "API" thing, in case you're curious.

There are 3 important pieces of software making up your "XYZZY" system that are always running on a computer in the basement:

  1. "Database management system” software
    • This is what our report-writing software and our ETL software run queries against and what I keep calling "the back end"
    • This is what I occasionally send our DBA "SQL" scripts to run so as to directly modify the contents of the database
  2. "Web server" software
    • This is what says, "Who's there?!" when a web browser goes, "Knock knock!" for anything hosted at "xyzzysys.yourwebsite.com".- It can read from and write to software #1 (the database).- It acts as your administrative and customer-facing "front ends."
  3. Another piece of "web server" software (or perhaps the same one as #2 ... TBD) – NEW!
    • This is what will say, "Who’s there?!" when our new CMS software goes, "Knock knock!" for anything hosted at "xyzzynew.yourwebsite.com".- It can read from and write to software #1 (the database).- It will act as "the API for our web-developer team" so that they can build other web sites that incorporate data from the XYZZY database.

Now I know – yay.

I was able to write this translation because I was able to speak web / server tech well enough to ask the director of the web team what was going on, even though I couldn’t yet write a robust, secure API or manage a corporate website.

Actual Impostoring, Not The Syndrome

Scene from a movie called The Impostors

Non-web-programmers at work often overestimate my web skills because I so comfortably throw around web vocabulary when asking questions of our web team.

I’ve had two (non-web-team) managers presume I knew enough to work on our web team.

That’s not “impostor syndrome” … that’s just straight up 😲…🤣🤣🤣 (“Ummm, thanks but no! Top-nav. 20 lines of code. 40 hours.)

But it’s not hard to set the record straight, and, I promise you:

It’s fun to cannonball into the deep end of the pool.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .