Every now and then I come across Youtube videos or ads along the lines of - “Learn programming in 24 hours!” or “Learn React.js in a week”. What’s the rush?
Programming is a craft. And like any form of craft, you don’t master it in 24 hours. You don’t master it in 24 days. Heck, you might not even master it in 24 years.
So, how do you really get there? Or do you even get there?
The magic sauce to this recipe is- *drumroll* practice. Ah, the glaringly obvious word.. What a disappointment, right? But really, think about it. How did the best programmer, muscian, driver, carpenter or anyone who you’d consider an expert get there?
Was it because they found some wonderful resource online or a youtube tutorial that helped them attain Nirvana? Did they learn it in 24 or 36 hours?
They started off just like any other kid who wants to ride a bicycle for the first time. By doing it. You didn’t read a manual on how to ride a bicycle in 24 hours when you were young, did you?
As a kid does, they tried out something that intrigued them. And like in most cases, they fell. They failed. Failure is an important step towards success. If you don’t know the taste of failure, you’d never know the joy of winning. And chances are, you will never win.
I understand, we are humans. We are greedy and we don’t like to risk it. Most of the undergrad students in my college took CS simply because “it has a good scope” or “it’s trending in the market now” or even for outrageous reasons like “I got great marks in my XYZ exam which involved math, physics and chemistry- so I should take CS because that’s what toppers do”. I am not saying that these are wrong motivations for joining CS, you gotta feed yourself, right? But when you do join CS, and then you DO NOT like the subject and you start memorizing code snippets, googling “learn C++ in 24 hours” to pass the test tomorrow, that’s where you are doing it wrong.
YOU DO NOT LEARN PROGRAMMING IN 24 HOURS. Repeat after me- YOU DO NOT LEARN PROGRAMMING IN 24 HOURS.
Sure, you can learn a few keywords, variable assignments, conditional statements, loops in a couple of hours. But that’s not remotely close to what programming really stands for. You are memorizing a language not learning how to program.
To be a programmer, to learn programming you have to start from the very beginning, go into the child curious mode and start asking the silliest questions that come to your mind. And then you start programming, with even the tiniest bit of information you gathered uptil now. You apply everything you learnt. You have to see it work and understand why it works. And then you learn a bit more, and you write a bit more. And you keep doing it. For a day. A week. A month. A year. A decade. A lifetime.
“Now take your best rhyme, outdo it, now do it a thousand times” - Eminem
You know the difference between a real software engineer at google and a wannabe hacker boyz straight out of college? The software engineer wrote thousands, maybe millions of lines of code in his or her life while our four year degree hackerz has been on youtube for far too long and installed Kali Linux. The skillful engineer is humble and knows their limitations. They keep learning and they don’t stop. The more they learn about something, the more they know how much they don’t know.
The only way to learn programming is by programming. That’s a recursive process and this is how every other form of craft or engineering is meant to be. You don’t learn if you don’t build enough.
“The master has failed more times than the beginner has even tried.” - Stephen McCranie
Over the years, I have been through a lot of phases on this journey to be a software developer. I have had the opportunity to meet some brilliant people and some downright desperate “coders”. The biggest differentiating factor between these two were the amount of time and effort each group put on themselves before they started calling them “programmers”. You need to write a lot of programs to become a good programmer.
So, you want to become a web/android/desktop app/xyz developer?
Here’s what you gotta do. Go out there, find a cool looking website, app or whatever, check out why it looks as such and draw a picture in your mind. This is your project for the next summer. Oh wait. Nope. “for the next summer” - very very bad suggestion. You DO NOT wait for the next summer. You do it now. Like, right now. You find a resource online for free, you follow it and you build something.
Don’t worry about good or bad practices. Don’t worry about how the end product looks. Your first piece of big project is going to be crappy. So is your next project. So is the next one. But that’s going to be relatively less crappier than every former version. It’s pretty common in the software business to write pretty code now and curse ourselves six months later for writing such a huge unmaintainable piece of crap. And that’s okay. You are most likely to fail on the very first project, and it’s okay.
Programming is not something you do in a day or a week. You take your time, commit to a task and keep improving everyday.
So how do I really get started?
My next blog post will contain some tips and pointers. Just a few hints to get you started. It won’t explain why this framework is better than the other or which language is the best, but it will give you a slight heads up on what to expect and what to avoid. I learnt from my mistakes, you probably don’t want to make the same mistakes that are easily avoidable and just downright silly. I will let you make your own sets of mistakes. Tune in to my next post to learn programming in 10 years.
PS.: I prefer refering to what I do as “Engineering”. Programming is just one part of what I do, one piece of the puzzle.
About The Author
Dedipyaman Das is a software developer and a student from India. He writes about software, and has been working on server, desktop, mobile, web development for 8 years. He is also a part time raster graphic artist. Currently, Dedipyaman is a Computer Science undergraduate sophomore.
All the views, thoughts, and opinions expressed in the text belong solely to the author, and not necessarily to the author’s employer, organization, committee or other group or individual.