My Journey into Tech: A Self-taught Developer
Hi, I’m Shaquille, a self-taught, Junior Web Developer living in London, England.
If like I was, you’re just starting out and you have some interest in coding, but are finding the different languages, job titles, jargon, and paths you can take a bit…overwhelming — well, then, this is for you. If you’re somewhere along the way but haven’t yet landed your first role, this is also for you.
I aim to break that all down and provide the entire route I took in my transition to tech, in the hopes of making the process less daunting.
What is a software developer/engineer? What do they do?
First things first. What is a Software Developer? What is a Software Engineer? How are they different? What do they do?
You can scour the web for definitions and differences, but as a beginner, I think it’s best to keep it simple. A developer, by definition, is someone who develops things…creates them, and causes them to grow/mature/improve. An engineer, by definition, is someone who designs, builds, and/or maintains things. I’m sure you can already see the similarities.
Now imagine this in relation to software. Usually, it’s a website, an app, or an API (more on those another time) being developed/engineered.
So, some may disagree, but for simplicity, I will say that the titles “Software Engineer” and “Software Developer” are pretty much interchangeable these days. If you really nail down, by definition, there are differences, but the lines are so blurred that it’s not worth worrying about at this stage.
There are so many differing job titles. It’s confusing! Which direction do I go in?
Ah, job titles. I feel that as a beginner, there are so many that it can be overwhelming.
Think of “Software Developer/Engineer” as umbrella terms for the following:
· Full Stack Developer/Engineer
· Front End Developer/Engineer
· Back End Developer/Engineer
· iOS Developer/Engineer
· Android Developer/Engineer
· Web Developer
All of these jobs entail very similar things. The main differences are the programming languages used to achieve them.
For example, a Web Developer works on…well…websites. Whereas an iOS or Android developer works on…you guessed it…apps! More on the others later. The key is to remember these are all similar jobs, using similar skills, and a similar way of thinking. But from now on, I’ll be using “Software Developer” as an umbrella term unless otherwise stated.
Now that’s out the way, where do you start? Well, I can’t help you there, as that’s entirely up to you. There are a plethora of roles that require knowledge of programming languages, it’s not just software development. Data analysis and machine learning being examples. It’s up to you to decide which route to take, but I will tell you which I took, and why.
Front end vs back-end vs full-stack explained
Before explaining more of my journey, I’d like to circle back to the three job titles that I mentioned earlier. For me, the easiest way to think about it as a beginner is this:
The Front-end concerns everything that a user can see and interact with. For a website or app, it’ll be the user interface and user experience. Ensuring that visitors can easily interact and navigate through the page whilst ensuring that it looks appealing. Buttons, links, images, videos, colours, fonts are all the responsibility of front-end developers.
The Back-end concerns everything that a user does not see and interact with. The technology required to power the software such as logic, scripts, databases and APIs. You may not know what these all are yet, but what’s key is that the back-end is the foundation of the software and it often helps provide most of the security.
The Full-Stack is the combination of the two. So, as you can imagine, Full Stack engineers often know how to work on the front end and the back end. Many have a preference to lean towards one or the other, but the point is that they’re completely capable of working on either.
Hopefully you’re still following! If not, don’t worry it can take some time to really settle in, but you’ll get it! It may be slightly easier to follow by thinking of it like a restaurant:
These three areas often require you to know different programming languages. I won’t list them, as there are too many to list, but I will go on to mention a few resources where you can figure out what’s best for you to start with for you.
When starting out, I had just been made redundant. It was the summer of 2020 at the height of the pandemic. I had been considering the switch since that March, around the time when lockdown began. So, I decided it was time to take the plunge.
I’m fortunate enough to have a few friends in the industry. So, after having done quite a bit of research myself, they were able to break it all down and suggest potential routes. I should emphasise that there are many ways to learn. Free courses, paid courses, bootcamps etc. I wouldn’t necessarily recommend any one over the other, but I would stress that you can definitely learn 100% of what you need to know, for free and you don’t need to pay unless you’re sure it’s the path you want to take. A list of the resources that I used most will be listed at the end.
This course took me 5 months and I would study Mon-Fri, 8 am — 4 pm, so that’s a rough estimate of a timescale for you. Some of it clicked pretty quickly, some of it…didn’t.
One thing I can’t stress enough is consistency. Imposter syndrome is completely normal. Errors in your code are normal. Googling everything is normal. These are things developers deal with on a day-to-day basis. It’s what continuously learning entails; feeling like you know nothing until, suddenly, it all clicks.
The best advice I can give is if you know you enjoy it, keep plugging away!!
Regardless of which route you take, after gaining sufficient knowledge, it’s time to switch focus. Portfolio. Projects. GitHub. CV. LinkedIn.
Your portfolio website is key, especially as a self-taught developer. It’s the first tangible thing that recruiters and employers use to assess what you can do. It’s the place where they can go to see your skills in action, learn a little bit more about you, and see your projects all in one place.
My portfolio was my first true solo project. It was the first opportunity that I had to get truly creative and build whatever I wanted to with my code, which was great. My portfolio has come a long way since then, but the foundations were set early on, so I’ll link it towards the end as an example for your future endeavours. There are also lots of good examples on YouTube, where they review the portfolios of self-taught developers and point out the positive and negative aspects.
After building the portfolio website, I began working on projects to display on it, whilst also applying for jobs simultaneously.
Applying for jobs can be draining at the best of times, but your first one as a developer will be the hardest to get. After that, I promise — the recruiters will be messaging you!
For this, LinkedIn is your best friend, and for getting your CV and LinkedIn up to scratch, Danny Thompson will be. Danny is a Software Developer, based in the US, that uses various platforms to provide free advice to help as many people as he can transition into tech. He most certainly helped me. I used his YouTube and Twitter in particular, to assist me with what was required to bring my CV & LinkedIn profile up to the appropriate level for a Junior Dev. He also has a discord channel and, of course, a LinkedIn profile. I’ll leave all of his info below as I cannot recommend him enough.
In regards to projects, advice varies, but I would recommend at least 3–4 solid ones.
My first project on my portfolio was the one I was most proud of from the Codecademy course — A Spotify Playlist creator. I used this despite it being part of the course (meaning anyone else that’s done the course could use it, and employers had probably seen it before), because I felt I understood it completely and could talk about it in-depth if asked in an interview.
For my second project, I created a Space Invaders game using a YouTube tutorial by Ania Kubow, whose channel I will link below as she has a vast array of fun tutorials for beginners. Once I’d followed the tutorial, I began adding to the game. This was key. I added levels to the game, styling and font, to really try and cement my understanding and solidify some key concepts from the course and the tutorial.
Finally, having used a project from my course and a project from a tutorial, I decided to see if I could build an existing web page from scratch. At complete random (and being a Londoner), I ended up deciding on a page from the Transport for London website. I chose it because it had a Google map and an address finder using postcodes, neither of which I’d added to a website before, so I knew it would be a challenge.
The projects which force you to learn new things will be the most rewarding. This was definitely my most rewarding project. It took the longest, but I learned the most.
GitHub was where my knowledge of Git from the course came in handy. After each project’s completion, I added it to GitHub, but that’s actually a very bad habit.
For anyone that isn’t familiar with GitHub, I tend to describe it as “Instagram, for developers”. It’s a place where developers can store & display all of the code for their projects, follow other developers, and even download other developers’ code and add to it (provided they allow it). Its true strength comes from its use of version control, achieved using Git. Version control is essentially just managing different versions of a project.
Let’s take a brand-new website as an example. You can add an early version of the code to GitHub, then continue working on it before uploading your changes, and repeating that process. GitHub will save all uploaded versions of the project, hence “version control”. This means that should your computer break, or new code additions bring unexpected bugs, you still have older, working, versions that you can return to. This is why it’s much better to add projects to GitHub early on, as opposed to when you’re almost finished like I did!
GitHub is a very powerful tool that developers use often, so displaying knowledge of it by adding your projects is key.
After approximately 3.5 months of job applications and working on projects, I landed my first role. Taking the total time to switch into a role as a developer to just under 9 months. Again, this is an estimate. For some, it’ll be sooner, for others it may take longer. But that was my time frame, so you have an idea of how long it can take.
I believe it was my third or fourth interview, and I generally feel I interview quite well. Tech interviews can be quite challenging. I think the key is to prepare well, try your best and always ask for detailed feedback if you don’t succeed. Then use that advice the next time and eventually, you’ll crack the code!
Information overload? Good. Embrace it 😂 Get used to it. Enjoy it! It’s part of the journey.
As I mentioned previously, my journey into tech took around 9 months of full-time work, 8 am — 4 pm, Monday to Friday. Please bear in mind that this time frame can vary drastically from person to person. The key is to keep learning, and keep having fun!
It will take a lot of hard work, persistence, and you’ll likely have to go over many of the same concepts over and over until they completely click, so remember to take breaks where necessary.
For me, it’s an extremely rewarding role. You’ll know if it’s for you pretty quickly…and if it is, stick to it!
If you have any questions, feel free to reach out!
Finally, having recently accepted a new position as an Associate Software Engineer, I have a couple of ideas for my next post:
1. My Self-taught Journey into Tech part 2: Interviews. An in-depth review of my experience interviewing for both roles
2. A Day in the Life of a Junior Developer
3. 1 year as a Junior Developer: Transitioning to Associate Software Engineer
Please let me know if you’d prefer one in particular! Until then, ✌️
MDN Web Docs: developer.mozilla.org/en-US
Danny Thompson: @DThompsonDev youtube.com/c/DThompsonDev
Ania Kubow: @ania_kubow youtube.com/c/AniaKub%C3%B3w