A Quick Guide for New Developers
This entire post comes with a caveat: I am not a software engineer. I do build a software product, and work with a bunch of people way smarter than me, though. I’m experienced enough to have an opinion on the topic.
I talk to lots of young people looking to get into the software world. Sometimes they want to build mobile apps or create simple tools, and sometimes looking to create entire products. There are a lot of possible places to start. The world is full of blog posts, podcasts, books, and videos that purport to “teach you to code”. Don’t get me wrong, it’s an awesome world we live in where this stuff is accessible, but I think people get priorities twisted during that early impressionable stage by thinking they can make a successful iPhone app from scratch in a few months. Even if it’s possible, is that really a life goal? Or do you want to actually become an engineer?
Young people interested in learning how to code could learn a lot by starting with the smaller steps. Instead of diving immediately into learning node.js, or beginning with “Build Your Own Rails App in 15 Minutes” blog posts, focus your energy on some foundations that will be 100% useful in building your skills as an engineer.
In no particular order:
Learn how to use the Linux command line
It almost doesn’t even matter what exactly you do with Linux to get started on this. Install some variant of the OS on a computer or virtual machine, and start trying to do stuff. Install packages, set up PHP, get Postgres running. Most importantly: learn the basic command line tools that you’ll use for the rest of your working life — things like grep, sed, cat, ack, curl, find. Think of these as tools of the trade; once you know how to work them, you’ll use them every day. Compare your craft to cooking. It’s possible to create good food without a razor sharp chef’s knife, a large rigid cutting board, and fresh ingredients, but it’s a lot easier when you have them.
Work on tools instead of systems
Starting out by building entire products is a bad idea. The most readily available ideas are ones that require a lot of moving parts, typically. These are the ones that sound fun. Starting to assemble some knowledge by building your own blog engine or social sharing site or photo database system won’t teach you nothing, but it puts the cart before the horse. A few hours into building your photo sharing site (with an objective of making something to share photos) you’ll be working on a login system and a way to reset passwords, instead addressing the problem you identified to solve in the first place. The easier place to start is to identify small pain points in your technology life, and build utilities to fill these voids. A script for uploading files to Google Drive. Wrappers to simplify other utilities. A command line tool to strip whitespace from files. You’ll be biting off something you can actually build as a novice, and you might be able to ship and open source something useful to others (one of the bar-none best resume builders around). Scratching small itches is your friend when you’re learning.
Prime yourself on “devops” knowledge
The “cloud” sounds like a huge loaded buzzword, and it is. But nearly every useful technology stack, even if it’s not a publicly facing consumer product is now built using these core architectures. If your mission is to build iOS games you’ll think this stuff isn’t valuable, but learning how to stand up instances on AWS, install database servers, and understanding the network security stack will guaranteed add indispensable chunks of knowledge that you will need in the near future. This stuff is free now to get a place to hack around, so there are no excuses to not plunging in.
Spend hours on GitHub
Dig for open source projects you find interesting. Pick apart their code. Follow the developers. Read the issue threads. You’ll find something you can contribute back to, without a doubt, even if in tiny ways at first. This is not only hugely satisfying to an engineer’s brain, but you’ll slowly build valuable trust and presence within the community. Don’t be afraid to dig in and have conversations on GitHub projects (trust me, no one else is scared to make comments or offer opinions). Being thoughtful, considerate, positive, and thinking like you’re working as a team are excellent ways to get invited into the fold on open source efforts.
See also, traditional resources
I’m a huge fan of starting by getting your hands dirty. This post was intended to help you find the best mud pits to put those hands into.