Learning to become a software developer is not a trivial task. There is a plethora of guides, tutorials and courses to take. And of course, there is the question of self-teaching or going to university.
But no matter, which path you chose you will always make mistakes.
I made a tonne of mistakes. And I want to share them with people who are learning software development. Here are 5 mistakes I made whilst learning to code.
1. Analysis paralysis of resources
I wasted a lot of time analysing the "best" place to learn to code. Early on, I often found myself reading articles about how "good" Codecademy was vs. a collection of "Head-first" books. This time would have been better used on doing the work. It's easy to enter this state of panic thinking you're committed to a certain learning path. But the truth is, you aren't. Mix and match, try different things and go with what works for you.
I also did this same analysis when choosing a language to learn.
Is Python the best? What about Javascript? My favourite sites use Rails, maybe I should learn that?
That was the list of questions that plagued me. It was exhausting and I shouldn't have spent so much time overthinking this. My advice for new programmers is to learn Javascript and web technologies. Yes, you might want to learn games, but Javascript is so widely used (now even in space!) that it will allow you to go down any path you want later on.
Lesson: Just learn Javascript. Mix and match resources that work for you to build a consistent practice of learning.
2. Not building early and often
What do I mean by "building"? I mean creating libraries, API's, demo sites and more. But to begin with, I thought the idea of "building" something was too complex to handle. Translating the code into something practical would have made me familiar solving problems. When I did start building projects, I found it challenging to shift from syntax to finished products. To liken it to real languages, it's the difference between knowing the word for "Apple" and knowing how to say "Would you like an Apple?".
This fixation on learning the syntax also had the downside that I didn't have anything to show for it at the end. To a potential employer, I was just someone who said they had learnt to code and could do some simple problems. By having a portfolio of projects that I could show off, I would have proven to myself and others that I had the skills to work.
Lesson: Apply syntax to real-world style projects after learning it.
3. Being tied to tutorials rather than problems
In line with the above, I spent too much time on specific tutorials. I should have learnt to break a project down into small problems and seek solutions. This practice of breaking larger projects into small problems would have been valuable when I started working. It would have also helped me train my "google-fu" to search out error codes, and problems I needed to solve.
Lesson: Learn to break projects down into small solvable problems.
4. Sweating "interview" preparation
Before I began to interview I spent hours doing code "katas" - small challenges using no libraries in your language of choice. I did this because they are supposedly common interview questions. But, I have never been asked to do specific coding challenges like this on a whiteboard or otherwise (having interviewed for 7 jobs in total). What I have had is take-home projects, and asked general technical questions.
Lesson: If you are interviewing for the FAANG companies you are likely to get these questions. If you are not, then skip this. Focus on projects instead.
5. No SQL Exposure
In self-taught land, starting a new project is quite simple. Install NodeJS, install React, launch Chrome - job done. But, installing and using SQL? That was far too scary for me to tackle. There were ports to configure, connecting it to NodeJS and then the table structure. In part, MongoDB gained popularity because it's so simple to set up. By not having the exposure to SQL, I struggled when I got a job.
It also meant that my coding style tended to lean on parsing data within the language. Over time, I've trained myself (for software performance reasons) to use the database to crunch and mould the data for me.
Lesson: My advice on this point is to set up a free account with Render.com or Heroku and add a MySQL or PostgreSQL instance.
If you're learning to become a software engineer, don't give up! It is difficult no matter which path you chose. I hope by listing my failures that you can avoid them. You will make others in your journey and I implore you to write about them and learn from them.