Recently I’ve been looking at Stack Overflow a lot. It’s a website that focuses on answering questions related to programming. I’ve always bumped into this website without fully engaging it. As you encounter those small problems when you’re programming and the immediate explanation isn’t always obvious, the natural instinct for a 21st century being is “Google it!”
Chances are, you’re not the first person to have this problem so Stack Overflow very frequently pops up in your results. You skim the listed answers, find one that fits into your brain to help you grok it, implement the solution or workaround and move on. It’s always been a passive thing for me that I’m entirely grateful for.
But people need to write those answers! What better way to help out someone who is struggling with the puzzles in programming? The site doesn’t discriminate, with filters and categories for questions both big and small.
So where do they get their answers from? Experience is most likely, but so is copying another answer they got from someone else, or a copy-paste when they ran into the problem initially, or documentation, or a YouTube video or a Udemy course. One of those should stand out: documentation.
When a new product is released or a new public API is developed or a new protocol is established, documentation holds the keys to understanding. The internet, despite all of its shortcomings, houses one of the most important and remarkable things in modern society: freely accessible and open information. What better way to learn how a thing works than by reading the specifications written by the people that made it! (Aside from exploring the source code, but that requires a different headspace.)
For an engineer, answering a question isn’t just about the answer, it’s understanding how to arrive at that answer. Reading isn’t always easy or interesting and takes longer than a ready-to-eat solution, but it’s okay to reinvent the wheel when you want to learn how the wheel works.