It’s Friday, and I have a little bit of time to put some thoughts on paper. These thoughts aren’t really all that organized, so forgive how disjointed and rough they are, but I wanted to put them down on paper anyway. Take them for what they are. Hopefully they at least resonate a bit.
Learning From Others
At the beginning of my engineering career, I had this very common experience:
I needed to look something up or find out how to do something, so I would turn to Google and type in my search query. Then, I would scan the search results and click on the first article available. Usually, the first article was either from Stack Overflow or from GeeksforGeeks. When I opened the GeeksforGeeks link, it usually took literally forever to load or just wouldn’t load at all. Eventually, I just stopped going to GeeksforGeeks (I have no idea if their site’s improved since). When I’d go to Stack Overflow, usually the question that was asked was kinda sorta like my problem, but not exactly. Usually, the answers below were also kinda sorta relevant but not exactly.
So, eventually, I’d try some other article out there from some other popular forum site or click-bait style website, written by some random person on the internet. Usually, their article was a mishmash of words and spaghetti code, thrown together in a few broken paragraphs. Finally, in frustration, I’d just go to the official documentation page of whatever software I was trying to learn how to use. What I found there was somehow even less understandable than the article I just came from. Sometimes, the documentation was just auto-generated and didn’t even contain meaningful explanations of what the software did or how it did it. At the end of this frustrating experience, I would finally just throw up my hands and try to just “sleep on it”, hoping that the answers I was looking for would come to me in the morning.
This was my experience of trying to learn something via the internet in software engineering. I thought that there were literally no helpful resources out there and no one capable of explaining things clearly. This led me to the false belief that fundamentally all software engineers were simply bad communicators. In reality, this wasn’t true. I was just a lazy researcher.
The more experienced I’ve gotten, the more I’ve started to find the types of sources out there that I wanted to find. Instead of just turning to the first article that pops up on Google, I’ve started to dig a little deeper in the search results. Instead of turning to the articles that are optimized to include the most keywords possible, I’ve started to search for personal blogs and articles written by people actually interested in real discussion. Some of these blogs that I’ve found are incredible, written by engineers who are thoughtful and great at what they do. And there are literally millions of these blogs out there. I could name so many of these blogs, but just to name a few, I’ve really been enjoying Ben Borgers and Tayler Town’s writing lately.
Turns out, the content and helpful instruction is out there, it’s just hard to find at first. When you’re first getting into a field, especially when you’re mostly self-taught like me, sometimes it’s hard to know where to look for discussion. But, as I’ve found out, the discussion is out there. The people are out there. It just takes time to find them.
Helping Others Learn
I’ve also realized that if the content truly isn’t out there or really can’t be found, it’s kinda my responsibility as someone in the field to write the content. Just because a helpful explanation isn’t out there, doesn’t mean I should give up and go into something else. It means actually I have the responsibility to fill in that gap. That’s really the essence and spirit of open source software. If something is broken or not as good as it should be, then I can be the one to make that contribution. This applies just as much to documentation and codified learning as it does to actual software.
I’m a big believer in the power of clear and concise explanation. I think that you don’t really understand something until you can explain it clearly and simply, in terms that a middle schooler could understand. I’m also a big believer in the need for conversation and discussion. I know from my own experience that most of the learning I’ve done happens when I’m talking through something with somebody else. A lot of this conversation gets lost in our reliance on the internet. Especially when we only find information from click-bait style articles and skim-able content, we miss a lot of the nuance and little details that we’d usually notice in conversations with real humans.
So, I think as a software engineer, I feel a kind of responsibility to foster discussion about the craft and about the technologies that I use on a daily basis. It’s one thing to understand how to write a program in JavaScript, but it’s another thing to understand why I wrote that program the way I did or why I chose JavaScript in the first place. Those types of details need to be talked through. I can’t really understand some of those more important things by just reading documentation. There needs to be surrounding conversation to cement these things in my head.
It’s something I think about a lot and something that I aspire to do more of.