Friend, first of all, congratulations! You have made the decision of your life time to learn code. However, having been coding seriously for three years (and as a hobby for many more), I’m now at working on my first programming book with a prestigious publisher and creating open source libraries for other to use. However, the road to here wasn’t easy, and there were a few things I wished I could have done differently if I’d known what I know now.
Not the whiz kid
Growing up in a developing country, unlike many American kids of the era, I never had my hands on a hackable computer besides an NES clone and a gameboy. When I was in my high school (before the world had Facebook and Yahoo was still the search engine), I began to culminate a fascination for computer graphics. However, I dabbled lightly in HTML and got into WYSIWYG softwares like Adobe Dreamweaver, Photoshop, and Illustrator. I only went into coding years later after I finished college.
With an interest in generative graphics, I started my coding journey in Processing, a software sketchbook that teaches programming through visual, interactive graphics. I consider it the BASIC of the millennials (I, surprisingly, am still one) and will strongly recommend it to anyone who would like to learn programming especially coming from a visual background.
The point I am making here is, I am not one of the whiz kids who have been hacking since 12. I, like many of you, did other things in life before winding up learning code later and chose the path less traveled by peers (right around the time I started coding, the Social Network movie and the mainstream media hasn’t made tech startups cool yet). I taught myself how to code, one runnable snippet at a time, all while still maintaining a distressed but high-paying job and when bootcamps and online coding courses were non-existent. I’d like to share some things with you, my friend, so you don’t have to stumble as much as I did.
Build things
Instead of focusing only on learning how to code and end up having many scattered snippets, try to be persistent and build something as you learn. It can be a small todo app, a chat app, or something interesting using APIs from other services. This will give you the chance to solve real problems and be resourceful. As a plus, you will end up with cool stuff to show off to friends, family, and possible employers. It was okay for when I was experimenting at the beginning, but in hindsight I wish I could have been more focused on building with code than just coding.
Start functional
Different languages were created for different purposes. Do not pick Java or C/C++ as your first programming language if you don’t want to risk being discouraged early on. Most schools (as in Bootcamps, online coding courses, and colleges) would recommend either Python or Javascript as an entry language. But I have an epiphany--try starting your learning experience with a functional language like Lisp, Haskell, or Erlang (Elixir is an interesting dialect to Erlang), or if you’re learning to build a web app, Elm is a great choice.
Why am I recommending you to do this? Because functional programming will make you a better coder faster, especially while you are fresh and new. A functional language will help you to
- learn to think about what you want and how to express it,
- learn to resist the temptation to change things (which is easy but often comes with consequences), and
- learn to write compostable code.
On the contrary, it is quite easy to just hacking out (which sometimes include mashing up code from different sources) and making the program runs just to find out it does not do what you wanted in imperative languages like C++, Python, Javascript, and etc.
Javascript is actually both imperative and functional. The new version of Javascript or ES6 has added many more constructs which makes it much more declarative as a functional language. However, it won’t keep you from programming in the imperative way though.
Functional programming can be a little difficult to meddle with once you are familiar with programming imperatively, so beginning your coding journey with a functional language is very optimal.
Github won’t get you a job
Github is great and you should always try to push whatever code you write to your github. Apart from not losing your code when your computer is busted, if you are learning code to get a new career in software, your Github will also serves as a great developer resume and get your foot right in the door. However, it is not an absolute proof of your worth as a coder, especially to the employing companies. More and more I’ve heard stories from open source developers with thousands of stars on their github who couldn’t land the job they wanted. Ironically enough, there were a few cases in which the company used open source projects but managed to decline to give a job to the authors of the said projects.
In my opinion, I think it’s an issue right now that companies and startups of all sizes are taking the cue from companies like Google and Facebook and prefer to throw in difficult technical interviews and use them as sole metrics to judge a candidate rather than tailor their interview to their size, focus, and goals, looking at the code written by candidates on Github, and give more weight to the candidate’s potential to grow based on her history and projects. Regardless of the rising demand for technologists in the market, I hear more cases of people failing the technical interviews at even as small as a few person’s startup. That’s a crazy formality, but you are stuck with it for now.
Just remember that developers, like you, don’t have time to read your code from top to bottom to validate you as a capable candidate. They’d rather be working on theirs. Therefore, building something to show them might be a better strategy.
Read more than write
If I could only give you one advice, this would be it. I made a mistake of rushing into coding and did not do much reading just because it was funner. I forgot that to be able to speak, one must listen, and to be able to write, one must read. That’s just nature. Reading other’s code can take a lot of time and feel like not much is being done, but remember that understanding something thoroughly will save you hours or even years in the future being stuck at problems you could have breezed through if you have read more.
To be able to speak, one must listen. To be able to write (code), one must read (code).
Don’t be shy to ask
Asking can save you a lot of time when you are stuck. Instead of googling endlessly for a solution you don’t understand, seek help right away. Online docs, books, and blogs aren’t the only resources. Most programming languages, frameworks, and libraries have their dedicated Slack, Gitter, or the more conventional IRC. Get in there and ask right away. Don’t be shy and don’t be afraid of getting looked down or bullied. Only weak people bully novices anyway. Strong, confident people help the younglings no matter how trivial the questions are. What they want to see is you’ve tried enough and understand your problem well before asking them.
Read books from front to back
As a new coder, this is something that I have no regret doing. It took me a lot of time to finish one book, but I ended up knowing things more. Remember that most concepts are like dots and the more you have them the better you can connect them and form a better, bigger understanding. You want to seep everything from a book like a sponge. Yes, include the forewords and appendices. Keep calm and exhaust that book until you know enough to jump around in one.
Protips: If you want to skim or quickly look up something, get a cookbook-style book or google it.
Don’t fall for frameworks
As a new coder, you want to avoid jumping into a library or framework too soon. By using it you are
- placing your trust in the hand of that framework’s creator, and
- introducing another layer of complexity to your learning process
Some libraries and frameworks can be really idiomatic and help teach you the language, but most of the time it’s better to stay pure until you get the hang of the language before using any additional tool for convenience
But again, if you have to use one to build something, try to pick the one with as little magic as possible. If you are into Python, use Flask. If you are into Ruby, use Sinatra. If you are using Go, try not to use anything.
Don’t pay for a bootcamp
Seriously, think about it. Wouldn’t you be better off spending 10K on something else? Bootcamps asking for that much for a tuition fee are just plain absurd and just irresponsibly add to the already problematic pricey education cost in this country. There is absolutely nothing a paid bootcamp can give you that Free Code Camp, Codecademy, Code School, Udacity, Coursera, EdX, Recurse Center or a meetup of your favorite language couldn’t, unless you’re paying for the label. There are other interesting, more affordable courses available at places like General Assembly.
Cherish other aspects of your life
It may sound like a sentimental song, but it’s important. You need to make time for friends, family, and other important things in life, and make sure you are really there when you are with them. You will need all the support and understanding from the people around you even though they may not understand what you do, and that goes vice versa. Other aspects of life can make powerful fuel into your learning journey as a coder, but not without you earning it. Because, mark my word, you will fail. A lot. Both when you run your code and your life.
Lastly, there isn’t a catch-all recipe for everyone. We are all different and indeed will take different approaches to learning and doing things. However, I am certain that if I have done these things I’ve just told you more I’d have had a much less rough road going forward.
