How I started programming 8 months ago (and some advice on learning how to code)
This is part 1 of a 3-part series on my journey as a software developer:
1. How I started programming 8 months ago
2. Lessons learnt from General Assembly’s Web Development Immersive
3. From bootcamp to real-world software development
Passing it on
I’ve played only a small part in this progress. In fact, I was able to learn this much in less than a year thanks to (i) a structured learning experience at General Assembly’s Web Development Immersive course, (ii) an awesome instructor who made programming accessible and interesting, (iii) the wide plethora of resources and tutorials available on the the internet, (iv) smart people whom I met at the course and at meetups, and most importantly (v) my patient wife who let me code in almost all of my free time :-) This post is my way of passing it on.
You may or may not have the luxury of time to join a 3-month full-time course. If you do, great. If you don’t, fret not — there are lots of materials out there that can get you started. In this post, I provide a breakdown of what I learnt each week, and each week’s topic(s) is accompanied by links to docs/tutorials/resources which I think provide comprehensive coverage for the given topic. I also list some tips on how to learn how to code. I hope it serves as a guide for anyone who’s thinking of learning to code, and hopefully an indication of what you can learn in a span of a few months!
How it went down
I’ve listed the schedule below in weeks (numbered), since the actual dates (e.g. Oct 31) don’t matter. Week 1 starts on 23 May 2016. Weeks where I didn’t learn a new topic are left blank.
At General Assembly Web Development Immersive (as a student)
Week 7: Server-side application development with Node and Express
Week 8: Learnt how to consume APIs. Built a simple API using LTA carpark data and visualised it using leaflet.js. Also, we learnt Test Driven Development (TDD) with mocha
Week 9: Built a full-stack reading app as a group project
At General Assembly Web Development Immersive (as a teaching assistant)
Week 14: Read up more on object oriented programming
Week 15: (Married the love of my life woohoo + got accepted by ThoughtWorks)
I’ll write about my journey after General Assembly in my next post. We’ll talk about exciting things like algorithms, data structures, TDD, Java and Bash.
Tips for getting started with programming
- Don’t do it alone. When I tried learning programming on my own, I would get an error and that error would block up 2–3 hours of my time, and I would have no clue why it happened and how to fix it. And I’ll give up. If you can find a mentor or a friend that knows a little more programming than you, that would be good. If not, gather 2 or more friends and work on tutorials/mini projects together. Doing it with someone else exponentially increases debugging speed, learning, fun and confidence.
- Work on your fundamentals for the programming language of your choice. The fundamentals are largely the same across languages (variables, functions, conditional statements (if-else, while loops, for loops), data structures (arrays, objects)). Once you pick up the fundamentals for one language, the process for learning another language can be quite similar. Sharpen your fundamentals by doing programming challenges (do one a day if you can). The fundamentals will go a long way when you’re building your app.
- Learn how to read the docs. Every self-respecting language and framework comes with good documentation (example). Documentation can look intimidating at first because there are a lot of words, but they are essential when you’re learning how to write/use code. My advice would be to focus on just three things: (i) the syntax, (ii) what inputs it requires (a.k.a. arguments) and what it outputs, and (iii) example code snippets (i.e. how to use it).
- Fixing bugs and errors. We will undoubtedly see error messages when we’re learning to code. They are scary at first, but they are in fact our best friends. They tell us which exact line in which exact file is the cause of the error. In the spirit of the Feynman Algorithm for solving problems, I’d like to introduce the S-O (stack overflow) algorithm for fixing bugs: (i) read the error message (it tells you which line the error is coming from), (ii) try to fix the error, (iii) failing which, copy the error message on Google/StackOverflow’s search, (iv) read through people’s suggested solutions and see whether they work in your situation, (v) fix your error! (This may sound like something very obvious, but based on what I’ve observed, this pattern is not immediately obvious to everyone — so I thought I’d just list it down anyway)
- Build small projects. Build something in one afternoon, a weekend, or a week. Even though simple projects like Hello World projects, a blog, or a twitter clone may seem trivial, they are a great way for us to build something functional and to gain confidence!
- Just start! When faced with so many options on what to learn, our brain goes into paralysis-by-analysis, and we spend all our cognitive resources thinking about what we should learn, rather than actually learning them. Just pick something and go with it for a couple of weeks.
- Be patient with yourself. Programming is difficult. Coding involves regular failure. I have felt lost and stupid at many points in time. Rome wasn’t built in a day. Learn together with some friends (see point 1), keep moving forward and have fun!
If you’re interested in getting started, but are not sure how, leave a comment below and I’ll point you some meetup groups or resources that may be of help.