How Not To Annoy Senior Developers — Sincerely, A Senior Data Engineer

Not yet in a position where you’re reporting to a senior teammate? Jumpstart your data science portfolio with my free, 5-page project ideation guide.

In undergrad, my least favorite part of every class was the first day of school. Aside from the syllabus distribution (kicking off “syllabus week” at most large universities), the first day was significant because, in many classes, we had to stand up and introduce ourselves. If you think this is an awkward and strange dynamic to navigate in a conventional college, try doing this in a room full of future on-air reporters. Through several credit hours of trial and error I eventually perfected the very niche skill of concisely but memorably introducing yourself.

Fast-forwarding years later, in my virtual workplace, we typically do introductions and meet & greets with new hires. Along with our location and a fun fact, we’re asked to explain our responsibility at the company. My go-to line was “I do what (senior engineer) tells me.”

Unfortunately, I can’t use this line anymore because I’ve assumed a senior role myself. Even though the promotion was fairly recent, I had been steadily trusted with more responsibility prior to management making it “official.”

If you’re unfamiliar, in tech, a senior ___ role isn’t what it may be in other professions. In many places, it’s the next rung up the ladder (or the MAANG alphabetical salary band). So it’s not like I’ve suddenly gained a ton of authority.

But the past several years of putting in time working with stakeholders, technical partners and more junior team members has provided me with a great deal of experience in understanding how to function and thrive in a technical environment. Through introspection and observation, I’ve also learned what not to do. So I figured now is as relevant a time as any to revisit a piece I wrote over 2 years ago at the time of this publishing: How Not to Annoy Your Senior Engineers.

This isn’t a Festivus-esque airing of grievances. Instead, I want to share strategies that, from a more senior team member’s perspective, can make you a team asset in less time.

Slack Status: (Pro)Active

When I began my role, I used to think being proactive just meant doing a lot of work–even before it was assigned. I wrote a ton of documentation, refactored code and generally grinded.

The sum of these contributions was productive but not as impactful as you’d think. Having gained more experience, I understand, more accurately, what proactivity means in a technical context.

A proactive development mindset isn’t as simple as volunteering for every task and happily doing grunt work. It’s about finding ways to tangibly impact your team and, by extension, your organization’s performance.

Some examples of how junior developers can demonstrate proactivity:

• You find a bug in a script and, without asking whether you “should”, you submit a PR with the fix (tested, of course)
• You check high-profile data sources and address any cleanliness issues like deduplicating–before the dashboard goes to the C-suite
• You find an opportunity to implement a tool or practice and don’t meekly ask “is this a good idea?” You pitch directly and confidently to your boss

Mastering this perspective will make you anything but annoying to those above you. In fact, you’ll be making their lives exponentially easier.

Proactivity Extends To Communication

Being proactive in a technical capacity is fantastic and will quickly make you less of a burden to those entrusted with your professional development.

However, there is one area that not only helps your team performance but also increases your own visibility: Effective communication.

In my previous piece I spoke of confidence and transparency.

Confidence in tech isn’t about always knowing the right answers.

It’s knowing that you’ve faced tough problems before and you believe that you will find solutions.

To make those concepts a bit more concise, I would bundle them together under a popular corporate buzzword: Ownership.

Even as a not-yet-senior developer, you have opportunities to take charge of and own a process.

One area I was able to hone and demonstrate my technical communication skills was in corresponding with vendors.

After the first few times of asking my seniors “Should I make a support ticket for this?” I began asking myself and, predictably, the answer was almost always an emphatic “Yes!”

In time I came to memorize the various technical account managers (TAMs) or support contacts for the various third-party products we relied on. Even if the process wasn’t something I developed, one of my main jobs as a junior engineer was to troubleshoot and fix broken scripts.

By proactively communicating the issue to both support and my team (CC’d on emails), I established myself as the point person for that issue, demonstrating that I could responsibly and independently communicate complex topics with outside parties.

With larger-scale builds and looming deadlines, this kind of communication and minor troubleshooting isn’t something that senior team members always have time for.

Make it your problem and you’ll be profusely thanked.

Open Source Your Learning For The Future

Recently, I spent 30-minutes talking to a new contractor through a process I designed and coded 2+ years ago. I spent most of the time reviewing and elaborating on a comprehensive document I wrote outlining the process.

The first question I asked as we began our session? “Mind if we record this?”

In my original piece I wrote of the importance of taking and referring to thorough notes.

Being able to record your senior’s thoughts, advice and requests on paper will reduce the necessity for follow-up questions, which can delay a development process.

Never mind that there is significant scientific evidence that hand writing notes increases retention of critical information, like what you need to make it through your first day, week, month and year on the job.

Having been on both sides of training and/or learning sessions, I want to advise you to take this a step further: Don’t hoard knowledge.

If you have a pair programming session with a senior team member or you are writing documentation that might benefit a future addition to the team, take the initiative and seek ways to “open source” what you’ve learned among your teammates.

By recording my session with the contractor I not only ensured that he has a thorough understanding of the process–I also increased the possibility of not having to give the same talk again.

Even with uncertain economic conditions (at least in the U.S.) impacting the tech job market, engineering teams tend to have a “revolving door” quality to them. Just because you might not ever refer to a certain section of your notes again doesn’t mean that a future addition won’t find them helpful.

Follow Procedure And Test, Test, Test

There are two cardinal sins in development areas from software engineering to data science:

• Don’t merge on a Friday or on a non-working day
• Never commit to main

Both these rules are industry standard because programming is already an objectively difficult discipline.

Introducing the possibility of breaking a build at a low-traffic time is tee-ing up a disaster.

As you gain more confidence (something I spoke of in the previous edition of this piece) and proficiency, you might be tempted to break either or both of these rules.

Not only do we need to test our code, but it would be helpful to reviewers if we included screenshots of logs demonstrating the output.

If you mimic production conditions, including the proper dependencies, you’ll be submitting robust, reproducible code.

Even now, years into my role, if I need to merge something directly to main (a “hot fix”), I try to give a heads up or, if there’s more time, clear it with the higher ups. They know by now that I’m careful enough to have tested my fix but, nonetheless, I’m still hesitant in breaking the rule.

As a newer developer you don’t have the luxury of credibility. Just because you “know” something will work (spoiler alert: often you really don’t), does not mean you can or should defy procedure.

Always ALWAYS test before submitting for code review and before deployment.

Nothing causes more headaches for a senior team member, myself included, than having to submit multiple “re-reviews” because the committer made a syntax mistake that would have been caught if they had run the script even once.

Can you tell I’m pretty passionate about this one?

I’ve had situations where newer team members not only break this rule, but break it so blatantly it sets the team abuzz with frustrated chatter.

Take the extra time to review the procedure and test. And, if you’re hesitant, you can always ask a question, provided it’s framed correctly.

You can also rephrase your question to be more experiential than conceptual, so instead of saying “what do I do here”, you can ask “when have you encountered this?”

This kind of rephrasing demonstrates that you’re not just interested in a quick answer; you want your senior to share their experience so you can go off and solve the problem.

You’re not being spoon-fed. You’re being nudged in the right direction.

The corporate hierarchy exists for a few purposes. To maintain your place within that hierarchy and even ascend, the best thing you can do is observe those above you. Figure out what their workload pain points are. What their knowledge gaps are.

Working not just in service of your company, but in your immediate superiors or more experienced team members will accelerate your own advancement.

And, most importantly, make everyone’s life just a little easier.

I need your help. Take a minute to answer a 3-question survey to tell me how I can help you outside this blog. All responses receive a free gift.