As a Senior Developer a topic that often comes up in conversation is how I mentor and teach my Juniors. Software is a massive field. There's always something to learn and its easy to feel like you're starting from last place in the race. This is doubly true for true Juniors starting their first real dev job. They're nervous, excited, and overwhelmed all at the same time.
I decided to sit down and write up this article for those Juniors (and some Seniors who hopefully find themselves mentoring the next generation of great developers). College and Bootcamps do their best but they can't prepare you for everything you'll face when you enter the workforce. Writing a sorting algorithm off the top of your head won't prepare you for success in the workplace. Hopefully you gain some insight on how to be the best dev you can be from this article and start to build your own reputation!
Don't Be Afraid to Ask Questions
Picture this. You're a new hire at a software company that's been around the block a few times. You've been placed on a great team working on a few different projects that have already been running in production for quite some time. You've finally made it. All those late Red Bull fueled nights and LeetCode cramming sessions have paid off.
The team you've been placed on has a great mix of Mid Level, Senior, and even a Staff Engineer. These guys have been in the field for a while and you're excited to work on something real. You join your first standup meeting of your career and people start talking. They're using all kinds of words and acronyms. Some you understand, at least in passing, some... you have NO idea. Did they go over that in orientation?
What do you do?
This is your first real challenge as a Junior developer. You're thrown in the deep end without a life raft (so you think). It's different from college or the bootcamp. There's no presentation beforehand to prep you for all this new information. There's no homework assignment (that you definitely didn't do last minute) to bring you up to speed. You're lost. What can you do?
Start asking questions! The first fear you will have to overcome on this new journey is the fear of looking stupid. No one expects you to know everything. In reality, your team will be more concerned that you aren't asking questions.
You don't know what you don't know. Don't be afraid to ask, "what even is this thing?" This is the easiest thing you can do to start learning and making an impact!
If you find yourself with a million and one questions at the end of a meeting. Don't worry! Your team is there to support you. I find it practical to write down questions that come to me during meetings but aren't urgent. I then get to work and start finding answers. Sometimes I do the dirty work and use my google fu to get a baseline understanding. Other times I find it more helpful to turn to my peers and ask them directly. There's no shame in not understanding something.
Speak Up, Speak Out, Get Noticed
One trait of new Junior engineers I've seen over the years is that most (but not all!) tend to go silent when someone important is in the room (or in the slack channel). When a manager or someone with a fancy sounding title joins the conversation they'll go from lively conversationalists to stone cold stoics.
Speak up! Don't let the fancy titles and the higher salaries scare you. They're just people like you and I. Share your thoughts and opinions like you would if they were not involved in the conversation. Showing them that you're actively participating in the team's discussions and not just sitting there waiting to be told what to do is great way to build your reputation and have you stand out! The same goes for leading meetings. If you have an opportunity to lead a meeting for your team, no matter how small the topic. Take it!
I was extremely lucky early on in my career to have this fear of important titles/people worked out of me. During my internship (and unbeknownst to me) I and my teammate worked along side our company's CTO for the entire duration of our summer internship. We treated him just like any other person. We had lots of chats, after work bar hang outs, and built a great camaraderie. It wasn't until our internship ended and we got actual full time positions at the same company that we learned just how fancy his title was! After the initial shock wore off, we learned an extremely valuable lesson. Behind the fancy title, he was just another nerd like us.
Soft Skills Matter
A misconception I think a lot of Junior engineers and students have is that Engineering is a solo sport. "I don't like people so I went into tech" is something I not only heard a lot while I was in school but, continue to hear from students and newly hired Junior developers. I'm here to tell you, if you think that's true, you're in for a very, very, long career.
Software is a team sport... and the team isn't all just us developers. You will have to talk to business people, managers, sales guys, customers. A multitude of people all with different personalities.
Your soft skills will matter. We as engineers get a little leeway (people kind of expect us to be a little awkward). But the ability to communicate effectively and at a level everyone can follow will do more for your career than any Javascript framework of the month. Plus, no one wants to work with someone who comes across as an asshole.
Sometimes Less is More
It's not the quantity of code you write, its the quality. Professional development isn't a competition. There is no annual award ceremony for the most lines of code written.
A trait I see in a lot of fresh Juniors is the tendency to want to write tons and tons of code, for every problem that's presented. I'm here to hopefully keep you from falling into that trap. Take a second to stop and think about the problem.
Before automatically hammering out a bunch of new code to tackle a problem. Take a breather. Look around. Is there code already in the project that does what you want? Or, a more realistic example, is there code already in the project that does 80% of what you want that just needs a few tweaks? Some times less is more and you'll save yourself a ton of time come peer review if you slow down and take stock of what is already there.
I wasn't immune to this. It's one of many lessons I learned the hard way. I remember early on in my career I was tasked to implement a small feature in our code base. I did what any Junior would do, I got to work! I wrote a bunch of new methods, unit tests, beautifully designed code (at least I thought it was at the time). When I was finished I opened my pull request and sent it to my mentor for review, thinking I had just nailed it. My mentor being the calm and cool veteran that he is (we are still friends to this day 10 years later, shout out Carlos) called me over to his desk, talked over everything I did and what it did great and what it did not so great. And then, highlighted it all, hit delete, and replaced it with a single method call that was already written... It's a tale as old as time in our field.
Giving and Receiving Feedback
That last story brings us to a very important topic. Giving and receiving feedback to and from your peers. This is something you will have to do at all levels, through your entire career and this advice is applicable to all levels of your software journey.
First and foremost, leave your ego at the door. Engineering is a team sport. You may be super proud of the pull request you've just opened. And you should be! That doesn't mean you've written perfect code. There is always something to improve and your peers want to see you improve! Comments on your code are NOT personal attacks. They're simply recommendations or potential pitfalls you might have missed. Don't grow overly attached.
Make your feedback count. I once worked with someone who left a million comments on every PR... The only problem is, none of those comments were helpful. They were pedantic, didn't point out any real problems, and didn't improve any aspect of the code under review. Everyone has their own ideas of beauty. This is true for art, furniture, and even code. But stylistic comments (unless its just insanely garish) do not provide any value.
Leaving a million comments on someone's pull request that say something along the lines of "you didn't end the comment with a ." are not helpful and will actively harm your reputation. *Eventually, your peers will not take your feedback seriously and start to automatically assume you have nothing helpful to say, even when you do! *
Try to use inclusive language. Try to form your feedback in questions. While you should strive to keep your ego in check, not everyone is as good as it as you might be. You don't want to attack your coworker. Using inclusive language is a good way to mitigate those hard feelings when leaving feedback on something they've worked hard on and are proud of.
Additionally, getting straight to the point can sometimes feel like an attack. I try to use words like "we", "what if", "what happens when?" when writing feed back to help avoid any feelings of attack. A good example would be "what happens when this call throws an error? Should we catch it and try to fix the issue or should we let it bubble up?" or "we should look into what happens when this value is null"
On top of being a little less hostile, asking questions can also trigger meaningful conversations. "What happens when this API call throws an error" could lead into a conversation on the best way to report the error to the user. Or it could lead into a conversation about testing patterns. Or even discover a whole new area of work that is a missed opportunity. These conversations might not have ever happened if you made more direct feedback of "catch the error".
Its Okay to Make Mistakes
One thing I wish new developers would learn is to get over their fear of mistakes. I know, I know, that's asking for a lot. Keep in mind that we're all human. It's not a question of if we make a mistake but when. And, that's okay.
The simple fact of the matter is... you're going to make mistakes. That doesn't mean you're a bad developer. It doesn't mean you're not cut out for this career. It just means you're human. Don't shy away from your mistakes. Embrace them and learn from them and you'll come out stronger and better than you were before. yes... I know that sounds cliche but its true. Don't beat yourself up over them.
If someone tries to tell you they've never goofed up in this field they're either the luckiest person in the world... or they're lying to you.
Make Friends
For many of us high school or even college were the last times we were in a structured environment full of people entirely in our own age bracket. Unless you're in a company full of just your friends you're going to be working along side people of all walks of life and all ages. Embrace this!
Make friends with your coworkers! I'm assuming that you enjoy development work (if not, then you're in for a rough time) but its not always fun. That's just the nature of having a job. Making friends and building relationships with your coworkers will do wonders for your mental health and help pull you through those rough sprints.
Your coworkers are also a vast wealth of knowledge. You'll be surprised how much you can learn from them just for little side conversations. Those interactions, inside jokes, and conversations will help bring joy to your daily life, especially when things get tough.
I understand that not every one of us are social butterflies. In fact, I'd wager that more of us are introverts rather than extroverts. Don't force your social interactions. This can have the opposite effect that you want. In time you will naturally grow closer to your team and become more comfortable working and socializing with each other. But keep in mind, relationships of any kind take work.
I'm lucky enough that I've managed to build lasting relationships with a lot of coworkers. I still talk regularly with people I haven't worked along side with in years. Its always fun and interesting to hear what they're up to and learn about the things they're working on. I've learned an immense amount from them as well. And I know if I ever get in a pinch I have a wonderful supporting community to fall back on.
Its All About Balance
Work life balance has become a buzz word of sorts these recent years, that doesn't make it any less important however. Engineering and software development is a tough job. I won't sugar coat it, it can be hard, confusing and stressful.
As with all things in life, its exceedingly important to strike a balance. Especially in this field. Its your job as a professional to keep things balanced out. Without some kind of work life balance you risk crashing and burning. And trust me, that crash is hard.
Take notice of how you're feeling. There is no harm in taking some me time. Your company has a PTO policy for a reason, use it! Take a vacation to de-stress and unwind, even if it's just a stay-at-home-cation. It can do wonders for your stress levels and help you feel invigorated when you come back to work.
Sometimes this job calls for crunch time. You'll have to burn the midnight oil every now and then. But don't make that a common occurrence. You'll do more harm than good being known as the "work-a-holic". And the longer hours you pull the worse your work will become.
Tying It All Together
Hopefully you've gained something from reading this short little article I've put together. Starting your career is a daunting feeling. There's so much going on and so much to learn it's easy to feel overwhelmed. It's my hope that this guide has given you some guidance and tips on how best to navigate the early stages of your career. Asking questions, speaking up, embracing your mistakes, making friends, knowing how to give and take feedback and, keeping your life in balance will set you on the right path for a rewarding career!
AI Notice
AI was used to proof read and point out any grammatical and spelling mistakes. After all I'm an engineer not an English major.
Top comments (0)