The most oft asked questions, especially in your first 0-2 years of being an engineer is, what should I learn next? (You will continue to have these questions for the rest of your life, but by the time you hit year 5 you've mostly stopped asking them in polite conversation).

So now that we've got here, what do we do?

Well, if you're someone who's really interested (and has the time and money) in becoming a top 1% of engineers. This blog post probably isn't for you. A quick google search will give you all of the very specific (and very stressful things) you can do to become a top programmer.

For the rest of people, who mostly ask these questions to well-meaning Senior and above level engineers, they will get a litany of responses.

Things like:

Go deep on algorithms because you'll use them everywhere in your career.

--or--

They might include recommending learning something like Go, Rust, or C++ because either it's a low level language or because the concepts practiced within it are carried through the rest of programming languages the world over.

--or--

The might recommend you go deep on a single language. Maybe become awesome at something like Typescript because you can learn and play around on the front end or the backend.

Or, maybe they'll say

go wide. Dabble in a bunch of different things. Becoming well rounded is important.

Personally, I find this advice incredibly stressful and not necessarily all that useful to someone who is just starting out and not entirely sure where the arc of their career is going to take them. There the type of things that make a lot of sense, as that Stanford address says, you can only connect the dots backwards, not forwards.

General Principles

Basically what I'm saying is that while it's helpful to pick some goals (Maybe you want to ship a project, maybe you want gainful employment, both are great) you don't need to obsess over what you're doing every day to reach those goals. Being thoughtful, taking care of yourself, and evaluating how you're feeling about those goals will take you way further (or at least took me way further) than trying to explicitly script out what I wanted to learn.

Honestly, being able to do those things might have made me a better programmer. There are probably better programmers who can do those things than me. But... I'm also a reasonably successful engineer. And at some point we have to trust the fact that the people will be able to make optimal decisions as they learn more.

If you're starting out (and even if you're not starting out if you're not starting out), continuing to code and learn tomorrow (and the day after) is way more important than whatever you might crunch on today. Compounding knowledge is really a thing.

The Actual Advice

So giving forward looking advice should be less about specific objectives I hit that got me here, and should be about habits I developed (or lucked into) that were useful, regardless of what I was doing as an engineer. In my experience there are two fundamental concepts (and one bonus!) you should focus on in your software engineering career:

1. Making coding a (mostly) daily practice.
2. Finding a community of people to give you feedback.
3. Skim a variety of sources so you can sound intelligent.

Simultaneously luckily, and also the most challenging, both of the first two (and likely the third) can be provided to you by gainful employment. But, not all employers will support you on either of those things, and you can get these things without employers.

1. Make coding a (mostly) daily practice

Realistically, you should code every day (that you're not on break or on vacation) somewhere between 30 and 240 minutes (that's 4 hours). The 4 hours thing is intentional, as there's some evidence that shows you have a limited number of resources.

If you're employed, you really should try to spend close to 4 hours a day (early in your career!) coding. Ideally it should be on specific problems that you can solve (code katas or other challenges will do) but ones that stretch you. Again, an employer will really help here, but even if you don't have one, the goal isn't necessarily to learn the hot new technology, or do something fancy. I've found in my career that problems will often become the most interesting to me right as they become the most useful.

The goal is like exercise, do something that pushes you just a bit, but not so much you hurt yourself. This is in direct contrast to advice that teaches you to learn a specific language or a variety. I mostly don't like it because I find long lists (without priorities) incredibly stressful and not all that useful towards doing the thing of learning.

Resources

Early on in code bootcamp, I'd pick pretty simple UI on sites like Dribbble and try to replicate them to my best ability, or maybe do a couple of Code Katas. Though, it's really best to try to solve real problems that interest you. Doing mock work can only take you so far, as the types of problems you'll run into there are often not all that useful to what you're currently trying to accomplish.

I've tended to dislike most tutorials, but Front-end Masters generally has some of the widest depth and breadth of entry-level (and further) content that I've found.

2. Find a Community of People To Give You Feedback

This doesn't have to be a large community (more than 1 other person will do, though ideally you want a group of 4-6 people). Basically what you want are people you can talk about the problems you're facing and ideas you can bounce off of. It's even better if they'll review your code. It's the best if there's a variety of experience levels.

Honestly, the best help I ever got was being able to be around other experienced devs who were willing to give me the time to walk me through what they were doing or what I was doing wrong. The most important thing is that you're stretching yourself just enough outside your comfort zone.

Being involved in a community of people you trust will also expose you to way more new ideas (in a way less stressful way) than you could ever tackle on your own.

The Job of It All

Look, the easiest way to do this is to find a job that provides these things. It will give you the impetus to work on interesting problems and the final compensation to allow you to do so. But not all jobs are created equally.

If you're looking for a job that meets the "community" requirements, here's what I'd recommend.

1. Find Senior and above engineers.
2. It should be a place that believes in the value of having people who ask obvious questions
3. Code Reviews should be an important part of the culture
4. It should want you to ship code early and often

Job or Otherwise

So if you don't have a great job, or you don't have a job yet and want to build a community, here's what I'd look for. What I want to note here is that it's not necessarily important to look for a mentor or someone to fulfill a particular role. Your goal is to get reps and to get reps working as closely as possible with other people. Tying yourself to another person (experienced or otherwise) won't necessarily facilitate that goal.

Will Larson has a great post about why activity-oriented communities are more stable. What it comes down to is that you want to be around people who are trying to solve a similar set of problems as you (from very similar experience to much more experienced). This means you're not necessarily looking for people who you immediately get along with.

This means that a group you worked closely with at a bootcamp might not be the best bet. If you don't have an obvious community in front of you, here's what I might try to accomplish:

1. Find 2-3 other developers of your skill set who would be interested in taking a course with you. It can be a free course online or
2. Agree to go through it at the same pace and create a new codebase where you all will work. (This could be )
3. Push PRs for this to the same codebase and ask each other for critiques on your PRs.
4. Find a senior dev (or set) who can answer specific questions for you. (This could be in the form of a local slack channel or someone connected to you through your bootcamp).

The other thing to note here is that people who make good friends will often not make great teammates from a learning perspective. The stuff that makes you like hanging out with them (similar opinions, diverse interests) make them not always great for learning (you want similar interests, diverse opinions). I've made this mistake too many time to count, thinking that people I get along with will make great study buddies and sometimes they do but very often they do not.

Bonus 3. Skim a Bunch of Articles

There are a few truly great email lists I think genuinely changed my life as an engineer. Basically there were a few times when I would chat with people at the many Meetups I would try to go to desperate for a job, where I would carry a conversation longer than I had any right to simply because I had read an article and new some vocabulary.

At first I thought this was faking it, but as I've gotten more experience I've realized that having a list of stuff you can wave your hands around about, and stuff that you know enough to ask some well-timed questions will serve you really well. Most of the stuff I've never had to learn in depth, but the couple of times I've needed to dive in (I'm thinking about Serverless and Typescript most recently), having that initial vocabulary experience was really helpful in guiding me towards learning the stuff more quickly.

The scanning part is also incredibly important here. Articles will want you (beg you, in fact) to read them deeply. You simply don't need to do that unless you really want to. Getting comfortable with vocabulary and terminology is more important than trying to pick up Go or Rust from the hot new blog post.

Resources

The reality is there aren't that many awe-inspiring articles going around the internet every week. Just find one you want to graze, and go through it. Here are a couple of the general purpose ones I find the most helpful:

• Progamming Digest
• Pointer