L1.md

L1

Overview

An L1 is an entry level or early career developer who has had formal training or equivalent experience in software development.

Responsibilities

An L1 is expected to demonstrate initiative, take ownership of their work product, learn quickly, communicate effectively, and collaborate fully as a productive member of the development team. They are expected to follow their team's software development process, and to treat their co-workers with respect and kindness.

The following sections provide more details on expectations for an L1.

Impact

The primary responsibility of an L1 is to make a positive business impact. To do so, you must first be productive and deliver on your tasks. This means:

• Writing code
• With quality
• On time
• To meet project requirements

Writing high quality code quickly is not the only way in which you are expected to make an impact. You are also expected to:

• Participate in code reviews
• Help other engineers when they come to you with questions
• Discuss potential efficiencies with PMs and other business partners (for example, you should let them know if they can get 80% the benefit for 20% the effort)

Ownership

You are expected to own your project end-to-end, and are responsible for designing, coding, testing, merging, and monitoring your end-product. Engineers own the quality of what is released, and are responsible for the underlying code and platform. Every engineer has the right - and responsibility - to prevent a release from going out if the feature/code isn’t ready.

Concretely, taking ownership of the success of your project means:

• Coming up to speed on relevant technologies, tools, and areas of the code base necessary to complete the project
• Writing quality code at every relevant level of the stack
• Asking for help when you get stuck
• Communicating project status to your manager and PM
• Writing an appropriate level of automated testing
• Testing your projects before committing
• Getting code reviews before committing
• Considering downstream and operational impact from - and risks related to - your changes (memory usage, number of service calls, etc.)
• Not breaking the build (and rapidly fixing it when you do)
• Testing your projects on all appropriate platforms (e.g., desktop and mobile) - if it isn’t tested, don’t ship it
• Following the appropriate process to meet compliance requirements

Taking ownership of your mistakes means:

• Communicating proactively, honestly, and completely as soon as you’re aware of a problem - bad news can’t wait
• Publicly taking responsibility for your mistakes, and fixing them
• Watching for build breakages after your commits, and assuming they were your fault until and unless you’ve determined otherwise
• Addressing any errors caused by your code
• Focusing on addressing problems, not assigning blame
• Learning from your mistakes - by writing a new test, a post-mortem, a JIRA ticket to fix fragile code, a playbook, automation, etc.

Process

When you receive a new task, you should go through the following checklist:

1. Read through the task specification to understand its requirements and goals

2. Follow up with the PM to clarify any confusing points

3. Consider different implementation options, and discuss with your lead and PM. Some examples:

   • A quick and dirty approach that gets the job done at the cost of later clean-up
   • Writing your code within the existing context
   • Refactoring and cleaning up existing code

   In all cases, the choice and its long-term consequences should be considered carefully. This means that all tradeoffs are accounted for, tickets opened if necessary, and follow-up work scheduled (especially when a quick and dirty option is selected). The developer is responsible not only for providing options, but also for the long-term health of the code base.

4. Ask the appropriate expert(s) on the impacted code for input on your approach

5. Update the LOE to reflect your personal estimation of the effort involved

6. Provide testing steps and/or use cases to follow once the code is ready to test

Each team does things differently, and following a team’s process is important as it is often optimized for what the team needs to deliver. Not following a team’s process may also impact its ability to meet certain compliance requirements (e.g., getting an appropriate level of code reviews to meet SOX compliance). You are expected to follow your own team’s processes, and to adapt to local processes when working with another team, or in another team’s area of the code base.

Culture

A successful culture supports distributed, fast, effective development.

The following are core aspects of this culture:

• Get shit done
  • Don’t let yourself get blocked - speak up and escalate if forces beyond your control are preventing you from progressing
  • Prefer simplicity of design, implementation, and feature set - don’t over-engineer
  • Minimize meetings
• Reinforce a positive, collaborative, high trust, respectful team environment
  • When someone asks a question, answer in a way that will help them to succeed
  • When you have a question, investigate on your own first - but don’t spend too much time running into dead ends before asking for help
  • Don't dominate conversations - make sure all participants have a chance to speak
  • Treat your coworkers with respect and kindness
• Be a role model for how to develop, test, and deploy high quality code
  • Meticulously review your own code reviews before asking anyone else
  • Add an appropriate level of automated tests

Communication

It’s critical to keep stakeholders (your manager, PM, any other business partners) in the loop with regards to project status and crises. When things are going well, this is important so that they know about the great work you’re doing. When you’re having problems, this helps them understand the situation and provide support as necessary. Bad news, in particular, can’t wait. You are expected to keep project management tools such as Jira up to date.

Concretely, communicating effectively means:

• Clearly communicating project delays, roadblocks, overall progress, etc. Project stakeholders (PM, manager, lead, other engineers) should feel they are in a tight loop regarding status.
• Keeping tasks up-to-date in your team’s project management tools. Give particular attention to the information your manager needs in order to understand project status (e.g., assignee, status, sprint, story points, etc.).
• Breaking down large time estimates into detailed lists of sub-tasks, each with its own time estimate
• Erring on the side of over-communicating status and issues. Don’t wait to be asked - be proactive!
• Writing design docs with an appropriate level of detail. Communicate with experts or stakeholders about your design beforehand.
• If you see something, say something - proactively report any technical or team issues to your manager or HR partner, when appropriate.

Growth

Engineers are expected to be continuously improving their skills and growing in their careers. An L1's growth goal is typically to improve quality, speed, and reliability; to become comfortable with the code base, toolset, and process; and to take on more complex projects.

As part of your 1:1s, regular reviews, and year-end performance evaluation, you and your manager will work out individual goals for personal growth. You are expected to actively work on these goals, and to demonstrate progress over time.

While managers are tasked with mentoring and guiding their teams, engineers are expected to own their own growth. They can (and should!) ask for guidance, opportunity, and feedback, but ultimately it is up to each individual to progress.

Anti-patterns

While the following problems can happen at any level, they are particularly common with new engineers.

• Cloak of invisibility. When a project starts going off the rails (something that happens to everyone), it’s common for the engineer involved to go completely incommunicado, in an attempt to catch up before anyone notices. This never works. The first rule of getting out of a hole is to stop digging - communicate status, get your manager, tech lead, and PM involved, and figure out a plan to get back on track.
• Low output. It’s easy to get caught up in urgent but unimportant tasks (e.g., email curation), and fail to complete the work you’ve committed to.
• Sloppy code review requests. When you post a code review, you’re asking multiple other people to take time away from their own projects to help you out. It isn’t unheard of for code reviews to contain egregiously obvious errors. You should review your own code in meticulous detail before asking anyone else to spend their time on it.
• YOLO commits. Never commit code without first compiling and testing it. Run any applicable automated tests. A large number of build breakages and P1 bugs are caused by code changes that were “so simple they didn’t need to be compiled or tested”.

Next up: L2