Developer Handbook

This handbook aims to guide team members on their role as developers in the engineering team by providing detailed insights on:

1. What the role is really about.
2. In what ways the role overlaps and connects with the other roles.
3. The expectations from the engineering team’s perspective.

Core Principles

A key part of better understanding the Developer role is to grasp the following guiding core principles.

Ownership Mindset

Ownership mentality is one of the core company values. Ownership takes a preponderance in how each team member is expected to behave and work in the engineering team. Indeed, while in a leader-driven/top-down organizational structure, the project’s outcome would solely bear on the shoulders of the Team Lead, in a self-organizing and cross-functional squad, every team member directly impacts the outcome of a project. That is why every developer must treat each project as their own.

In software development, there is always a multitude of implementation paths. It is very rare that the implementation path is even clearly known — by the Team Lead or other developers in the squad — before one starts any task. The assigned developer must think thoroughly of the problem, perform research to remove unknowns, put their ideas to the test (e.g., find issues, use analytical tools, solicit feedback from others), and eventually, pick and implement the most viable solution for the project. Since they are the ones who always spend the most time on solving their assigned issues, they must become the ones who know best the problem and its solutions; i.e., they must become the expert for their assigned backlog items. In practice, once backlog items are assigned to a developer, they become the owner of their stories, i.e., they are entrusted to deliver the best outcome possible and convince others that the solution they chose is indeed the best outcome possible.

Ownership is also related to dependability, which is another core company value. A squad can only achieve the project’s goals efficiently if every member is dependable. Indeed, for instance, it would be inefficient if a developer solely relied on the Team Lead or their fellow developers to catch all issues in their pull requests once they completed their work, or if a developer would not inform about the blockers they face when working on their assigned stories. Instead, developers must communicate about their research, inform about the blockers they face, propose their implementation plan before working on the code, and perform a self-code review to catch all trivial issues that stem from the development process. The more ownership developers demonstrate on their tasks, the more they are dependable.

Wide Breadth of Skills

The Developer Track comprises ten levels with a common path from levels 1 to 7 and two specialization branches — the People and Technical paths — from level 8 to 10. Throughout the levels, developers are driven to develop T-shaped technical skills.

When on the Common Path, developers must grow their technical skills to cover all areas of software development (back end, front end, infrastructure, and testing) and be proficient with at least two programming languages (i.e., they can develop software for a project with either of the two programming languages). Developers grow the horizontal bar of the “T”. At this stage, for junior and mid-senior levels, the wider, the better.

By having a wide breadth of skills, developers have more individual growth outlets. In practice, developers can work on more diverse client projects, internal engineering initiatives, and Growth projects, thus acquiring more skills and experience. Inversely, a developer who would work only in a specialized area with a single programming language would have more limited options. In addition to projects and initiatives, continuous learning activities are crucial to broadening developers’ skills. Individual objectives, certifications, and self-learning efforts are essential. Besides technical knowledge, developers also strengthen their soft skills by being exposed to a wider range of technical areas. Developers become more open-minded (i.e., not entrenched in specific thinking) and empathic (i.e., they know how challenging frontend or infrastructure can be, for instance) individuals, thus collaborating more efficiently in squads.

Every developer is on a journey to discover how and what they like to work on. It is very uncommon for developers to know early on which specialization path or even programming language would be best for them. This is why developing skills in as many areas as possible and gaining experience in as many domains as possible can best prepare developers to define the path that would suit them independently. While it is common for managers to recommend a role or career path for their reports, at Nimble, developers are coached by their Engineering Leads to broaden their skills to confidently decide what they prefer to focus on in the future.

Team Player

Every developer plays a crucial role in building the best team. Developers must be active participants in the life of their Chapter(s) and Guild(s) (i.e., micro-level), and the engineering team (i.e., company-level). It takes the continuous involvement of every member to build a striving community of individuals, i.e., an environment where everyone feels like they have a voice, an impact, and enjoy working.

While developers are usually defined as individual contributors (IC), it might yield to behaviors considered inefficient and unwarranted since the focus is on the individual instead of the group. However, lone-wolf or diva-like behaviors, even if these developers are prolific ICs, are incompatible with the expectations of developers in the engineering team at Nimble.

