Principal Software Developer Handbook

Hero image for Principal Software Developer Handbook

Welcome to the Technical path of the Developer Track đź‘‹

This handbook aims to guide software developers on the Technical Path (from level 8 to 10) leading to the role of Principal Software Developer 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 role of developers on the Technical Path is to grasp the following guiding core principles.

Hands-on Role

On the Technical Path, even as they gain extensive experience, developers continue to remain individual contributors, i.e., they have no people-management-related responsibilities, unlike developers on the People Path. They continue to execute similarly to — and alongside — their less senior developer peers, i.e., developers on the Technical Path are not only advising on technical solutions but fully participate in implementing them. As a result, senior and principal developers continue to code, review the code of others, build tools, etc.

These developers work on a client project as part of a squad in practice. Thanks to their seniority and experience, they regularly officiate in the role of Team Lead of their squad, but such a role is not compulsory. Indeed, they also regularly officiate in the role of Developer too. As part of the priority put on individual growth at Nimble, it is crucial to leave room for all developers to endorse leadership roles such as Team Lead.

People become leaders by doing leadership work

  • Act Like a Leader, Think Like a Leader, Herminia Ibarra

More often than not, in many organizations, software development leadership roles are reserved for a handful of most senior developers. However, such organizations do not build their future leaders. At Nimble, the role of Team Lead is open to developers from level 6 (the last level for mid-senior developers) to acquire the required leadership skills.

Since senior and principal developers work alongside less senior developers in a squad, they can continuously mentor and transfer their knowledge to those who need it. Keeping the most senior and experienced developers hands-on and integrated into squads is the key to growing the capabilities and efficiency of the engineering team as a whole.

Specialized Generalist

Over time, software developers work on several applications in different domains and generally with different tools (i.e., programming languages, frameworks, libraries, etc.). At Nimble, such a wide breadth of skills is purposefully built into the Developer Track so that, by the time developers reach the levels on the Technical Path, they have acquired T-shaped technical skills. As a result, they can efficiently work in all areas of software development (back end, front end, infrastructure, and testing) in their area of expertise (Web or mobile) and develop software with at least two programming languages.

At the same time, unlike more junior developers, senior and principal developers have usually acquired enough experience to develop more substantial expertise and interest in specific areas of development and tools (e.g., a stack, a programming language, or a framework). Indeed, with years of experience, these developers have gathered many data points and mental models that make them more attracted to specific types of programming work. The need for mastery is not only an essential element for personal motivation — as asserted by Daniel H. Pink in Drive — but also the natural progression for software developers. While initially in their professional journey, developers might constantly seek novelty above all, focus and mastery usually become later on as important as working on novel things.

When reaching the levels on the Technical Path, developers must already have a wide horizontal bar of the “T” and know what their focus area should be. As a result, they can then strive to become an expert in one focused area to develop the vertical bar of the “T”. For some senior developers, it might mean becoming an expert in infrastructure or a programming language such as Elixir or Go, thus allowing them to guide, teach, and train their peers internally and also in the development community at large. With several senior and principal developers on the Technical Path, with each a different focused expertise area, the engineering team can thus have a team of experts covering a broad and diverse technology landscape.

Over time, senior and principal developers might accumulate more than one core specialization or change their focused area of expertise altogether. Since software development is constantly evolving and developers — at any seniority level — seek novelty, it is common for some developers to move from one area or programming language to another.

Team’s Force Multiplier

While developers on the Technical Path do not have management responsibilities, they still bear a responsibility to their peers. They are the drivers of technical knowledge, advancement, and excellence at the team level; this is called force multiplication. To fulfill this responsibility, they must be at the forefront of engineering progress and best practices to continuously expand the capabilities of their Chapter(s), Guild(s), and the engineering team as a whole. They ensure that none of these sub-groups and the engineering team rest on its laurels but strive for excellence continuously.

