Tales from the jar side: Admitting You Don't Know Something, Kotlin Ki, and Funny Tweets

Includes jokes about ferocious frogs, Star Trek sublight engines, container ship Tetris, and even a Barry Manilow story. You've been warned.

Welcome to Tales from the jar side, the Kousen IT newsletter, for the week of March 28 - April 4, 2021. This week I taught a Reactive Spring class on the O’Reilly Learning Platform, a Kotlin Fundamentals class as an NFJS Virtual Workshop, and completed a private class on Spring MVC.

I also got a chance to meet with Johanna Rothman, author of books like Create Your Successful Agile Project, Manage Your Job Search, Manage It!, and Hiring Geeks That Fit, among others.

Many of her books are available on the O’Reilly Learning Platform, which makes them easy for me to access, but the links above are to The Pragmatic Bookshelf, where you’ll find more. I used the fact that my book Help Your Boss Help You (HYBHY) is now in beta at the same publisher as an excuse to meet with her, but honestly I’ve been a fan of hers for a while and mostly just wanted to connect.

We talked about a lot of issues, but one suggestion she made that I plan to follow up on is to try to talk about my book on as many podcasts as possible. I was already planning to do some of that, but now I intend to increase that effort. HYBHY provides a special challenge for me in that area. All my previous books were technical, and therefore had natural audiences of developers interested in those topics. This book is different in that the audience is pretty much anyone with a manager.

Let me be clearer about that. As I say in the Introduction to the book (which you can read in pdf form here), my book focuses on working professionals. I define the term working professional this way:

A working professional is someone who is has a non-managerial career and cares more about that career than rising through the ranks of management, though they may consider that someday. That includes, but is not limited to, engineers, software developers, accountants, lawyers, physicians, actuaries, sales people, and more. If you care about the details of doing your job, learning about new developments in your field, and demonstrating technical experience, you’re a working professional. Note that while most professionals require continuing education and are always trying to learn more about their fields, no particular academic degrees are required in order to be considered a professional.

(Did you notice the typo in the first sentence? It says “someone who is has a …” and obviously I meant to delete the word is. Sigh. Yeah, I’ll fix that in the next beta. I suppose that’s what beta releases are for.)

That’s a rather broad target audience for my book, and I wanted her advice about marketing it. Since she stressed the importance of podcasts (among other things), if any of my brilliant and talented readers (that’s all of you, of course) know of any podcasts I should approach, whether you listen to them regularly or not, please let me know.

Another marketing effort I’m planning is to release YouTube videos on each topic, and to create a series of blog posts that go into more detail about them. I’ll talk about them more when I start producing them.

Admit You Don’t Know Something, But…

One of the articles published at Johanna Rothman’s site is Leadership Tip #4: Admit When You Don’t Know.

The article is well written and informative, as you’d expect. The idea is that when someone asks you a question and you don’t know the answer, you should say so, and the article describes several ways to make it safe to do that.

My day job is teaching software development training courses. My goal in any class I teach is to be able to answer every questions immediately and completely. That’s a rather high bar (okay, that’s a ridiculous bar), but hey, everybody needs a goal, right? So when students ask me a question I don’t know how to answer, I have a problem.

Students always say that when an instructor doesn’t know an answer, they should admit it. Anything else is a waste of time, not to mention dishonest. There’s some truth to that, but the reality is a little different. One saying I’ve come to live by is:

In a training course, I can say “I don’t know” three times, but they can’t all be Monday morning.

(Note: Monday morning means the first morning of the first day, whatever that may be, but you get the idea.)

In a training class, some students will trust the instructor from the beginning. Others, especially if they’ve been burned before, are more suspicious. Unlike academic environments, almost everyone in a training class already has a job and has work to do. They are there because they believe you can help them do it. That means they come in with an agenda, and your job as trainer is to adapt the material to their needs.

(Btw, that’s the opposite of what happens in academic classes. In an academic class, I have a body of material to teach and they have to learn it. I don’t have to customize it for their specific needs, which may be all over the map or even none at all. In an academic class, I’m grading you. In a training class, you’re grading me. The power dynamic is completely different. When I used to teach at Rensselaer at Hartford, I can verify that it’s a heady experience. When I walked into the room, I could feel all the power flow to the front of the room. If I told them the course required it, they had to do it. That is not at all the case in my training classes.)

The result is that you need to convince the attendees in any given course that the course is worth their time and effort. You have a small window of opportunity to establish credibility, starting on the first morning of the first day, and if you lose it, you’re in trouble.

Personally, I have a couple of advantages that help. For one, I’m a white male, which shouldn’t matter but obviously does. It means I start with a certain level of credibility. I’m also older, but don’t (quite) look really old. That’s important, because the IT field skews very young. Looking older suggests some authority, but I have to balance that with the need to demonstrate I’m still relevant. As what little hair I have turns increasingly grey, it becomes more important to show I’m aware of current developments in the field and have kept up with them, so the information I have to impart is still relevant.

Incidentally, when I first became a professional instructor, one of my managers made an interesting analogy. He said that how the students feel about you when you first walk into a training class depends on how much they liked their fifth-grade teacher. If they liked that teacher, they’ll like you. If not, you have a problem. I laughed, but I’ve often wondered how much truth there is to that.

In the article, Rothman suggests three ways to handle the “I don’t know” issue:

  1. Add a “yet” to your answer.

  2. Explain that you’re the wrong person to ask.

  3. Say that you need to check on the answer and will get back to them later.

  4. Use the consultant’s answer: “it depends.”

(Seriously, read the article. It’s very good.)

I like that first suggestion, but again I don’t want to use that at the beginning of class and I better not say it in response to a question the student feels I “should” know, or I’m going to have some reclamation work to do.

