3MW (5 Lessons For Getting Better At Programming)

3 Minute Wednesdays is brought to you by

First-ever Black Friday sale on R for the Rest of Us courses

From November 26 through December 2, all R for the Rest of Us courses are 40% off (no coupon needed!). And this isn't an ordinary Black Friday sale: 10% of all revenue goes to support the work of the United Nations High Commissioner for Refugees.

Guten Tag!

Many greetings from Munich, Germany. Today is a very special day as this is my 100th newsletter. 🤯 So that's why I'm doing things a little bit differently this time.

Instead of my typical tutorial e-mails, I'm going to cover five lessons I've learned in the last two years of writing this email newsletter. So let’s dive in.

Lesson 1: Language Doesn’t Matter

This one might surprise you. I know that I mostly focus on R and you’ll find that practically all of my content is about R. And you’ll also often find me defending R (particularly against Pythonistas.) But honestly, when you're doing data work, the programming language doesn't matter all too much.

Now, this doesn’t mean that I don’t like R. In fact, I have a huge appreciation for the language (which is why I’ll defend it against trash talk) but I’ve for long adopted the stance that real world problems happen at the intersection of programming languages.

More importantly, when you’re doing data work, the concepts of programming and data science don’t change much. Sure, the tools are different, and each language has specific strengths. But switching from one to another isn’t that hard if you have expertise in at least one language.

And that’s the point I want to stress here. When you have a deep understanding of one language and know what it takes to push data around, you can make things work in other languages too. Similarly, having only a shallow understanding of a couple of languages means that you likely don’t have a solid understanding of working with code and thus with data.

That’s why I believe that getting really good at R paid off because I learned the mechanics deeply. So, my advice? Get good at one language first, and then adjusting to another will be manageable.

Lesson 2: Get Progressively Better

There is zero chance that you will pick up a programming language and be really good at it immediately. That’s just not how it works. But what can happen is that you progressively get better by accomplishing small goals.

People overestimate what they can accomplish in the short term and underestimate what they can achieve in the long term (I totally stole this from someone on LinkedIn but I don’t know who I can attribute this to.) With programming, if you get a tiny bit better every week, over time, you’ll see significant progress.

For me, participating in challenges like TidyTuesday was invaluable and each week I learned something new. While my early results weren’t great - let’s face it, my first charts were shit 😆 - over time, my charts improved, my programming skills grew, and I became better at working with data overall. That’s the magic of slow but continuous change.

Lesson 3: Learn Shortcuts

Next, let’s talk about tools. And I don’t just mean programming tools. This lesson applies to everything.

You see, there’s one thing that I noticed in all three of those:

  • Programming in RStudio

  • Video editing in Davinci Resolve for my YouTube channel

  • Doing the big ol’ corporate stuff in Outlook, Word, or PowerPoint

I got waaay more productive when I embraced these tools and the shortcuts they provide. The thing is: It’s easy to dismiss these tools, but learning their shortcuts makes you significantly more efficient. For instance, here are a few shortcuts in some of the tools I use:

  • Ctrl + Enter to send an email in Outlook,

  • Ctrl + Backspace / Ctrl + Delete to delete whole words instead of single characters everywhere

  • Q, W, E to cut or ripple delete at the playhead in Davinci resolve

All of these shortcuts are meaningless on their own. But repeat them often enough and they compound over time to make you more efficient. And there’s also a meta-point to all of this:

Whatever tool you’re using (whether it’s a programming IDE or a video editor) take the time to get to know it. Taking pride in how to operate it, knowing its in-and-out, it’s what makes you stand out and what lets you speed up and improve your workflow.

And whatever you do: Don’t conflate “getting better with a tool” and “liking the tool”. It’s perfectly fine to operate a tool effectively without liking it. After all, many tools (Powerpoint, that’s you!) are objectively shit 😆 

Lesson 4: Refactor Your Code

You won’t write perfect code on the first try. That’s fine. In fact, it’s to be expected. There will come a time when you’ll need to refactor your code. Whether it’s to add new functionality or to fix issues in unexpected scenarios, that’s all part of the programming journey.

And that’s also were Lesson 2 fits in quite nicely: As you improve your skills, refactoring will become less tedious. And more importantly, you might even learn to view it as an opportunity to improve your code, rather than a struggle to redo everything.

Lesson 5: Share and Teach

When I was in academia doing my PhD, I felt like I was missing out on practical projects that my peers in industry were doing. “All” I’ve been doing in terms of programming was learning to solve tiny problems with code and share what I learned with others.

But what I didn’t realize at that time: Teaching others, regardless of whether through Twitter, LinkedIn, or Bluesky, it forces you to think critically about your work. This helps you solidify your knowledge and understand tools much more deeply than hopping from one project to the next.

Thus, going seemingly slow via the teaching route instead of the applied projects approach can also have advantages in terms of deeper understanding. And it’s this deep understanding that lets you navigate new tools and technologies more confidently (see also Lesson 1.)

So, even though I felt like I was behind, this process of teaching and sharing compounded over time. And to my surprise even though I’m technically in my first year of a professional job, I don’t feel like I’m lagging behind my coworkers.

Closing Thoughts

I hope you enjoyed this special edition of my newsletter. It’s been more strategic than my usual "how-to" content. Let me know what you thought—whether on LinkedIn, Bluesky or by just replying to this mail. And finally, thank you for being part of this milestone, and here’s to many more newsletters to come!

See you next week,
Albert 👋

Enjoyed this newsletter? Here are other ways I can help you:

Reply

or to participate.