A lot of people ask me things like ”What should I learn to get a programming job?” or ”How can I get a job as an engineer in Silicon Valley?”

Here’s an actual quote from last week:

So, I need some advice. I am 33 years old, and I need to get out of Support and in to at least DevOps if not full-stack development, but it’s so expensive. Any advice on what I should learn first?

The implication is usually which technology should you learn to get a job. As if your choice of technology is some kind of silver bullet.

Wanna know a dirty little secret? It doesn’t matter.

Any technology you’re likely to have heard of is a good pick. Does it have more than 10,000 results when you Google it? Then there are companies using it in production.

If companies are using it, then you can get a job doing it.

Ok, fine. There is a caveat: jobs are easier to get for technologies that are growing in popularity, and it’s harder to get a job in a technology that’s on its way out. So, maybe don’t pick FORTRAN or COBOL.

There’s another caveat — your choice of tech matters a lot more when you’re a programmer or developer than when you’re an engineer. That’s why engineers make $20,000 more than programmers on average.

Your real job as a software engineer isn’t to write code. It’s to translate hand-wavy business requirements into detailed specs that a computer can follow.

Your job is to ask questions and to find edge cases that the product people didn’t think of. Your job is to help operations define processes well enough to be automated.

Sure, you’ll write the code in the end, or maybe you’ll hand off the spec to a coder, but your real job is coming up with the spec. Even if it’s just in your head right before you write the code.

Don’t just learn a technology; learn how to solve problems with a technology.

The key here is that you have to play the long game. What interests you enough so that you can keep doing it for 10 years? It’s probably not a tech stack or a language, but a problem you want to solve.

Let’s say you work in support like that guy from the quote up top. What can you do to get a better job?

First, you can look at the job you already have. Are there problems you have or repetitive tasks you run into every day? You can probably automate those.

Start digging. Learn what you need to learn to solve your problem.

Then you look around. Are there any processes your team follows that are annoying? Processes that could be improved? Processes that you don’t use, but could make everyone’s lives better?

Then you can build something to make it easier. Start digging. Learn what you need. Someone who can take a loose problem and translate it into code is much more valuable than someone who can take specific instructions and write code.

Congratulations! You’re an engineer. You used technology to solve a real-world problem. And you didn’t even need anyone else to tell you the spec!

Not only is problem-oriented learning the most fun way to gain knowledge, it also teaches you all the other fringe skills that you need. Skills like turning fuzz into spec, Googling for solutions, digging into code to find bugs, talking to users, testing, and learning random new tech that’s handy. Learn all the things!

If you’re still stuck and don’t know which technology to use, go to HackerNews and find a “Who’s hiring” thread like this one. It’s a monthly collection of around 600–900 high quality jobs. Many of them list which technologies they use.

Read those threads. Count technology words. Pick the most popular 3. Learn them by solving a problem you have.

Be warned, though. That list changes completely every 2 or 3 years for libraries and frameworks and every 5 to 10 years for core technologies like languages, servers, and databases.

So don’t sweat the tech. Focus on learning to learn and solving problems. Be an engineer.

 

source: https://medium.com/swizec-s-nightowls/what-should-you-learn-to-get-a-better-coding-job-6453ef083597