Studying programming by writing glossaries

17 Feb 2019 🔖 tips
💬 EN

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:

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

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.

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

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.