Lesson 2 - Writing Code is (Probably) not What you Think

Writing code, especially for beginners, can feel intimidating. Part of this feeling is due to the unique nature of writing code. Writing code is its own thing, and you will learn a bit more about that on the course.

But another part of this feeling is rooted in stereotypical representations we all have. We all have seen a movie or a TV show with a character being portrayed as the archetypal genius hacker. Double points if they are evil hackers. Triple points if they face a screen with a black background that displays mysterious symbols. In real life, writing code is nothing like that.

Before diving into R, it is important to rapidly debunk some of these misconceptions. The goal is to establish a healthier relationship with writing code moving forward. A healthy relationship starts with reasonable and realistic expectations.

2.1 “Writing code is hard”

Very few things are fundamentally hard. Writing code is definitely not one of them. What happens is that we usually conflate “I don’t know how to write code” with “writing code is hard”. But they are not the same.

2.2 “I spend a lot of time finding and solving errors in my code, I am bad at writing code”

Finding and solving errors in the code we write is called debugging. Debugging is an integral part of writing code. Some companies exist solely to provide tools and services to make debugging easier. It is completely normal to spend time finding and solving errors in your code.

2.3 “I made a stupid mistake; I am bad at writing code”

What is really a stupid mistake? Sometimes, we think we made a stupid mistake. But what happened is that we ran into a hard problem, but we do not have enough experience to understand how hard it is.

Even if it was a stupid mistake, it is fine. Developers, including experienced developers, are humans. It means we can, and we will, all make stupid mistakes from time to time—me included. As long as we learn from them, in my opinion, stupid mistakes are fine.

2.4 “I don’t know how to do X; I am bad at writing code”

In my experience, we tend to conflate “I don’t know how to do X” and “I am bad at X”. Sure, you do not know how to make great looking plots with R (yet). But does it really mean you are bad at making great looking plots with R?

If you don’t know how to do X, the good news is that you can learn how to do X. And you will. When I wrote my first line of R code in 2014, I had no idea what the Tidyverse was. I had no idea what RStudio was. I had no idea how to create plots. And look at me now: I have written a course where I teach people how to do these things—and more!

Many of the things I learned during this journey have proven much easier to learn than I anticipated. I sure was intimidated at the beginning. And some of these things were (and still are) hard. I am not saying it is always easy. What I am saying is that in retrospect, my feeling of intimidation was overblown.

Last but not least: we should not compare ourselves to people who have vastly more experience than us. They sure know more things than us, but it does not mean we are bad at these things. It just means these people had a head start when we did not.

2.5 “I used my preferred search engine to find a solution, I am bad at writing code”

This one is probably the most misguided misconception we will debunk today. Not only search engines are useful tools to help us find solutions. But we actually need them to build our knowledge. When learning something new, we need a starting point. Search engines are the most natural starting point we can think of.

This misconception is particularly misguided because all people who write code use search engines. All of them.

2.6 “I copy/pasted something from the Internet in my code, I am bad at writing code”

Using a search engine to find answers is fine. But what to do with the code we find? Is it fine to copy/paste it?

Copy/pasting code from the Internet is tricky: in some circumstances, it is a terrible thing to do. But in other circumstances, it is a wonderful thing to do. The issue is that we may have pasted badly written code, if not outright dangerous code. Usually, we do not really understand this code as we are learning about it—hence why we do not realize it is bad code.

I would recommend to use copy/pasted code as a starting point. Imitation is a powerful learning technique. Modify the code you pasted. Comment and uncomment some lines. Google some functions to understand what they do. Read the docs. Experiment so that you understand better how the code works. A code you understand better is also a code that is easier to debunk. Your future productivity will thank you!

2.7 “You need to do X and Y to write good code”

Sure, good practices are important. We will cover some of them in lesson 15. But some people have a very ideological approach to writing code. If code is not written exactly how they think code should be written, they will judge this code negatively. We will see an example of this attitude in lesson 7, as some people have strong opinions on the Tidyverse.

2.8 “I reuse the same code everywhere I need it; I am bad at writing code”

Many people see reusing code as laziness. And in a sense, they are right.

But here is the trick: when it comes to writing code, laziness is good. If you have a piece of code that you know runs fine, reusing it will save you time. Why reinvent the wheel if you already invented the wheel? Plus, if you run into a bug, debugging code you know already will be faster than debugging code you wrote from scratch.

Reusing code is such a fundamental part of writing code that these pieces of code even have a name: they are called snippets. And it exists a whole class of apps dedicated to snippets: snippet managers.

Be smart. Be lazy!

Sidenote: when you purchase Getting Started with R for Busy People, you get three months of access to the Integral plan of my newsletter, which give you access to my collection of ready-to-use snippets of R code.