Learn as much as you can
In your first year as a new professional software engineer, you are a blank slate. A dry sponge that's ready to absorb and touch everything in sight, and you should. During your first year, you may not have the required knowledge to make an immediate impact at your new job, and that's completely okay. While it does depend on where you work (a smaller team may demand more from you straight out the gate than a larger team), most places don't expect you to hit the ground sprinting. In fact, quite the opposite, they want you to start slow and really use your first year to learn as much as you can. So, make sure you're really taking advantage of the time that's being given to you.
Closed mouths don't get fed, so stick to a senior developer and shadow them, they can be goldmines of knowledge. There's no such thing as a dumb question, so really pick their brains about the work they're doing, taking care to ask "why" and "how" questions. Finally, if you work somewhere that doesn't encourage taking time to really learn more, it's worth considering if that's the ideal place to spend the developmental years of your software engineering career.
Don't be afraid of a challenge
One of the hardest things for me to get over in my first year, was the fear of accepting the big challenges. Big challenges usually come with big expectations, so it's easy to shy away from some of the bigger projects that come down the pipe because you feel like you're not quite ready for something so large yet, but in reality you'll never be ready! The only way to start is to just dive in head first and learn on the fly. Not only will you get comfortable with some of the minutia that comes with larger tasks, like time management and pre-planning, but it'll also make you better at some of the larger engineering/architectural concepts you must consider when making software. Truth be told, most of the time, you'll find that the tasks you were originally afraid of end up being pretty tame and the more senior engineers will be there to help if you need it. So, the next time you see a large ticket is coming up, step up to the plate and grab it!
Seek out responsibility
A very important piece of my growth in my first year, something I feel often gets overlooked, is getting involved with responsibilities that don't necessarily involve writing a single line of code. To some, this may sound like a turn-off and not what they signed up for at all, but it's important to recognize that as a new engineer you bring a perspective to the team that other team members who've been there for years don't have; you can use this to take initiative.
There may be flaws in the on-boarding process that made it difficult for you to get spun up, or maybe you think that the team's documentation process is lacking (which made it difficult for you to get up to speed). These are opportunities for you to take ownership and tackle them head on! The process and environment for an engineering team is arguably just as important as any single line of code that is going to be written.
Alternatively, there are usually some minor tasks that senior engineers are required to do as a part of their work load. It could help them out to ask if you could take some of these smaller opportunities off their hands, not only will it free up their time, but it can also give you insight on some of the day to day operations of the team.
Finally, getting involved with non-code related activities can give you an idea of your future career path. You may find that you absolutely loathe anything that doesn't take place inside of Visual Studio, and that's completely okay, code away friend! But, you may find that you actually really enjoy the administrative side of things, and perhaps a Development Manager role may of be of interest in your future. Either way, you won't know for sure until you try.
Overcoming impostor syndrome
So, you came into college (probably) a complete rookie, barely understanding what a for loop is. There were moments when you thought you couldn't do it, but you kept grinding. Then, the next thing you knew, you were a senior, standing on top of the coding world. There wasn't an algorithm invented that you couldn't figure out the Big-O notation of. Create an algorithm that can find all of the Pythagorean triples in an array of ints? Ha. Child's play. Bill Gates himself would marvel at your coding abilities.
Then, you start your first day as a real software engineer, and you're asked to diagnose and squash an extremely simple bug in a code base that spans tens of thousands (possibly hundreds of thousands or more) of lines of code and you're at a complete loss. You've spent three hours trying to solve this one bug and you feel like a freshman in your intro coding course all over again. You start to wonder, "Am I cut out to be an engineer?"
Impostor Syndrome is natural, and it seems like everyone goes through at one point or another. It's important to remember though, you worked hard and deserve to be there. They know that, and that's why they hired you, now you just need to believe it. Don't worry if "simple" tasks seem hard in the beginning, that's natural. Just be confident in your abilities, and it will show in your code. No one wants to work with a Dev that has no confidence in their work and looks towards others for confirmation that they're doing things right every time they add one line of code. You made it this far, and you're the real deal! Keep the faith.
Attack your weaknesses and target your strengths
No junior engineer is perfect. You're going to find out very quickly that there are some things that you just are not good at. You will also find out there are some things that you're a natural at. These things will both, hopefully, be pointed out to you by a supervisor that wants to see you improve. When you have identified your strengths and weaknesses (honestly the more weaknesses the better!) you can start game-planning on how to improve your weak spots and leverage your strengths to create a solid foundation to build on, and to push the team to greater heights by making immediate use of them.
Don't rush yourself
Finally, and arguably the most important thing I've learned, is not to rush yourself. When you first get hired, you might feel like you want to just hurry up and get that senior developer title, so you stack your plate as high as you can and start sprinting. Just remember to slow down and stop to smell the roses as you progress through your first year. Really soak things in and internalize all the new information and lessons you're being hit with. This was honestly the hardest thing for me to learn, and trying to sprint very quickly leads to burnout. Your career as a marathon not a sprint, so make sure you start slow and pace yourself in your first year and you'll be where you want to be in no time.
Top comments (1)
You'll always be learning - absolutely! It can be daunting at times, but it's also what makes being a programmer great; there's always something new to do! Thanks for the article - good tips :)