Tales from the jar side: You say tomato, I say pomodoro
Welcome to Tales from the jar side, the Kousen IT, newsletter, for the week of August 11 - 18, 2019. This week mostly involved writing and editing on the Kotlin Cookbook.
Tomato Timers And Pomodoro
I first heard about the Pomodoro technique for time management several years ago, probably around 2009 or so. The word pomodoro is Italian for tomato, and the technique is named for a small tomato-shaped timer used by Francesco Cirillo (the creator of the technique) at the time.
The picture is from Wikipedia, https://en.wikipedia.org/wiki/File:Il_pomodoro.jpg. Here is a link to the original web site by Cirillo, but apparently it's now almost all advertising for his own training courses. I'm fine with that, in principle, but I can assure you that you don't need to go there to understand the technique. The Wikipedia page is enough.
The basic idea behind the Pomodoro Technique is that for any task, you set a timer for 25 minutes and work on that task without any distractions. When the timer goes off, you take a five-minute break and then do it again. Each block of 25 minutes is itself called a pomodoro, and after four consecutive ones, you take a longer break, normally 15 minutes.
There are more formal requirements, especially regarding planning and reporting (heck, Cirillo managed to write a 45-page book about the technique, which you can download in pdf form here), but I've always ignored that part. The approach appeals to my need for structure without being too confining. The biggest benefit to me is that the technique requires me to focus on one task without checking my email, or twitter, or playing some game, or anything else I tend to do when I run into difficulties and need a distraction. I know if I can just stick to a particular task for the full 25 minutes, I can do anything else I want during those breaks, and that's often enough to keep me going.
To be honest, I don't use the technique all that often, but I find it very useful when I do. My "flight or fight" reaction to difficulties has always been flight. On a small scale that means finding something else to do when I hit a problem on a difficult task. I also know I have a tendency to obsess over whatever I'm doing, so I can wind up spending hours and hours on a single task. That can be a good thing, but it is exhausting, and one side-effect is that I'm often reluctant to start any difficult task because that I fear it will cost me all day. The pomodoro technique forces me to take a break every 25 minutes, and that's a good thing.
Ultimately the question becomes, why don't I use this technique all the time? The real answer is I don't want to be constrained like that. But when I'm fighting myself, avoiding all the things I need to do but don't want to do, my little pomodoro timer helps me break through the resistance and at least get started.
(For the record, I have a timer on my Mac called Be Focused Pro, but it's no better or worse than any of the myriad other timers on the market. It cost me $5.)
When I'm working on a book, I set as a goal giving it at least one pomodoro a day. I may give it several more, which often happens when I get wrapped up in a particular topic, but if I can do even one, that counts as progress. Eventually that leads to the "emptying the ocean with a tablespoon" metaphor, where small amounts of progress daily add up to large amounts over time.
Speaking of metaphors, I often come up with them as my natural way of thinking. For the record, here's my metaphor joke:
- Life is a metaphor
- No wait, life is like a simile
- No, actually life is an analogy
Okay, I'll stop now. Well, one more. I've been thinking about Twitter a lot lately, which is my social media platform of choice. That sounds awful unless you factor in how much effort I spend curating my Twitter feed. Twitter is all about who you follow. As such it can be an invaluable source of information and even humor, with a low-level stream of awfulness mixed in that makes you question why you even bother. My current metaphor for Twitter is that it's an I/V drip of dopamine hits containing a small but steady dose of poison. Since I'm an older white male who tends to avoid tweeting about politics, the poison levels normally stay low enough for me to build up an immunity, like the Man in Black had to Iocaine powder. Sooner or later the poison will become too much and I'll have to give it up, but in the meantime the stimulation outweighs the costs. I'm sure another side effect of Twitter is that it makes it harder for me to focus for any length of time, but that leads me back, once again, to the pomodoro technique.
I spent a fair amount of time this week doing pomodoros for the Kotlin book, which helped make a lot of progress. I still feel like I have a long way to go, but I'm further along than before.
Of course, what happened again is what happened several times during this process -- I thought I understood something, but when I started writing about it, I discovered there was much more to it than I originally thought. I wound up going down the rabbit hole again and again, but hopefully I understood things a lot better now than before.
Cooking More Kotlin
For those who might be interested, one of those issues this week involved Kotlin ranges. In Kotlin, a range just means there's a starting and and ending point and that the values are comparable. In other words, I can make a range like "1..5" or, with dates, "now..then", and I can ask if a particular value is contained inside it using the "in" operator. That's all fine. What I can't do, however, for anything other than integer, long, or character ranges, is iterate over it. I can't say, for example, print all the dates contained between the start and the end dates, because a "comparable" range doesn't have an iterator.
I found that very strange, probably because the situation is way easier in Groovy. (That's not the first time that's happened, btw. Groovy is far more mature and powerful than most developers realize.) In Groovy, if you want a class to be able to form a range, you give it a "next" method, a "previous" method, and make the elements implement the "Comparable" interface. That's all, and I've done it a few times myself. For example, I once wrote a "TrainStation" class that could be used as a range, basically by putting the stations along a track. That way I could make a range from, say, Washington to Boston, and visit every station in between.
Replicating that behavior in Kotlin is not so easy. I can make a range simply by making my class, whatever it may be, implement Comparable, but I can't iterate over them unless I also create what they call a "progression". Unfortunately, there's no "Progression" interface -- a progression appears to be an Iterable (and a ClosedRange) by another name.
I think I get it now, but the trivial little recipe I was planning to write just exploded, and now I have to decide how much of this is worth including in the book. I expect I'll know better in a couple more pomodoros.
Other recipes I worked on this week included more about data classes, an elegant way to override the equals method in a class (found while looking at the source code for the "KotlinVersion" class), and working with the overloaded "replace" method for strings with regular expressions. At the moment I'm up to about 72 recipes and 185 pages, but some of those need work and I've got plans for several more. I'm hoping about 200 pages will be sufficient, assuming I cover all the topics I really need to include.
This week I'm giving my Basic Android class at Safari again, which ties into all these Kotlin issues. Now that Kotlin is the preferred language for Android development, should I be teaching the class in Kotlin? It's highly unlikely that the students will know Kotlin coming in, especially because up to now I've always taught the class in Java. I would estimate that still roughly half of all Android apps are written in Java, though that percentage will likely drop quickly in the coming year. The problem is that there's already more features in Android than I have time to cover even for those students who already know Java, so if I have to add in Kotlin, then I'll lose a lot of time for Android topics.
Android is actually a mess right now, because it's not obvious how to proceed. The developers at Google have created a series of "architecture components", like "ViewModel" and "LiveData", that they recommend all developers use. Should I be using those in my course? In principle, yes, but in practice they each have their own learning curves and assumptions.
So yet again, I'm faced with making decisions in a volatile environment of uncertainty. What I usually tell students is that there are two facts of life in our industry:
There's never enough time to learn everything you need to know.
What you've already learned changes.
Back when I joined the Golden Consulting Group in May of 2000, my boss, Nancy Golden, still occasionally taught training courses. Her specialty was teaching COBOL. She updated her courses roughly once a year, generally adding or removing an exercise or two. My courses on Safari need to be reevaluated pretty much every time I give them, to make sure they keep up with latest developments.
It's the nature of the beast, I guess. I could stick to something old and stable, but I'm sure I'd just get bored. Oh well.
Last week:
Lots of work on the Kotlin Cookbook
This week:
Still working on the Kotlin Cookbook
Basic Android on Safari
My first two days teaching some basic Java for the "bootcamp" in downtown Hartford. I have approximately two days a week on that for the next six.