I entered the tech industry through SQL. When I came to work as a business analyst, I was handed the credentials to an Oracle database, pointers to some tables, and let loose.
Because SQL is declarative, it’s probably the least intimidating programming language to start with, and it remains one of my favorite technologies because what you see is mostly what you get.
But coming from the world of consulting where all I knew were spreadsheets and manipulating tabs upon tabs of pivot tables, I had no clue what was going on. Indexes, b-trees, blobs, transactions and other terms flew buy my head.
“Think of a table as a file cabinet, and indexes as drawers labeled A-C, D-F, and so on,” my manager at the time said, and I was introduced to IT terminology by analogy.
I’m now at a point in my career where, at the same time as I’m learning, I’ve also begun to help more junior people. I’ve taught countless people about indexes with the file cabinet analogy. I’ve taught git by comparing it to a very strict version of shareable Google docs, and I’ve started architecture diagrams on Hadoop with, “Imagine your data is water flowing through a pipe.”
I’ve always sworn by analogy, because there really is no way for a non-technical person to understand any of the abstract, jargon-laden documentation out there based on anything other than comparisons to the real world. Just look at the introduction to Python 3.5 documentation.
Python is an easy to learn, powerful programming language. It has efficient high-level data structures and a simple but effective approach to object-oriented programming. Python’s elegant syntax **and **dynamic typing, together with its interpreted nature, make it an ideal language for scripting and rapid application development in many areas on most platforms.
This introduction makes perfect sense if you already know software. But when you’re just starting out, it seems like the whole tech universe is layers of unintelligible jargon.
For example, recently I was helping someone (who is just starting out in computer science at the undergraduate level) to understand how Wordpress works.
“That’s easy,” you say. “Just explain that it uses MySQL in the back-end, PHP in the server-side layer, Apache to serve requests and responses between these two and the front-end.” The LAMP stack at this point is a canonical, almost boring, pattern.
But when you are just starting out, you have no idea really what sever and client side even mean. I began by explaining that the server is just another computer, and to imagine accessing documents on your desktop versus someone else’s desktop. I then asked the student to think of the command line as having the ability to open up the hood of the car to work directly with the engine instead of going to a mechanic every time something breaks.
It started out well, but soon we got into DNS, php hooks, Wordpress themes, PHP, high-level languages, git, and all sorts of things that depend on a deeper understanding of a possible computing environment as a whole.
There are people who are against using analogy for this very reason: that it’s impossible to explain what a database index is without understanding that an index is a data structure that can be traversed more easily than a table, which is another type of data structure, which are both objects in programming that are written on disk, which is a type of memory in a computer…and it’s turtles all the way down.
And the more I explained, the more I could relate to my mentors, who, when I asked them in frustration, “Why can’t you just explain an index to me simply,” could not. There is a LOT of context in tech. A whole lot.
I was thinking about the best way to teach complicated technical concepts when I was watching The Big Short. I read the original book last year, and, even though my undergraduate major was economics, and Michael Lewis is a great writer, I found myself rereading many sections to understand the complex underpinnings of financial instruments and wading through many layers of complicated terminology.
“Why can’t he just explain this through very simple analogy,” I found myself wondering. Something this complicated deserves justice. And in the movie, they did just that. Not only did they have a supermodel in a bathtub explaining collateralized debt obligations, but Ryan Gosling essentially used Jenga tiles to explain the tranches of CDCs and how the bond ratings agencies grouped the worst ones together.
I couldn’t decide whether this was brilliant or insulting. In theory, it was a great move to make something intangible and insanely hard to wrap the average moviegoer’s head around, real. But somehow, I felt vaguely insulted. Like the movie thought I wouldn’t care to pay enough attention to a movie about something that’s impacted the entire country and the global financial industry unless it was explained by Selena Gomez in an evening gown at a roulette table.
I began to see the other point of the argument: teaching by analogy oversimplifies and assumes the other person is incapable of reaching up and doing some reading about core concepts.
But where is the happy medium, then? Where is the balancing point between getting into Big O notation and simply using the file cabinet analogy? This will be an important question to answer as we try to get more and more people involved in the tech industry, people who were previously on the fringes, people who are completely intimidated and overwhelmed by this gargantuan infrastructure? Or, maybe, people who buy this infrastructure and need to understand it to explain it to their managers. Or people in the news who report on technology.
I still don’t have an answer, but I think, for people just starting out, maybe even Selena Gomez is better than nothing, because it at least gives you some abstract idea of what’s going on so you can use that as the base of your thinking as you learn more.
It’s been the challenge of my career so far to ask for that happy medium from the people who were mentoring me, and, now, to offer it to people just starting out.