Members and Remembrances

I had a busy Christmas doing almost nothing, which was nice, but meant I forgot to write an editorial. We played backgammon, which I hadn’t played for ages now, and moved on to charades. The randomness of backgammon means you can’t learn a sequence of moves off by heart to try to win, but some sensible moves given, say, the initial setup and a certain dice roll do stick in the mind. Certain pairs of numbers together with the distance apart of pieces gives ways to keep things safe, or small risks worth taking, Playing charades is another matter, but again certain visual clues are memorable. Making a ‘T’ shape with your hands to indicate the word ‘the’, for example. As the game progresses, once a word has been guessed from a silly action that becomes a new way to express a word. The sillier, the better. Or maybe that’s just me.

Certain properties, such as silliness, make ideas and actions more memorable. Children are taught songs that have repetition, rhymes and rhythm. The structure and sound means a novice can mimic or guess and often get things right. People can manage to ‘jam’ together, extemporizing and ad-libbing music or other types of performance, without sheet music or a script by knowing the rules of the game. Playing in a given key means certain notes will work together. Having a time signature indicates when to play a note. To the uninitiated, it probably looks like magic. To those on the inside, the magic is more a combination of experience and known rules or guidelines. Some jams start with a known tune, but then go on the change and bend the sequence creating something new.

All kinds of activities follow this kind of pattern, along the lines of the Shu Ha Ri idea from martial arts. Meaning ‘embracing the kata’ it describes three steps in learning:

• Shu: Student follows instructions precisely.
• Ha: Student starts to learn principles and theory (i.e. can break the rules).
• Ri: student becomes master and ‘is’ the rules, creating new rules.

Martin Fowler wrote a brief blog about this [ Fowler14 ], comparing it to the Dreyfus model of learning, though Alistair Cockburn originally introduced it as a way of approaching the learning of software development. Starting with known patterns and rules, once you can remember them, you can try out new things. This helps you understand what and why. Then you can try completely new things.

Do you know the rules? Perhaps software development doesn’t really have rules. Sometimes people have memorised algorithms, perhaps in order to succeed at interviews, or maybe just for fun. This may start by following some pseudocode in a book or on a website, or even copying and pasting from a website. This will not be sufficient to learn the technique properly. More practice is required. It can be illuminating to find several different ways of coding up the same thing, or trying it in various languages. As you go deeper, you may start to understand some underlying principles. Sometimes you can build up an instinct, and spot what might be making code slow, but an expert knows to always measure as well. Sometimes your instinct is wrong, nonetheless being at a point where you do have instincts, even if it’s which websites or books to turn to for help, indicates a level of knowledge. If you can then explain what you are noticing to someone else, you are building expertise. If they can follow what you said, then you are doing even better.

Sometimes, you might be trying to learn on your own. If you try to learn a new language or to drive a new framework, where do you start? I find myself constantly looking things up, until I bore myself and get determined to remember the basics. Sometimes practising a few small functions over and over until I can use something like muscle memory to let the code happen helps. Some people prefer books, others videos or classes, either in person or on line. In some ways the medium is immaterial. The process will be similar. Try, try, try again. And then either succeed or give up.

Do you remember how you learnt to code? Or how to find your way around an unfamiliar code base? On several occasions when I’ve started a new contract, team mates will sit with me, often in a meeting room, and sketch things out on a white board. Or sit me by their desk, pressing the ‘go to definition’ key in their IDE. Even when I desperately try to make notes, I never feel like I know my own way round until I have explored by myself, or try to actually add new features. Certainly, a short introduction can help you find your way more quickly. We went on holiday to Morocco a while ago. It’s very easy to get lost in the medina, but there’s a Mosque with a large tower on the edge of the market square. The simple instruction, “Look for the tower” helps us not get completely lost. If you visit a new town, and someone shows you around, you will not remember exactly which routes you took, even if you take extensive notes. When you next venture out by yourself, you will almost certainly have unsure moments of which way to turn. If you at least spot one landmark to get you back to the car park, bus station or other significant place, you have more chance of finding your own way round. You can’t remember every detail, but having one or two important things in mind makes so much difference. Introducing a new starter to your setup is difficult, don’t get me wrong. You need to find a balance between pointing out an important signpost and allowing your new colleague to explore. Talking at someone for several hours, and having to look things up yourself as you go isn’t the best approach. Let the new person look things up. Pair with them for a bit. Ask what they need to ‘hit the ground running’, as the phrase goes.

Can you remember your best onboarding experiences? What about your best learning experiences? I could tell war stories about some lecturers at University, or some teachers at school. I’m sure we all could. When things didn’t go well, those who were keen to learn would often form small self-help groups. Students can often figure stuff out between themselves, despite the teacher. I’m allowed to be negative about teachers because I used to be one. It’s not an easy job. I have a lot of respect for people who manage to teach well, and am saddened when I hear of the hard time some lecturers are having in various institutions, trying to find time to help their students. This is straying dangerously close to a political opinion piece now, which would count as an editorial. I have avoided this so far, so must change subject immediately.

