So you’ve just completed a university course, or a coding bootcamp, or a series of lessons on CodeCademy, and you’re ready to spread your wings as a web developer.
You may be asking yourself, now what?
The first year in the professional journey of a web developer is often among the most challenging, but it can be decisive in shaping the entire early phase of a young programmer’s career.
In this article we will explore how you should approach that first year, and some of the dos and don’ts for a junior developer in this early stage. This is not an article about how to find a job or how to approach an interview – these are topics that we have covered in dedicated articles.
Instead, we will take a more general approach that will look at the first 12 months of a web developer’s career in terms of their possibilities and their strategies, both on and off the job, while also offering some advice that can help you get an edge. Our article will be structured as follows.
CONTENTS
The Slow Lane: Find A Big Team
The Fast Lane: Develop A Small Project
The Super Fast Lane: Early-Stage Startups
Bonus tip: nip the toxic sprout in the bud
Part 2 – Approaching Your First Job(s)
Don’t Underestimate Your First Assignments
Don’t Bite Off More Than You Can Chew
Part 3 – Mindset And Philosophy
Leave Before The Second Year Is Over
Conclusion: Go Forth And Conquer
Let’s get started then, or more aptly – let’s get you started!
Part 1 – Planning your career
There are several paths into the world of web development, and no single one will be optimal for everyone. Bear in mind though, that every day you spend coding will help build experience, so as long as your job is letting you do that, trust that you’re not in the wrong place!
Having said that, you should make a conscious decision about what sort of career you desire, and look for a job accordingly. For a junior web developer, the choice usually comes down to 3 broad options, which are as follows.
The Slow Lane: Find A Big Team
While no type of company can guarantee a low-stress environment, those who are fond of gentle landings should look to join either a relatively big business or a company which is specialised in software services. The reason for this is that your first job as a web developer will see you asking for help a lot, even well past the end of your onboarding phase.
The most difficult part of a junior developer’s first job often has to do with them not getting the help and support they need. Joining a bigger team helps stave off against this – there should always be someone you can turn to for help. Even better, you can find yourself a mentor, someone who will provide you with a treasure-box of tips and advice that will serve you for years (more on this later!).
As a beginner, you want to surround yourself with senior software developers who will teach you the proper methodology to deal with problems and get unstuck. This will let you learn and have a productive first year while going at your pace.
The Fast Lane: Develop A Small Project
The alternative to the above is to find a relatively small project, in which you have the freedom to do things your way, and pursue and develop your own methodologies. By small project, I mean something that can be completed within 6 months, of the type that is usually (though not always) found in the form of freelance work.
This option is considerably more challenging and you should be prepared to manage frustration. It is also, however, one way to turbo-charge your career: in the space of just one year, you will have worked on two or even three projects, and the label of junior developer will be far behind you. Your salary will jump by perhaps 30-50% each time you change jobs.
Doing things without support and having to find new work multiple times a year can be taxing. But for those determined to go places, this approach is the best to take them where they want to go.
The Super Fast Lane: Early-stage Startups
Take both the stress and the career boost that you get from working independently on small projects, triple it, and you’re working for a start-up in its early stages.
We have covered the dilemma of working for big companies against working for startups in greater detail elsewhere, but for the purposes of this article, suffice it to say that working for startups is like playing a game on Very Hard difficulty.
You will get little or no mentorship, you will be asked to do all sorts of things that were never part of your job description, you will face one emergency after another, you will be haunted by deadlines, and you’ll be lucky to work 40 hours in a week. Plus, your company will probably fail.
In fact, the reason you’ll probably be hired in the first place is that the startup can’t afford to enrol a senior web developer and they have to make do with an underqualified beginner like you! The experience is going to be unfair practically by design.
For those who are willing to put themselves through it, however, there is nothing in the world that can make you grow as fast as working for a start-up. You will pick up a tremendous range of skills, and you could easily go from junior developer to manager of a small team in less than a year.
Working for a start-up can be rewarding on all sorts of levels, but be aware that it is not for the faint of heart, and that goes double if this is your first job. Also, let me stress again that I am talking about a startup in its relatively early stages – if you join a ‘startup’ that already has 40 employees, you’ve basically just joined a company.
Bonus tip: nip the toxic sprout in the bud
This doesn’t apply only to web developers or tech workers, but it’s worth stating all the same: if you have the bad luck of ending up in a team with a toxic work culture, don’t make the mistake of accepting it in the name of fitting in!
You may not have the power to reform it all by yourself, but you should set clear boundaries and let people know about anything that makes you uncomfortable, starting immediately. Trust me, the longer you wait to challenge toxic behaviour, the harder that challenge will get, and the more likely to fail.
Part 2 – Approaching Your First Job(s)
This section assumes you have already chosen the type of career you want, and landed that magical first job in tech. Congratulations! Here are some guidelines to make sure you start on the right foot.
Explore The Ecosystem
If this is your first job as a web developer, you should avoid ending up in the ‘tech team bubble’, and instead reach out to representatives from various departments to get a broader sense of how your company works. Do this right from the start.
This admittedly used to be easier before working from home became the standard – back then, you could simply carry a box of chocolates around the various offices and introduce yourself.
All the same, you can schedule calls and find out, say, exactly what the marketing department does. Get an understanding of the structure of the business. This sort of information will become valuable on the long run, not least when it comes to choosing the next company.
You should also do some investigation within your own team, with one objective in particular: find a mentor. You’ll be asking questions a lot at the beginning of your job, and it will help immensely if you have someone offering close help.
Regardless of whether you find a mentor or not (or whether someone is assigned to guide you), get to know your team and find out who has the competences and the affability to assist you when you need it. Your mentor or direct supervisor may not always be the best person to answer your questions, so make sure you know where to turn.
Ask For Help The Right Way
As I said above, you will have a lot of questions. This is normal, and you should not be shy about asking for help – but you also don’t want to bombard everyone around you with 600 questions a day.
So, before asking for help, always ask yourself have I done everything that I could do to solve this by myself? If the answer is no, then try solving the problem by yourself first. Ask Google, ask Stack Overflow, and ask your rubber duck. This should be your standard procedure before you ask any of your colleagues.
When you have determined that you do have to ask a question, ask the right people – those who have the appropriate competences, and who don’t mind interrupting their tasks to help the newbie. You should already know who they are – that’s what the previous tip was about.
Don’t Underestimate Your First Assignments
Your team will know that you are a junior, so at first they will assign you the simplest possible tasks. Some of them may well look elementary, particularly if you just emerged from the final and most complicated phases of a coding bootcamp.
Don’t fall into the trap of taking these tasks lightly. For one thing, many will be more complex than you initially thought, and you should be prepared when they get frustrating. For another, these tasks represent an opportunity to get acquainted with the methodologies of your team.
If you are assigned a very simple task that requires importing a specific library, for example, then this is a sign that you need to start exploring and practising with that library – regardless of whether that extra research is necessary to solve your particular problem at that moment. This way, when tasks get more complex (and trust me, they will), you’ll have the foundations firmly in place.
Don’t Bite Off More Than You Can Chew
Given the simplicity of your initial tasks, and most people’s natural desire to prove themselves when entering a new work environment, you may be tempted to speak up at the next sprint planning and offer to take on more (or more ambitious) work than what you have been assigned.
A proactive approach is always commendable, and in certain lines of work this attitude may take you very far indeed. In a field as technical as web development, however, you may want to resist the temptation.
I’m not saying you shouldn’t have ambition, but who does what in the team comes down to the scrum master, who will usually have a good reason for their decisions. Moreover, sprint planning has an integrated feedback system: the time it takes to complete tasks relative to how much time the developer was given tells the scrum master if they assigned something too easy or too hard. Let that feedback system speak for you.
Again, the point here is not that you should never show initiative or go beyond the call of duty. Only, give it some time before stepping forward, and make sure you understand how each task serves the team as a whole. Grabbing the spotlight and raising your voice works wonders if you want to be a singer – for a junior web developer, there are other priorities to worry about.
Mindset and Philosophy
If you have learned to code, then you already know a thing or two about the sort of mental approach necessary for this line of work. Here we will look at where this approach should change – and as importantly, where it should not change – once you enter the professional arena.
Focus On Clean Code
People who are still learning to code are often big fans of the “whatever works” approach to programming. As long as it solves the problem in the tutorial, who cares if I gave my variable a silly name or if I didn’t space things out properly, right?
Dead wrong. One of the big changes when entering the professional world is that suddenly clean, legible and (ideally) elegant code matters. Any habits you picked up which you felt made you work better at the expense of the above qualities must be shed.
Your new focus now should be on writing code that will be a pleasure for others to read, and to comment the code clearly and consistently, so it stays legible even if a stranger picks it up 10 years from now.
There is no universal guideline on how to write clean code, but one good practice is to do quite a bit of pair programming and code reviews, which will give you a better appreciation for how others write code. If that is not an option at your job, then take some extra time and do some open source work.
Fortunately, there are tons of open source resources specifically for beginners. GitHub already has some options listed, naturally, but you can also take a look at Up For Grabs and Code Triage.
Also, here are a couple of reading tips to help on the way: Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, and the old but evergreen Design Patterns: Elements of Reusable Object-Oriented Software, written by multiple authors.
Keep A Learning Mindset
To some of you this may sound like I’m stating the obvious, as it’s common wisdom that you can never stop learning if you want to stay competitive as a developer. But since this article is intended for people new to the profession, it’s worth saying this out loud.
You can never stop learning. Never.
Finishing a course doesn’t mean that the time to learn is over and now it’s time to work. It only means that you have to change the methodology of how you learn. You no longer have a professor or a bootcamp instructor to watch over you and tell you what to study next.
Instead, you must schedule time to practice. Your working hours should normally accommodate this – an intelligent scrum master will assign deadlines to beginners that account for the time they need to get good with their tools. If you’re set on learning something that is only indirectly relevant to your immediate tasks, do that in your free time.
I’m not trying to promote a hustle culture of working every second you’re awake, but I do want to make the point that one of the most impressive things you can do as a new hire is learn something new outside of work, introduce the rest of your team to it, and put it to use on your company’s project. It’s not mandatory, but any extra hour put into learning something new will reward you immensely on the long term.
A couple of extra tips on learning – firstly, network. Join Meetup, Twitter, Reddit, or anything you like, but surround yourself with people who are interested in learning similar things.
Secondly, if you’re not doing any other extra research, then at least carry around a copy of David Flanagan’s Learning JavaScript: The Definitive Guide, and read a little bit – even just a paragraph – every day. You’ll be amazed how much that helps.
Keep Your Eyes Off The Clock
A task that will take you one week to complete could be done in less than 4 hours by a senior developer in your team, and better. Realising how much faster your more experienced colleagues are can be really withering, but it’s the sort of thing that you have to be prepared for.
Understand that this is normal. The fact that someone is an order of magnitude faster doesn’t mean that they are an order of magnitude more intelligent – it’s simply the way that programming skills scale. Small differences in experience can result in massive differences in productivity.
Set your own benchmarks and don’t compare yourself to others. As well, accept that your first year as a web developer is still part of the learning phase (see above). You’re not going to be hugely productive at first. And that’s ok. Be cool with it.
Leave Before The Second Year Is Over
I will end this blog with a few words about what happens after your first year as a web developer, because that is when you should start thinking of changing jobs. Whatever type of career you’re looking for, you should not end your second year as a web developer in the same company in which you started.
For one thing, yes, you are needlessly hurting your wallet. Even if you negotiate a raise, it’s unlikely the base salary of your entry job could compete with what you’ll be making in your second and third jobs.
But more importantly, if you have kept that job for so long, it means you’ve grown comfortable in it. For a web developer – and for a programmer in general – this is not a good thing, especially this early in one’s career!
Being comfortable means that you are not being challenged, you are not learning anything new. You may feel that you have ‘arrived’ because you are happy where you are, but you are hurting your career on the long term.
The field of web development is extremely dynamic, and most people who work in it change jobs relatively frequently. Those who do stay at a single company for a long time usually do so after they have picked up considerable experience, and/or when they are hired by truly elite companies.
If the job you got in your first year as a web developer is the same job you have halfway through your second year, then it’s time to start looking for a new one. This may not be the most ‘comfortable’ option, but it’s the best one on the long run.
Go Forth And Conquer
Your first year as a web developer will probably be challenging. The good news is that if you make it a good year, then your opportunities are going to explode. You will be able to work on so many more projects – and so many more types of projects – than you could when you first started, and your revenue will rise commensurately.
We wish you all the best of luck in this new journey! And if you haven’t started on this journey yet, well – what’s stopping you from becoming a web developer?