At any level on the Developer Track, and even very early on in the initial levels, developers are guided to become solid collaborators and communicators. That is the reason why the Developer Track does not consist only of technical skills but even puts soft skills on the same par as technical skills. Developing software is inherently a collaborative process, therefore developers must develop their team player skills to be efficient.

Eventually, being a team player means that one internalizes that they can be part of the solution. While there will always be challenges that must be addressed either in their Chapter(s), Guild(s), or the engineering team, instead of spending vital energy on blaming others or feeling frustrated, they have the space to act and are empowered to improve their work environment and processes. It is not someone’s else responsibility to make improvements, but it is everyone’s responsibility. Strong teams understand that they need to move as a cohesive team to go far together.

Responsibilities

Write Code

The primary responsibility of developers is to write code for software applications as individual contributors. The latter means they do not have any leadership or management duties; they can entirely focus on the work required to deliver feature, chore, and bug stories on their assigned projects. Since each squad is dedicated to a single project, each developer can truly focus on doing development tasks on only one client project at any given time.

Developing software means writing maintainable, performant, and secure code at its core. However, at Nimble, developing software goes beyond this limited definition. Developers must not only write the code needed to deliver the requirements of their assigned stories, but they must also write automated tests (e.g., unit tests, integration tests, and UI tests) at the same time as delivering working code. While in some other engineering teams, a separate team of testers might be in charge of the testing work, there is no such separation at Nimble. Developers are responsible for writing the tests to verify that their produced code works. In addition, developers must continuously document the technical decisions, implementation details, and support information for their peers. Quality technical documentation is best achieved when done during the development process (i.e., so not after the development is completed) by the developers who wrote the application code.

In addition, developers are expected to work on all areas of development in their stack, namely frontend, backend, and infrastructure. Just like there is no dedicated team to write tests, there is no dedicated frontend, backend, or infrastructure team. The squads are small cross-functional teams consisting of versatile developers who can work in all areas. While new members might join the engineering team with more substantial expertise in one area, developers are trained and tasked in all areas of development on a client project. Developers are even encouraged to volunteer to work on specific tasks to sharpen their skills in one area whenever needed.

Eventually, in addition to writing code, tests, and technical documentation, developers do not simply execute tasks. They are not robots or machines. Developers are able-thinking humans who approach every project as their own, every codebase to fully understand the application being developed, and every task with a critical mind and the goal to deliver the best outcome possible. Nimble collaborates with clients to deliver quality code and solutions to achieve their business goals. Developers are key actors in making it happen.

Review Code

While developers are individual contributors, they do have a responsibility concerning their fellow developers: reviewing their code. This responsibility is as crucial as their primary responsibility of developing software. In practice, it means that, for developers, doing code reviews is as important as working on their assigned backlog items. Hence code reviews must be prioritized and performed with the same focus as writing code.

Contrary to developing software, for which developers can focus on a single client project, developers usually have to perform code reviews not only on their current client project but also on internal projects (e.g., template repositories, engineering initiatives, etc.), individuals’ projects (e.g., internal certifications) and sometimes on a second client project (when a squad does not have enough developers to reach the minimum number of approvals for pull requests).

The engineering team has guidelines and tools to make code review an efficient process. In addition, git analytics are used by Engineering Leads to ensure that their assigned squads have a healthy code review performance in every sprint. This demonstrates that code review is a key component of the engineering team culture. Hence developers must consistently demonstrate they are efficient and impactful code reviewers.

Collaborate with Peers

Developers never work alone. They are always part of a squad consisting of three to eight members. Even in the smallest squad configuration, a developer would work with a Product Manager and an Engineering Lead. Science demonstrated that groups perform better than the best individuals at solving complex problems; many brains are better than one. Therefore, collaboration with peers is always needed.

In practice, developers must consistently communicate their assumptions and ideas for their assigned tasks. When stories do not make sense or need more clarifications, they must flag and bring them up to the Team Lead and/or Product Manager. While both the Team Lead and Product Manager do their best to ensure all stories are ready to be picked up for development, developers are entrusted to share the blockers they face. Then, when development has started, developers must also continuously share their progress status with the Team Lead. Since the Team Lead must ensure that the squad can deliver the sprint’s goals, providing a progress status is an efficient collaboration mechanism. The Team Lead can know how each developer is doing without interrupting them.

