This is post 3 of 4 in Tyler's How To Become A Coder Series.
I learned to code the hard way. I dropped out of school, relied on friends and family while sleeping on couches and configured my tools from the ground up.
Don't do this!
My circumstances were unique: I had friends and family to support me, I was comfortable being alone and finding my own path, and I already knew some coding.
When I decided to become skilled as coding, I was already a novice hobbyist. I had two goals:
I dropped out of school and didn't work any job at all. I lived with family and on friends' couches. Avoiding distractions allowed me to focus on learning.
Most cost runs on Linux, because that's what most of the internet is made of. So, I erased the operating system on my laptop as often as I could, sometimes every day, and configured my tool belt - a Linux desktop.
Once I had my Linux desktop working, which took many days when I first started, I followed web coding tutorials. I wasn't able to work on my own yet, but I could follow steps.
Traditionally, you learn computer science theory before learning to code. That's dumb, because it's backwards.
First, you need to learn the tools of the trade and how to do the basic work that people value. Today, that means using the basic pieces of a high-level language, like strings, lists, maps, functions and classes.
Only once you have been in the field for a while, should you learn the details of your operating system, patterns for avoiding bad mutation, or deciding between productivity and juggling pointers.
I wasn't very skilled at coding by the time I got my first coding job, but I was very skilled at using coding tools, reading coding documentatoin, and troubleshooting other people's code.
After a few months on the job, I was also a skilled coder. On the job, I learned algorithms, design patterns and operating system details. But I didn't see myself as a professional until coding for a living for a few years.
What I did well that you can learn from is eliminating distractions, focusing on the tools of the trade and the skills that matter.
At this point, I've been trying to solve real problems with code for years, but I feel like I've just started.
As a hobbyist first and a hacker second, the hard part for me is recognizing the difference between a real problem and a neat solution.
Real problems don't always have a neat solutino, but they are worth solving. Neat solutions don't always solve a real problem, which makes for ugly business.
Whatever your goals are, I wouldn't recommend my path to you unless it excites you. It took a long time, it was lonely and it was very difficult.
In the next post, I'll share my definitive guide for learning to code in 2022.
This was post 3 of 4 in Tyler's How To Become A Coder Series.