I started working at CTI just over a year ago, which means it's been a year since I became a professional front-end developer. So, I thought now is the time to reflect and check I’m still sane.
I managed to get through it without losing any hair or melting down any mainframes, and with a newfound addiction to Vimto, I can safely say it’s been amazing.
So, how’s my first year been? What would I have been interested to know before I started this career? What has helped me through?
I’ve met some great people, worked on interesting projects and learnt an insane amount of new skills. I’ve put together a good old ‘top 5’ list of my experiences so far (there’s too much to cram into one blog post). If you’re about to start out on a similar journey, then hopefully you’ll find some useful advice or something you can relate with.
1. You need a passion for web development.
I can safely say that my brain isn’t hard-wired to do this job. I’m not mathematically minded, or the stereotypical ‘computer whiz’, but I love web development. I love writing code, reading about writing code, the history of computing with its heroes and villains, and everything in between. I think that has carried me through some knocks and moments of self-doubt.
There have been times when I’ve struggled with a coding problem, or just found myself in the clutches of a bad day, and passion for the subject has been the main drive. Sometimes you’ll feel a massive sense of accomplishment from just getting a different error message to the last one. It can be painful, but it’s progress! You have to want to be good at development. Think Eddie the Eagle with more screens and fewer skis.
When I started to apply for developer jobs, there was no plan B. I was going to keep at it until I got a developer job. Your first few weeks as a developer will feel like ski jumping. You might not land on two feet after your first try (…I’ve never done a ski jump by the way), but you’ll improve every time you try.
2. Imposter syndrome is no big deal.
There’ll be times when you feel entirely out of your depth, but it’s nothing to worry about. I found honesty was the best policy and couldn’t have asked for a better team to turn to for advice when I was stuck. If you don’t understand the task from the off, then ask questions. If you’re stuck on a coding problem, you have the endless resources of the internet at your fingertips. Still stuck? Check if a team-mate has a bit of spare time, explain what you’ve tried to do, and ask for advice.
But what I did find out pretty quickly, is that starting out as a developer is quite similar to learning to drive. You can take lessons and pass your test, but when it comes to driving on a motorway, you’ve just got to figure it out when you get there. Luckily, I had an understanding ‘passenger’, and my colleague talked me through the work. This was a common theme in my first few weeks; looking at code syntax that I only vaguely recognised, frantically looking up Git commands, and wondering if I really knew what the hell I was doing.
3. Be, and stay, humble.
On your first day as a junior developer, it’s probably best not go strutting in like Elon Musk. Working at CTI, I soon realised I was surrounded by some very knowledgeable people who knew a hell of a lot more about programming than me. I’ve tried to learn as much as I can from them. I found it was best to put your ego to one side, don’t be precious about the code you write, and absorb information from every direction.
4. Learn Git. And learn it properly.
This is quite a straightforward one. I thought I knew Git. I was asked in the interview and said I knew the basics. Using Git on your own is very different from dealing with version control on large projects, involving a team of developers updating multiple branches. A year later, I now know the basics. Online training courses don’t really drill this in enough, but you will use it constantly as a developer. Definitely…learn…Git.
5. Development is more about the bigger picture than you realise.
When I started out as a developer, I didn’t really grasp the importance of approaching tasks with ‘the big picture’ in mind. The common use of Atomic Design and component-based development means writing DRY, re-usable code is more important than ever. It sounds fundamental but took some getting used to, especially if you’re fresh out of an online coding Bootcamp and keen to throw yourself into real-world projects.
Around 80% of the role is problem-solving, and that’s something I had to keep reminding myself. A developer’s job isn’t to code something up as quickly as possible (although coding speed is another skill to work on). You break the problem down, recognise where parts can be reused across the project, communicate this to the team, start coding, stop, review, and probably repeat the process. For the majority of developers, this advice is like teaching your grandma to suck eggs. They call it ‘planning’, and it makes all the difference if you’re aiming to write clear, concise code.
So, that wraps up the top 5 talking points from my first year as a fully-fledged front-end dev. It’s been fascinating, infuriating, euphoric and catastrophic all in equal measure.
For anyone who is thinking seriously about teaching themselves to code, looking for their first job, or has just accepted their first job offer, forget about plan B and give development everything you’ve got…with the occasional coffee break, of course.
Photo cred: Christian ter Maat.