Second, developers participate actively and meaningfully in the technical decisions for the project they are working on. The development team of the squad holds regular technical discussions on Slack and in meetings. While the Team Lead has the final say, developers have room to propose their technical ideas (e.g., RFC, POC, etc.), new technical-focused backlog items (e.g., codebase improvement chores, bugs found when testing the application, etc.), and technical priorities (i.e., what the squad should focus on). Therefore, developers must ensure they are active participants and not passive attendees.

Eventually, in addition to technical peers, developers must collaborate efficiently with non-technical individuals, namely Product Managers, and UX/UI Designers. They must know how to adapt their discourse so that non-developers can understand them and work with them efficiently. For instance, developers must clearly state their needs when requesting a UI asset to avoid unnecessary back-and-forth. Or, when some acceptance criteria written by Product Managers are unclear, developers must provide technical details that are actionable for Product Managers.

Contribute to Tooling and Processes

In addition to being a member of the engineering team, every developer is also a member of at least one Chapter (sometimes two) and, optionally, one or multiple Guilds. These sub-groups consist of developers who share the same technical interest and expertise focus. As a result, they are entrusted to build and maintain their tooling and processes continuously. For instance, the Android Chapter is in charge of defining its code conventions for Kotlin. Or, the Elixir Guild is in charge of building and maintaining the Elixir templates used to start every new client project on Elixir. Therefore, every developer must be an active participant and contributor to the engineering team as a whole and their Chapter and Guild(s).

In practice, active participation and contribution mean that every developer must:

• Be up-to-date with what the engineering team, their Chapter, and their Guild(s) are working on and focusing on.
• Take part in the discussions happening on various media e.g., Slack, GitHub, etc.
• Contribute to Compass, template repositories, and engineering initiatives.

The guide for team contributions provides all detailed information on the types of contributions and processes that every developer must follow.

A Typical Sprint

Since developers are members of a squad for a client project, an efficient way to visualize how all the aforementioned responsibilities can be fulfilled is to use a typical two-week development sprint schedule:

• Week #1
  • Day #1:
    • Review the planned stories for the current sprint and prepare questions or concerns.
    • Attend the sprint planning meeting held by the Product Manager along with the Team and the other developers. Raise the prepared questions or concerns.
  • Day #1 → Day #5 (Monday → Friday)
    • Review all pull requests on the client project.
    • Development of user, chore, and bug stories on the client project.
    • Regularly update the Team Lead on the progress and bottlenecks on the assigned stories.
    • Optionally, when assigned, review the pull requests on a second client project or an individual’s project (e.g., internal certification).
  • Any day between day #1 and day #5, but at least once per week, any of the following must be performed:
    • Review pull requests and contribute to the repositories maintained by their Chapter and Guild(s).
    • Review pull requests and contribute to Compass.
• Week #2
  • Day #6 → Day #10 (Monday → Friday)
    • Review all pull requests on the client project.
    • Development of user, chore, and bug stories on the client project.
    • Regularly update the Team Lead on the progress and bottlenecks on the assigned stories.
    • Optionally, when assigned, review the pull requests on a second client project or an individual’s project (e.g., internal certification)
  • Day #8
    • Prepare a short presentation or demo for the retrospective session.
    • Participate in the retrospective of their Chapter.
  • Day #10
    • Ensure enough room to support the Team Lead for the sprint’s release.
  • Any day between day #6 and day #10, but at least once per week, any of the following must be performed:
    • Review pull requests and contribute to the repositories maintained by their Chapter and Guild(s).
    • Review pull requests and contribute to Compass.
    • Work on a Growth project.

Performance

Metrics

When officiating in a role, beyond knowing the responsibilities, one must also know the key metrics to assess how well they fulfill their duties.

High and Consistent Velocity

As an individual contributor, unlike the Team Lead who has to allocate time for coordination activities, such as assigning stories or orchestrating code merges, a developer can dedicate themselves almost entirely to execution. As a result, developers are expected to be the most prolific contributors to a project. Their contribution is measured by their velocity in each sprint, i.e., the number of story points delivered.

Good performance in that aspect means:

• The higher the velocity, the better. Indeed, the more story points are delivered in each sprint, the more business value is delivered to end-users.
• The more consistent, the better. Indeed, velocity is used by Product Managers and Team Leads to plan future sprints. The more reliable a developer’s velocity is, the more accurate planning can be.

