- 3 Minutes Wednesdays
- Posts
- 3MW (5 Lessons For Getting Better At Programming)
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.
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