A friend of mine asked me this in our quarantine Discord the other day:
Any advice on how to make a good first impression to my manager and my team? I start Monday 😀
Advice for new grads should be more specific than the usual advice for standing out as a software engineer.
I'm excited to share what I've learned in the past 2 years.
It's tricky to manage a good impression IRL, especially remotely, but easy to tear down a good prior impression.
The trap I notice some smart new grads or interns fall into is trying to act like they know everything. Be humble and pleasant to work with. If you really want to, signal confidence in other contexts, maybe when talking about the things you're sure you're good at (like maybe you understand CSS specificity or obscure football trivia really well).
The majority of junior developers will maintain code the majority of the time. If you're maintaining code that's frustrating to read, don't let frustration lead you to think, "oh, this code is so stupid, what dumbass would write it like this?!" and maybe even embark on a risky path down a rewrite no one asked for.
Maybe you're partially right, but there's also a good chance you're wrong.
There are obviously counterexamples to the above, but those are just things to keep in mind. You always reserve the right to be frustrated, I mean hopefully they're paying you a lot for your patience.
I forgot where I heard this from, but there's a saying that "the young make up for the old in speed and the old make up for the young in experience." This holds some truth on a software development team: the young are spry, ready to move fast and break things, whereas the more experienced are calm and calculated, making long-term decisions that don't bite the team back in the future (in the form of technical debt). This could be a powerful dynamic, respect it.
Here's what worked for me:
This held true for working life in the office and at home as well, but it doesn't impress me much when someone sends me a Slack notification or stays in the office until 3am (unless 3am is when they think they're productive).
Humans are probably capable of 6-8 hours of productive and creative flow time per day (writing code and prose, not shuffling emails). My idea of a "good engineer" is one who balances their time efficiently, understands the most important, high leverage things to work on, and spends their time on that.
The value of engineering as a discipline is literally leverage, that is reducing the time for people to do dumb tasks, including the way you engineer. Let me get into that when I talk about going faster. For now, understand leverage as: impact produced / time invested
.
What are examples of "high leverage" things? It's hard to think about especially if you're not being assigned interesting work. But tons of "uninteresting" work can be high leverage (and actually fun once you get into it):
One of the highest leverage things you could do when you're not being assigned interesting work is to prove you're worth assigning interesting work to (assuming your team has reasonable people assigning work).
To prove you're worth assigning work to, live out the four characteristics I described above, but also help yourself go faster. What a perfect segue...
To go faster, invest in tools that improve your workflow. Demonstrate curiosity about more senior engineers' dev workflow. Some examples:
Think about the resources you encounter when you research towards solving a problem:
It's useful to be reflective about the relevance of the documents you're parsing and decide if they're worth understanding the details of now or later. This can save you time from going down a rabbithole. Though I will say, old design docs and product briefs can be super interesting to read!
A related skill is knowing how to Google effectively.
I walked into my first job (a startup) with this mindset (no one there asked me to think this way):
Rainier, you're the first new grad engineer hire at this startup. Right now and for the next few weeks, you're costing the company more than anyone else (think about the resources that went into hiring you and the time you'll take from senior engineers pairing). Your top priority is to be productive and impactful as quickly as possible.
Obviously, you don't have to approach it this direly at like, Microsoft. And no matter where you are, don't feel "selfish" with other people's time—if an senior engineer helps you with a task that you would've been stuck on otherwise for 5 hours, that's 5 hours of the team's time.
A more specific analysis of the time tradeoff would go like this: Well, if I ping an engineer in flow, it'll probably take them 30 minutes to switch context back to whatever they were doing, plus the time they'll have spent helping me, plus the time I'd been stuck on it prior to messaging them. If you're working in an office (unlikely as of the time of this writing, so you're already doing this unless you're calling them on the phone), you should instead message them asynchronously (e.g., on Slack) if they seem busy.
On the flip side, you will learn by struggling a ton and you shouldn't ask your hand to be held for every complex task. As a happy median, timebox your confusion. If you're stuck on something for longer than say, 30 minutes, then ask. Also, I like to round robin my teammates if the thing I'm stuck on is something anyone on my team can help with.
I had trouble keeping up with this, but I've recognized that as we're working remotely now more than ever, a frequent writing habit for your reflections and wins can come in handy when you're thinking of things to talk about with your manager—and justifying a promotion or comp adjustment during performance review season. What are things I write about?
I like these because they're a paper trail, these writings are artifacts of your personal growth and accomplishments outside of your GitHub commits.
If you made it to the end, you likely care enough that you'll be at least ok. You can do this! Good luck.
Did I miss anything? Feel free to reach out to me @rainieratx or via my contact form.