Photo by Glenn Carstens-Peters on Unsplash
2 years in as a dev? doing well? how to keep it that way.
As you pass 2 years as a dev, here's how I intend to keep progressing and prevent a learning plateaux
We ticked over into 2023 recently, and with that, I passed 2 years in my first role as a software developer. Towards the end of last year, I started to realise that my level of progress as a software developer had slowed down. I wasn't pushing myself, I wasn't learning as much as I had done in the previous months, and I felt frustrated with this. Fortunately, I'm in a position where I have some supportive team members who have given me invaluable advice on how they've overcome this problem. Below are some brief ramblings on their advice, and how I intend to / have already started to implement it.
Pick something new to learn, and give yourself a deadline of being competent with it by a set date.
This sounds obvious, but by picking a new technology, you're giving yourself something to keep things interesting. It's natural to get bored with some things over time, so keeping things fresh helps with motivation
The deadline gives some impetus. It doesn't have to be a hard deadline, but it should be achievable, and ideally, you should have something at the end of it to say 'Yeah, I can now do this'. Good examples of goals are being able to provide a tutorial to your team or do a peer code review with a senior colleague and explain how something works.
For me, my team moved over to using Typescript for all new frontend code from a previous pure vanilla JS project. This was quite a steep learning curve as I hadn't worked in a strongly typed language, but I feel it's helped with my overall understanding of coding in general. From January to March, I made it my aim to feel really comfortable with this, and now, I write TS code pretty much every day with few issues.
Go for the picky reviewer, no really, get them to review as much as possible.
Every team has them, the one person you dread having a code review from. They will put 30 review comments on a 100 line PR and you'll spend half a day fixing them, only to get another 30 comments on a second review. Your estimate goes out the window, and your manager constantly asks 'Why did this take longer than expected?'. Despite all this, I generally try to get this person to review my code.
It makes my eyes roll just writing this, but every comment is an opportunity to learn. If you go for the person who barely reads your code before the thumbs up and approval stamp, then you'll end up never learning from your day-to-day tickets. Standard, everyday work makes up probably 90%+ of your code, so it's really important to force yourself to learn from what you do every day. Besides, building good habits never came from one-off 3 hour youtube tutorial binges on a Sunday night... It comes from things you do every day.
Write a blog
As you can see, I'm already taking this one on board, but writing a blog gives you a whole load of benefits:
You can keep track of things you struggled with and use it as a personal wiki for the future.
It looks good for future employers. Link a blog to a LinkedIn or CV, and employers can see how serious you are about your career.
By writing about something you can ensure you fully understand it or even get further ideas and feedback from comments.
you can feel like a hipster by writing in a coffee shop with a croissant and your blue light glasses.
My aim with this blog isn't to write every week/month/quarter. It's just to keep something in the background I add to now and then when something suitable comes up. Not committing here makes the entire thing seem more achievable.
Read books about tech. Even if it's old-fashioned.
I've been told multiple times now to read books about tech. There are certain things which I think you can't learn by doing, and below are a few on my list to read over the summer. (I'm not a big reader, so this may take me well into winter):
Refactoring - Improving the Design of Existing Code (Martin Fowler)
A Philosophy of Software Design (John Ousterhout)
Seven Languages in Seven Weeks (Bruce A. Tate)
Learning JavaScript Design Patterns: A JavaScript and React Developer's Guide (Adnan Osmani)
Get a Mentor
- As I said at the top of this post, I've been really lucky to work with some devs who are both very talented and offer great advice for someone getting into the nitty gritty of their developer journey. If you have anyone with 5+ years of experience who is a kind soul and will take you under their wing - please please please, (in the nicest way) take advantage of them. Having someone you trust to help you out is the single best thing I've done and even if you don't learn from them, just getting general advice is often a highlight of my week.
There are so many other things you can do, but alas, I only have time for my top 5 today. I hadn't intended on this being a top 5, but serendipity reigns supreme once again.
The long and short of this is, just make sure you have time to reflect on your progress and ensure it's still on a consistent and steep(ish) incline. Sometimes things will get in the way, but as long as you are improving month-on-month, you'll reach your aims in no time at all. For me, the first 2.5 years of my career as a dev have given me a list of skills in which I can feel confident. My target now is to make sure every 3-6 months I have something new which I can add to that list.