It has been just over 6 months since I started my first job in the Software Developing world, after graduating from the coding bootcamp, Makers Academy. Before I started to learn to code, all I knew was related to the Arts, flittering between different creative subjects like Graphic Design, Photography, Film & Writing. I had no STEM-related knowledge, and I believed that I just wasn’t cut out for that kind of thing, even though I badly wanted to be. Even after making it through Makers Academy and subsequently gaining a job, I entered this new career with so many doubts about myself and my abilities still hanging heavily over my head; imposter syndrome in full swing.
Slowly, these doubts about not being able enough started to creep away, as I began to realise that with enough persistence, patience, and positivity, anyone with the right mindset can be successful in what they do. I was first introduced to the ‘Growth Mindset‘ at Makers Academy, and I think this discovery has been a key part of why I’ve been able to stick it out, even when things start getting really tough. Being successful to me now is not this big, obvious, fancy thing – it’s just being that little bit better than I was yesterday.
It’s definitely not been an easy ride, but over the last year and a bit of going from knowing nothing about code to being a Junior Developer, I have adopted some habits have made my days more successful:
Try to focus on really learning one thing at a time.
This relates more to side projects or learning to code in your spare time. It’s personally been something I’ve found really hard to stick to as there is always a ton of things I think I should be learning. I have found that if I decide I want to learn about and get better at a specific thing, e.g. Observables in Angular, I learn in more depth if I just focus on developing my knowledge on that one thing in my spare time, rather than bouncing between different features of Angular and trying to get “good” at it all. Since starting my blog and side project, organising things I want to do and learn on Trello has really helped me do this. On there, I can split tasks into smaller steps, so I can focus on one thing at a time. It feels great when I can tick off these small tasks one by one and then move it into the “Done” column.
Write things down you don’t understand yet, to learn later.
At work, I’m constantly writing down words or syntax I don’t quite understand yet to look up at a later time. I do this instead of immediately Googling it because I think it’s disruptive to break the current workflow to constantly be looking up things, which is especially relevant if you’re pair programming. I think immediately Googling something you don’t get is only helpful if the thing you want to learn is part of the task at hand. I can look back at my notes when there is a natural break in coding or even if I’m on the bus or at home and I can try to learn these bits then.
Don’t just copy and paste.
This one is a classic. It’s really hard not to just copy and paste, especially if you’re at work and feel the pressure of just getting something done and working. At my job, a lot of syntax we use to test and develop new features has already been written in the code base, so it’s easy to find code to copy. I have definitely found it beneficial to try and go through the code line by line and question my knowledge on how it is actually working. It’s even more beneficial to try and write it out yourself rather than copy and paste, after you’ve had a look at the implemented code. If you can’t do this at the time, the previous habit I wrote would come in handy: write it down to learn later.
Ask lots of questions, but not too early.
If you’re working on a feature and get stuck, I think it’s best to save asking for help until after you’ve tried/debugged as much as you can and struggled through it. Even if you don’t manage to figure it out completely, at least you’ve deep dived into the code and probably learnt something new that will stick. I have personally found that I’ve learnt the most when this happens. If you’re fortunate enough to not have too much time pressure, try and chip away at the problem for as long as you can, then ask for help along with explaining what you know.
Break down problems into it’s smallest step.
This is especially a good one if you are writing code through Test Driven Development, but also a great way of problem-solving and learning. Unless I’ve worked on a particular problem before, I usually have to spend some time planning on paper to fully understand the requirements. It really helps me to write down each step in the workflow and visually see it. When I get stuck or have been distracted, it’s been super helpful to refer back to what I wrote down. Also, breaking it down into it’s simplest form helps with TDD because you can see what you need to test first, and where the tests will need to go.
This is really important. This comes along with having the right mindset, as I mentioned earlier. It’s hard to do when there are so many things we don’t yet know as Junior Developers, and it’s easy to compare ourselves with others in a similar situation around us. You’ve just got to realise that everyone has different learning curves, personal situations, and personalities, and there is no good reason to compare yourself to another. Whenever I get stuck on something now, I think, yeah I might not be able to do this right now but as long as I keep plugging away at it, I’ll solve it eventually. I guess it depends on the situation you’re in though, for example, if there’s a bug in the code at work and it needs to be swiftly fixed, I’d spend a lot less time trying to figure it out myself, then try and learn it better later. I recently listened to the “Syntax” Podcast episode, Advice for New Developers, Imposter Syndrome and Interviewing at Google, and it has such good tips relating to having the right mindset.
Practise writing clean code as early as you can.
One of the best things I learnt through Makers Academy is the importance of “Clean Code”. For example, code that’s simple as possible, easy to maintain, and avoids being tightly coupled. Practising TDD helps with this because the cleaner your code is, the easier it is to write good tests! If you can get into the habit of writing clean code early on in your career, you can focus on other things whilst writing code that is easy to understand and explain to others, which is beneficial for both you and your team! This website gives great examples and points to follow: https://www.butterfly.com.au/blog/website-development/clean-high-quality-code-a-guide-on-how-to-become-a-better-programmer and if you want to learn best practices for writing clean code in depth, this book is highly recommended: Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin).*
Challenge yourself – find something you think you can’t do and slowly work through it.
The best learning days have been when I have found myself making progress through something I initially thought I wouldn’t be able to do myself. For example, I’m currently challenging myself to build a mini travel web app for the Philippines as my side project, even though I have no idea right now how I’m going to implement all the routing logic. It’s something I’m passionate about creating though and I think it will be a good learning experience. I bet if you challenge yourself to do something out of your comfort zone, you’ll find that it will eventually come together, bit by bit and you will learn so much from the struggle!
Spend a little bit of time each day on a side project.
I took me way too long to realise that I could be actually making progress on a personal project and learning so much more if I just took a little bit of time before or after work to do it. I guess the initial few months as a Junior Developer were quite exhausting so it was hard to “find the time”. This is especially due to the fact we pair program all day at work, which although it’s really enjoyable and beneficial, it is quite draining for an introvert like me! (I wrote some tips for pair programming aimed at introverts here). So as I was feeling too tired after work to do any serious programming, I found that the best time to be productive is in the morning. Now I get up earlier to give myself around an hour to do personal things, and it’s made such a difference to my productivity levels. I’ve finally been able to set up this blog, and start on my side project! I recommend finding out the best time for you, and taking just a little bit of that time every day, or even every other day, to do things for yourself – it makes such a big difference in what you can achieve.
Finally, and most importantly, remember to take breaks! It might be the most obvious thing to do but I often find myself forgetting to take a break, especially when I get stuck. I feel very fortunate to be currently working at offices where table tennis breaks are taken very seriously… I’ve found it so beneficial just to step away from the computer after I’ve been stuck on a problem and can come back with a much clearer head. Another thing we have recently started doing at work is going for a 5-10 minute walk outside as a team. I think this is such a great idea as anyone can do it and it really does help bring back focus, especially in the afternoon when I’m feeling a bit sluggish – it’s definitely better for you than that cup of coffee!
I hope these tips help you in some way or provide some inspiration if you’re a Junior Developer too!
Do you have any habits that you’ve found have helped you grow as a Developer?
*This is an affiliate link. Clicking on this link won’t cost you anything, but it might help me to maintain this blog by giving me a small commission. Thank you!