Tales from the jar side, Jan 13 - 20, 2019
Welcome to the latest issue of "Tales from the jar side," the Kousen IT, Inc. newsletter, which has well over 100 subscribers (and by well over, I mean 102)! Thank you very much, and I hope you enjoy this edition. :)
Do What You Love
During my vacation last week, I got into a rather unpleasant discussion with a friend about the future of various technologies. As I may have mentioned, this annual vacation trip was started by a group of current and former No Fluff, Just Stuff (NFJS) speakers and their spouses, so many of us have heard the same questions over and over again at NFJS conferences. A very frequent topic there, especially on the (Pretend To Be An) Expert Panel, is how to deal with change.
The technology industry changes as fast as any. For years I've felt it was futile to predict any changes in this industry more than two years into the future. There's a famous quote about that, from Bill Gates (of all people):
"We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten."
Feel free to play with the numbers, but there's something to that. This article lists 10 technologies that didn't exist ten years ago. Here are eight of them:
Uber
Ride sharing services changed how I travel. For NFJS conferences, which only span a couple of days and are held in hotels, I rarely rent a car any more. I take an Uber or a Lyft to and from the airport.
Bitcoin
About 18 month ago, I told my wife I was thinking of buying a small amount of Bitcoin, just to have it and see what happens. The look she gave me made it clear it was way too expensive to be worth a joke, and thank goodness for that. Bitcoin was selling for about $18K at the time. Today it's at $3712.
Instagram
I've never really gotten into Instagram, probably because I'm more of a text person. Plus I don't take very many pictures. That's probably a generational thing.
Spotify
I have subscriptions to both Pandora and Google Music. I think that's enough.
AirBnB
I've never been to one, probably because I actually like hotels. But next time I travel to Silicon Valley I'll have to think about it.
SnapChat
See Instagram. I also understand the appeal of a message that has an expiration date, but it's not something I care about.
Tesla (!)
Yes, I see that Tesla is laying off 7% of its workforce, but I still love my Model 3. I've had it for just about six months now. I'm at exactly 4000 miles (really -- I just checked) and it's awesome. I'll write more about it in another newsletter, but I have noticed one spurious correlation: before I had a Tesla I never went to Starbucks. Now the app says I'm a gold member.
(In the unlikely event anyone cares: "venti skinny blonde vanilla latte". That's a DSL (domain-specific language) if I ever heard one, which sooner or later I'll probably use as an example in Kotlin or Groovy.)
Late in the afternoon when I tell my wife I'm headed out for coffee, I refer to it as "Tesla therapy" (a term I shamelessly borrowed from my friend and fellow Tesla owner Dean Iverson).
iPad
I'm not an Apple person. I have an Android phone (a Pixel 3, which I got late last year), an old Chromebook, a Windows Surface Pro 6 (meh), and my main machine is an MacBook Pro laptop. I loathe the touchbar, but what can you do?
Back to the change discussion, on the NFJS tour the topic often comes up in the context of, "how can I accomplish change at my company," with the subtext that you're a developer who wants to use the latest tools and technologies and has to convince your boss to allow it to happen. There's a darker side, though. Each of us makes an investment in which technologies to pursue in our careers, and there's always a risk that whatever we select will fall out of favor. Then what do you do?
My friend who started this discussion told a story about how he got burned years ago when he became an expert in a field that got crushed by one of the big boys (I think it was Microsoft), to the point where he had to almost completely change directions in his career. I sympathize, but the problem I had was that his (over)reaction to that event is to argue that the only technologies that have any chance of surviving are the ones in which large enterprises are willing to invest money, and adopting anything else is an unwarranted risk.
My problem is that all the technologies I like and speak about (Groovy, Grails, Gradle, Kotlin, Android; a few others) are highly vulnerable by that measure. "Groovy had its chance and didn't make it." "Gradle will never become big, because large enterprises won't replace an existing technology like Maven, no matter how much they hate it, with a product backed by a single, small company." "Kotlin is proprietary to JetBrains, so the same argument means it'll never be big." "Google keeps trying to kill Android and replace it with a component model." And so on, and so on. Basically everything I cared about came under attack, or at least what felt like an attack.
"But I've written books in several of these areas and have more on the way!" I protested.
"Nobody reads books anymore," was his reply.
It was a fun conversation. And by fun I mean the exact opposite.
So what's my approach? How do you mitigate the risk of adopting a technology that falls out of favor? Do you restrict yourself only to technologies that are highly likely to succeed? How much career risk can you afford?
I take the following attitude: Do what you love, because:
If it becomes popular, you'll still stand out, because when you love it, you'll spend the extra time and effort needed to really learn and understand it. Plus there will be enough opportunities to go around.
If it isn't popular or loses adherents, then all the people who jumped in "for the money" will leave. You'll still be left, because you love it, so if there are any opportunities at all, you'll get them.
This does assume that there is a minimum number of available opportunities (there's that Maslow's Hierarchy of Needs again), which is certainly a gamble. But your field is collapsing so completely that there's nothing left, hopefully it'll be obvious and you can do what you need to do to move on.
As an aside, I recently read that there are still over 4 billion lines of COBOL used in the industry, and COBOL consultants are very highly paid, mostly because there are so few of them. Of course, the price you pay for that job is you have to code in COBOL.
Despite its name, Groovy has never been the "hipster" language. It has always been a quiet technology, helping to make Java better rather than replacing it. Plus, the community is made up of some of the nicest people I've ever met. Fortunately my experiences with both the Kotlin and the Android communities have been similar. That matters to me. I usually care as much about who I'm working with as what I'm actually doing, and with those communities my experiences have been overwhelmingly positive.
Admittedly, it helps to be a white male in all this, and getting older hasn't negatively affected my job prospects yet. (When you own your own company, you can't be let go, but you can go out of business.) Your mileage may vary.
My friend is a good person. He just has curmudgeon tendencies (like so many senior developers) and loves to pontificate (like so many professional speakers). Maybe I mind so much because that's my job. After all, he's not the one with his own newsletter.
Wanted: People Who Aren't Me
I talked to my Managing Your Manager editor this week, and we're hoping to have our "three chapter review" done by the end of the month. The book is supposed to be short anyway, which I need to have happen in order to successfully accomplish other commitments. Oh boy, that ought to be fun. I'm not intimidated at all right now, as far as you know.
I do want to mention one issue, though. I expect to have a chapter in the book on advice for women and underrepresented minorities. I know that's a risk, because when a white male says they're going to give that sort of advice, the best response is to tell them to be quiet (or, more forcefully, STFU). I get that. Still, I feel that in the #meToo era, it's important that I at least show how the advice I give in the rest of the book applies or needs to be modified for those circumstances.
That said, it will be vital to have reviewers whose perspectives are different from mine. I already have a few people in mind to approach, but if you're one of those people and you're interested, please let me know. I don't expect to be ready for reviewers for at least another month, but feel free to contact me anyway.
Keep in mind that replies to the newsletter are added to the archive, so if you prefer to contact me privately, please use my regular email address ken.kousen@kousenit.com.
Oh, and if you have a Safari account (on The Site Formerly Known As Safari), I'm giving my Managing Your Manager half-day training class on January 31. Feel free to drop by and say hi.
Have a Groovy Spring (in the Winter)
This week I got to teach my normal Spring and Spring Boot class for a private client, but the twist was that they wanted to implement the code in Groovy. That's the first time in years I've had to port something from Java to Groovy, and I forgot how much fun it is. Groovy simplifies everything, from basic code to POGOs (Plain Old Groovy Objects) to tests and more.
The class was really enjoyable, but it lead to one unexpected issue. Because the code was so much simpler, I ran out of material much sooner than I expected. As a result I had to scramble to add all my material from my regular Reactive Spring course, again ported to Groovy. The result worked well, but the result was that the class took more time and effort outside of class hours than I originally anticipated, which means I didn't get much writing done.
I did get contacted about a similar class, however, to be done in Kotlin. I've been digging into the Kotlin features supported by Spring (I'll probably start talking about that in the next newsletter), so that ought to be fun, too.
Last week:
Spring and Spring Boot with Groovy course
Met with co-author of one book and editors of two others (to be explained later)
Next week:
Teaching online Introduction to Gradle Tuesday and Wednesday for Gradle, Inc.
Teaching Spring and Spring Boot on Thursday and Friday on TSFKAS (The Site Formerly Known As Safari)
MLK Day, so errands and writing and stuff along with the holiday.
Better be more writing, too :)