We are a Team

I Need Help

This is to be expected. If you run into an issue where you feel stuck, and enough time has passed without progress that involving another person is warranted, do not hesitate to do so, many times just saying it out loud unsticks you.

Escalation Path

There is a well-defined escalation path to getting help. You can skip levels, but make sure you can articulate why:

Your project partner(s). Your first line of aid in every situation, it is what they are there for.
The resident expert (might be the same person as 1). This is the person who knows the area you are working on best. If you are in the backend, it's probably an Architect, the frontend is likely a Staff Engineer.
Your team manager. This person may or may not exist.
Derek. I'm here for ya when needed, don't hesitate to reach out, I just may not be the quickest response.

The exception to these is when you are onboarding, don't hesistate to reach out to anyone during that time, no matter who they are.

Huddle Up Meeting Etiquette

Whether with your boss or a colleague, be sure to respect others and ensure the person is at a good stopping point to answer your questions.

In addition, make sure when calling the person, that you use the "Meet Now" style functionality. This creates a meeting that starts at that moment, rather than just calling. This signifies to others when the people in the huddle are likely to become available again.

Code Review

Code Review is one of the most valuable forms of communication we have, is a great learning tool, and is what will make or break our code quality standards. Show respect for your fellow Engineers by giving a review in short order, this goes double for the more Senior members of the team.

Receiving a code review, even, or especially, one that provides lots of points of feedback, should be considered an act of love, an opportunity for learning, and a conversation starter. New members of the team should expect to initially receive many suggestions, as should more experienced members of the team coding in a new area. This can be a jarring experience and one difficult to initially react to in a positive fashion, but is one of the main tenets of Egoless Programming and a vital part of our teams' success.

My Boss

View your boss as being there to support you, not the other way around. We use the "inverted pyramid" or "servant leadership" principle, where management is the bottom of the pyramid, supporting the contributors, and the primary job of your boss is to support those who he/she manages, period.

Delegate to your boss by letting him know, accurately and in short order, the important things causing you issues in your role (No Surprises). If you feel issues are not adequately being acted on, say something again.

If you don't feel your boss is accessible enough to achieve this objective, make sure to make that known as well during your one on one.

One on One Meetings

These should be held very regularly, likely weekly, and be treated as sacred (rarely, if ever, skipped).

The meeting agenda, or non-agenda, should be set by you, but there are items that should always be covered:

What can your boss do, or stop doing, to make your work life better?
What is the most difficult item you have come across in the past week, and do you currently need help with it?
What is the coolest thing you have come across in the past week?

You should feel free to also not have an agenda, and just use the time to have a conversation. This is your meeting to have your boss's undivided attention, to use how you see fit.

Conflicts / Decisions

Conflicts are inevitable in any team who cares about their output. Conflicts may be hard to resolve, but they are not complex or mysterious.

There may be little advice that applies to every conflict, but we will do our best here. If nothing else, perhaps reading the below will help put you in the correct mindset for a discussion rather than an attack:

Approach conflict with ingredients (to collectively cook a dish), not precooked meals (to shove down others throats, like the world's worst potluck).
When someone is disagreeing with you, repeat their argument back to them for clarification, to ensure you are properly interpreting the argument and giving their voice respect.
Remember that your opinions are just that, and they are formed based on your experience, they are not facts. It is easy to get attached to your thoughts, and have them become your identity when someone disagrees. No one is disagreeing with you only your thoughts.
When in an extremely difficult disagreement, start by agreeing on the process to build the decision instead (get the ball rolling).
Sometimes the best outcome is not consensus, but for individuals to pursure their best alternatives with everyone committed. More important than consensus is everyone's commitment to the plan.

Ultimately, sometimes you just can't reach an agreement, in this case:

Bring the conflict to your boss together.
If, for whatever reason, your colleague refuses to bring the conflict together, re-invite him/her to do so, warn that you will bring it to your boss's attention alone, and then, and only then, should you do so (and you will be asked if this is the case).