This is an old post, but it popped up in my feed last week. In it, the blogger describes how he went to a hackathon with a friend, a person he described as a programming god, and just felt totally inadequate. He watched his friend and realized that his friend didn’t know everything either, that the friend just Googled the problems he ran into and then figured it out. The next hackathon he went to, he was the programming god, because he followed his friend’s lead.
Both of these people are CS majors in college. Going from CS major to work at Google (or any programming-oriented job) is a big leap. You know the foundations, but you do not know exactly how web security works. When I first started learning to program, I did a combination of things. I used other people’s code and modified it to do what I wanted. In order to do that, I had to understand the code. I went through books, step by step. And finally, I took some online classes. I do wish, sometimes, I’d had some direct instruction from a real person in that process, but the reality is, the landscape of computing changes so rapidly that keeping up requires a chunk of just figuring stuff out on your own. Often, you have a specific problem to solve in front of you, and you need answers. You can’t wait until the 6-week mark of a course where they cover that topic to get the answer.
I know some faculty hate when students Google the answers to the problems they’re given. Code for most basic CS exercises can be found anywhere on the web. And some of those basic CS exercises are necessary foundations, but the solution to a lot of “cheating” is to have harder problems. Have students design their own problems. Partner with people in the school to solve real problems.
I have students who are planning to attend a hackathon in a couple of weeks. I shared this article with them, and I also explained that what we’re doing in class is not what people in the “real world” do. There are frameworks and tools that real developers use that we don’t, because just those tools themselves are hard to understand much less the coding. And I want to focus on coding. And, more importantly, I want to focus on learning. I want to end with a section from the last paragraph of the post, where describes the hard work learning takes, and the understanding that there’s much to learn:
The barriers to becoming a software engineer are real. People born in technical families, or who were introduced to programming at an early age have this easy confidence that lets them tackle new things, to keep learning — and, in our eyes, they just keep getting further and further ahead. Last year, I saw this gap and gave up. But all we really need is the opportunity to see that it’s not hopeless. It’s not about what we already know, it’s about how we learn. It’s about the tenacity of sitting in front of a computer and googling until you find the right answer. It’s about staring at every line of code until you understand what’s going on, or googling until you do. It’s about googling how-to, examples, errors, until it all begins to make sense.(emphasis mine)