The second response is one I used this week. One of my students was asking about some architectural issues regarding the design of a software system. I told them what I knew, but added that I wasn’t really an expert in that area and suggested they contact Mark Richards or Neal Ford or Nate Schutta, all of whom know way more about that than I do. As another obvious example, my HYBHY book is about advice for working professionals when dealing with managers. If you are already a manager and want to get better at it, talk to Johanna Rothman. :)

The third answer I also like. During my private classes, I like to keep a shared Google Doc open, mostly as an easy way to share notes or code snippets. I also keep a running list of questions that come up that are too big to answer right away or that I’m not sure how to resolve. I add them to the list and promise to get back to them later. That works as long as I remember to go back eventually.

I’ll add one option of my own, which I learned the hard way in graduate school many years ago. As part of the Ph.D. program, each grad student had to go through a series of three one-on-one interviews with a faculty member. That meant you stood at the blackboard and they asked you questions. The questions were supposed to be in specific advertised areas, but the professors where allowed to ask anything they wanted, for as long as they wanted, to assess what you knew and what you didn’t. The interviews were particularly stressful for me, because once the professor realized you knew something, they skipped it and moved on to something else.

I failed my first interview very badly, to the point where the professor had to go talk to my advisor to find out if I understood anything at all. The problem was I tried to answer every question immediately, and that meant the answers I gave were oversimplified or off by some margin, and the professor was really good at finding holes in my arguments and leading me down dark paths as a result. I wound up being wrong a lot, and while I’m really good at explaining things I understand, if I’m not comfortable I can wind up sounding like an idiot.

My advisor’s advice to me on the retry (fortunately the professor was willing to let me try again) was, Work The Problem. When they ask you a question, don’t assume it has a one-line answer. Write it down. State your assumptions. Try to reduce it to a problem already solved. Apply basic principles, and so on.

As you might have guessed, my second interview went a lot better than the first one. Eventually we grad students came up with a saying: When all else fails, conserve mass. You can’t go wrong by doing that, and it might get you moving.

We also learned which questions were asked by which professors and what answers they liked to hear, but that’s a story for another day.

Ki

My virtual workshop on Kotlin ran on Wednesday. I didn’t find out until it was over that the team at JetBrains released a new tool for Kotlin, an interactive shell called ki. Ki is introduced in this blog post. The announcement came in a tweet:

Kotlin already includes a shell (or REPL, read-eval-print-loop), which you can trigger from the kotlinc command. The problem as stated in the post, is that the shell started by kotlinc does not have autocomplete, syntax highlighting, or type inference, or the ability to download dependencies using Maven coordinates.

I downloaded the tool, which is very basic. Everything is bundled as an executable archive (meaning a Java jar file) along with a shell script to start it on either Un*x or Windows. In order to install it, you download it and add the bin directory to your path. It requires Java, too, in order to execute the jar, but the instructions don’t say much of anything yet. You can’t install it using either sdkman (my package manager of choice), homebrew, scoop, or anything else yet, but I imagine that’s coming.

I ran some experiments similar to those shown in the blog post, and it works, as far as it goes. I have to admit that I’m not much of a REPL person. I’m usually fine with opening my IDE (IntelliJ or Android Studio for anything Kotlin related), and this probably isn’t going to change that.

Still, I think it’s worth keeping an eye on, and I wouldn’t be surprised if it’s eventually bundled inside the language installer itself, like the groovysh and groovyConsole commands are with Groovy. We’ll see.

You can learn more about the tool at its GitHub repository.

Meme Watch and Funny Tweets

Nothing this week rose to the level of a meme, at least not in my Twitter feed. To follow up on last week, however, I loved this image:

Container Ship Tetris FTW

This week led up to Easter, and every year Glen Weldon releases a series of jokes related to that. I’m going to share one of them:

My goodness, a Barry Manilow Mandy joke (or, in this case, Maundy). That took me way back. I remember when the original song came out, and seemingly every girl in school swooned for it. Barry Manilow was far more successful than most people realize. He practically owned the 1970s. He had 51 Top 40 singles in his career (so far), including 13 that hit number one. He had 13 platinum albums. He was praised by (if you can believe this) both Bob Dylan and Frank Sinatra, which is as unlikely a pair as you’ll ever see in the same sentence.

My Manilow story is that when I was in high school, I played in the World’s Longest 24 Hour Volleyball Marathon for charity — we played on the night the clocks were turned back for daylight savings, which meant our 24 hour marathon took 25 hours — and somebody kept playing Daybreak, for obvious reasons.

I liked the songs Mandy, Could It Be Magic, Weekend in New England, Ready to Take a Chance Again, and a few others. I hated Copacabana, and many, many others, but you’ll probably have that on any career that spans 50 years.

Moving on, my friend Scott Selikoff tweeted this awful joke:

I still haven’t forgiven him for that pun, but it hasn’t kept me from forwarding the joke to several friends, not to mention including it here.

Finally, in case you missed it, this was awesome:

A “sonorous war cry of a very angry frog. Ferocious.” Yup, can’t argue with that.

Share Tales from the jar side

As a reminder, you can see all my upcoming training courses on the O’Reilly Learning Platform here and all the upcoming NFJS Virtual Workshops here.

Last week:

  • Reactive Spring, on the O’Reilly Learning Platform

  • Kotlin Fundamentals, an NFJS Virtual Workshop

  • Spring MVC, private class

This week:

  • JUnit 5 Testing, on the O’Reilly Learning Platform

  • Spring and Spring Boot, same, but at 5 am Eastern time to better accommodate those students in the Asia/Pacific time zones. I’m yawning already.