Firsts are exciting but can also be overwhelming. When I started my first programming job, I knew there’s a lot I needed to learn tech-wise. But what I didn’t realize is that there’s many other skills you need to be a good developer besides coding. Mastering each of these is essential in accelerating your career growth. The earlier you learn them, the faster you’ll ditch that “junior” title.
Do: Find a mentor ?
Find someone (or multiple people) outside of your company who you can ask questions and get advice from. Mentors within your company are great, and important too, but I’d recommend finding at least one person outside of work who you can learn from. They’ll have an unbiased opinion, and you don’t have to worry about any conflict of interest, so you can truly feel comfortable asking anything.
How to find a mentor? This could be a whole post in and of itself. But the quick version is: go to meetups, attend tech events and introduce yourself to people, follow up with them, and let people know you’re new in the industry and looking for a mentor. You’d be surprised how much strangers are willing to help.
Don’t: Be afraid to ask questions ❓
I used to think that asking questions was a sign of weakness. That it would reveal my lack of experience. Now, I realize that asking questions is a core part of being a programmer. Let me explain.
There’s thousands of buzzwords, and more are added every day. Even people who are in this industry for years are constantly learning new things. It’s impossible to know absolutely everything. So asking questions is an essential part of programming.
Being good at asking questions is a skill. The earlier you develop it, the faster you’ll gain confidence as a programmer.
Here’s a tip on knowing when to ask a question:
Gather enough research to effectively communicate: what works, what doesn’t work, what you’ve tried so far, and what information you’re missing to solve the problem.
Example of a “bad” question: “I have no idea what’s going on here, but something isn’t working...”
Example of a “good” question: “I’ve checked the logs, and was able to reproduce it locally. It looks like the problem is somewhere between X and Y. I’m thinking it's either an issue with the API version we’re using, or some unexpected value being sent. Is there anything else you think I might be missing?”
Do: Share your successes ?
Not every success. But if there’s something you’re really proud of, share it with your team. Whether it’s an email or Slack, write up a summary of what you did, how you solved the issue, what you learned, and what value it provides.
If you have a great manager, they should encourage you to present about it at a dev team meeting, or maybe even encourage you to speak about it at a meetup or even a conference. If not, you should take the initiative and find meetups to present at, get a dev team meeting together to talk about it, or even write a blog post about it.
It might feel awkward to toot your own horn, but believe me, visibility is important and helps you gain respect and recognition at work. No one will know how amazing you are until you show them.
Don’t: Panic ?
Problems will inevitably happen. Whether you caused them directly or not. It’s not a matter of if, it’s a matter of when. So when the problem does arise, let the relevant stakeholders (product manager, tech lead, teammates) know ASAP and then discuss with your tech lead or manager what you plan to do to fix it. The more calm and collected you are, the more confident you’ll appear. It happens to the best of us, and no one’s life is on the line. The only way to guarantee no bugs is to not write any code… It comes with the territory.
Do: Speak up in meetings ?
It may feel intimidating at first to be in a meeting with teammates who are all much more senior than you (believe me, I’ve been there). But don’t let it get to you. You’re a fresh pair of eyes, so something that seems weird or confusing to you, probably is exactly that: weird and confusing.
If you know the topic being discussed ahead of time, try Googling and doing some preliminary research prior to the meeting. If not, and they’re discussing a topic you aren’t familiar with, ask for a high-level explanation or some context. Do this at the beginning of the meeting. It’ll show you’re engaged, and that you care. If you wait until “question time” at the end, it won’t reflect well on you that you sat through an entire meeting confused and clueless.
Don’t: Continuously try to prove yourself ?
When you’re just starting out, don’t put so much pressure on yourself to do big, crazy, impressive things that will get you noticed by your team. You’ll waste a lot of energy, and won’t get the response you’re hoping for.
The truth is that everyone’s busy and focused on their own tasks and responsibilities. No one will notice or care that you completed a feature in record time or took on 8 extra features on top of your workload or never had QA find a bug in any of your features. So don’t kill yourself. It’s not worth it. Trust me.
What does help earn your teammates respect is being reliable, passionate, curious, and thoughtful. Show your team that you are on top of things by: thinking holistically about how your feature will impact other areas of the product, raising potential issues, thoroughly testing your feature (and asking others for testing ideas), bringing up potential edge-cases to the product manager, asking questions whenever you’re not sure about something, etc.
Bonus tip: If you really want to go above and beyond, choose to do a mini project that helps everyone on your team’s workflow. Pay attention and find pain points in your work and create a small shell script to automate it. Or if your team uses Slack, create or find an integration that will help. Make sure that there’s really a need and that this would be a convenient way to solve it. Ask a teammate what they think and if they can review the code with you. You’ll get double points for taking initiative and creating something that helps everyone in their everyday work.
Do: Be extra communicative ?
I initially had the mindset of “just put your head down and work”. If the designer made changes, teammate changed the API unexpectedly, or you encountered a big bug that you need to take care of first, I thought I was supposed to accept it as is and keep working. I thought that saying something would come off as complaining or making excuses. No. It’s really important to communicate these things with the product manager and tech lead.
It is their job to prioritize features and delegate tasks according to everyone’s time schedules. If things come up that impact the estimated time allotted for the project, they need to know about it ASAP so they can adjust.
Additionally, it’s important for them to know why things are taking longer. Otherwise they might assume it’s because you are slow or not performing. That is NOT the case, and it’s important for them to understand that.
You won’t get complaints for over-communicating. But you will cause problems if you under-communicate.
Don’t: Seek acknowledgement from others ?
You just had an “ah, ha!” moment with the feature you’re working on. You’re thinking to yourself, “Wow, I can’t believe I just did that!” You impressed yourself and that should be enough. Your teammates might not even remember what it felt like to deploy their first feature, implement some recursive function, or do their first database migration. It’s exciting to you, and it should be. Find those people at work who you can share things with and who will be genuinely happy for you.
Do: Make an effort to learn keyboard shortcuts ⌨
Pay attention to your coworkers. You’ll notice they barely touch their mouse or trackpad. They can switch apps, jump around their text editor, and search and replace in their sleep. Learning these simple shortcuts will make you more efficient in your work and is another way you can “level up” as a developer. But don’t try to learn them all at once. There are even some great command line tools you can download. Ask your teammates for some tips and tricks.
Don’t: Say ‘yes’ to everything ?
Initially I said ‘yes’ to everything because I wanted to be a team player and show that people can count on me. But, I was wrong, that’s not the way to do it. The only thing that resulted from that was me feeling overwhelmed, overworked, under appreciated, and caused me to lose focus.
“Focusing is about saying no.” — Steve Jobs
There needs to be a balance. As the junior, you’ll often get the tasks that no one else wants to do. That’s okay. You want to get your hands on all kinds of work and no matter how “boring” the task, you’ll still be learning. But, that task shouldn’t overwhelm you or make you regret saying ‘yes’ when another opportunity comes around that you now have to say ‘no’ to.
Do: Get involved in things outside of work ?
Figure out what you’re passionate about and then seek out opportunities to volunteer, find meetups to attend, get involved in groups/organizations, work on side projects, write blog posts, etc. Being a developer means being part of a community and sharing things with that community. So put yourself out there!
To be honest
It’ll take some time before you feel comfortable doing all 11 of these. It’s hard to master them all. Honestly, I’m still working on a few of these myself ?. But these are all things that I’ve learned from experience, and wish someone had told me when I was just starting out.
Try working on each of these one at a time. The key takeaways here are:
- Advocate for yourself
- Be confident
- Ask questions
- Surround yourself with supportive, encouraging people