Whoever will be free must make himself free. Freedom is no fairy gift to fall into a man’s lap. What is freedom? To have the will to be responsible for one’s self.
– Max Stirner
In the grand scheme of things, a person can never claim all of their success is entirely their own. We have teachers, peers, and mentors from all walks of life that we draw our knowledge from. I owe a lot to where I am now in life to the amazing web developer community that shares educational content freely, whether that be in the form of blog posts or videos. I feel forever indebted to this kind community that goes out of their way to help others. I write this blog post as a way to pass on the knowledge I gained and in hopes that my first hand account of going from zero programming skills to full-stack developer helps you on your journey. Shall we begin?
Where should you start?
I’m going to start off with the assumption that you have no experience writing code at all. There’s a few different routes you can take here.
- Go to a traditional school
- Go to a bootcamp
- Become self-taught
- Combine all of the above
I started my journey into tech when I decided that I didn’t want to work in sales anymore. I didn’t see much room for growth in sales and I saw year after year how e-commerce companies were beating brick & mortar stores so I decided to embrace change. I didn’t know anyone who was in tech so I did the obvious thing - I enrolled in college. The tl;dr here is that I finished my A.A.S in Computer & Information Systems and learned strong fundamentals of programming and I.T but in retrospect I feel like that time could have been better spent diving right into web development and making projects.
You might think going to a bootcamp is a better option then since they’re usually between 3 - 6 months in length. The downside is they cost A LOT and if there’s no upfront price, they usually take a cut of your salary when you do get a job. And if for whatever reason you don’t get a developer job, you’ll still be paying them back. Unless you’ve really done your research and are willing to spend a good amount of money I can’t recommend going to a bootcamp. I think if you’re willing to teach yourself that there are countless of free (freecodecamp, youtube) or very cheap (udemy, egghead) alternatives.
How should you structure your time?
Once you’ve settled on a course or MOOC of your choice, the most important thing will be consistency. You should expect to spend at least 9 months to a year of studying/practice before you should be ready to look for work. If you’re working full time it might be difficult to code 8 hours a day and everyones life situation is different. I’d recommend setting out at least 2 hours a day to code in a distraction free environment and being deliberate about what you’re doing. That’s why following along a course is great because someone is providing you structure. Otherwise you might be hopping around from subject to subject while your progress is only superficial. If you can afford more time, that’s even better. It’s incredible how much a person can achieve if they structure their time and use it wisely.
Once you’ve gone through an introductory course your main focus should be on building things on your own. I can’t stress this enough, it’s very important to take the training wheels off. You can take a look at the search results for the term “tutorial purgatory” and see there are countless articles and videos talking about this pitfall. It’s a real thing to be aware of and it happens because we get comfortable. It’s hard to leave the comfort zone but it has to be done in order to cultivate what I believe is one of the most important traits a developer needs to be successful.
Embracing Ambiguity
Embracing ambiguity is one of the most important traits you can adopt. For example, now that you’ve followed along a few courses you should aim to build something with real world utility as either a project for your portfolio or for a real client. This project is going to be a lot more complex than what any one course will teach you. At the time, you may not know how all the pieces fit together but you can start researching. Look for other examples, use diagrams to architect your project, read all the documentation, and most importantly write the code. If you just show up in front of your laptop and try to make things work I promise you after enough time things will start to make sense and they will work. The satisfication you’ll derive from building your own project will be great and you’ll embrace ambiguity.
You don’t need to know everything. In fact, you can’t know everything. It’s okay to start a project and not know how every piece of it will ultimately fit together and work. You have to go through the process of learning through documentation and experimentation. You can write code and if it doesn’t work its okay - all that will happen is you’ll get an error, it’s not the end of the world. That error has a silver lining though it means whatever you’re doing now can be ruled out as an option and you have the chance to correct it.
Being okay with ambiguity ties into what developers really get paid to do and that’s being creative. Innovative solutions are creative solutions and that means embracing the unknown and all of its infinte possibilities.
When should I apply?
You might think you should apply only after a specific amount of time has passed. The truth is, we all develop at different paces and have different life situations. I think if you can build CRUD applications with your eyes closed (this is a metaphor) and can explain every step of the way comfortably you can start applying. There’s a lot of soft skills required and no matter how much interview prep you do it’ll never be exactly like the real interview. Expect to put out a lot of resumes but also expect to hear back from recruiters and companies too. Even if you hear back from places where it seems obvious that you won’t get the job (somewhere that wants 5+ years experience for a junior dev or requires knowledge of 10 different skills you’ve never heard of) you should still take the interview. It’s going to be great experience and you’ll learn a lot about what to say and not say, how to present yourself succinctly, and you’ll gain insight into how you can improve.
You should never look at a failed interview as a bad thing. It’s just another chance to succeed. In essence, it’s no different than dealing with an error in your console. You simply need to figure out where to improve and it will only be a matter of time. I hope you found this article helpful. I will keep updating it as I grow and gain more insights. Take care of yourself and remember you can do it if you sincerely try.