Many of our customers are keen to take advantage of the exciting new features and productivity gains offered by new technologies and tools. However, their internal developers are often completely untrained in such technologies and are unaware of the best methods needed to pick up support of a complex new application. Training developers and teams to work with new technologies and processes is one of Ghyston’s strongest specialisations. We are constantly doing this both internally and with our customer’s in-house development teams.
Years of experience have shown us that the best way to transfer knowledge to fledgling developers, or those new to a project, is to make them part of the team, with as much visibility of the whole project as possible from start to finish. Put simply, the best way to learn is to do. Combining this core philosophy with a few more specialised techniques (below) makes a reliable and proven formula for knowledge transfer.
One of the hardest things for a less experienced developer is knowing how to get started with a new task in a new project; it is extremely helpful to have an example of something similar to work from. We begin each project with a “setup phase”, which has a basic “hello world” application as one of its deliverables. In this phase an experienced Technical Lead develops the fundamental underpinnings of the application, giving other developers patterns to work from when adding further functionality.
As development continues, the addition of new patterns remains the responsibility of the Technical Lead. With clean and consistent coding patterns to work from, developers can quickly pick up the fundamentals of a new technology and become productive at using it to complete a wide range of tasks.
Our strongest learning tool is code review. Every line of code written in our projects is reviewed by at least one other developer on the team. We use reviews as an opportunity for discussion: to explore different approaches, to point out any issues or concerns, and to agree the correct approach for the project. The developer will often make further changes before both parties are happy and the code passes review. Jake goes further into these benefits in his blog post on the topic.
This process improves overall code quality and consistency, simplifying future maintenance and modifications and as a result reducing the total cost of ownership. But the real benefit is in the learning opportunities. A less experienced developer reviewing an experienced developer’s code can learn much from seeing their approach to a problem. More importantly, an experienced developer will be able to give very helpful feedback and support on code produced by a less experienced developer, helping them to develop their knowledge of appropriate patterns and framework features, along with their knowledge of existing features of the codebase and coding standards.
Another less obvious benefit is that when a developer is aware that their code is going to be read, they are more likely to take the time to do things properly. In particular, they are more likely to take the time to research options fully and work out the correct approach to a task.
At the early stages of the project, or during the completion of a particularly complex task, it can be extremely valuable for developers to work as a pair. The pairing can contain an experienced and a less experienced developer, or could even simply be two less experienced developers. In the former case the benefits are clear; the less experienced developer can be guided through tasks and be given instant feedback and an opportunity to ask questions as design decisions are made and as code is written. In the latter case, two developers working together have a much greater chance of challenging each other on their decisions and assumptions, resulting in numerous opportunities to learn and develop.
Pairing can be particularly useful for complex technical tasks. For example, the setup and management of deployment processes is something that we would often partially pair on; working together to get things set up helps us to spot gaps, and leaves a greater number of parties familiar with the steps required in business-critical management processes.
We are strong believers that the best code is self-documenting; a developer should be able to understand code knowing only the business context and the underlying technologies thanks to strong naming and straightforward, consistent patterns. Therefore, we do not heavily document the code itself; instead we document the processes involved in development:
This documentation becomes an invaluable reference to new and ongoing developers.
Less of a methodology and more of a philosophy; we believe that a big part of getting developers ramped up on new technologies is making sure that they have the right support. Developers need to feel that their learning is as much a priority as delivering functionality, and the project needs to be structured to allow developers the time to get things done properly, maximising the quality of the code produced, as well as maximising the learning opportunities. In our experience, this approach saves time and money in the long run.