DEV Community

Cover image for Advice to a New Engineer

Advice to a New Engineer

Michael Gardanier on November 08, 2023

Everyone who has started any new job (software or otherwise) can probably remember the first few days spent desperately trying to retain as much in...
Collapse
 
wraith profile image
Jake Lundberg

Great tips! 😄 These are absolutely things all new hires should be doing/considering.

In regard to #2, something I try to do is to batch a bunch of the small questions into a single interaction with someone. So rather than interrupting someone 10 different times, try to group a bunch of questions, and then ask the person 10 questions, but only interrupt them once. This isn't 100% foolproof, but it really helps. Just don't wait to have 10 questions before reaching out if 1 or 2 of them are blocking you from completing your task!

I'm so happy to see that you mentioned #3! In my opinion, this is the single best thing a new hire can do to contribute to the company right away. I encourage people to not only write down what they learned, but also what they were unable to learn without someone else's help. What questions did they have, and then what were the answers the got? Now that you have that information, tidy it up and post it somewhere public, like in the team's GitHub wiki, in a Confluence doc, wherever they are putting documentation. Now, the next person wont have to interrupt anyone because they can just read through your docs! I find new hires are the best people for this because after a while, you gain that "insider knowledge" and lose the ability to empathize with those that don't have it.

Again, great post, and keep up the great work!

Collapse
 
anotherengineer profile image
Michael Gardanier • Edited

I agree that batching questions is a good way to avoid pestering others, definitely something worth keeping in mind.

And I also agree that capturing the perspective of new hires is such a powerful way to learn about what it "actually feels like" to use the docs, setup guide, etc. After being immersed in a company for some time it is hard to truly empathize with someone new!

Collapse
 
jakemc profile image
Jake • Edited

Thanks for the great post, I loved 'ask questions' and 'don't ask questions' haha. But so true.

Most of all, I loved 'write down and track what you did/learned each day' - I wish I did this sooner... I wish I started blogging sooner, actually, to write down everything I learned and consolidate it in memory.

One tip I would add is to get good at project management (agile - kanban, scrum) and master:

1. Communication: deadlines, who is responsible for completing a task, and just plain communicating in a way that makes you nice to be around and motivates others around you. The last one is huge and gets missed by many, but basically, your opportunities in life come down to charisma (being highly competent AND being pleasant to be around/likable).

2. The project management tool your team is using: for example, my team uses monday dev which is kind of a new product from them and doesn't have a heap of documentation yet. But poking around and learning how to make the most of its features (bug tracking, retrospectives, roadmap planning) has definitely paid off in just making me look better at my job – especially the higher-level strategic things like roadmap planning and retrospectives. I'm angling for a promotion!

Full disclosure: I'm not an engineer, but I am a data scientist who works with engineers (of the software and ML variety). I genuinely think that the above applies to almost any role tbh...

Collapse
 
iamspathan profile image
Sohail Pathan

Nicely covered.

I wish I could have read this article when I was starting my job. I think I made these mistakes like asking too many questions, depending on my seniors, and trying to avoid long overdue tasks.

But I was fortunate because I got a chance to work with smaller teams, and that made me realize how important it is to respect others' time. Hence, I myself rote a blog to share what founders are looking for when hiring candidates in small/early-stage startups.

You can read it here: apyhub.com/blog/what-startups-look...

Collapse
 
jodoesgit profile image
Jo

I laughed at your first two. Because I am the queen of asking questions, but equally have shot myself in the foot by asking too MANY questions. And now know how to meter said questions...to a point =P! Nice read, thanks for the post =)

Collapse
 
anevskii profile image
Stefan Anevski • Edited

I liked this post so much, thank you @anotherengineer for this post. I found myself here because 2 months ago I got employed as a software engineer and all of the things you said here I'm going through them. I'll make sure that I follow those steps for sure!

Collapse
 
anotherengineer profile image
Michael Gardanier

Congrats on the new position, so exciting!

Collapse
 
eljayadobe profile image
Eljay-Adobe

The "Ask Questions" is very good advice.

I phrase it "Don't be afraid to ask questions."

And it isn't just for new engineers, it's for all engineers. Why? Because this stuff is hard.

Collapse
 
anotherengineer profile image
Michael Gardanier • Edited

Shhh, you're going to expose the secret goal of this post -- helping us all feel better about not being universal experts regardless of years of experience ;)

Collapse
 
tbowzz profile image
Tyler Bowers

Great post by a great engineer. I think your points highlights the value of an engineer being willing (and brave enough!) to communicate when things are hard. Forming the habits when new will translate to having the skills later on, too!

Collapse
 
anotherengineer profile image
Michael Gardanier

Yeah it can be tempting to hide when we struggle with something, but I agree that being open about it can be the best way to learn and develop quickly!

Collapse
 
jack94507501 profile image
Jack

This text is great to read, really great advice.

Collapse
 
stefanmoore profile image
Stefan Moore

I read something similar to this a while back. Thanks for posting this.