Jason C. McDonaldI did an Ask Me Anything over the weekend that turned out to be incredibly popular; it's already my fourth most read DEV post...
I noticed that a lot of the questions were along the same lines: how to get started as a developer. I decided to expand on my answers in a dedicated article.
These are the same steps I took to becoming a developer. I have no college degree, no bootcamp certificate, and precious little formal training of any kind. Yet today, I'm an experienced programmer in Python and C++, a lead developer, an internship supervisor, a debugging expert, and an author of programming articles and (now) books. I am by no means unusual. A surprising number of developers have taken "non-traditional" pathways into this industry.
Whether you're in college for computer science, attending a bootcamp, or just teaching yourself in your basement, these tips are for you. This is the definitive guide to becoming a software developer, no matter what path you're on!
1: Learn A Language
This is perhaps the most painfully obvious item on the list. Programmers write computer code, so you have to learn to speak the language.
However, it doesn't matter what programming language you learn first! It all depends on what you're interested in. For example...
If you want to get into web development, you should start with JavaScript or CSS (yes, nerds, CSS is Turing-complete!)
If you want to build user applications, Python, C#, and Java are popular entry points.
If you're interested in systems development (such as operating systems), look into Rust or C++.
If you want to play with data analysis or statistics, start with Python or R.
Haskell, Ruby, Go, and Perl are other popular languages.
If you have absolutely no idea where to start, pick up Python! It is considered one of the best languages for beginners, and it provides a solid foundation for learning virtually any other programming language later.
06:05
4 Reasons To Stop Caring About Picking The “Best” Language / Framework To Learn - Read or Watch
Matthew Collison for Skill Pathway ・ Aug 6 '19
Check out the Recommended Reading section at the end of this series for a list of excellent learning resources.
I Want To Learn Everything!
Don't. No one will ever know everything about programming. There will always be languages, tools, algorithms, libraries, and concepts that are foreign to you.
Even developers who have been at this for decades are continually finding that the sum total of their understanding is only a tiny drop in the ocean of knowledge in this field.
If you think about it, this is a good thing! No matter how long you work in programming, you'll never run out of new ideas to explore. There is virtually infinite room for growth.
I was in a job interview recently where I was asked to describe the difference between TCP and UDP. My heart skipped a beat for a moment, because I didn't know the first thing about it. Then, I took a deep breath and gave this answer:
I've had to come to terms with the idea that I can't know everything, as much as I'd love to. There is so much I could study, but if I'm honest, most of it is going to decay in the back office of my mind due to lack of use. I've had to adopt a policy of not learning most things until I need them for the project I'm working on. Thankfully, it only takes me a few minutes to do this, so it works out well.
Based on the positive response I got, I can safely say that was the right answer.
2: Write Code
Theory is all well and good, but it means absolutely nothing until you put it into practice.
I often compare programming to swimming: you can read about swimming all you want, but it won't mean a thing until you jump in the water. Furthermore, if you only stay in the shallow end, you'll never become proficient. You NEED to dive into the deep end as soon as possible.
Thankfully, in programming (unlike swimming), you can't actually drown. Oh, sure, you're going to feel like it at first, but this is a good thing! As you struggle through your first experiences with coding, you will eventually find things starting to "click". A bit of frustration is actually beneficial to the learning process; it helps things stick.
In my own journey, I've learned exponentially more from the hard-won victories than from the easy ones. I've had many times when I was up against a seemingly unsolvable problem, an impossible bug, an infuriating mental block...and each one of these instances has become an anchor line for me! I can remember each one. Most of my expertise came out of these experiences.
So, just start coding. Research things as you go. Learn new skills when they become needed. Ask lots of questions.
What Should I Code?
Many developers ask me, "What should I work on?" There are three major ways you can gain experience coding:
Create a project for yourself.
Make it something simple, something you'd personally use. No one can come up with this project for you. It should solve a problem you're acquainted with.
YOU must be the target user! That ensures you have both the knowledge about the problem to build it, and the passion and drive to stick with it.
Contribute to open source software.
Once again, find projects you personally use or care about. Don't worry about not knowing enough. Just dive in!
Start reading code. Clone the repository and build the project. Try to fix small bugs or make little improvements. Help with the documentation.
If you think you've made an improvement to the code, don't be shy about creating a Pull Request. Even if it's rejected, you will have learned more about programming, and proven yourself willing to help. That active willingness means far more to an open source maintainer than a hundred bug reports.
Reinvent the wheel.
Are you trying to understand linked lists? Heap sort? Form submission? Build it yourself!
The goal here isn't to create something production-quality. By coding, you're mastering the underlying concepts of the thing you're learning. This is literally how I gained all my expertise in data structures.
Unfortunately, some detractors will try to tell you that you shouldn't "waste your time reinventing the wheel." Ignore them. Anyone who will tell you to "just use" something pre-built as a substitution for learning how things work is at best lazily ignorant, and at worst a saboteur to your growth as a developer. Often they're just trying to justify to themselves their own decision not to learn more.
What If My Code Is Terrible?
You are going to write terrible code, and that's okay. The point isn't to be perfect, or even good, at this stage. Your only concern should be in writing code that eventually works.
I like to tell new developers: if reading code you wrote three months ago doesn't make you slightly ill, you're doing it wrong. In other words, you should be continually learning and growing as a developer, such that the quality of the code you write one day is always better than the day before.
3: Read Code
Anyone who is studying English would read great books in English. In the same way, anyone who is studying programming should study great source code.
Unfortunately, this is often overlooked because it's just so intimidating. How do you find good code? What if you encounter things you don't understand? What file in a project should you even start with?
In terms of finding a project, GitHub Discover is a great place to start. Skim through the popular repositories. Find one written in a language you know or are studying. It's ideal if you find a project that you use, or which is about a topic you find interesting, but that's not essential.
Once you locate a project, browse through the file structure to get an idea about how the repository is laid out. This is more important than you might think! Don't worry about finding the "beginning" of the program. Just look for any file the right file extension indicating that it's code in the language you're interested in.
I personally like looking for files with interesting looking names. What do you suppose bubbles.py does? How about alarm.h? Let's find out!
Once you find a file to study, download it to your computer. Open it up in a code editor, and comment your way through it. Write a comment for every single logical statement describing what it does. If you don't know, research it, or mark it as something you're curious about and come back to it later. Type out your questions as you go. This is your own personal copy of the code. You can do whatever you like to it!
If you encounter statements that import code from other places, don't worry about finding that code right away. Start with the file you're on, and see if you can figure it out without knowing about the other files. You can always go back and read more later!
When you're all done, don't sweat it if you didn't understand everything. You will still have picked up some new knowledge. If you make a habit of reading code, you'll find yourself getting better and better at it.
What If I Find a Possible Error?
This is the icing on the cake! If you are reasonably sure you found an error, clone the entire repository onto your computer and try to fix it. One of three things will happen:
1) You'll discover it wasn't an error at all, and you'll have learned something new.
2) You'll confirm it's a bug, but will only manage to break stuff in trying to fix it. Don't sweat! You can still report the bug, and you'll be able to point the developers to the exact code that's broken. If you're right and they fix it, you can study their bugfix. If you're wrong, you'll still learn something new.
3) You'll fix the bug, create a PR, and make the project better. How cool!
In the next section, we'll explore some surprising skills beyond coding.
