Recently our team at Unabridged was discussing company values. I listened intently as one developer after another described how much they appreciated working in an environment where we teach one another new and better ways of working. As a former teacher, I was delighted by this observation!
The conventional model of teaching suggests a kind of top-down flow of knowledge where the experienced teach, and the inexperienced learn. Translating that to business, we'd expect to see senior developers giving information to the more junior developers. However, the reality at Unabridged is more exciting and nuanced, one where developers at every level engage in meaningful teaching and learning.
Learning from Junior Developers
Generally, a junior developer will understand business and technical requirements but need an implementation path (or at least a nudge in the right direction) before they can complete the work at hand. In education, we call this scaffolding. Junior developers often need scaffolding—extra structure and support—to keep moving. They might not know how to classify the problem they are working on, or perhaps are unsure where to go for help.
And yet junior developers can do their share of teaching.
First, junior developers can teach one another. This peer-to-peer teaching is often more effective than help coming from a senior developer because there is direct and personal knowledge of the challenges, and the information that helped to overcome them.
Second, junior developers become experts in the features they build. In a good team, they will have opportunities to teach others how those features work and how to interact with them.
Finally, by asking questions, junior developers can teach senior developers which parts of the business domain and codebase are clear and which areas are confusing and challenging to navigate. A senior developer who has spent several months (or years) with a codebase has built a complex and nuanced mental model of their work. These models may allow them to forget all the work it took to build the codebase or overlook its many rough edges. Junior developers do not have this luxury. Their inexperience can help senior developers to retain a beginner's mindset.
Learning from Mid-Level Developers
Mid-level developers will usually be able to take business requirements and a loosely sketched set of technical specifications and get the rest of the way there on their own. If they run into obstacles or questions, they can do the metacognitive work necessary to recognize that fact and take appropriate actions and find help as needed.
Like junior developers, mid-level developers quickly become experts in the features they build but likely have a more holistic understanding of those features. In that sense, they also model for junior developers what feature ownership looks like, and can teach clients and users how the software works.
Mid-level developers are often called upon by junior developers for help. While teaching may not yet be a refined skill, with time and patience, their lessons usually stick. Mid-level developers will likely perform a lot of code review for junior developers, and their feedback is another mode of teaching.
In our organization, it's often our mid-level developers who drive innovation by testing out new technology and tools. Unlike junior developers, mid-level developers have some level of comfort and familiarity with the work and have extra cognitive overhead. And, unlike senior developers (who are often focused on projects and people more than lines of code), mid-level developers have the bandwidth to build POCs and share their learnings with the team.
Learning from Senior Developers
We expect senior developers to have technical expertise beyond what we would expect from a mid-level developer. However, the real distinguishing characteristics of a senior is their leadership, ability to navigate ambiguity, and ability to teach.
Senior developers work closely with our clients to understand their business, challenges, and goals. They use that information to generate business and technical requirements for the rest of the team. This level of leadership requires the ability to:
- Develop a deep understanding of the client's business domain.
- Teach other developers how to understand the business domain.
- Teach our client how to map their business onto the software we are creating, and vice versa.
- Establish shared definitions with our client regarding what a finished user story or feature looks like and what expectations can we align around.
- Cultivate the codebase and make broad technical decisions.
- Establish conventions and select tools.
A senior developer should be able to teach others the "how" and the "why" behind these actions while watching to see how their choices play out over time.
Senior developers should also be aware of the strengths and weaknesses of their team (and of themselves). This awareness will allow them to strike the right balance between providing opportunities for growth and getting things done quickly and correctly. While "correctly" is never negotiable, "quickly" sometimes is. When constructing those opportunities, senior developers teach in a myriad ways: diagnosing tricky bugs, or finding holes in test coverage, or making sense of unclear aspects of the business domain.
Developers at every experience-level have the opportunity to share knowledge, create mutual understanding, and set one another up for future success. Valuing teaching is less about being in a position of authority and more about asking good questions, building competence, and investing in others. The result is an environment where learning can come from any direction and a team that does better work.