People have ways of remembering salient points, and so do machines. In order to remember state between function calls, object oriented programming stores values in member variables for future use in member function calls. Without something like the single responsibility principle, the class can end up more like a school with hundreds of members chucked in to save having to think about how to share state between various objects. An alternative would be lots of global variables. A more functional style might chain calls together, never having state, per se , but rather results to operate on. There are also various approaches to asynchronous code. C++20’s coroutines can stop for a bit and resume later. They need to ‘remember’ what they were doing when they kick off again. There are various approaches to this, however ‘Coroutines are stackless: they suspend execution by returning to the caller and the data that is required to resume execution is stored separately from the stack.’ [ cppreference ]. Perhaps you are a full heap developer, rather than a full stack developer, if you are using C++. See what I did there?

What else involves remembering or learning? The first thing that springs to mind, for me, is machine learning. Almost all machine learning algorithms start with a random setup, often several random numbers, and iterate until a criterion is fulfilled, nudging the numbers up or down a bit, based on feedback, in the form of a ‘fitness’ or scoring function. When complete, they have a new set of numbers. Describing this as learning seems a bit odd at first glance. When we learn, we tend to feel like we can then remember something new afterwards. Does a machine ‘remember’ anything? It might cache or serialise the new numbers. Perhaps this is like us holding something in memory for a while, or resorting to taking notes. The machine won’t be able to explain its new knowledge to anyone though. Don’t get me wrong, I love machine learning, but words like ‘learn’, ‘train’, and ‘intelligence’ need some consideration when used in a new context.

What about other new things? How do you get a talk at a conference accepted? Or an article published, or even write a book? Well, if you don’t try, it won’t happen. It can be helpful to talk to people who have done the thing you want to do. When I consider which of my talks have been accepted and which haven’t been, I’m not certain of the main differences. Though proposals with a clearer main topic did better, but there’s more to it than that. Getting an article accepted is another matter. It varies between publications. Some more academic journals can take months, if not years, to finally accept or reject an idea. Overload has a much quicker turn round, and we’ll help you improve an initial idea if required. As for getting a book published, asking for published authors to read your pitch will help. They have been through it before. When I first joined ACCU, I was blown away by people who talked at conferences, wrote articles and had even had books published. I got used to this, making it seem less unachievable. If you are an ACCU member, well done. Use this opportunity to network and join in. If you’re not, you’re missing out. Just saying.

Another angle of getting published or a talk accepted, is considering how your idea will be assessed. If you’ve never read someone else’s proposal, you’re missing out. Many organisations will give you a chance to be on a review board or committee. Several publishing companies let you join their review team, and the ACCU members’ magazine, CVu , runs a book review section. Review other people’s work: you may not get paid for doing so, but will gain valuable experience. You’ll start to spot ways of saying things, how to make yourself clearer, and how to develop an idea. Insider knowledge is invaluable. Join ACCU, and take part in the Code Critique Competition. You might win a book token, or at least see your name in print. Write for Overload . Volunteer for the review team. Or volunteer to be a guest editor. I’m serious; if you would like a go, then get in touch. I’ll help you through the process, from encouraging people to write, to coordinating with the review team and getting the magazine to the production editor. Learn what happens behind the scenes. It’s not magic, but is rewarding.

I joined ACCU many years ago. I’ve met so many people, some I only know by name but others I have met in person at meetups or the conference. Inevitably, people come and go. Last year, a long standing member, Hubert Matthews, died. He was our chairperson for a time, and I went to several of his conferences talks. Many of us paid tribute via the accu-general email list. It’s always a shock when someone dies, but having fond and positive memories is wonderful, even when initially tinged with sadness.

I’ve spent a long time talking about how to learn new things, as well as remembering what’s gone before. Whether remembering people or experiences, taking a moment to think back and reflect is useful. Maybe history and tradition give us the Shu – some kind of patterns or ‘instructions’. However, to learn from past mistakes and glories, we should avoid cargo cult stuff, mindlessly following a recipe. Don’t do something because that’s the ‘right way’, ‘best practice’, or ‘most appropriate’, or it worked for someone else. Bend the rules once or twice. Move on to Ha and then Ri. Join ACCU, get involved and lay down good memories and make friends. Bring on the New Year.

References

[cppreference] Coroutines (C++20) at https://en.cppreference.com/w/cpp/language/coroutines

[Fowler14] Martin Fowler, ShuHaRi, published 22 August 2014, available at https://martinfowler.com/bliki/ShuHaRi.html