Tales from the jar side: Reflective Listening and Fix Mode
Welcome to Tales from the jar side, the Kousen IT, newsletter, for the week of August 25 - September 1, 2019. This week I taught online classes on Functional Java and Managing Your Manager, and did another couple days for the bootcamp for career changers. I also spent a fair amount of time on my Kotlin Cookbook.
I noticed that this week I gained several subscribers to this newsletter. I don't know what triggered that. I don't do much advertising for it, other than mention the newsletter during my talks. That usually takes the form of saying, "I'm an older white male, so of course I have a newsletter," which probably is still more ironic than funny. The newsletter still doesn't appear on my company home page, which is a rather silly omission. It's just that my web site desperately needs a full rewrite, and the person I had create it in the first place used a JavaScript framework that is seriously out of date, and I still can't face the job it would take to redo it.
I'm willing to pay for that, btw. If you know anyone who might be interested in a short contractor job like that, especially if they're from a non-traditional background (women, underrepresented minorities, "issues" in your background, whatever), please let me know. It's a small job for someone who knows what they're doing, but if somebody needs the work I'm happy to provide it, and of course remote to anywhere in the world is fine.
At any rate, to my new readers, welcome! I'm just a one-person company, so my company newsletter is really just about what I've been doing each week. I try to keep it to professional topics, but occasionally other subjects creep in. So far the newsletter has appeared every week, on Sunday, and always seems to be longer than I expected.
Between the newsletter and the books I've written (three so far, with at least two more on the way), I'm forced to conclude that I might actually be a writer.
Reflective Listening To Avoid Fix Mode
As I mentioned, I taught my online course in Managing Your Manager this week. Even though I've been giving a talk of the same name on the No Fluff, Just Stuff conference tour for several years now, and also delivered the online course many times and even have a video on the O'Reilly Learning Platform about it, I keep finding new insights about the subject. This time I was talking about the psychological trick known a reflective listening, and realized something new.
The idea behind reflective listening is to listen to what someone says and then to say it back to them. According to the Wikipedia page on it, it came out of "client-centered therapy" in counseling, and supposedly is based on empathy.
In practice, I find it comes across as very fake. Someone says to you, "I didn't enjoy that meeting. It was really boring," and you respond with something like, "So you're saying you thought the meeting was boring," or "It sounds like you were bored at the meeting," or something similar. It sounds artificial when you do it, and comedians make fun of it easily.
The reason I bring it up during the Managing Your Manager course is that it's an easy way to sound like you're engaged when you're not. One of the major points in the book is going to be around the issue that Your Boss Is Not Your Friend (an extensive topic I'll talk about in a future newsletter). But if you follow a lot of the techniques I present, you become someone the boss wants to be around. That means they occasionally start to tell you things that you don't really want to hear or be a part of. Reflective listening is one way to sound like you're listening without committing too much of yourself to the combination.
Boss: "Bob was at that meeting, and he started complaining about how his project is running out of funds."
You: "So Bob was at the meeting, huh?"
Boss: "Right. You should have heard him go on. I think he's got some personal issues going on as well."
You: "You're saying you're worried about Bob."
And so on. You come across as supportive and even involved, but all you're really doing is echoing what they just said.
This week in the class, though, it occurred to me there's another good use case for the technique. Most people I know are problem solvers. That's what we do at the job, and that tends to bleed into every relationship. Therefore we all have a tendency when listening to someone complain to automatically go into what my wife and I call "fix mode", which is the unfortunately tendency to suggest quick fixes that almost certainly have already occurred to the other person.
Sometimes when your spouse or significant other is complaining, all they're really doing is venting their frustrations. They don't want solutions -- they probably already know what to do, or know why they can't fix the problem. They just want to express their own annoyances to a sympathetic ear. When someone you care about is unhappy, though, it's hard to simply listen. You want to make it better. That leads to "fix mode".
Btw, the term "fix mode" in practice is short for "would you please get out of fix mode?" (Optional addition: "you idiot!" or assorted profanity, depending on how blindingly obvious your proposed "solutions" are.). "I'm just venting here."
During class this week it occurred to us that reflective listening is one way to stay out of fix mode. It gives you a way to contribute without making everything worse, and you get to stay engaged. That usually works better than just staring at your phone while they talk.
(Yeah, I'm still working on not doing that. It's hard.)
Now that I write it down, that seems rather obvious. Heck, that's probably why therapists do it in the first place. Still, it hadn't occurred to me until then, and it felt like something worth talking about. I expect when I get back to the book, I'll have to add a section on it.
One last issue about fix mode. Some people say that going into fix mode is a "guy thing", but my experience is that everybody does it until they understand you don't want them to. As I say, we're all problem solvers, and when we hear someone in trouble, we want to fix it.
In case you've never seen it, here's the best example of fix mode ever, care of Bob Newhart.
Telling Too Much
There are three stages in the development of an instructor:
You tell the students everything you know
You tell them everything you've learned since then
You tell them only what they need to know
I've talked about this before. When I know a topic, I have an irresistible urge to share it. I enjoy learning about new techniques and strategies, and when I learn something I think is really cool, I want to tell everyone around me. That urge is probably at the heart of why I'm an instructor. When I'm working with a programming language, I'm not driven to improve the language itself -- I don't care who does that, and frankly there are many developers much better at that than I. What drives me is learning and understanding how to use the language to do things I couldn't do before, and then helping everybody else do it, too.
The result is that I like staying on the cutting edge of whatever technology I'm in, but I also rather enjoy breaking down the concepts for those people who don't know them yet. Training classes normally are really fun for me, because you take a group of students who need to be able to do something, and you show them how to do it, and then they're happy.
At least that's how they're supposed to work. Another benefit of teaching training courses is that they end. As a friend of mine likes to say, the worst training course in the world is over in a week. :)
I'm in this bootcamp now, however, and it involves seeing the same students for a few months at a time. I'm only working with them two days a week, but they've already been in the program for six weeks and we have several to go. The number of topics the students are learning is so large that it's been a challenge for them to learn anything well, much less get enough coding experience to master them.
I understood all that going in. My problem is that this week the students received an assignment which involved simulating a dice game. I thought we'd talk about it, but unfortunately I think I made the situation worse. Rather than going with the simplest possible solution, I started speculating on how you would attach a user interface to the game, and maybe turn it into a RESTful web service, and add tests, and do a nice object-oriented design, and everything.
During my "processing out loud" phase, I free-associated to thinking about the State design pattern, which is pretty cool but not really relevant to the dice game. I took the time to code up a simple, interesting example (a door whose open and close method implementations depended on whether the door was open or closed).
It was fun, but it wasn't what the students needed, and I've been regretting it ever since. When I got home I started coding up a really simple solution, which is probably all the assignment required. I've since made a second version with a Swing user interface on it, and I'm tempted to keep going and play with JavaFX (which I don't know and really don't have time to learn, given that I'm supposed to be finishing a book) and maybe even working out the REST version of it based on the Spring framework.
In other words, I think I'm pretty firmly being a stage 1 or stage 2 instructor, and I'm finding it hard to let go.
All is not lost. When I see them next week we'll talk about it again, and I'll show them how I approached the problem and see what they've done. I just feel bad that I complicated their lives unnecessarily. Worse, I think I made it seem like the simple answer wasn't good enough.
I suppose that in itself is a lesson. It's really hard not to get ambitious on any problem, and problems have a way of growing in scale and scope. We'll definitely talk about that. I'm just feeling frustrated that rather than give them what they needed, I too easily slipped into talking about all the stuff I know, much of which is probably irrelevant for this problem. Oh well.
I also can't take too much time for the explanations, because we really need to get through functional Java in order to do some Spring applications as soon as we can.
Speaking of Functional Java, my Safari online class on that topic went well, but only if you treat those Safari classes as extended presentations. The Safari approach is to limit the trainings to a single four-hour day, or at most two four-hour days. That's not nearly enough to cover everything and give the students a chance to practice. In other words, those constraints mean the classes favor the stage 1 or stage 2 approaches, which is nice for the ego of the instructor, but not nearly as beneficial to the students.
The bottom line is that in my continuing effort to be a stage 3 instructor, this has been a challenging week. These issues are never far from my mind, though, so I'll be thinking about ways to adjust for the future.
A few miscellaneous items:
I'm working on wrapping up the Kotlin Cookbook, but all I can see is how much is left to be covered. A friend of mine used the beautiful phrase, "I'm going to be finished before I'm done." That's a perfect description of my life over the next couple weeks, I think.
I hope you had a pleasant Labor Day weekend. My wife and I were rather active, which means I actually left the house more than once. I'm one of those I.T. people who believe walls are there for a reason, and that if I don't have both air conditioning and high-speed Internet access I can't truly be happy. Still, it's nice to mix with other people occasionally, at least in moderation.
In a couple weeks I'm headed for the Oracle Code One conference. I have three Safari classes already scheduled that week, which means that since I'll be in San Francisco (i.e., on Pacific time), those classes will be running a 5 am to 9 am each morning. That ought to be fun.
Of course, the real reason I'm going is to perform with the Null Pointers band. I just wish my voice was more suited to the type of music they want rather than the crooner style I prefer, but honestly that's just giving me another excuse to worry about nothing unnecessarily.
Last week:
Functional Java online on Safari
Managing Your Manager online on Safari
Bootcamp for career changers
Work on Kotlin Cookbook
This week:
Spring and Spring Boot online on Safari
Bootcamp for career changers
Update the Kotlin Cookbook based on feedback from a couple of tech reviewers
Add as many more recipes as I can, given the other constraints
Talk to my contact at O'Reilly about future course proposals