Book: Talking It Better

I’ve written a book about counselling and psychotherapy. It’s called Talking It Better: From Insight to Change in the Therapy Room and is due out on February 4th 2021. I’ll be posting a little more about this in the coming weeks. In the meantime you can find out more about the book or even pre-order at:

  • PCCS Books – be sure to check out the rest of the PCCS catalogue too. There are some really great books.
  • Amazon

The book’s a wee bit chapter (£14 as opposed to £15.99) if you buy it direct from PCCS. I get some tiny kick back if you click on the Amazon link and buy it that way.

 

About the book

Talking it Better is a practical book about the everyday practice of counselling and psychotherapy, written by a practitioner for fellow practitioners. Using case studies based on his own clients, Elton carefully examines what helps and what hinders the process of change in the therapy room. At the heart of therapeutic work, he argues, is the development of effective mind skills. He explains how counsellors and therapists can borrow valuable ideas from the teachers of skills such as swimming, reading music or learning to drive. And he shows us that, when it comes to developing our mind skills, practice is often far more important than insight or theory. Marie-Anne wants to manage the sergeant major in her head who keeps telling her what to do. Calum wants to learn to hear what his partner is really saying, rather than what he fears she is. Isobel wants to stop rushing to help people and then resenting them because they take her for granted. These, and the many other characters in this book, were profoundly stuck until, through talking it better , each found a unique path taking them closer to the self they would prefer to be.

Advanced praise for the book

This is a beautifully written, accessible and inspiring book, that has a lot to offer to both novice and experienced counsellors and psychotherapists, and also to clients. Matthew Elton invites other practitioners to look over his shoulder to find out how another colleague works. The reader is introduced to an array of vividly-depicted individuals who are seeking assistance to deal with life difficulties that are typical in therapy clients, such as anxiety, depression, relationship difficulties, stress, and recovery from trauma. Elton’s approach is highly collaborative. He writes about how he seeks to facilitate shared reflection on what does and does not work for the person, with the aim of creating a bespoke approach that varies from one help-seeker to another. Although he acknowledges the theoretical influences and training that have shaped his practice, one of the most striking and impressive aspects of the book is the extent to which he has integrated these influences, alongside aspects of his personal life experience, into a personal style that both demystifies therapy and is highly authentic. I enjoyed reading this book, learned from it, and would recommend it to anyone – practitioner or help-seeker – who is interested in understanding how therapy can make a difference. Julia McLeod, Lecturer in Counselling and Psychotherapy, Abertay University and co-author of Counselling Skills: A practical guide for counsellors and helping professionals.

I read this book avidly, riveted by the author’s creativity, the clarity of his presentation, and by the rich, compassionate case studies that weave through his writing from beginning to end. Informed by a range of psychological and learning theories, Matthew Elton generously and modestly shares his thoughts on what is possible to achieve through collaborative endeavour within a trusting relationship between help-seeker and practitioner. Beyond theory, he combines his breadth and depth of knowledge with his professional and personal experience to address how to help people bring themselves closer to becoming their ‘preferred selves’. Practitioners of differing approaches and levels of experience will find this book refreshingly practical. It encourages us to explore and experiment, to respectfully and sensitively work with long-established frames of reference (recognising the part played by our own), and to actively work through the ‘blocks’ that maintain our stuck patterns. Phil Lapworth, counsellor, psychotherapist, supervisor and author of Tales from the Therapy Room and Listen Carefully.

Here is an accessible and beautifully written account of how a psychotherapist understands and works with the people who seek his help. It is both rich in metaphor and eminently pragmatic. Matthew invites us to ‘look over his shoulder’ to see how he makes sense of and responds to a range of issues that his clients bring and that many helping practitioners will recognise from their own practice. I enjoyed this invitation and the unfolding stories, interwoven with distilled yet lightly held theoretical models and reflections, of helping people move from being stuck to finding their preferred ways of feeling, thinking and behaving. I also appreciate how, throughout the book, Matthew shares his impulses, dilemmas, options and choices at various points, mindfully demonstrating his ethical sensibilities. I never had the sense of being told how to do this work from a one-up expert position. Instead, I experienced a caring and skilled practitioner sharing his craft. What a gift! Graeme Summers, coach, trainer and author and co-developer of co-creative transactional analysis. See: co-creativity.com. Graeme is the co-author of Co-Creative Transactional Analysis.

