Your First Engineering Job

There’s an unspoken set of rules for software engineers. They don’t teach them in school, you won’t find them listed in a wiki or Readme, and they don’t exist in the company’s culture handbook. If you discover and follow them – which requires humility, discipline, and ambition – it will be the fastest way to gain respect from your peers and mentors.

Before you ask a question, do some legwork

When you’re heading down a logic trail and you come across something you have a question about, it’s natural to want to ask for help. Asking for help isn’t a bad thing, but if Google or StackOverflow could have answered your question then you are wasting someone else’s time — or potentially something far more valuable: their focus.

When you have a question, exhaust the obvious resources before interrupting someone. Next, take the time to provide context to your question so your peer understands the scope of the question. Lastly, remember the answer (or better yet, document it). Answering the same question more than once can become annoying quickly.

Sweat the details for code review

When you ask a peer to review your code, you’re asking them to take time out of their day to provide you the feedback you need to do your job well. Asking someone to review your code is very similar to asking for a favor and as such, you should try to be mindful of their time. To use an analogy, it’s like asking someone to help you move. When they show up at your house, everything should already be in clearly labeled boxes and ready to go.

The coding equivalent of having everything already in boxes starts with a great Readme. You should clearly state the background context for the effort, a summary of changes, and what specifically you’d like feedback on.

Next, you should review your code as if you were the reviewer to address the obvious feedback yourself. Style guidelines, syntax mistakes, indentation, trailing whitespace, unnecessary comments, running the test suite, etc. The more you fix before the actual review, the more time the reviewer can spend on more meaningful feedback (such as code design or patterns).

Feedback is a gift

While we’re on the topic of feedback, there’s nothing more valuable to your growth than critical feedback. Well intentioned feedback that is tailored to your desired career path is gold. Embrace it. It may not always be 100% spot on, but if you seek it from the right people, you’ll have what you need to propel you to the next level.

Volunteer for the grunt work

On every engineering team there are a lot of tedious tasks to be done. Unexpected bugs, escalated customer support tickets, deprecated libraries, you name it. Someone needs to do this work and there’s no better way to make friends on an engineering team than by being the first one to volunteer when one of these tasks pop up.

Having a great attitude goes a long way

Morale is an accumulation of everyone on the team regardless of experience. Considering there are very few things more important than morale on a team, it’s a great way to make an impact if you’re new. Be positive, try not to complain about legacy systems, and be grateful for feedback. There’s a reason teams have the following rule: don’t hire brilliant jerks.