by Alexander Kallaway
How to Get a Developer Job in Less Than a Year
Speed Up Your Learning
What is the most difficult part for someone who decides to teach themselves to code? The fact that they usually don’t know what to learn — what programming language to choose, how to approach learning, which resources are the best in terms of time efficiency.
It all starts with Google searches on those topics, which inevitably lead people to one of the many resources that teach people to code. The format of those resources varies greatly, and common sense tell us that we should try a bunch of different resources, and choose the ones that best suit our learning style. Tutorials for some people, screencasts for others, articles for yet another group, etc. Seems pretty logical, doesn’t it?
Well… no. Today I want to convince you that one of those formats of learning will get you to where you want to be faster than any other. With no further delay, let me tell you what it is and why you should focus all your efforts on it.
I bet you saw that one coming.
First of all, let me get some of your objections out of the way. I am not saying you should drop all the other types of learning resources altogether.
All the tutorials and screencasts have their place under the sun, and I will elaborate on that further in the article. For example, sometimes the most effective way to get introduced to a new technology or a framework can be reading an article or going through a tutorial.
The problem is that we tend to stick (or at least I do) to the resources that keep us in our comfort zone, even when it is time to do something of our own. It is just all too convenient, ready for consumption. It also always makes us feel great, because hey, here we are, learning! Right? Who can say that we are wasting time? How dare they? We are filling the gaps in our knowledge!
It’s dangerous that it may seem to us that these resources are also the most effective way to learn. As humans, we can justify pretty much anything that keeps us within our comfort zone. I’ve been living in that illusion for quite some time.
Knock, Knock, Neo.
Creating projects… what’s new about this idea? Nothing, and deep inside, we all know that it would be the best use of our time and energy, and would get us to our goals faster. So why don’t we do it? Resistance.
I’ve talked about the Resistance in my previous article (read it if you are struggling or if you feel stuck), so let me explain why I am so adamant about this topic, and let me convince you to shift your focus (unless it’s already there) to building.
Like Neo in the Matrix, who is given the choice between the red pill and the blue pill, we can return to our illusions that the resources that are holding our hand all the time are the best way to learn, or we can take the red pill and embrace the reality that we only move forward and grow when we are out of our comfort zone. (If you haven’t watched the Matrix, you should probably do so.)
Here are some of my thoughts on how to approach these projects, which can be intimidating to start, as well as some tips I’ve picked up along the way.
It may take you even less than a year (What?)
The reasoning behind this is that based on my personal experience, on talking with the members of our Free Code Camp Toronto group, and on reading about the journeys of the members all over the world.
I find that most often, people are able to find a job even before they finish Free Code Camp’s Front End Development certification. They build the projects required, and start applying. Soon enough, they get an offer to code for money.
If you read through Free Code Camp’s subreddit you will find there are a lot of stories like that.
Note that job markets vary from city to city. In Toronto, for example, there are a ton of front end developer job openings.
Free Code Camp’s official position is that you should complete all 2,080 hours of the curriculum. You will probably be a much stronger candidate (and command higher salaries in more challenging positions) if you do so.
Let’s do some math:
Front End Web Development certificate with Free Code Camp takes around 478 hours. There are people who complete it faster, but it varies depending the level of person’s preparation, so let’s keep 478 as our base.
What’s less than a year? For the sake of the argument, we’ll work with 9 months. 9 months * 30 days gives us 270 days.
478 hours / 270 days is roughly 1.8 hours per day. That means we can code less than for 2 hours a day and in 9 months we can become job ready.
I know that for some people the schedule doesn’t allow for two spare hours a day, but for most, it’s possible to find them. For others, it might take a little longer, but there are always weekends and other ways to find (or make) the time.
If you are looking for advice on how to find time to code, don’t hesitate to reach out to me on Twitter and I will be glad to help.
I took a bit longer than that — about one year and two months. This article is the analysis of the reasons why it took me longer than it should have. I’ve made all the mistakes that I am talking about in the article. When I give you advice, remember that I am giving that advice to myself as well. We are in the same boat.
I got hired before I could finish the Free Code Camp Front End curriculum, but I know for a fact that it will help me grow as a developer to get back and finish those projects. Here in there in the article I’ve placed links to my Codepen profile (I am a bit ashamed of it!) and when you take a look at it, you will see that I still have a long way to go. So I say — let’s do it together! I am making it my goal to finish all the Front End projects, and to make them my priority over anything else code-related I learn in the near future.
This article is for me and for you — to make us push through the discomfort and optimize our learning so we can get to where we want to be faster!
Make sure you’ve covered your basics
An attempt to build projects right away without that knowledge would be too frustrating. Make sure you don’t spend too much time at this stage, as it is very easy to do.
When I was learning HTML/CSS/JS, I would go and learn similar topics from different resources, thinking that somehow that would fill all the gaps in my knowledge. It did fill some gaps, but at some point I’d realized I was using these resources as a crutch to keep me from moving to new, more exciting, but a bit scarier stuff. Don’t get stuck in endless loops (probably a while loop? ;) of reviewing and revisiting the information you already know.
Don’t give in to rationalization
When you start creating projects, you will inevitably get stuck. If you stick with it, after a while you will overcome the barrier, but soon thereafter you will hit another one. It’s not an option, and it happens to everyone.
In such moments every part of our body is screaming — let’s do something else, let’s run from here, this is making me feel uncomfortable, I can tackle this later when I know more, I will get back to it, and so on. So we take a pause.
However, we are afraid that our pause is going to stretch and we will just continue to code less and less and drop it. To not let that happen, but still keeping our “decision” to not work on the project, we decide that for now, we will work through some tutorial or an online course.
It’s very easy to rationalize yourself out of creating. Nobody will tell you are not learning to code or criticize you in any way for doing that. You are the only one who can identify what’s really going on (fear, risk aversion, resistance) and make a decision to stick to working on the project.
Trust me, all the walls will crumble if you bang on them long enough. Think of the people who, back in the day, were learning foreign languages by having two copies of the same book in their native and target languages. How did they do it? They just stuck with it long enough.
Don’t start with your BIG IDEA
It’s amazing that you already have it, but there are some other considerations at play here that may change your mind. The reason I bring this point up is that I keep hearing this a lot from people: “I want to build an online application that lets people create accounts for their pets, upload photos, track locations, and many other things. I’ve recently started learning to code, and I am already in the process of building out my idea.” This makes me go “Whoa whoa whoa”.
What I can easily see happening in this situation is that a person gets overcommitted to the idea, they start very enthusiastically and slowly build it out, but as the time goes, their learning can’t keep up with the project’s demands, and it feels dragging, always at the back of their mind, unfinished.
The worst that can happen in this situation is that the person will give up on the project and with it give up on coding as well.
I recommend starting with simple projects, and as you finish each of them, you will get a feeling of accomplishment, and a better understanding of how to structure a bigger project.
Imagine you were a writer and you had an idea for one major book of your life, and you’ve started writing it right away. You would probably have to rewrite the whole thing 3–4 times to get it to a decent level of quality, whereas you could start with writing small stories, get feedback, improve you writing, and approach your Moby Dick when you are truly ready.
Where to get ideas for projects
The best place I know is Free Code Camp. That’s what I used after being completely stuck. In the beginning of my coding journey I would ask all the developers I knew (both offline and online) what should my first project be. I kid you not when I say (surprise surprise) they all said it should be a To-Do List app. I honestly think that if we keep making these To-Do list apps they will soon overcrowd the whole Internet.
It is the strongest starting point I know to get you building. For all of the projects you finish you can get feedback from the community, as well as see how others have approached them (after you’ve built yours, no cheating!) For extra inspiration you always can Google “list of cool code project ideas” or something of this sort.
Structure your project first
Before you start building, write out what you want it to do. Have specific user stories written, for example: “Users can play audio when they click on the audio player button”, “Users can log in using their email and password as well as just using Facebook”.
Your code has to have a basic structure too, before you begin writing it. Write in pseudocode — basically just explain in words what each part of the application or the project code will do.
// When user opens a page, grab their location
// Send a request to the weather API site with the location
// Receive data
// Display the degrees on the page
// Change background image of the page to reflect the current weather
Don’t overdo it, there is no need to write out every little thing your code will be doing in pseudocode first, but do have the main parts laid out.
The best example I can provide you with is: remember when you were writing essays in school, you had to structure them first, for instance, an intro with your opinion on the subject, 3 main points in support of your opinion, and a conclusion.
This will help you anticipate potential problems and improve the quality of your code.
It’s okay to get stuck
As I mentioned before, it’s okay to get stuck. It doesn’t mean we are stupid, it just means we don’t know yet. You will always experience the moments of getting stuck: not just when you are learning, but at work too.
The sooner you get comfortable with being uncomfortable, the better. It will make your progress that much faster. Programming itself is creative problem solving. If there are no problems that are difficult for you to solve, it means you are playing it safe. Stop treading in the shallow water and take a dive!
Most of all, and I will repeat this again, don’t think of yourself as stupid. I know it is easy to do in these moments. I often talk to people who went through the HTML/CSS/JS part of Free Code Camp with ease, knocking out 30–40 items a day, and then they get to basic and intermediate algorithms and find out that they can only do 1–5 a day, so they come to a conclusion that they got stuck and that they are stupid, not good enough, or not meant to be a developer.
I was the same way as well, I felt like there are people probably who just fly through this section and I felt bad about myself and my progress. Now I know better.
What I am trying to say here is you should learn to:
Be in over your head
You have to find that level of project difficulty that keeps you right in the middle between the “things that are easy” and the “things that are still too hard.”
I’ve talked a lot about the reasons why it’s dangerous to keep reviewing and relearning the same material (the easy things), so let’s talk about the opposite side of the equation: the difficult things.
Your general rule when approaching something difficult — something you think you might not be able to do —should be to try doing it first.
Start from the basic structure, and try to code it. If you are stuck on the same thing for more than three days of focusing on it, drop it for a while and find similar — but a bit easier — things to do.
What I find is that after I do that, my subconscious mind is still focused on solving the problem I got stuck on. I get these random ideas on how I might solve it when I am doing simple things — like taking a shower or washing the dishes — it suddenly hits me!
Sometimes it works exactly that way. Sometimes it doesn’t. But the main advice here is — always pick something that makes you a little uncomfortable. Anything else is not worth your time.
I want to share with you one of my absolute favorite words:
Resilience — the capacity of a system to tolerate disturbance without collapsing, to withstand shocks, to rebuild itself when necessary, and to improve itself when possible.
This is an amazing quality that you as a programmer (and as a person looking to succeed in life) should work on developing in yourself. Prepare for all the problems, all the challenges, all the criticisms of your work, of your designs, of your solutions, and anything else you might do even before they happen.
Are you afraid of being on stage? Sign up to teach people in your local community the basics of web development, or sign up to speak at a conference/tech event.
Are you disappointed in how your interview went — and that you didn’t get hired afterwards? Are you afraid that it’s too late to start learning to code? Aren’t happy with the project you just finished?
Reframe all of this: what can you learn from the experience to make it better next time? How can you turn your weaknesses into strengths?
For example, you might worry that you are coming to coding too late after having been on another career path for X number of years. Reframe that in your mind by thinking about a different perspective and maturity you will be bringing into the industry that desperately needs more mature people (psychologically) and more diverse backgrounds? You are making the tech industry richer by the very decision to get into it!
If you hear a voice within you say ‘you cannot paint,’ then by all means paint, and that voice will be silenced. — Vincent Van Gogh
What I can recommend for increasing your resilience is these three books:
- “Letters From a Stoic” by Seneca
- “The Obstacle is the Way” by Ryan Holiday
- “Turning Pro” by Steven Pressfield
Set a daily time-bound goal
In order to progress faster, you should work on your projects every day. That part is just common sense. However, there are some additional considerations that you should keep in mind.
Instead of setting an outcome goal (“I will finish this feature or that part today”), set a definite period of time which you will spend coding every day. Don’t make it more than 30 minutes or an hour per day.
I know you want to make a commitment of coding for 3 hours a day and try to stick to it. This works, but only for so long, until life comes into play. With a reasonable time limit — like 30 minutes a day — you will always know that it can be done, and that you will always have half an hour a day to spare on coding, especially if your main goal is to learn to code. You will even find yourself coding more on certain days, and that will feel great, because you will already have fulfilled your quota for that day.
This time limit is more of a psychological trick that works because of the way our brains are wired. Remember that time you had a big project that you needed to start, but you kept delaying and delaying until you just had enough time to finish it before the deadline? You did OK, but you were stressed out all the time prior to that. Then add to this the fact that there is no one to set you a deadline on becoming a developer. That is, no one, but you.
What happens when we set an outcome goal is that we can’t estimate the time it’s going to take to finish that or this feature. And more often than not, we end up not accomplishing what we’ve set out to do for the day. That makes us feel terrible, and decreases the desire to sit down and code the next day.
With a time-limited daily goal, you will make progress every day. Who cares if you haven’t finished that specific feature you wanted to wrap up today? You’ve made progress! You showed up. That’s what gets you ahead.
Another great bonus is once you sit down and start coding, ideas and solutions will start flowing, as if out of nowhere (similar to writing an article, huh? :). It will be much easier to get yourself to sit down and code once you get unrealistic expectations and fears out of the way.
Copying code is wasting time
During the process of building a project, either at the very beginning — when you don’t know where to start from, or at a later stage when you hit a problem you can’t easily solve — you will experience a strong desire to look at the source code of the project to see how it is done. You will rationalize that it will make you instantly understand the code, and that means you’ve learnt and assimilated it. Far from it.
Don’t copy whole projects and customize them. Don’t take parts of the code. Don’t even take pieces of it.
With projects — don’t look at the code in the first place. With the stuff that you looked up on Stack Overflow and such, look at it, analyze, understand, but then code it yourself from scratch. You will see that it’s difficult to write it yourself even after you just saw the whole thing.
This is how deliberate practice is different from regular practice (repetition). The 10,000 rule’s main catch is that the practice has to be deliberate. Following templates and ready-made solutions will not take you anywhere. Someone probably would be able to write a Python script that will replace you in whatever it is you are doing, if you go that way. Pay attention to what seems difficult for you.
Another off-topic idea is that if you struggle with a particular topic, try teaching it to others, or just even explaining it to them the way you understand it. Results will follow for both you and the learners.
Copying code will rob you of the opportunity to learn to do it yourself, and it is in no way better than going through a tutorial. Yes, the solution is right there. Yes, you can take it if you want to. But what’s the point? Are you trying to impress someone with the speed with which you’ve built the project? Or are you trying to avoid the hard problems that will take some time to solve?
Whatever your reason might be — it is just another way back into the warm comfort from which we are trying to escape from. Do the opposite. Run toward the discomfort.
The only time it’s OK to peek into other people’s code is after you’ve finished the project. Then look as much as you want, analyze it, and learn from it.
Every difficult problem you solve makes you grow by leaps and bounds.
Don’t spread your efforts around
I am very guilty of this, and that’s actually a piece of advice I am writing more for myself than for anybody else (sorry!). When you start working on a project and hit the walls that I mentioned, you will be tempted to put that project on hold and start a new one.
It always feels great in the beginning, until you hit a wall with the second project. Then you will have two unfinished projects on your hands. This will repeat again and again, if you let it.
The solution here is to limit yourself to 2 projects at a time. Once you get stuck on one, spend some time figuring it out. But if it seems uncrackable at the moment, just move to the other project you’ve got. The key thing is not to start a third one, because it’s a slippery slope from there.
You should always try to do anything possible to make yourself stay on the path of learning. If you feel fed up, or are just bored with what you’re currently doing, take a little break, adjust, and get back to it. Don’t give up on coding altogether.
This is why I always recommend having a little wiggle room, be it a temporary distraction in a form of a different learning resource (limited to a week), or, in this case, two projects instead of one.
Your portfolio is what will get you hired
All of the projects you build and put online comprise your ultimate live resume. Anyone can look at it and be convinced that you actually know what you are doing.
Don’t get scared though, it doesn’t mean your code should be ideal for them to even consider you. These projects will help whoever is tasked with interviewing you to properly assess your skill level.
You won’t have to experience interviews way above your level because some HR person have found a particular set of keywords on your resume. Your employer’s expectations will be more on-par with your actual abilities.
The positive benefits of having your work online include:
- employers see that you know what you are doing
- they see that you are constantly working on improving your skills
- they see that you are, in fact, a developer, and that you are brave enough to put your work online for everyone to see.
From my personal experience, and from what I keep hearing from the people at our Toronto Free Code Camp group is that the most important factor in finding a coding job has been their portfolio of projects.
You will do better at interviews
At interviews, you are likely to get a real life little web app or a page to build, or to be given a problem to solve.
Often with these problems, the person who is doing the hiring is looking to see how you think through solving a problem. They don’t always want you to produce the ideal solution. Sometimes they give problems that can’t be solved just to see what you will do. You will get a lot of practice of that kind with projects: each of them will be filled with these mini-problems.
As for the real-life stuff that you can be given to build, it can and will vary. Here is something I had to build during the interview for my current position. I know the code isn’t that great, but this should give you an idea of what to expect. The only reason I was able to finish it on my interview day was because I had previous experience building things like a weather app and a calculator through Free Code Camp.
You will identify the real gaps in your knowledge
Here is where the tutorials and the like play a trick on you. They make you feel that when you’ve finished them, you’ve covered everything you need to know about the subject. But the moment you try to build something on your own, you’ll instantly get stuck — often on very simple stuff.
Why is that? Because the bits and pieces of information given to you in a tutorial were chosen by someone who created it using their own understanding of what people might be looking for. And because it is simply impossible to cover everything in a tutorial.
The only way to truly see what knowledge you are lacking is to keep discovering the gaps in it as you go. You don’t know what you don’t know. So the process is: go, hit a wall, work through the problem, keep going, and so on.
Every new project scares you. What to do?
I don’t know about you, but with me it happens all the time. I finish a project and feel great about myself and my skills. Then the minute I read the user stories for my next project, I become paralyzed by fear.
I find myself thinking — how can I even start? What should I do first? How was I able to finish the previous one? I know nothing! *Toggle Full Panic Mode*
There are a couple of techniques that I use when I get into that situation:
First of all, take a look at all the previous projects you’ve built. They were also hugely intimidating. Somehow, you found a way to solve the problems and build these projects out.
Looking back on your past successes when you’re in a low self-confidence moment is a powerful method to pull yourself back together, and to get ready for a new challenge.
The key is to look at the project as a bundle of tiny problems to solve. We only get scared because we see the whole iceberg in its entirety, and it’s coming towards us. However, if you use a technique we talked about before — breaking the project down to a basic structure — it will be very easy to get started.
You are not doing this to create some sort of an ideal, amazing project with the code so beautiful it will make experienced developers cry.
The goal is to do what’s necessary: fulfill the user stories that you have been given (or have created for yourself) so you can learn the mechanics of how a certain coding technique/language feature/framework works, be it APIs, functions, promises, etc.
Then do as much as you can to improve the project — both design, functionality and the quality of code.
But at some point, allow yourself to stop. It’s not an international art competition. It’s you and the subject you want to learn. Don’t let the subject scare you so much you can’t even start.
People who have an extreme need to do everything perfectly are usually the people who get absolutely nothing done.
I wouldn’t be able to start on this article, for example, if I spent too much time worrying of whether it would be good or bad, let alone perfect. I knew this was an important topic that a lot of people are interested in, and that I needed to write about what I’ve discovered so far, in hopes that it would help someone and make their coding journey easy.
If everything had to be perfect, would there be any place for sketches in art? Imperfections are what makes them unique, after all.
Let your creativity flow!
Don’t feel like you have to make your project exactly the same as you see on the page, if you are working from a description and an example you found online. Programming is as much art as it is science.
Take this point even more seriously if you are doing front end.
If you are making a Random Quote Machine, let the quotes be from your favorite character. If you are making a game, let the sounds and design be whatever you want them to be!
Be weird. Let all of the quirks and unique differences of your personality out. Unleash your true self.
Focus on fulfilling all the user stories, but everything else is completely up to you.
Here is the Zen Calculator that I’ve built, as an example of what I am talking about. Of course, you can get much more creative. The original is here, though it’s already been updated. The version I’ve worked from reminded more of an iPhone calculator app.
The web — and programming in general — allow us that freedom. Never hold yourself back. Be whoever you want to be, do whatever you want to do, and let that spill to every part of your life, including coding.
Here is something for inspiration, and to illustrate what I mean:
Things only get their flavor when you add personality to them! Compare hyper-realistic painters and Picasso. Could you tell hyper-realistic painters apart just by looking at their work? I highly doubt it. Yet you would know a Picasso painting right away. Makes you think.
Give in to a distraction — once in a while
Sometimes it’s okay to take a little break from the projects, but for that you have to have some rules.
Ideally, your distraction has to take less than a week, be it a course or a tutorial, or anything else. It should be a specific subject you want to learn, preferably connected to something you need to know to continue refining your project.
Otherwise, it’s completely fine with me if you are reading programming books or watching coding videos during your commute, or while waiting somewhere with no access to the internet.
Just make sure that when you are back at your desk (or whichever place you code from — could be a bed or a couch, right?), you are back to the real stuff. It’s your Practice.
Get feedback on your projects
In addition to helping you fill the gaps in your knowledge, projects also give you an artifact which you can share with the world, soliciting constructive feedback.
Be careful whom you share your projects with. Don’t let the over-critical people in. Try to find real developers, or people who are also still learning, but are already a little more advanced than you are. Ask them to review your code and provide their feedback. What you can improve? What works? What doesn’t?
This will further accelerate your learning, because these kind people will help you uncover insights you wouldn’t have otherwise found yourself.
I hope I’ve convinced you by now that building live projects is the most effective way to go about learning to code.
I’ve personally noticed that the periods when I build — as opposed to watch, read, or go through online courses — are the periods when I learn the most. I hope your experience will be the same as mine.
Good luck! Feel free to add your advice in the comments to this article, and share your projects here as well.
Random note: I wrote this article while listening to the Tron: Legacy Soundtrack.
If you liked this article, please click the ❤ to recommend it here on Medium. It would mean the world to me! :)