Developers! What Do They Know? Do They Know Things?? Let’s Find Out!

When I started coding, my professors taught me that copy-pasting code from the internet is the worst thing a dev can do. It almost felt like an army boot camp, with the drill sergeant screaming: “What will you do in the battlefield, soldier? What will you do when you’re a full-stack developer, and you can’t look up code snippets on Stackoverflow? Quit your whining and write your own damn code! Now drop and give me 50!!”

But it seems that devs have been posting questions and copying answers since time immemorial. In a study from 2011, computer science researchers have raised this question to a scientific level, and wrote a research paper asking “How Do Programmers Ask and Answer Questions on the Web?”

Many of the insights published in that paper are still quite relevant today. Some aren’t very surprising, like the fact that we consult StackOverflow when trying to enter a new domain. Other insights are less obvious. Borrowing from the greats, like Douglas Adams and Isaac Asimov, I wonder if there is another, more important question we haven’t asked yet: In what situations do developers NOT ask questions or search for answers on StackOverflow? But I’m getting ahead of myself. Let’s start with what we know.

Ask, and you shall learn

It takes us a while to get from “hello world” to “ask me anything about python,” and developers spend a good portion of that time in Q&A forums. In some cases, it’s obvious that we should be asking as many questions as possible. For instance, when we’re facing a new programming language, a new cloud framework, or a new type of problem. And of course, we all find ourselves asking the age-old question: how the h#$% do I exit vim?

In other situations, we’re not sure whether we should be asking a question, because we’re unclear on what exactly is going on with our code. We’re facing an unexpected problem, and we’re confused – is it a bug? Is it a feature? Is there documentation for it anywhere? Has anyone ever faced this specific exception or error message? And if they did, how did they resolve it?

This lack of clarity makes our Q&A behavior inconsistent and unexpected. In some domains, the first thing we will do is post a question to StackOverflow. In others, we’d rather bury our heads in our IDE until we figure it out on our own or until our laptop catches fire, or both.

Maybe it’s because the problem domain is something we don’t get no matter how hard we try. Some of us will forever turn to google to help with regex, for example. And maybe it’s because the domain or the specific framework we are working on is fresh, undocumented, and unexplored. In a couple of years, StackOverflow will have all the answers for debugging serverless apps. But today, some of our questions will remain unanswered, and we’ll have to settle for our well-earned tumbleweed badge.

Asking for a friend

There are also times we don’t ask for help because we are too embarrassed to admit we don’t know something. Sometimes we are stubbornly convinced we’ll get to the answer if we think about it for five more minutes. At other times, it’s because we see ourselves as disciplined, hardcore developers, and how will we ever learn to solve problems on our own if we keep copy-pasting from StackOverflow?

It’s such a common concern that the dev memeverse abounds with “copying and pasting from StackOverflow” memes. A classic case of “it’s funny ‘cause it’s true.” Just look at that fake O’Reilly book. You know the one I’m talking about, the one with the sloth.

You’re probably cackling to yourself: “It’s funny because other people are stupid/lazy/incompetent. But not me. I’m a 10X developer. My commits never break, my regex is stronger than your kung fu, my ruby is sharp.”

Although…

It really do be like that sometimes

Sometimes we need to ask for help after all. It may be because we’re under such a strict deadline that we don’t have the time to bang our head against the docs until inspiration magically shows us the answer. The boss says we have to push the change today; production is down, and the company is bleeding money; or, more realistically, we want to push our changes and get a beer with friends, as far from the office as possible.

And in those situations, we don’t just post on StackOverflow and cross our fingers. We reach out to our friends on Slack, WhatsApp, or any other channel we can find. We search through our logging tools, our APM dashboards, our exception management frameworks.

When the problem seems hard enough, or urgent enough, developers are prepared to go to many extremes to solve it. We’d probably be willing to get down on our knees and pray to the flying spaghetti monster if we thought it could point us at the right line of code to copy-pasta, change or delete.

What was the question again?

Often, after searching literally everywhere, we go back to where everything started. We ask ourselves, our rubber duck debugging companion and our own code. We set a breakpoint, read deeper into the logs in search of a helpful code comment or an eye-opening commit message. We gather all the knowledge we found on StackOverflow, our online dashboards, and the tips we got from friends, and we use it to look at the same code with a fresh set of eyes.

Of course, sometimes the problem was that we couldn’t debug our code in the first place. It was running too far away, using an unknown configuration. Or we couldn’t find a helpful log line, because adding a log line requires us to compile our code, and go through a release cycle. That is where Rookout, comes in. Using Rookout we set a non-breaking breakpoint that lets us debug our code wherever it is. That way we can add log lines without fear or delay.

Next time you find yourself facing a difficult question, and you’re about to go on a mighty quest to find the answer, keep Rookout in mind. Your code, your log lines, your cloud and production environments may be closer than they appear. While you’re waiting for the community to answer your question, you may be able to quickly find the answer yourself.