Thanks to
https://www.youtube.com/user/NerdyAnd... for the question! Shares appreciated!
Twitters:
https://twitter.com/cheerskevinThere you go. Here’s the code that will get you past your first technical interview.
By the way, don’t ever write things like that.
So today, I got a question on Twitter, from Sabrina, widely known as the Nerdiest and Quirkiest person on YouTube
And I got really excited, because this is a question I should be qualified to answer! I’ve been coding since I was a little kid; I’ve been working as a developer for the past eight years. I completed a computer science major (though I didn’t wrap up the degree), and I’ve given talks, tech reviewed many books, read and written tutorials.
This is a question I should be qualified to answer.
Surprisingly though, this is a really difficult question. And it’s one that developers get asked a lot by people who are looking to break into the field. "How on earth do I get started?"
And there are two sort of stock replies, that I don’t think work very well. I want to talk quickly about both of them.
The first one is: get a degree! Study the fundamentals of computer science. If you want to develop game engines, you have to learn vector calculus. If you want to work on systems engineering, you have to learn boolean algebra. Study your algorithms!
The problem with this approach is that most developers are inherently lazy. That’s why they program computers to do things for them. It’s very hard to get invested in software when you’re not actually making something you’re excited about.
A lot of people will say "Learn C" or "Learn JavaScript", or learn some other language or toolset. And usually that’s because it’s a tool that they use, to solve problems that they are excited about.
Programming languages are a lot like human languages. Just because you can read and write in French doesn’t make you a French novelist. And in the same way, just because you know the syntax of a programming language does’t mean you can solve problems with it.
There are a lot of languages out there, and they’re all designed around solving particular problems. But unlike human languages, most of them are designed to be somewhat friendly to people who don’t already speak the language.
Let’s use "Hello, World!" as an example. "Hello, World!" is usually the first program you’re going to write when you look at a new language. All you want is for the program to output "Hello, World!", and that’s kindof the basic test to know you’ve got something that runs. So let’s pull up some examples.
What I want you to notice is that even if you don’t know anything about programming, you can tell that these are all pretty darned similar.
And what I think a lot of developers forget to tell you is that eighty to ninety percent of what you learn programming in one language, is going to be transferrable to another language.
We all tend to have our favorites — I tend to like Ruby, JavaScript, and Elixir — but don’t listen to people who say "You have to learn this or that", because those preferences are based on personal preference, and the problems those people are trying to solve.
So I’ve argued that it’s not a great idea to try and force people into studying a particular academic field, or prodding them toward our favorite languages. But then where do we start? There’s a lot of information out there, and it can be very overwhelming.
I’m here to tell you that you don’t actually want to learn to program. What you want to do is solve a problem. Maybe there’s an app on your phone that you don’t like, and you want to come up with a better solution. Maybe you’ve decided that you want to have a website. Or maybe you want to build a game.
Learning "programming" is like practicing scales. It’s going to make you a very strong musician, but if you do that for years without ever playing a song, you’re going to get very frustrated. It’s a lot easier to learn something when you have a reason to want to know it.
For me, the first problem was high school math tests. I’d be using my TI calculator; I’d show my work; I’d make a little tiny mistake, and I’d get the wrong answer. That was a problem I wanted to solve. So I learned TI-BASIC, and I wrote some programs that would factor and foil and all that stuff. That way, when I found my answer, I could go ahead and check that it was right.
It was so much easier to learn that language, because I was using these tools to solve an actual problem that I had. I was excited to figure out ways to make it better and faster.
So before you look at programming at all, figure out a problem that you’re excited about. Something that’s going to motivate you to learn about the languages and tools available. And once you’ve built that really cool thing, you’re going to discover that you accidentally picked up a lot of skills along the way.