In this engaging book, therapist Matthew Elton takes us on journeys with people who come to him for help, exploring the ‘internal blocks’ that get in the way of making changes in their lives. On one level, this is a book for therapists and counsellors. But it’s written with a lightness of touch that makes it accessible to someone who doesn’t know the first thing about psychotherapy or counselling. Indeed, it would be an excellent book for someone who thinks they might benefit from therapeutic help but is unsure of what it might involve or how it might help them. Fundamentally, it’s a book about the possibility of changing ourselves in ways that make us better equipped to deal with whatever the world throws at us. I really loved it. Helen Beebee, Professor of Philosophy, University of Manchester – author of Free Will: an introduction and, with Michael Rush, Philosophy: Why It Matters.

Apps on the App Store

I’m hoping to restore the Obliquely Productive to the app store during 2021. At the moment it’s not for sale because I’ve not kept up with all the updates that Apple have made to iPhone / iPad operating system. If you miss the app – or are a bit frustrated that your existing copy has gone a bit chunky – send me a message of encouragement. If I know people are keen to have the app restored, it’s added motivation to get it sorted and back on the store.

The Paragraft app is not for sale and I think it’s unlikely that I’ll be able to find the time to recreate a more modern version of this app. When it first existed it was hard to do rich text on the iPhone or iPad. But now even the stock Apple apps do some of what Paragraft made easy. I miss using the app as, for me, it had some really neat features. So, maybe, one day. But not any time soon.

Is It Working Yet? hasn’t been on sale for a while. And, again, I think this is one that may be retired permanently.

BBC micro:bit – Lunar Lander Project (part 1)

With my godson’s eleventh birthday coming up, I was wondering what would be an interesting gift. A few months ago, J, his little brother N, and I had been talking about passwords. They’d been told at school that it helped to misspell words – so ‘werdz’, say, rather than ‘words’ – and to insert punctuation marks. But why are you being given this advice, I pressed them. This led to some discussion about how a person – or more likely a computer program – might try and guess a password. And this, in turn, led to us writing some code in Scratch, a programming language for kids, that would actually guess passwords. The boys enjoyed themselves hugely. And they were just awestruck by how many brute force guesses were required to crack passwords.

So for J’s birthday, I thought something with coding might be fun. But I also liked the idea of him having something of his own, something not virtual. And so I got to wondering if we could code a game on one of these new breed of tiny computers, such as the BBC micro:bit.

What I had in mind was the sort of game that I had coded up back in the early 1980s using machines such as the ZX80 (my big brother’s), Commodore Pet (at school), Acorn Atom (at John Cupitt‘s), Oric-1 (mine!), and BBC Micro (at JC’s again). This was when I was first learning about programming and you either used BASIC – which was often too slow or couldn’t let you control the screen with sufficient precision – or more likely machine code. Tricky, but rewarding when you finally got things to work.

Preparation

So I started doing some research on-line. It turns out that you can buy tiny displays and it looked, in theory, as if I could connect one of these to the micro:bit and make it work. I reckoned that if I could hook up a 128 x 128 pixel display to the micro:bit that would be large enough to make a playable Lunar Lander game.

Before I committed to ordering any parts, I thought I’d do some sort of proof of concept. These days, when I program it is mostly for the iPhone using Apple’s Swift language. So I knocked up the vary bare bones of a Lunar Lander program as an iPhone app, scaling the display size to 128 x 128 pixels. And all seemed OK.

Is 128 x 128 pixels enough for a playable Lunar Lander game? Doing a “proof of concept” on the iPhone.

There remained some uncertainty though. I couldn’t find any definite instructions or a worked example of connecting a micro:bit to any of the displays I’d been looking at. There were things written about doing this for other tiny computers, such as the Raspberry Pi, but not so much for the micro:bit. So I couldn’t yet be sure whether I could actually get the micro:bit to “talk” to a display. But I was getting to the end of what I could realistically do with desk bound research. And so, I ordered two micro:bits and two Inventor’s Kits, one each for me and for J. I also ordered one display to test out. If I couldn’t make it work, then I’d have to come up with a plan B.

