This month marks my first anniversary of being a frontend developer after switching over from design. There are so many things I learned along the way. Things from a technical point of view, a professional point of view, and from a personal point of view. In this post I want to share seven things I learned during my first year of being a developer.
Okay, you got me. This one’s a bit of an easy hit. As cliché as it sounds, though, it’s true! You will be googling a lot and that’s okay. It will help you learn new things, it will help you find things you need faster and it will help you remember some things faster.
I’ll be honest, there are things you will be googling from now until the end of time. In my experience it’s the things you use once every couple of months that need googling the most. The worst part about it isn’t having to use Google, it’s the fact Google will show you that you’ve been there before and you just can’t seem to remember 😅.
I don’t know about you, but I can’t remember every single thing that was discussed in a meeting, said to me at some point in time, or everything I’ve discovered about a topic I am researching. So I started taking notes. About everything.
There are many different ways of taking notes and not all of them will work for you. I’ve tried a lot of methods and I finally found one that works well for me. I’ve also tried many different note-taking apps and notebooks. Eventually finding the one that works for me.
A quick Google search will help you find all the different methods of taking notes. I use a combination of the outline method, sentence method, and mapping method. I picked out the parts that worked for me and combined them!
I use a Moleskine squared notebook for handwritten notes as it gives me a grid to work with if I ever need to structure stuff and I use Bear for my digital note-taking needs.
I’ve fallen into this trap a few too many times; not asking for help sooner. Sometimes you just can’t figure it out on your own. You’ll feel like you’ve read every single link on Google, tried every solution and it just won’t work. That’s where your fellow developers come in!
Don’t be afraid to ask for help, because there’s a good chance they have run into the same problem and will be able to help you. Even if they haven’t experienced the same problem, they will be your extra pair of eyes and you can pair program the solution or they can even be your rubber duck!
No, seriously, I have solved so many problems by simply explaining to someone what is going on and while I was doing so I realized what the problem was and how to solve it.
Asking for help isn’t the only way to help you solve your problems, tho.
There’s something magical about spending hours and hours on something, coming back the next day, and all of a sudden it makes sense so now you spend two minutes solving it.
I’ve discovered I can sort of force this moment by taking regular breaks from coding. The problem with grinding away at your code is that you start to develop tunnel vision and you lose sight of the bigger picture. This makes problem-solving a little more difficult. To counter this I’ll get up and go for a short walk around the office every hour or so.
Not only is this great for your health, but you will come back to your code with a fresh pair of eyes and things will make a lot more sense! At least to me it does. This means my productivity has, despite taking more breaks, gone up.
Eventually, one way or another, you are going to fail. I know I did. Here’s the cool part, though. Moments of failure are moments of learning. Every time something doesn’t work out the way you thought it would, you know that’s not the way to do it. You go back into it, figure out why it went wrong and you’ll be better for it!
Think of it like learning to walk. When we learned to walk as a little kid, we would fall… a lot. We got back up, put our foot in front of the other, and fall again and again. Until we didn’t fall anymore and ran away with our toys because they are mine.
I firmly believe that one of the most important skills you can have as a developer is the ability to learn other people’s code. Working in teams, working on a shared project, or even coming back to code you’ve written ages ago means you’ll be looking at code that is unfamiliar to you.
It will help you do code reviews faster, it will help you learn new ways of doing things, it will help you think about how this person is solving problems and, most importantly, it will solidify some of the knowledge that you might be struggling with.
Try and read other people’s code as soon as possible! I only started doing this recently, so I am still struggling at times, but it’s incredibly valuable already.
Most of the time our job is about solving problems. How can you get that element to be over there while this element stays here? How can I get this data to that place? Is there a way I can make this bit of code run faster? How can I solve this bug?
No matter how big or small the problem is, solving it feels like a win! Celebrate the wins by sharing them with your team, posting them on twitter, sharing them with your spouse, giving yourself time to do something else, relax, or whatever you can think of.
By celebrating the wins I’ve built confidence and kept myself motivated to tackle the next problem.
This was just a small selection of what I've learned during my first year as a frontend developer. I hope you've enjoyed reading this post and found some use in the things I've learned.
You're one click away
Level up every day
Are you confused by the rewrite vs refactor debate? In this post, I'm going simplify things for you and help you decide if you should rewrite, refactor, or do something else to improve the health of your software system.