#2 - Writing code doesn’t have to be traumatic

Dear subscriber,

Let me start this issue by wishing you a happy new year! You’re increasingly numerous to subscribe to my newsletter and I’m both baffled by the numbers and thankful for all of you to be onboard!

As you can tell, I’ve decided to start 2022 with a dramatically titled issue. But drama put aside (and it’s a big “but” considering how much I love drama), I’d like to discuss a trend I’ve noticed among my fellow economists: how somewhat traumatized many of us are when it comes to writing code. Massive impostor syndrome, anxiety, extreme procrastination and so on — all the usual suspects are around the table.

Writing code has become a key part of our scientific work, especially (but not exclusively) in empirical economics. R, Python, Stata, Julia, Matlab, many of us use these languages (and others) regularly. And because writing code has gained such prominence, I think it’s important that we establish a healthy relationship with this activity.

I’m convinced that most of these code-related negative feelings are preventable. Solutions exist, some easier to implement than others. But even for the most costly ones, I think there’s a case to be made here that their social benefits would be huge. Both in terms of mental health and in terms of increased productivity.

Many of us perceive writing code as this giant mountain to climb. And too often, for good reason. If, like me, you’re an economist, there’s a fair chance that you didn’t learn how to write code in a computer science class; you were probably in a statistics or econometrics class, put in front of a computer and asked to write some stuff you barely understood on the screen.

Here’s a first fix: the first exposure students should have with writing code should be in a dedicated, introductory class instead of… this. I know available slots in a curriculum are a scarce resource. But considering how ubiquitous writing code has become for the modern economist, I’d argue that adding a mandatory introductory code writing class would massively help. This class doesn’t have to be long; it doesn’t have to be a four-semester-long “introduction” explaining the principles of computer programming. The goal is rather to expose students to the basics of code and code writing. The same way a derivative is easy to understand once explained properly, a variable or a loop or a condition also are easy to understand when explained properly. Students only need a basic working knowledge of coding — such as when they have to write economics-related code for the first time, it doesn’t feel as if they had to urgently learn how to swim after being thrown out in the middle of a pool.

More generally, I think we need to professionalize the way we deal with writing code. Our relationship with code is too artisanal. Making the teaching of code writing more professional is a first step, but a second step is to learn, get accustomed to and normalize good and normal coding practices. I’ve been sincerely baffled by economists telling me they’re bad code writers because “I copy/paste code from the Internet all the time” or “I reuse the same code all the time.” Girl, those are normalthings professional developers do all the time! And some of them are in fact super smart – like reusing the same code. They’re even a wide range of apps decided to help you reuse code called snippet managers!

Learning in a more rigorous way how to code would probably alleviate many of these fears. And it would eventually create a more robust and healthier environment in economics around writing code. It won’t solve everything – but the goal isn’t to find a perfect solution that probably doesn’t exist, but rather to transition to a (even marginally) better equilibrium.

I had the chance to learn how to write code before my economics education. I’m not saying it was always a smooth ride, but I’ve never felt an impostor or was paralyzed because I was impressed when I had to write code. On the contrary, I actually kind of enjoyed it! And considering I’ve felt an impostor and was paralyzed by so many things during the rest of my economics education, I’d argue this different feeling is probably not caused by some idiosyncratic characteristic (although I am an idiot) but rather by my prior exposure to coding.

An underappreciated silver lining of normalizing our relationship with writing code is that on top of improving our mental health, our productivity would probably improve as well. We probably would write better code — and for the fraction of the effort we currently spend writing it. I’ve been writing code for so long that nowadays, I spend very little time writing code — and even less, debugging it. Don’t get me wrong, I’m not bragging, my code is still trash and poorly commented. What I’m saying is that I’ve become really efficient at writing this trashy code. And I think it’s in most part due to having developed good habits around this activity.

So this is where this first issue of 2022 ends — on me publicly revealing that I write trashy code. But as I wrote in my first issue, I plan to regularly write about coding — so I’m assuming I’ll have many other occasions in the future to willingly expose my dirty secrets to all of you!

Take care, hold tight if you’re in an unexpected remote arrangement due to the current epidemic conditions – and see you soon for the third issue!