Hi. My name is Stephen, and I'm a software developer.
Now, I think everyone who's known me for a while knows I like to either be a goofball, or be as correct as possible. As such, I'll be one of the first to tell you that the question is "how do I become a software developer?" is not the best starting point. So let's define some things and answer a couple different questions first!
In this article I'll use a few terms a lot, so for the sake of completeness I'll just stick all of my definitions for those terms in this section. Feel free to skip this if you have an idea - this is just for anyone who has close to no idea what these mean. I'm going to use a personal banking site as an example to help illustrate the idea.
Front-end development: Working with parts of a system that the user can see and interact with. This is ideally separated from the parts of a system that are doing any "heavy lifting", that is to say complex calculations or directly interacting with a database, but not everything is always ideal in life. For a personal banking site, this would be things like the login page, account detail pages, basically all the parts of it you can see and navigate throughout.
Back-end development: Working with the parts of a system that retrieve and manipulate the data behind the application. As you might guess, this is where you calculate anything that's at least kind of hard and interact with your database. In the personal banking site, this could be the balance management system that calculates your balance after each transaction, or the credit pre-approval system that determines if you pre-qualify for credit offers.
Database: This is just something you put data into. This would be your actual transaction history, your current balance, account details, anything that you'd want to keep "written down" for the user more or less.
Full-stack developer: This hot recent word just generally means someone with a reasonable competency across the whole gamut of an application. They won't necessarily be as effective at any one part of it as someone else, but that's what code review is for.
And now for the meaty part of the article...
Then your next step should be closing the tab. Sorry friend. On to the first question!
Probably.
There are a lot of different motivations for why people become software developers. For me, I wanted to learn to code because I played Super Mario RPG when I was 4 and decided I wanted to make games as cool as SMRPG. Some people want to make a career switch. Some people just want another hobby. A couple of friends in particular have asked me about it for the purpose of data analysis for their research projects. I even know one or two excellent developers who learned purely because someone told them they would never make it, which is sort of why I use my text editor of choice (vim).
The best part is, these are all valid answers! If you want to learn to program, that's really all you need! That said, how I would suggest one work off of any particular motivation to learn to program will vary.
Ultimate Goal: Be able to have a good enough idea of what it would take to do most common tasks without crippling intimidation keeping you down
Estimated time to Ultimate Goal: 1-3 months
This is probably the most common among the developer autodidacts I know of. I hear a lot of versions of "I wanted to automate something, so I looked up how to do it, and it was easier than I thought, so then I did more stuff".
That sounds pretty great, wouldn't you say?
The best way to git gud if you don't really want to make a career out of it is, much like anything else, to just do it! Probably with Python. The most important thing is really just to pick a language, like Python, and do a bunch of stuff with it. If you don't know how to do what you want to do, just Google it. Seriously. Knowing what you don't know HOW to do and being able to put that in Google is a non-trivial chunk of what I'm doing when I'm writing code. Now, you do need to understand what you find from Google so you can properly integrate it into your project, but that also comes with practice. The most important thing is you're writing code that does something interesting for you.
And that you're starting with Python. Or one of these:
Even if you don't start with Python, I would recommend against the following common languages, because they have a large knowledge barrier to getting useful things working, which means you're spending less time programming and more time mucking around with installations, configurations, and all kinds of silly nonsense. Don't get me wrong, I'm mostly okay with these languages, but you're less likely to learn decent programming and more likely to learn dumb irrelevant things about these languages that won't help you a whole lot in the long run.
That's more or less my advice for you. Do stuff, and use Python!
Ultimate Goal: Be able to use programming to help with (but not be the focus of) research
Estimated time to Ultimate Goal: 1-3 months
This one has come up a bit as my friends enter grad school and decide they want to work smarter with some kind of data analysis in their research projects. This is probably the easiest one to give advice for, because it's almost always just using basic stats methods, or simply implementing computations they'd be doing by hand otherwise or something that's mostly just mathy, AND the problem and method are well defined, so it's just a matter of translating that into code. That's pretty easy.
Especially with Python.
No, but seriously, you likely want to use Python or R for this. Matlab is an option, but you either need to be a student to have access to it or you need to pay a bitcoin to purchase it - plus there are some weird things about Matlab I personally don't like that make it difficult for me to recommend.
If you're using Python, you have the numpy and scipy packages that offer
just about any kind of number computation you might want. I'm not too familiar
with R, but I have nothing really against it and it has a reasonably sized
community, so it's a good choice too.
Now, if you're in a lab that already has some familiarity with a particular language and a couple basic questions make it clear that they're unlikely to switch to something else, you should ignore this and use whatever your research lab is doing. Doing anything else would just be silly. One thing you could do, that would also be good practice, is convert over a small project or isolated part of a project into your target language as a proof of concept. That way you can show the potential benefits (but don't ignore the costs!) of target language versus the entrenched one in a way that doesn't require too much further investment.
Ultimate Goal: Become gainfully employed as a software developer
Estimated time to Ultimate Goal: 6-12 months, depending on how sexy an offer you want
This path probably has the most volatility just because work environments in the software world have essentially no average - there's such an incredible variance in everything from team structures to tooling to project management that you are more likely than not to see two separate teams in the same company operate almost entirely different. I know this because I've seen it. That said, there are some things that you should expect to see (and conversely, be expected to know) that knowing will give you a bit of a leg up against the competition.
As a side note about the competition, you shouldn’t feel discouraged that you don't have a computer science degree! I know some excellent developers with other degrees who were once trying to make this very same switch and became very successful. I have also seen a non-trivial amount of people who have a computer science degree and have absolutely no business writing professional, production grade code. The degree isn't meaningless, but it's just an additive part of the formula that makes an attractive developer candidate.
Anyway, to the things you should have at the very least a surface-level understanding of!
If you can write decent code and have a decent conversational understanding of
the latter three, I'd usually hire you as an entry-level developer. The only one
I'd say is at all optional is source control - you can get a job without one,
but man, it is way easier to say "Get this person an offer!" when I won't have
to explain why you should never git push --force.
Now, in regards to some more concrete things I've noticed with regards to accomplishing this - front-end development is sort of the "hot thing" these days, which means A) lots of companies are looking for those developers; and B) lots of people are trying to become those developers. It's also probably the easiest to get started with, which leads to lots of competition, but also lots of resources available for you to learn with.
It is definitely possible to get started as a backend developer, but the path is less clear, and it's not as simple to see progress in general for backend development. Additionally, modern development has a lot of full-stack talent who can do the whole shebang - sometimes parts of it poorly - and these will be most of your competition today. I think the best opportunities to get started in backend would be getting into something like machine learning or neural nets, which requires a decent code ability as well as a decent to excellent stats ability.
That's more or less my take on beginning one's life of software development. It's great as a hobby and it's great as a profession, like many things. I think it's pretty great that the field, more than other hobbies I can think of, is accessible to anyone with a computer of their own and an internet connection. And it doesn't even need to be a good computer! The first programs I wrote were on a computer with a 166MHz CPU, 256 MB of RAM and less than 8GB of hard drive space.
All that said! It's not easy and it's definitely not a Land of Milk and Honey like the sensationalism around the industry and its high demand for talent as well as high average starting salary might make you think. But there's a lot of computers in the world these days. Being able to make them do cool shit, even if I'm the only person who thinks something is cool, is pretty rewarding.
This page brought to you by Stephen Hara.