Qafoo GmbH - passion for software quality
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:Author: Kore Nordmann
:Date: Wed, 28 Jun 2017 07:26:46 +0200
:Revision: 7
:Copyright: All rights reserved
===================
Methods Of Teaching
===================
:Abstract:
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.
:Description:
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.
:Keywords:
teaching, workshops, pair programming
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.
Recorded or Written Trainings
=============================
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.
Training / Workshop
===================
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:
* `Continuous & Automated Testing`__
* `Object Oriented Design`__
* `Refactoring`__
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.
__ https://github.com/QafooLabs/TestingKatas/
__ https://qafoo.com/services/workshops/testing.html
__ https://qafoo.com/services/workshops/object_oriented_design.html
__ https://qafoo.com/services/workshops/refactoring.html
Pairing / Mobbing
=================
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:
* Refactoring__
* `Testing Legacy Code`__
* `Build Automation`__
* `Continuous Integration & Delivery`__
* `Performance & Load Tests`__
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.
__ https://qafoo.com/services/workshops/refactoring.html
__ https://qafoo.com/services/workshops/testing.html
__ https://qafoo.com/services/workshops/continuous_integration_and_delivery.html
__ https://qafoo.com/services/workshops/continuous_integration_and_delivery.html
__ https://qafoo.com/services/workshops/performance.html
Full Team Workshop / Discussion
===============================
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:
* `Object Oriented Design`__
* `Architecture Workshop`__
* Refactoring__
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.
__ https://qafoo.com/blog/097_extended_definition_of_done.html
__ https://qafoo.com/blog/055_finding_the_right_test_mix.html
__ https://qafoo.com/services/workshops/object_oriented_design.html
__ https://qafoo.com/services/workshops/architecture.html
__ https://qafoo.com/services/workshops/refactoring.html
Continuous Code Review
======================
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:
* Refactoring__
* `Continuous & Automated Testing`__
* `Object Oriented Design`__
__ https://qafoo.com/services/workshops/refactoring.html
__ https://qafoo.com/services/workshops/testing.html
__ https://qafoo.com/services/workshops/object_oriented_design.html
Summary
=======
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.
..
Local Variables:
mode: rst
fill-column: 79
End:
vim: et syn=rst tw=79
Trackbacks
==========
Comments
========
- how do you write a narrative essay at 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. I, 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
...