Short and Consistent Cycle Time

As a tenet of the team’s delivery metrics, Cycle Time provides a tangible measurement of how long it takes for code to be shipped. As a result, a developer must ensure that the code they write is shipped as fast as possible to benefit end-users.

Good performance in that aspect means:

• The shorter the Cycle Time, the better. Indeed, a developer must ensure they have efficient personal coding and code review workflows to minimize both Coding Time and Review time.
• The more consistent, the better. Indeed, a developer must demonstrate that they can achieve the same efficiency level in tackling any task. A constant Cycle Time results in consistent progress and delivery.

Timely and Impactful Code Reviews

Since code must be reviewed and approved by several team members before being merged, a developer must be timely in 1) reviewing the code of their peers and 2) resolving the code review comments they receive. Timeliness in processing code reviews is crucial to ensure code reviews are not a bottleneck in the development process.

However, speed must not come at the expense of code review quality. That is why the Code Review Depth metric measures a team member’s impact on the code review process.

Good performance in that aspect means:

• The sooner pull requests and code reviews are processed, the better. Indeed, the speed at which feedback is given and fixes are made directly impacts when code can be merged.
• The more detailed and thorough, the better. Indeed, code reviewers play a critical role in ensuring the team delivers high-quality, performant, and secure code.
• The more pull requests reviewed, the better. Indeed, the more code a developer reviews, the more they can impact meaningfully the code shipped.

Timely and Efficient Communication

A developer has to face unknowns and blockers constantly. What makes a difference is how they approach them and collaborate with their peers to have them resolve. While a developer is an individual contributor, they work as part of a squad. Hence they must know how to collaborate efficiently with others.

Good performance in that aspect means:

• The sooner issues are raised, the better. Indeed, since a sprint is a time constraint, the earlier a blocker is surfaced, the more time it provides to the squad to overcome it, maximizing the delivery of the sprint’s goals.
• The faster an issue is resolved, the better. Indeed, a developer must understand they are the most knowledgeable about their assigned tasks. When needing assistance, they must make it trivial for others to support them and get prompt resolution.

Regular Internal Project Contribution

Regardless of their seniority, a developer must demonstrate they can impact the engineering tooling and processes as a member of the engineering team. In addition, they must demonstrate they can balance both client-project and internal work.

Good performance in that aspect means:

• Regular contributions are more valuable. Developers who allocate time frequently to support internal projects have a more significant impact.
• The more engaged, the better. The engineering team members are the sole drivers of the direction of internal projects. So as a developer, it is essential to be proactive and open to exchanging ideas with others to maintain and improve these projects.

Best Practices

To avoid some common pitfalls, the following guidelines must be followed:

• DO schedule and prioritize team contributions at a fixed day/time slot every week.
• Do NOT consider team contributions as something to do when there is some time left on a given day.

👉  While the assignment to a squad takes up the largest part of a developer’s schedule, developers can always make room for 2-3 hours per week to contribute to the engineering tooling and processes. Having a fixed day/time slot ensures that developers are regular and consistent in their efforts.

• DO work in large blocks of time (i.e., 2-3 hours).
• Do NOT try to multitask as a way to achieve more work.

👉  Respect the need to be in a state of flow. Software development is a creative process, so developers should be on a maker’s schedule. In practice, developers should do code reviews in one block and development in another. There can be several blocks of code reviews and development per day but focusing on a specific activity is crucial to be efficient.

• DO consider code reviews as equally important as working on the assigned stories.
• Do NOT schedule code reviews as the last thing to do in a day.

👉  Code reviews are as critical as delivering the assigned stories. Therefore, code reviews must be prioritized. Doing code reviews at the end of the day usually yields the following negative side effects:

• Blocking the work of other developers. Oftentimes, they might need their pull requests to be merged to continue their assigned stories.
• Code reviewing only a few pull requests instead of reviewing all of them as there is limited to no time left.
• Skipping code reviews altogether when individuals are too tired to provide quality feedback.

Closing Words

Being a Developer at Nimble might likely differ from the expectations of other engineering teams. This purposeful take on the role of Developer aims to build a robust team of versatile, skilled, and experienced software developers who enjoy working together and growing as individuals while delivering efficiently what the company and clients need at scale.