Over the past decade, I have been through the experience of being a self taught developer, and I have also had to hire multiple developers for multiple companies. In this article I'm going to outline some of the problems that I encountered myself as well as some that I saw other people dealing with.
I first started learning programming when I was in university. It wasn't part of any of my classes; I was just interested. I went to the library and just started grabbing books about any language that I could find. My only criteria was that the book was relatively new. Still, I ended up with books on C, C++, Java, and php.
Everything worked out in the end, but the first 6 months were painful. I would spend hours going through a chapter of a book or some online tutorial, and it felt like I could never quite get anything working. When I would hit a wall, I would switch languages.
This really comes from two things.
First, I wasn't sure at the time that the language could actually do what I wanted. I was finding tutorials, but they were all outdated or wildly complicated. (Try setting up a web application in C++ as your first project).
Second, I felt like another language might be easier. It turns out that this part was very true.
Now that I have experienced this, I know that it's best to research the best language for the topic you are interested in up front, and then just stick with it. I put together a video about exactly this topic.
Whenever I'm hiring a junior developer, I spend a good deal of time looking at their Github or code examples. Often times I'll see a bunch of apps from random frameworks that have very little custom code in them. Maybe they have a slick front-end or something, but the framework is doing all of the heavy lifting in terms of logic.
I will dig into this a bit more later, but I want to hightlight part of it up front.
Much of software development is more about muscle memory than smarts. Muscle memory is a term from sports. It essentially means that you practice so much that during a game, you don't think. Your body just responds to whatever situation is presented.
This doesn't mean that you need to memorize the documentation or anything like that. Googling error messages and function documentation will always be your best friends. However, if you primarily work in a single language (or programming stack), you will develop much faster reflexes and get work done much more quickly.
I have not always made the right choices while learning programming (or when starting a business), but one thing I have been good at is staying consistent.
For all of the years since I started learning, I've maintained a habit of getting up an hour or two early and reading books, taking courses, or working on side projects.
Is this strictly necessary? Maybe not.
Will you be better if you do it? Definitely.
I'm not the most naturally confident person, and putting in the extra work gives me more of a feeling of control. I generally believe that if you push yourself to be the best you can be, things will turn out better.
There are a lot of topics that you will learn in computer science courses that aren't really necessary in the early days of being a developer. For example, I'd avoid looking much into algorithms until you're pretty good at a number of other things.
In almost 10 years of development work, I've had to worry about the algorithm I was using maybe 3 times. And in those instances, the solution was ultimately to use a different, faster tool. This won't be true for everyone on every project, but it will be true for a lot of people.
This may be a contraversial opinion, but I think it's better to get your feet wet doing actual work, and then spend time going deeper into topics like this when the need arises. Additionally, if you do what I said previously and study every day, you'll find that after a while these topics become more accessible and interesting.
One caveat: this doesn't mean you shouldn't care about things like performace. It's just that these days, if you learn a particular framework really well, the best practices of that framework should keep you safe most of the time.
Over the past years, programming bootcamps and accelerators have popped up all over the place. Some of these can cost 10's of thousands of dollars. I've hired people who have gone through them, and I will say two things about it.
First, if you are the right kind of person at the right level, it can be very useful. If you already know a pretty good amount of stuff, and you are looking for a context to formalize, expand, and engrain what you know, it might be great for you. They also tend to help you find your first job, so that could be very helpful.
Second, I've not hired more people from these things than I have hired. Most of the people that I interviewed from bootcamps were not ready for a real job. Again, it probably has more to do with where they were at when they started.
In my opinion, the best strategy would be to push yourself as far as you can go on your own, and then if you feel like you need something like this, explore some options.
On the flip side, you don't want to be one of those people who want everything for free. Spending $29 per month on something like LinkedIn Learning is a no brainer for most people.
Here's the deal.
You're aspiring to learn a skill that can literally pay you over $100k per year, and not that far from now. If you get good at programming, you could be there in under 5 years. (I did it in under 3).
You want to optimize to get there as fast as possible. This is why I said that things like bootcamps might be a reasonable choice. In the end, if it helps you land a high paying job, it's actually worth it. However, avoiding spending money entirely is just absurd.
It demonstrates a fundamental misunderstanding of money and investment. People will spend $30 a week on coffee, but avoid $30 subscriptions that will dramatically accelerate their career.
This actually has a bigger side effect. I've talked with a number of business owners who have had developers spend days to build a solution to a problem when there is a $50/mo subscription that does the same thing. So they spent thousands of dollars from the business (their time working) in order to save hundreds of dollars for the business...
I've never met a serious owner of a growing business that was cheap. I'm not saying that they don't exist, but it's certainly a minority. Just something to think about.
At some point while you are learning to program, you will hit a wall and get stuck. You need to be willing to take advantage of every online and in-person resource at your disposal.
For example, no matter what level you are, don't be afraid to post a question on stack overflow, and don't be afraid to attend local meetups. There is no feeling worse than being totally stuck and having no way to move forward.
Everyone was a beginner once, and if someone puts you down, that says more about them than it does about you.
I'm not going to say that it's impossible to get a job if you live in a small town. It's not. But you are choosing a very difficult road if you decide to live in the middle of nowhere.
Once you are established, this becomes much more possible. But if you are a junior developer with no experience, you're going to have a very hard time for a number of reasons if you stay in a small town. When you're serious about launching your career, it's worth considering a move to a bigger city -- at least for a little while.
Remote work is on the rise, and I'm a fan. But speaking from personal experience, cities just present you with many more opportunities for work and connecting with others.
At some point, it becomes important to develop an understanding of different programming paradigms and design patterns. That point is not at the very beginning.
I went to an object oriented programming workshop a while back, and one of the instructors recommended a book on design patterns. Then he told us, "After you read it, you won't be allowed to code for 6 months."
His point was that when you start learning certain topics, it can cause you to dramatically overthink things. It's useful to periodically study these topics, but in the beginning, it's better to just follow some basic guidelines.
For example, Sandi Metz has a four rule system that I've found helpful when working with Ruby:
1. Classes can be no longer than 100 lines of code
2. Methods can be no longer than 5 lines of code
3. Pass no more than four parameters into a method. Hash options are parameters.
4. Controllers can instantiate only one object.
Whether you choose this or something else, having a simple set of guidelines is extremely useful. Your code won't be perfect (it never will be), but it will be cleaner than if you have no guidelines.
(This is a bit related to the very first point I made, so I'll keep this brief.)
It is good to learn new tools, but there is a balance. You don't want to be the person who knows just a little bit of every framework.
A good rule of thumb is to have a few go-to tools that you spend 90% of your time becoming an expert in, and then spend 10% of your time exploring new things. The 90% should center around things that have wide adoption. Think NodeJS, React, Ruby on Rails, etc.
When I review an applicant's Github, I immediately jump into areas of the code where business logic tends to reside.
There is a big difference between being able to wire together pieces of a framework and being able to solve problems with code. I personally like to see that a good amount of energy is going toward moving beyond basic CRUD operations.
As an example, one of my long-time projects has a good deal of code that models how certain types of biological cells change over time. Other examples include things that are more process oriented--like rules around when different users should receive notifications or emails.
If you're just getting started, the real trick here is to push your personal projects past the point of just being a quick demo. This even applies to things like blogging apps. Sure, you can create a blog in Ruby on Rails in 15 minutes. But take it a few steps further. When someone comments, who gets notified? What are the rules around that? What is the process for publishing an article? So on and so forth.
Fear of failure. Imposter Syndrome. Worrying that you're not smart enough.
These are all things that many people face when they want to embark on something technical for the first time.
Should everyone learn to code? Probably not.
Can they? I would say that most people have the capacity to learn if they have the right tools and enough patience. That said, believing you that can do something is at least half of the battle--so you might as well just believe in yourself.
When I used to hire junior developers, I'd typically ask at some point in the interview process what hourly rate or salary they were looking to receive. Keep in mind - this was in NYC.
I frequently had people tell me things like $18 per hour.
The first time I heard this, I was a bit startled. That is way too low.
This means one of two things: you're not very good and I shouldn't hire you, or you don't actually know how much you're worth. Since it's hard for me to figure that out in a quick conversation, that was typically an automatic disqualifier.
For some context, my first freelancing job (after 1 year in the corporate world) was at $75 per hour. The client was happy to pay and commented that they thought it was very reasonable.
Setting rates and charging clients is a complicated topic that could merit it's own article or series, so I'll just leave you with a few pointers.
First, do some serious homework. Find out how much people in your area typically charge for whatever it is you are doing.
Second, ignore places like Upwork when it comes to pricing. (By the way - a secret of Upwork is that many times, people who charge more get more clients. I know this from both working and hiring.)
Third, decide how valuable you want your time to be, and work to make it happen. In the past couple of years I've had clients that paid between $150 per hour and $300 per hour - depending on what I was doing. It's not easy to get to that point, but it's also very doable if you have the right work ethic.