How Not To Annoy Your Senior Data Scientists, Engineers Or Developers

It’s a senior’s job to put up with you; make that an easy task.

Not yet working with seniors and want to break into data science? Create a job-worthy data portfolio. Learn how with my free project guide.

Author’s note: Part II of this story, revisited from a senior engineer’s perspective, is available here.

One of the most significant but least-talked-about hurdles when it comes to your first tech job isn’t applying, interviewing or on boarding.

It’s earning respect.

When you first start a new job, at any level, your co-workers are automatically skeptical of your abilities, your experience and even your personality.

As a junior, especially in your first job out of college, you’re under a different kind of microscope.

Luckily, being a junior has its benefits, like the understanding that you’ll require mentorship. The best employers will make sure you receive quality, hands-on and patient mentorship.

The rest will stick you with a seasoned employee who may be less than thrilled you’re now their problem.

As someone who was recently new to data engineering and the tech industry at large, I spent many of my first months on the job trying to be as self-sufficient as possible.

In the process I developed strategies that, over time, made me less reliant on senior team members and, by extension, allowed me to make more of an impact.

Take (And Refer) To Notes

I’m sorry if “write it down” isn’t groundbreaking advice.

However, when you’re in a new environment, especially a new job, handwriting information helps you retain it quickly.

While I’m not sure if companies have an official “clock” for junior development (I wouldn’t be surprised to learn this was the case) they certainly have broader expectations of progress, i.e. by their second quarter they should have completed roughly x JIRA tickets.

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.

The last reason you take notes is so obvious that it sounds like I’m reaching here.

The act of watching someone take out a pen and paper shows they’re engaged and invested in next steps.

Believe me, this will put a senior’s mind at ease.

Well, at least, until they give a scathing review of your code.

Test Your Code… And Offer Proof

After one too many deployment failures (thankfully nothing catastrophic), my senior team members have implemented a new rule when it comes to raising pull requests.

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.

Since we’ve adopted this rule as both the reviewer and submitter (committer?) I’ve had less trouble with deployment.

This isn’t because I’m writing better code, necessarily.

It’s because, with a higher bar set, I’m taking more time to proofread and test my work before submitting.

If you want to go above and beyond as a new hire, remember one word:

Test.

Everyone has their own strategies for testing code but, to me, the best way to evaluate your code’s functionality and quality before deployment is to create and activate a virtual environment (PyEnv is a favorite).

One thing seniors hate to hear when code fails in production (I know because I’ve said it a lot) is “it ran in my environment.”

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

Pardon the interruption: For more Python, SQL and cloud computing walkthroughs, follow Pipeline: Your Data Engineering Resource.

To receive my latest writing, you can follow me as well.

3 Before Me

3 before me is a phrase elementary school teachers use that requires students, when faced with a problem, to consult three different sources of information before asking the teacher for help.

Oddly enough, when I interned on a TV production, this meant ask one of the 25 other interns before bothering our overworked, underpaid boss.

As strange as it sounds, this strategy can be applied to tech work too.

On my team we have a soft rule of reaching out to someone else for help if we’re absolutely stuck for more than a few hours.

I used to be a frequent abuser of this rule as, admittedly, I’d get frustrated and overthink problems.

If you absolutely need help but think you’ve relied on a senior teammate too much, make a lateral move.

Chances are, there’s a peer on your team who may be nearing the senior position but hasn’t received a promotion yet.

Or, there simply might be someone who isn’t as busy but can offer a different perspective.

I’m a firm believer in the idea that I can learn something from anyone so I’m not above asking someone comparably newer than me for their perspective on a problem.

Seeking a lateral source of help accomplishes two things: It builds camaraderie among peers (no need for dumb power struggles or politics if you’re humble enough to ask someone in your position for help) and it frees your seniors up for the many projects they have on their plates.

For Every Question, Offer A Possible Solution

In addition to judging your problem solving skills, more senior team members will likely notice how you’re asking for help (when necessary).

You have to realize that asking a superior for help is like Googling something in that you won’t receive a sufficient answer if you don’t provide the right context.

Frankly, it isn’t helpful to ask a conceptual question without knowing why you’re trying to do an operation.

For instance, asking whether you should convert nested JSON to a data frame or keep it in its original form is highly dependent on your use case.

Additionally, when answering these questions, your senior teammate is going to have to take time out of their day to replicate your situation or pick apart your code.

Make life easy for them by accompanying each question with a possible solution you’ve tried already.

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.

Be Confident But Transparent

While I’ve been fortunate to gain some marketable skills and valuable real-world experience in my role, the greatest asset I’ve gained is confidence.

However, I wasn’t initially confident.

Quite the opposite.

I often made the mistake of downplaying my skills when I should have been more assured in my ability to solve problems and contribute.

Senior team members appreciate someone who they know they can trust with low to medium priority tasks with little supervision.

Like note taking, simply appearing confident helps put the other person at ease, especially when that person is still somewhat skeptical about you.

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.

The flip side of this is that if you don’t know something, speak up.

My senior team members were great at making me feel comfortable admitting I hadn’t encountered a certain term or programming concept.

A pair programming session or kick-off meeting isn’t the time to pretend you know everything. Ask any question, no matter how basic.

It’s much better than having to ask for clarification later.

Takeaway

Having recently been the new guy on my team that definitely annoyed my teammates with my questions and, simply, my “newness”, I empathize with any of you who are hesitant to bring things up for fear of looking “dumb.”

Even though this post contains tips to not annoy your teammates, I want to mention that I’ve been lucky to benefit from some very patient and knowledgable on-the-job mentorship.

Chances are, you’ll have a similar experience.

Remember that when teams hire a junior they’re not expecting a PhD-level full-stack developer.

They’re bringing on someone who knows enough to get started but still needs room to grow.

There will certainly be growing pains and you may feel like you’re an annoyance for those above you.

But remember you need to do everything you can to feel comfortable, confident and capable.

And, above all, remember how you feel so you can be patient and empathetic as you help the next generation of talent.

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.