In practice, senior and principal developers give away their legos, i.e., they teach others what they know, techniques, and best practices (what to do vs. what not to do). At the individual level, they mentor their technical peers continuously. At the team level, they create and engage in knowledge-sharing activities that can scale beyond one single individual. In addition, they are at the forefront of researching, adopting, and promoting novel tools and techniques for their Chapter(s) and Guild(s). They must be robust embodiments of continuous learning, i.e., it is not because they are senior and experienced that they stop learning or are closed to new ideas. As a result, they are constantly up-to-date in their area of expertise and actively engage the team on engineering initiatives and projects to expand and multiply its capabilities and efficiency. At last, they promote the engineering team’s technical expertise regularly to drive the engagement and interest of other team members and the development community at large.

Responsibilities

Developers on the Technical Path combine all the responsibilities of the Developer’s role, albeit with increased expectations, and a set of specific additional responsibilities aimed at contributing to the engineering team and the company as a whole.

Develop Software

Senior and principal developers fully participate in the development of applications and tools. They are hands-on on all types of development tasks, commit code, review code, and release code to production. They are assigned to one squad for a client project and a variable number of internal engineering projects. Thus, they continue working with their fellow developer, product manager, and designer teammates.

In practice, thanks to the high level of their experience and skills, the following expectations apply to developers on the Technical Path:

  • They are often in the role of Team Lead of the squad they are members of. However, they can also be in the Developer’s role as well. Their assignment for both of these roles remains limited to one squad at a time, so they can entirely focus on doing development tasks on only one client project at any given time.
  • They are prolific individual contributors to the project they are members of. In addition to consistent high velocity and efficient cycle time as key tangible metrics, they have a measurable impact on the technical discussions of the squad.
  • They guide teams on the best practice and outcomes for technical problems. While Engineering Leads are accountable for the technical implementation and delivery of all the assigned projects, senior and principal developers, regardless of their role in the squad, are expected to guide the squads to make the right decisions. Similar to Engineering Leads, they do not coerce but influence, debate, and persuade others.
  • They are efficient code reviewers, i.e., they demonstrate a high code review volume and depth on any project consistently. Thus, they can review code in an increased capacity, i.e., they review more code than less senior developers. Depending on the code review needs, they might review code for more than one client project, at least one but usually multiple engineering projects, and one to several Internal Certifications (IC).

Technical Progress Accountability

Regardless of the area of expertise, software development is in constant flux. New tools and techniques constantly emerge to improve teams’ capabilities or the Developer Experience (DX). As a result, an engineering team cannot rest on its laurels if it aims at delivering high-quality software and an efficient work environment for developers.

Senior and principal developers are accountable for ensuring the engineering team is constantly up-to-date and efficient in its technical practices and processes. In practice, as members of their Chapter(s) and Guild(s), they lead efforts and initiatives to constantly promote, trial, and adopt new tools and practices for the benefit of the engineering team.

Unlike Engineering Leads who have management duties, developers on the Technical Path can entirely focus on execution work. However, the latter must not be limited to their squad. Thanks to the high level of their experience and skills, they have room to contribute regularly and in an increased capacity beyond their squad. They are expected to create, lead, contribute and deliver engineering initiatives and showcases. They are also expected to be regular and impactful contributors to internal projects such as template repositories. The latter enables their Chapter(s) and Guild(s) to adopt new tools and techniques.

Create Learning and Training Resources

With experience accumulated over several years, senior and principal developers are in a position to mentor less senior developers. Many even develop a fondness or personal interest in teaching others. Indeed, as part of software development activities, developers repeatedly need to tell others how to do specific things or how things work, thus developing skills to explain technical topics to others. Therefore, they can efficiently mentor developers at an individual level to become better day-to-day. However, their impact must go beyond one-to-one mentorship.

As senior members of the engineering team, they are responsible for creating learning and training resources for the benefit of their Chapter(s) and Guild(s). In practice, they proactively turn everything they learn into learning materials for the team:

  • They share their notes on books, articles, and courses as documents or blog posts so that the team can digest the information faster and more efficiently than they did.
  • They curate and document best practices based on various sources that they have read or developed by themselves over time.
  • They create and update technical books and courses at Nimble University.
  • They create and hold training sessions and workshops on technical topics.