Microbits and Inventor’s Kits. One for J and one for me.

Before I wrapped up J’s micro:bit I wanted to try things out and get a sense of how it worked, so I could tell his mum a little bit about it and write a decent note for him in his birthday card. I encouraged J to try out the hardware and follow the instructions on his own. But I also know that what he loves more than anything is doing things with other people. For him, that’s at least three quarters of the fun. And, so it turned out, he chose to wait for my visit – scheduled for a couple of weeks’ time – before breaking the seals on his new toys.

The actual micro:bit really is micro. I was expecting it to be small from the size of the box, but even so I was surprised at how tiny it is.

Back at home, I was figuring out how the micro:bit worked. You write code on your computer, using a special web page. And even without connecting the micro:bit you can see the effects as the page has a “simulator” – an animated picture of the micro:bit that performs, more or less, in the same way as the real hardware. The main thing the micro:bit does is let your create patterns on a 5×5 grid of LEDs, to respond to two buttons and, if you connect some headphones or a small speaker, make noises and play tunes. The simulator lets your try out all these things. And then, if you connect the computer to the micro:bit you can transfer the program to the tiny computer.

There are a few different choices of programming language for the micro:bit. Because I wanted J to be able to do some of the coding himself, I went for the option called the JavaScript blocks editor. The JavaScript language is one I know something about. It’s the language that can be run inside a web browsers and is used to make web pages do all sorts of clever things. And the “blocks editor’ bit means that kids can drag chunks of code around rather than having to type things in word by word.

Great, I thought. What I can do is to develop some code in my web browser using JavaScript and I can simulate the pixel display there. That way, I can write and test code before my display arrives. I went ahead and did this, getting some basic code to paint a lunar lander on the screen and move it about. (If you are reading this on a Mac or a PC, you can see a bare bones JavaScript proof of concept version of the game running in your browser. And you can click through to JSFiddle to the see the code.)

I was greatly encouraged to have my proof of concept up and running, but there was still the question of whether I could successfully connect micro:bit and display.

When the display arrived in the post, the first task was to do some soldering so I could plug it in the “breadboard” and, through that, wire it up to the micro:bit.

Working with hardware is different from working with software. There are fewer second chances and my soldering skills were pretty rusty. But I seemed to get on OK. The most anxious part of the soldering operation was that the ‘connector’ part that came with the display had more pins than there were holes in the display board. I needed to clip off a few of the pins. I’m glad I was cautious and did an experimental clip first, as it turned out it was very easy to overshoot with the clipping.

The next phase of the project was the most challenging. The display is designed to talk to a computer using something called a Serial Peripheral Interface Bus (SPI). I was learning about this for the first time and was not finding many examples on-line of making practical use of the SPI with the micro:bit. Not for the first time, I wondered if I had bitten off more than I could chew.

At root there needs to be some wires between the display and the computer, and signals get sent down these wires to tell the display what to do. At the level of the hardware, I needed to connect some power and then four wires for communication. By following the published data sheet for the display and the micro:bit documentation, I wired everything up. And, at this point, the display actually lit up. This wasn’t telling me anything much, because I wasn’t yet sending any messages to the display to tell it what to do. But it was at least an encouraging sign.

The next phase was to start sending messages – in the form of a series of numbers – to the display to get it to do what I wanted. The people who provided the display provided lots of useful documentation and also some sample code that lets people with computers that are not micro:bits talk to the display. So I had to look at the code and convert it into the JavaScript language that the micro:bit could understand.

Writing about it now, it sounds straightforward enough. And by the time I’d gone through their code line by line, I suppose it was. But it took time and patience. For example, I had to identify what code was essential and what I could set aside. I couldn’t run or test this code, so it was a matter of reading through and making sense of it step by step. To even start the display up at all, required sending a series of numbers. And if any one of them was wrong it was entirely possible nothing would work. And then to get coloured dots to appear meant sending more carefully crafted numbers. Some hours later, I had checked and re-checked the code I had written. It all looked OK, so it was time to transfer the code to micro:bit and see what happened.

