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

Code schools and crash courses are awesome new resources, without a doubt. I don’t mean to discount traditional educational structures for foundation-building and creating a regimented path for walking through the process. The good ones will teach you plenty of my previously-mentioned core pieces without getting you ahead of yourself. But the bad ones get new students thinking about picking libraries and frameworks immediately. So little of the initial hill to climb has to do with your choice of Javascript vs. Python vs. Ruby, or whether to use Angular or Backbone in your first app. None of that matters because you don’t really know anything yet, and you haven’t even climbed the initial three or four rungs of the ladder. You shouldn’t attempt leaping to the sixth or seventh rung without having some scars from the lower levels. Jobs that have you mucking around with data in VBscript or maintaining old SQL Server databases are (unfortunately) excellent seasoning for your career. This is usually where you’ll determine whether you really like this career choice that much. If you come out of the trenches still interested in being a programmer, you’ll love it when you get to work on something satisfying, and you’ll appreciate what you have.

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.