Creating long-lasting artifacts to transfer their knowledge to others ensures that their mentorship efforts scale beyond one individual. As the company grows, scaling efficiently, the technical know-how of the whole engineering team is crucial to maintaining a high level of excellence.

Lead Outreach Initiatives

Since senior and principal developers have a focused expertise area, aiming to be an expert in the latter, they are in a position to have an impact beyond the engineering team at Nimble. Instead of reaching tens of developers, they can reach hundreds or more developers. Many even develop a personal interest and motivation to reach out to a larger audience than their teammates.

At the company level, the engineering team aims to positively impact the local and global communities via sponsorship, for instance. However, beyond financial support, the engineering team also aims at other types of contributions such as:

  • Organizing, volunteering, and attending meetups, conferences, and other types of events.
  • Creating, maintaining, and releasing open-source software.
  • Promoting the company in tech events developers attend.

These efforts sustain and grow the local and global tech communities of the stacks and programming languages that the engineering team relies on and uses daily. At the same time, like in a virtuous circle, these efforts support making working with the engineering team attractive to other developers and companies, thus participating in the growth of the company as a whole.

A Typical Week

Schedule

Senior and principal developers on the Technical Path are members of a squad. Thus, they dedicate the most significant chunk of their time to a client project. However, they also need to fulfill additional responsibilities as senior engineering team members.

The following weekly schedule is representative of how they fulfill all their responsibilities efficiently:

  • Day #1 → Day #5:
    • Review all pull requests on the client project.
    • Development of user, chore, and bug stories on the client project.
    • Review all pull requests on a second client project, an engineering initiative, an engineering initiative showcase, and/or an individual’s project (e.g., internal certification).
  • Any day between day #1 and day #5, but at least once per week, each of the following must be performed:
    • Work on development tasks for an engineering initiative, an engineering showcase, or a template repository.
    • Review all pull requests on the repositories maintained by their Chapter(s) and Guild(s).
    • Review all pull requests on Compass.
  • Any day between day #1 and day #5, but at least once per month, each of the following must be performed:
    • Contribute to the repositories maintained by their Chapter(s) and Guild(s).
    • Contribute to Compass’ content, i.e., address open issues, open a pull request, etc.
    • Propose new engineering initiatives or showcase initiatives.
    • Involve in an outreach activity such as an event and/or an open-source project.
  • Any day between day #1 and day #5, but at least once every two months, each of the following must be performed:
    • Contribute to a learning or training resource.
    • Lead or participate in a Growth project.

Best Practices

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

  • DO involve other engineering team members in internal projects.
  • Do NOT try to demonstrate your knowledge and skills by single-handedly delivering work.

👉  Being a prolific individual contributor does not mean doing everything by oneself. As senior and experienced engineering team members, it is crucial that they consistently work alongside less senior developers. Less senior developers need role models to emulate. Mentorship and knowledge transfer can also be achieved outside of their squad assignments.

  • DO prioritize non-client project activities on a regular basis.
  • Do NOT schedule team contributions and activities as the last thing to do in a day.

👉  While the squad assignment on a client project must be prioritized on most days, other types of activities can take priority on at least one day per week or every two weeks (i.e., once per sprint). To be consistent in their efforts outside the squad, senior and principal developers must allocate time and prioritize work that will benefit their Chapter(s), Guild(s), and the engineering team.

  • DO constantly challenge yourself to become a better professional.
  • Do NOT rest on the laurels of your past achievements and current skills.

👉  With years of experience and robust technical expertise, senior and principal developers could develop a false sense of being fully accomplished or, worse, self-importance. As the software development ecosystems constantly evolve, there will always be new areas where they must learn and improve to be more capable and efficient. Therefore, it is wise to remain humble and open to new ideas to continue growing as professionals.

Closing Words

Unlike developers on the people path who have an internal-focused perspective (i.e., focused on their squads and individual reports), developers on the Technical Path are individual contributors with internal and external-oriented responsibilities. Internally, they lead and contribute to projects and initiatives while simultaneously creating resources and activities for the benefit of not only the engineering team but also the development communities.