How I graduated from medical school and made the best decision of my life: to learn to code
I graduated from medical school knowing that I didn’t see myself working as a doctor. Luckily, at that time, a company called AMBOSS was looking for a doctor who had passed the United States Medical Licensing Exams. So I applied and landed my first job as a medical editor! The job was fun and challenging, but, after about 2 years, I realized that I wasn’t as passionate about it as I would have liked to have been. This led me to one of the best decisions I’ve made in my life, so far: to teach myself how to code.
The basic idea is to focus on one thing at a time, and spend as much time writing code as possible without getting sidetracked by other languages, frameworks, operating systems, editors and so on. After that, you can learn React, frontend related tooling (Webpack, Babel), or maybe focus on NodeJS and the backend if you’ve decided that frontend is not your cup of tea.
The first two months were spent figuring out what I should learn and how. My Google search history was full of “Ruby vs PHP” even though I didn’t understand half of the answers and had no way of figuring out which advice was useful. One of my biggest mistakes back then, that I probably still make, was not asking the people around me. It’s incredibly tough to navigate the tech landscape on your own. If I could do it again, I’d find a couple of people I trust and just straight up ask them what I should do. The second piece of advice I would give my past self is that the choice of programming language matters far less than I imagined. But this article isn’t called “Reflections on Learning Programming,” so here’s why I do believe that JS is a good first language:
- It’s a popular first programming language, meaning lots of documentation is aimed at beginners and there are many high-quality tutorials.
- As a general-purpose programming language, you can use it in many different scenarios including things like Google Sheets.
- It allows you to quickly build something tangible since the browser supplies everything you need to create a user interface (HTML and CSS).
- JS is a so-called multi-paradigm language, which means that it doesn’t dictate any specific style of programming; you can eventually experiment with different paradigms using the same language.
To make matters worse, once you’ve decided to learn JS, you’re then faced with navigating the maze of different JS flavors. A tutorial might start with instructions on how to install Webpack, set up Babel and maybe add a generator runtime, even though none of that is immediately relevant to what you’re trying to learn. And then you go on a huge tangent to figure out what all those things do and why you need them, and one week later you’ve barely made any progress on your initial goal. That’s precisely why I’d advocate for following a single course or book and not doing what I did, which is jump from tutorial to tutorial. The JS ecosystem is vast and you will eventually feel lost. Best not to experience that right at the start.
Additionally, don’t skip chapters that don’t interest you at that moment, because they’re probably important, for example, those covering error handling and asynchronous code.
In my opinion, the biggest missed opportunity in every programming language book I’ve read is that testing is introduced too late and being given insufficient emphasis. If testing is covered in just two paragraphs in the middle of the book, new developers will think that testing is an afterthought. It’s something corporate and professional that you should be doing but which no one really does. But testing is an important part of software development, especially in a language as lenient as JS.
Testing helps not just with preventing bugs, but also with writing higher quality code. In the beginning it’s pretty much impossible not to write spaghetti code. Testing forces you use your own functions and assume a different role. That perspective can be incredibly helpful: you suddenly realize that your function is depending on dozens of global and out-of-scope variables.
So you rewrite the function so that it’s easier to test, and you’ve immediately gained a practical, first-hand insight into good software development practices.
If testing is mentioned in a tutorial, book or online course, double down on it and use it throughout the rest of your learning journey (meaning forever). You’ll thank me later.
Some distractions are obviously counterproductive in the sense that they don’t help you at all with becoming a software developer. And then there are other, more insidious distractions, where it’s sometimes not even clear if they really are distractions. For example, I have learned a lot from reading Hacker News (HN) and reddit. But I’ve also wasted an incredible amount of time on those sites. Especially in the beginning, you’ve got so much on your plate already, that the discussions on HN — even though many of them are worth reading — would just take away precious time from learning your first language.
Another favorite time-waster of mine is text editors/IDEs. To put it in a nutshell: it doesn’t really matter. Choose a versatile and lightweight editor in the beginning, which can be an online editor as mentioned above, or something like Sublime Text or Visual Studio Code. But they’ll all get the job done. Just in case you stumble upon vim or emacs: there’s plenty of time to learn those, but that time is definitely not right now.
One exception to this rule is version control with git. I would recommend learning the absolute basics of git early on (
commit, pull, push) and putting everything you do under version control. If your code is on GitHub, it’s easy to ask someone to review it, or show it to a potential employer. Besides, version control is something every developer will have to learn, regardless of whether you do frontend, embedded or machine learning.
Here’s a super opinionated starter guide: