By Kore Nordmann, first published at Tue, 08 Aug 2017 09:57:34 +0200
Download our free e-book "Crafting Quality Software" with a selection of the finest blog posts as PDF or EPub.
You can also buy a printed version of the book on Amazon or on epubli.
There are many different ways to teach topics of software developments. From recorded lectures to pair programming. Over the time we tried many of them with different customers and different topics. I want to provide you with an overview of what worked best for us for which topic.
From a producers perspective this is the most scalabale and efficient way of teaching. Just put the material online and charge for it. Why aren't we doing this then?
What we miss most, and this even applies to most online trainings, is the direct feedback from the participants. We want to make sure that everybody understands the intention and can apply their learnings to what they work on. For this we want to get immediate feedback and help every participant if something is not clear.
On top of that no recorded training will match exactly what you try to accomplish or your environment. Thus you learn something, then try to apply the learned knowledge to your use case and then need to teach it to all other team members.
For all those who prefer this way of learning we put our blog posts online, free of charge, which contain many topics we also teach. But as teachers and consultants we prefer the direct contact and feedback of the participants.
Traings or workshops are a great way to provide an overview on a complex topic. We make sure that you are able to weigh the risks of the decisions you'll make based on the workshop. During any workshop we already use all the following techniques, where it makes sense, to ensure everybody understands a topic in depth to make sensible decisions.
What is always required after a training or workshop is additional time allocated by the team to reflect on the workshop topics and transfer it to their real environment. We usually already try to simplify this path during a workshop, but this will never be sufficient. Just a few common practical exercises in a training on Testing with PHP can involve:
Simple Kata with PHPUnit
We use this to familiarize everyone with the involved tools. You need to be fluent and feel safe with a tool to use it in more advanced contexts.
Integration Tests / Accptance Tests in demo environment
To get used to the tools involved in makes sense to use the tools in a sandboxed environment most of the time.
Live testing the participants code
We show that testing the code of the participants is actually possible by finding sensible code and writing test for this code in their environment. We usually do this as live coding on the presenter and sometimes migrate to mob programming while doing so.
Even with all those exercises every company needs to make sure that the learners will get some additional time to apply their insights in their daily work. Otherwise most of the training contents will be forgotten after a couple of weeks.
This approach works for topics like:
To make sure that the participants apply the knowledge during their daily work we sometimes help them by doing remote code reviews for a couple of months together with the team to resolve remaining questions right on the project.
With Pairing on a set of problems we can increase the amount of transferred knowledge specific to the specific domain of all the participants. This especially applies to topics where the solutions are really dependant on the customers domain and environment.
For example it is hard to do trainings on topics like Continuous Integration & Delivery or Build Automation. A training can give an overview on the decisions you have to make and their consequences – but this will stay very far away from the practical implementation since there are just so many options and differences in all setups.
In such cases we prefer to pair with the customer, while a "pair" may include more then just two people. We can solve the pending problems directly together with the team and can illustrate the benefits and drawbacks of each decisions on the way to the solution. The team will learn a lot because all examples are implemented directly in their domain which eases the knowledge transfer – and there will even be a working solution at the end of the day.
Topics where this approach makes a lot of sense are:
For us as teachers it is one of the most rewarding approaches because we know that we provide immediate value to the customer. Also when working directly with the customers domain and envoirnment we learn most about their challenges and can provide the best advice based on our experience with many, many other customers.
Sometimes it is most effiecient to solve problems together with the whole team. This is most important when a shared understanding and collective ownership of a solution is required. This especially applies to problems where the participants already have (different) strong opinions or solutions did not work as expected and new ideas are necessary.
A simple example is everything related to "Clean Code", from Coding Styles to defined common Object Oriented Structures, as mentioned in Extended Definition Of Done. A more complex example are upfront architectural decisions. Even finding the best Test Mixture for your project can benefit from trying different test methods as a group and discuss their drawbacks and benefits.
Another good example is agreeing on a way to refactor your old code into a clean new state. For this the team first has to build a shared understanding of what clean code is. Live refactoring by the presenter can first show the team how the resulting refactorings can be accomplished. By doing the first refactorings ourselves we can show the team that this is easier then most most people expect. One can then switch to Mob Programming again so that everybody can try it out and lead the team for a while.
Thus we suggest this approach for topics like:
While it is challeging every time I personally love to show how approchable refactorings are even on an entirely foreign code base and how code can quickly evolve into something more elegant, understandable and mainintainable. Also designing new software components in groups and then discuss the reasoning behind those decisions is something most teams do not do often. In those discussions teams even learn from each other while we work as a faciliator.
Last but not least there is Continuous Code Review. No matter how much knowledge and enthusiasm a workshop creates in a team it is easy to get lost in your daily work. When the old problems are coming back and quick solutions are required it is always easier to fall back to your old working style. Also you will always discover problems which have been forgotten about in the initial workshop and finding solutions for those can take a lot of time.
What we offer teams starting with something new are code reviews for a couple of months where we can discuss their solutions and find the best way for them. We strive to write empathic, positive, complete and helpful code reviews because we want everybody to learn and improve. We believe that this is only possible if we can discusss solutions in a dialogue of equals between two professionals. While we might know more about (for example) testing strategies you definitely know more about your requirements, environment and domain.
This approach is especially helpful for topics like:
When people want to learn about a certain topic they usually think about tutorials or trainings. Especially half-understood knowledge from tutorials can even misguide you if there is no mentor to ask. From our experience there are more efficient ways of teaching for most topics. Therefore, when you request a workshop from us we will already use some of those methods. But you can also directly request pairing sessions on topics from us and you should do the same with other teachers. You will be impressed how much you can learn – and how much fun learning can be this way.
Stay up to date with regular new technological insights by subscribing to our newsletter. We will send you articles to improve your developments skills.
how do you write a narrative essay on Thu, 31 May 2018 11:30:03 +0200
Thank you for the article. Totally agree with you. Training, and the more so self-education and subsequent self-improvement - this is very important for any sane person.
Link to commentI, for example, also for self-study. After watching the video lessons, I was able to create a site on my own where you can find a lot of interesting information, eg, how do you write a narrative essay.
The main thing here is for a person to have this desire - to develop, learn. Because when there is no desire, no teacher and no video or books will help ...