Standing out as a new SDE

No doubt, as you start your journey as a software developer, there are countless things to learn and improve upon. Here, I'll share a few subtle yet immensely impactful practices I've seen make a real difference.

Picking up on patterns

Your very first PR can be... let's say, a revelation. You're likely to receive several review comments, and rightfully so, because there's so much to writing production-grade code, beyond syntactic and semantic correctness. Besides refactoring, better variable nomenclature (can I interest you in a meme? 🃏), covering corner cases, addressing Sonar vulnerabilities and boosting test coverage, it's possible to receive comments based on coding conventions, styles and patterns that are specific to your team/product. A few of these, you might find, tend to slip your mind. Creating your custom, organized checklist for a pull request can help in such cases. If you're feeling experimentative, there's actually a way to set this checklist up on git itself: say hello to git hooks! It runs through all the checks you've set up before allowing you to commit.

Everyone likes someone who only has to be told things once. (But don't start overthinking your PRs though! Remember, you're still new, and making mistakes is good to an extent; it helps you learn and grow fast.)

If you have the time and interest, exploring related repositories and walking through the code early on can provide valuable insights into your team's coding practices. Here's a guide on how to best read and understand huge repos that are new to you.

From bare minimum to nice-to-haves

This skill develops gradually, typically after settling into the primary demands of the job. However, being able to think beyond the basic requirements can make you a valuable contributor to the team. And what's more, it helps show you're ready to take ownership.

• Thinking about non-functional requirements (performance considerations such as compute and memory usage, response times and monitoring- including dashboards and alerts) was a very new concept to me. It's something that I had to practice to keep in mind, but when I started doing so, I realized it made my understanding of a service/product more mature and holistic. I was able to better contribute to the product.

• While making larger code changes such as introducing a new feature or workflow, think about future implications, and design your solution with that in mind. For example, ask yourself

  1. how easily extensible is this implementation, if this feature has to be expanded upon in future?

  2. is your implementation modular?

  3. are dependencies well-maintained and relatively new? Would community support be terminated shortly?

• The product team and senior devs have no doubt scoped out the work very well, and you have been presented with a very clear-cut set of requirements (often in the form of acceptance criteria). However, don't shy away from putting forth your little suggestions (for instance, haptic feedback on the frontend, or an additional dashboard for better visibility on your microservice); the product might be all the better for it. Especially when it comes to building internal tools and products, your feedback can be important.

Seeing the big picture

It's easy to get absorbed in day-to-day tasks. Simply completing assigned user stories can feel like a daunting challenge, especially when faced with a new tech stack, work environment, or project— which, for many newcomers, is often the case.

And yet- take the effort to step back and look beyond these tasks once in a while, and you'll find it an eye-opening experience. Engage with senior colleagues to gain a broader perspective. This might involve familiarizing yourself with your company's product portfolio at a higher level, exploring business aspects and commercial considerations, and even understanding the rationale behind key leadership decisions.

Why? Well, because-

• better understanding can sometimes mean greater motivation. At least, it does for me. Understanding how my work fits into the larger goals of the team- or better yet, the organization- makes me feel more motivated.

• it can help with improvisation and innovation. Knowing your North Star (haven't heard of this before? Check this. Basically, it's the primary goal your product or company is working towards) and understanding what you need to work towards can enable you to work smartly, rather than chipping away at one feature/bug with brute force.

• the process itself can be very rewarding, offering you a chance to interact with a diverse, talented and experienced pool of people you'd not have the strict need to interact with for your daily tasks. Simply put, it's a great way to open the door to an array of opportunities and to build a network.

More importantly, you might ask- how?

If starting up a conversation out of the blue isn't your cup of ☕, here are a few ideas

• following a town hall or team catchup, you could ask any clarifying or follow-up questions you may have to a senior, one-on-one. If you don't have any, simply try: "What were your thoughts on (an idea discussed in the meeting)?". Or, perhaps: "From your experience, what do you think might be the challenge with adopting this new workflow X?". Even simpler perhaps, is voicing your thoughts (excitement, doubts, concerns) to a colleague. It could spark an interesting conversation.

• participate in any technical competition; hackathons and ideathons are my favourites. Team up with folks from different teams, and make sure you approach senior colleagues from different departments for a quick feedback session. Most are kind enough to spare a half hour, even if they can't be a member of your team. "Hi, could you spare 10 minutes to hear our pitch? We have an exciting idea in the works and would love your critical feedback and thoughts". You'll be surprised to see just how many are genuinely curious and excited to hear new ideas, especially from a fresher.

Communication

Putting all that extra effort, but not effectively communicating is like putting in effort to build muscle but never flexing it. 😉

As important as going the extra mile to "see the big picture" and thinking about nice-to-haves, you must also communicate these efforts to your team. It helps you get feedback on whether you're taking the right approach to things or need a bit of course correction. It can also signal to your team and senior devs that you're curious and not afraid to punch above your weight. You're already exhibiting the drive to level up.

What better way to begin than at daily standups? Nothing too formal, but keep your update

1. structured

2. brief, but sufficiently detailed

   Jot down points if you tend to go off tangents or say too little.

   Also, make sure to organize your observations, thoughts, and ideas in a way that allows you to access them quickly. This way, you can easily bring them up in conversation whenever the opportunity arises.

Finally, remember that none of this should be forced- adapt these to suit your style, and in fact, let me know what works best for you.

That's all for now, see you in the next one!

Until then, onwards and upwards 🚀