And what happened was… precisely nothing at all. The same white screen – yes, I already know the power is working – stared back at me as I stared at it.

Carefully checked code running, all wires attached and no change on the screen. Oh dear.

There was a real moment – indeed an extended stretch – of doubt here. Because at this point I wasn’t sure how many moves I had to make. I’m used to working in software, but perhaps there was some hardware thing that I’d failed to understand. Perhaps my soldering had been shockingly poor. Perhaps, I wondered, I just won’t be able to fix this.

Still, it’s engineering, right. So it’s a matter of coming up with hypotheses as to why it’s not working and testing each one. I checked which wires I’d connected between the micro:bit and the display. Everything was checking out. I got back to the original software provided by display supplier and compared key sequences between it and my code. And then, I spotted something.

One bit of code controls the signal sent down a particular wire that, basically, asks the display to sit up and pay attention. Surely, the pay attention signal would be positive three volts and not zero volts? That is a one instead of a zero. Well, I must have thought this without really thinking, because that’s what the code I’d written assumed to be the case. But as the display supplier’s code made clear, the “sit up and pay attention” signal was a 0 and the “ignore everything, it’s not for you” signal was a 1.

The code change took less than half a minute. Transferring the software to the micro:bit took about the same time again. By this time, I’d also wired up a speaker so the setup made some sounds when the software had transferred. And now, as the beep sounded, so the display transformed into hundreds of random coloured dots. Not quite what I was expecting, but a clear sign that the signals I was sending were getting through. And, amongst the random coloured dots, in red, was the just discernible outline of a lunar lander. I pressed one of the buttons on micro:bit that I had programmed to move the lander a pixel to the right. And again. And, yes, the lander was moving, leaving a trail of blackness behind it. Time for a picture, I thought.

Game On! My code is working and I have something that looks like a lunar lander on screen.

The multi-coloured background is just what happens when the display starts up. I needed to ask it, explicitly, to clear the screen. But I already had code, adapted from the display supplier’s, to paint rectangles of an arbitrary size. Although, even that code didn’t quite work the first time.

An almost clear screen with the lander

At this point I was optimistic about making rapid progress. The plan was to take chunks of the code I’d written for my proof of concept in the web browser and use it on the micro:bit. After all, they both say they use JavaScript.

However, as it turns out, the JavaScript for the micro:bit is a severely stripped down version of the language that runs in a web browser. Just how stripped down became apparent slowly and painfully. So, for example, inside the web browser the JavaScript language understands decimal numbers. And my code relied on the use of decimals all over the place. For example, it relied on decimals in working out how to draw a straight line or how to apply gravity or the force of a rocket booster to the lander. This particular problem was one of the more straightforward ones that I encountered. Instead of relying on fractions, I was able to just multiply everything up and then, when it came to calculating the real pixel position, divide down and round up.

Slowly, the game started to come together. There were plenty of wrong turnings, as there always are with programming, such as the landscape appearing at the top rather than the bottom of the screen.

Landscape in the sky. Classic computing error. The machine, of course, was doing exactly what I’d asked it to do.

The not so solid surface of the moon. Not so much a bug this time, just a case of not having got to the point where I’d added a test for the lander hitting the surface.

Next Steps

So I had most of a working game. I didn’t want to polish it up too much. Rather, I wanted to take the basic building blocks and ideas and get my godson to, first, put together his own hardware and, second, code up the game. Knowing that I had the really tricky code to talk to the display, to put pixels – and also little patterns of pixels, such as the lander – on screen, made it a viable plan. Although it still seemed pretty ambitious. I was only visiting for a weekend. But I very much hoped, J would both have fun and, at the end of the visit, have a viable – if basic – Lunar Lander game.

I’ll add a link to part 2 when it’s written… watch this space. If you want to try this project yourself check out Connecting a micro:bit and an AdaFruit 1.44 inch display.

Questions and Comments

Comments are not enabled on this site, but if there are interesting comments or useful tips submitted then I’ll append them to this or one of the other Lunar Landed related posts.

    Name

    Email

    Question or comment