Implicit no

I’ve felt busier at work this year than usual. (Hence why it’s been a year since my last post – yikes!) I’m probably not actually busier as measured by, I dunno, theoretical units of work effort. It’s that there is a wider variety and breadth of what I have to deal with each day than, I think, ever. Rather than concentrating on fewer items, my time and attention are spread across many items.

I don’t like working like this, and I’m also not used to it, compared with diving deeply into technical efforts. I don’t have the mental habits in place to work well this way (at least by my own assessment).

So, I’ve been learning and reading about this conundrum. While researching one topic, how to make effective requests, I ended up reflecting on how I respond to requests. I try to take care of everything on my plate, regardless of who placed it there, but this year I’ve seen just how finite the size of that plate is. I can’t respond to everything that either I want to or others want me to.

For this common work scenario, you’ll hear the recommendation to learn to say no. I’ve realized how very rarely, nay, even seldom, I out-and-out say no. I mean, I totally buy into the idea, but when it comes time … that little word barely ever passes between my lips. Just thinking about saying that to a coworker feels bad to me when I imagine it.

The problem is that, because of my reluctance to explicitly say no, I am instead implicitly saying no, now more than I used to. That’s even worse.

Continue reading

Chunking through unit tests

Ever since the advent of multi-tier application architectures (which seems forever ago now), I’ve commonly had to work on tasks that span multiple levels of abstraction. You probably have too. For example, say you need to implement a new REST API call in your classic web application. You have to:

  • Define the endpoint itself, with its request and response formats.
  • Implement some business logic for it.
  • Update the data layer to persist and/or query what needs it.

That’s just your three classic tiers, and sure, once you’ve done this sort of work enough, it’s almost straightforward. But, as time goes on and your application gets complicated, more aspects creep in. Security. Audit logging. Retries and resiliency. And then there’s all those newfangled microservices to deal with. The neat layer cake ends up looking more like monkey bread. How can you keep track of all of this and get your work done?

One way is to use something you should be doing anyway: writing unit tests.

Continue reading

In praise of incremental development

A good traveler has no fixed plans and is not intent on arriving. – Laozi

The other day I was asked about whether an encryption feature in a product I work on supports user-supplied keys. I had to look back in Jira, years into the past, for the answer, which was: nope. It supports default keys, but we hadn’t had time for supporting user-supplied ones.

While this is a little disappointing, it still was the right thing for us to do. That’s the paradox of incremental development, and why I think it’s hard for developers to fully embrace it.

Continue reading

Hierarchy of “Is it supported?”

As tech lead of Cloudera Altus Director, I’ve often been asked whether some product feature, or use of a particular version of some external software, or use of some external service – some it – is supported. I found that it’s really hard to answer these questions. There are different factors involved, like how much testing we’ve done or continue to do, or what we recommend to customers, or say we’ll let them at least get away with. The answer is rarely a binary, absolute yes or no.

So I spent some mental cycles thinking about the question of whether something is supported. Thinking about the different angles, I came up with a hierarchy of support levels. It’s certainly a “1.0” sort of artifact. But, I think it’s a good starting point, and it already helps me answer “Is it supported?” questions today.

Continue reading

Remote Work Tip #4: Overcommunicate

Those who are against remote work are right about one thing: There really is no substitute for face-to-face interaction with someone where you are. All those nonverbal cues that we’ve evolved over eons to pick up on. The side conversations about hobbies, family, sports, TV … you know, the non-work stuff. Just existing in the same place as your coworkers. It definitely helps to bond a team together.

HOWEVER. Being physically together with your team is not necessary for success; there are successful, all-remote teams (and companies) out there (see Gitlab, Basecamp). It also isn’t sufficient for success, as evidenced by the legions of failed software projects which, despite everyone being stacked into one building, ultimately failed.

The best argument one could make, perhaps, is that co-location increases the odds of success. I am, in fact, quite the proponent of increasing your odds of success – that’s why you stay in school, say, or don’t smoke. So, if you and your employer are considering or implementing remote work, you’d need to use other tactics to make up for the (possibly) decreased odds of success from having a distributed team where no one is in the same place.

The primary tactic to employ is to consciously make up for those missing side conversations and cues that are harder to read over a video hangout. It is helpful and effective to intentionally overcommunicate when working remotely.


This doesn’t mean to become a incessant fountain of vacuous emails and phone calls. That’s as bad as being that loud coworker who won’t stop talking about the latest episode of Such-and-Such or the Ludicrous Display Last Night. It means to take steps to actively fill in the gaps that are created when you can’t just lean over and ask a question, or answer a question. Here are some essential steps to take.

  • Be present in a chat window. For example, my team has a persistent chat room where we can ask and answer questions, or make quick announcements. This is the closest analogue to all sitting in the same physical room, without the coughing and keyboard clackering. While this is a key practice for overcommunicating, it’s just as important to not let chat take over your time (looking at you, Slack). Sometimes you are busy, and it’s good to hang up a virtual Do Not Disturb sign when necessary.
  • Don’t hesitate to hop on a video call. Text chat and email are great for what they are great for, but back-and-forth, involved conversations work better using our voices. An audio conference call is OK, but a video call is better; it’s more like everyone is together. Just make sure to look presentable.
  • Document more. Even in a standard workplace, it’s common for decisions made in a meeting to not get written down, and that can cause problems because everyone tends to remember the past differently. Documenting plans, decisions, and meeting minutes becomes even more important for remote workers, since the lack of physical presence makes their experiences vary more. Also, maybe they all can’t make it (because they are asleep halfway around the world), so they need the record to stay informed. A good video call system should permit recording, and a wiki or shared storage is great for writing everything down to share with everybody.
  • Don’t stick only to work topics. It may take bravery, but having a discussion or email thread about something random helps a team gel, and takes the place of those metaphorical water cooler discussions. An easy starter topic is linking to some semi-work-related blog article, which was a pretty good read and you thought you’d share, and so on. Then you move on to a webinar video, or some interesting news from your field, or some resource about a hobby you enjoy, or information about a vacation. Eventually, once you’re sharing cat videos and using emoji as your team’s secret vocabulary, you know that you’ve got a good culture going.
  • Follow up with confirmations on actions, decisions, and discussions. Email threads and chat conversations can sometimes just fritter away without a solid conclusion, especially without some leader-ish person running them like an in-person meeting. Be sure to close out remote discussions with a summary, next steps, and the like, to be sure that everyone is in agreement. Again, this is a great practice even for a co-located team, but more important for a remote set of coworkers.
  • Say hello and good night. Mindfully practice those little niceties that are automatic when you’re with someone.

There are plenty of other useful overcommunication practices that you can discover, but I think this is a good starter set to think about. Even though you are sitting by yourself somewhere, you’re still part of a team, and expanded communication is the way to make it feel like you are with everyone, working alongside them. Technology has granted us lots of ways to communicate that make achieving that feeling, that spirit, possible. Once you have that, you’ve beaten the odds.

Remote Work Tip #3: Make an effective work area

In my first remote work tip post I talked about creating a separation between work and non-work. Part of that is having a place in your home that is only for work, and nothing else. That modest physical separation helps with the mental part of the separation.

If you were working in an office, you’d have a desk set up with the usual set of equipment. Working remotely shouldn’t be much different: Set up an effective area for remote work, with elements like a work area in an office. Your couch is probably not the best environment for getting down to business, no matter how comfortable it is.


For example, I am a software engineer. So, I have a big (not enormous, this is in my house after all) monitor sitting on a desk, into which I plug my closed laptop, and I have a high quality keyboard and mouse to use all day. I’m not spending all day hunched over my little laptop screen, typing away on a merely OK keyboard. What I have at home is, in some ways, actually nicer than the bog standard equipment I’d have in an office (before I’d swap it out, anyway).

Don’t forget to use a good office chair. It’s easy at home to just haul out a cheap folding chair or stool, but you’ll be sitting in this thing for hours, so just like you should have a good mattress for all the time you spend sleeping, you should be kind to your body with quality seating.

When you are working remotely, you need to pay special attention to the technology that enables audio and video chat: webcam, microphone or headset, and speakers. In an office you might not have any of that, since you could always go off to meet in a conference room, but they’re obviously essential for remote work. Pay special attention to the webcam and microphone / headset quality, since those affect how you are presented up on that screen at your home office. It’s much more desirable to have a clear, crisp image of you up there than a low-grade, pixelated image; to others, it feels more like you’re there with them as part of the team.

Speaking of webcams, do make sure that the view behind you isn’t embarrassing. It doesn’t have to be perfectly clean and formal-looking, but there shouldn’t be piles of laundry, greasy tool racks, or questionable posters in view of the audience. The view from your webcam is essentially “your office” as far as everyone else is concerned, so just like it’s important to get dressed, your walls should be presentable.

I’ve found that I don’t really need to work with paper much beyond taking notes; remote work naturally lends itself to working with online documents. If you still need to deal with writing on dead trees, though, also invest in a decent printer or multi-function device (printer / scanner). I can say that they are still as complicated and touchy as they’ve ever been, so it might be tough to find one that’s good quality, but give it your best shot.

Beyond the tech, make sure you have the usual office supplies around that you need, like paper, pens and pencils, scissors, a stapler, necessary cables, all that. It’s the same stuff you’d have in drawers in your office desk. When I travel to one of my company’s offices, I always check to see if there’s anything useful in the supply closet to bring home.

Try to keep your work area reasonably clean; this is actually pretty tough depending on your work style anyway, but it’s even harder when the area is in your house and no one else can see it. If you need to keep papers around, get a filing cabinet or some other sort of organizer. Put books in a shelf or cabinet, not in a crooked stack. Wipe down the area once in a while. It feels better to work in an environment that wouldn’t make your mom worry about you when she sees it.

Also, don’t forget to dress up your space with knickknacks, office toys, artwork, or whatever else you like to have around you. Again, this would be just like what you’d do in an office. If you’re going to spend eight or so hours a day in the area, you might as well make it pleasant to look at. Bonus: since most of your work area is off-webcam, you have a lot more freedom to decorate.

Finally, pay attention to the lighting and ambient sound in your work area. Avoid working in spaces with a lot of ruckus nearby, like just off your kitchen. Since you’re not in an office, you don’t need to deal with horrendous fluorescent lighting, so use a good lamp or a few LED strips for backlighting, or whatever you find pleasant. The light and sound around you matters a lot for those video chats, too; ensure that there’s enough light for you to be seen by, and little enough noise that you can be heard.

See if your employer has a budget for remote workers to purchase equipment (they are saving money on office space anyway), or if they will otherwise reimburse you for home office purchases; that’ll help take the bite out of the cost for bigger items you decide to acquire. If not, then just think of it as spending some of the money you’re saving on gas, parking, and lunches, except you get to keep what you purchase.

Having a highly customized work space is one of the many perks of working remotely, so optimize it for what you need and where you’d like to spend your work days.

Remote Work Tip #2: Get Dressed

Last time I wrote about maintaining an artifical work/non-work separation as important for healthy and effective remote work. Here’s one (of several) associated, specific ways to help with that separation: dress (mostly) like you would for the office.

Perhaps the most common diss against people who work at home is that they are so lazy they just work in their pajamas. Or without pants. While these wardrobe choices probably aren’t as common as the haters say, there is a good point behind the criticism. There are studies about how what you wear can affect your performance and how others view you (which is unfortunately something you have to be concerned with for those who are back in the office while you’re not).

I generally dress as if I were going to the office, but perhaps backed down “one step”. On reason is that I can demonstrate that I am working just like everybody else, so as a show of camaraderie. Another is to help maintain that separation between work and non-work, foster that mental shift from “I’m at home” to “I’ve gone to work”. You can’t do that as easily in your pajamas.

I say backed down “one step” because, well, you are actually not in the office, so there is a slight relaxation of judgment that everyone understands. I think if you were working at home and wearing a suit like all the other dudes in the office, it would look odd to everyone. (Unless you’re getting on a client call or something.) Dropping the tie, or the jacket, seems quite reasonable to me.

Retiring in 67

The office environment where I work is quite casual already, so I have an easy time of it. For example, T-shirts and jeans are completely fine. Still, I won’t wear some of my older, run-down shirts to “work” anyway. Again, these are your co-workers, so it’s nicer to them not to look way out of sync with them.

I’ve kind of been implying that all of your coworkers can actually see you, because I know that face-to-face telecommunication is essential for effective remote work. So, you’ll be on a video chat with people on a regular basis. When you know you aren’t going to be seen, though, again, that switchup in wardrobe helps with the separation from home life, so it’s still a good idea.

Now, I’ll admit that I do sometimes “pop in early” to work while still wearing what I slept in. This is tantamount to checking your work email before heading in to the office. It’s not long before I step away to take a shower, get dressed, and formally start my day. On the flip side, when I’m done with work, sometimes I’ll change my shirt to signal to myself that I’m done for the day. It’s funny, in such a cerebral, abstract field like software engineering, how what you wear can have such an effect.

I haven’t worked in a co-working office before, where people from random jobs come together into the same physical space. I’m not sure what I’d do. My first guess would be to stick with what I’d be wearing at home; after all, everyone has different levels of comfort or job-related need, and the collection of people in the office are not themselves a team.

This isn’t a tough tip to follow. If you’re concerned about exactly what to wear, imagine that you would have to go drive in to the office later. If you could just step out of your door as you are, or maybe just change out of shorts into slacks, you’re good. If you’d need 45 minutes to get ready, maybe you’re looking a little too relaxed.

P.S. Regardless of the above, one rule remains above all others: Always wear pants. Thank you.

Remote Work Tip #1: Maintain separation


I am a full-time remote worker for my employer. I work from my home as part of a distributed team, spread literally from one side of the (continental) US to the other. I’ve been doing this for a few years now, after about a decade and a half of the usual office / cubicle work life.

I’ve come to realize that I am, perhaps, odd about this, in a good way. Usually when someone describes remote work, they say that there are the downsides of lack of social contact and feeling hemmed in at home and such, sometimes. NOT ME, MAN. I could stay at home forever and it’d be great. I can still go where I want to, but I feel connected enough with my coworkers that the occasional trip to see everyone in person is enough. For me, that social downside is barely there.

So, having been immersed happily in remote work for some time, I can anoint myself as a minor authority on the subject, if you don’t mind. As such, I’d love to talk about tips for being an effective remote worker and loving it.

I’m not going to try to convince anyone of the merits of remote working. There’s plenty of material out there about that: studies, and real-life stories, and all that. This is for the remote worker who wants to up their remote game. Of course, I could always use tips too, so if you have them, I’m all ears.

My tips will bend towards working at home, versus at a local coworking office, because I do the former. Still, some of what I talk about will apply no matter where you physically are.

With that out of the way, here’s my first tip.

With a classic (I’ll say “legacy” with a snicker) office work environment, you go to work to work, and then you go home when you are done with work. Well, except these days, apparently, people can’t stop working even when they’re home, and have to keep answering emails and writing reports and stuff for all hours. Setting that huge problem aside, the idea at least is that at the end of the work day you go home and do all those other things in your life, you know, like eating, sleeping, and perhaps relaxing if you won’t get fired for it.

When your home is where you work, that physical separation is gone. There’s no commute either, which is super great, but that also takes away that transition time when you are either mentally preparing for the day or coming down off the day. So the temporal separation also vanishes.


Without those separations, it’s really easy to “lose track of time” and keep working. Or, have the problem I fight, which is to check back on things at, say, 10 at night, you know, because it’s all right there and maybe somebody needs something so it’s quick. This, like taking work home with you in the classic environment, is bad, for all the same reasons as the classic environment.

It’s important, when working at home, to create a semi-artificial work/non-work separation. What this means is that when you are about to start work in the morning, you say to yourself, “I’m going to work. I’m at work. Work has started,” and when you are done (and you pick that moment when you are done), you say to yourself, “I’m done with work today and I’m heading home. I’m home now. Work is over.”

It’s silly, but that doesn’t mean it’s dumb. (I joke with my family that my commute home is walking down the stairs, and the only hazard in that commute is our cat.) It keeps work from seeping into the rest of your life. Those studies about eight hours being about as much as a person can work effectively in a day aren’t irrelevant just because your work area sits inside your home.

This may sound ironic to remote work haters who figure everyone who works at home is actually lazy / slacking off / eating bon-bons and watching Dr. Phil. Well, just because those haters would do that if they were working remote doesn’t mean everyone does it. Heh heh.

Part of enforcing this separation is having a defined space for work. Sure, it’s fine to chill on the couch once in a while, but having a dedicated proper spot, just for working, is crucial to confine your work time. I’ve got a desk, set up just as it would be in an office, optimized for me getting stuff done. It’s not for gaming, or doing the bills, or anything else. When I sit there, I’m working. When I’m home, I’m not sitting there.

Your family, friends, and anyone else you live with need to help here, too. If you were working in an office, your kids wouldn’t hang all over you, or your parents call you daily, or your friends pop in unexpectedly for a few hours. Working remotely is no different. You are “on the clock” doing your job. You understand that, and they need to as well. This doesn’t mean you can’t take a break to chat with your spouse, or talk with the ‘rents once in a while. Those are benefits of working at home. But they can’t be common distractions.

Besides the physical and social separations, there’s the temporal separation, but this is tough when your commute is zero. I find it’s helpful to let myself ramp up when I’m starting to work, and also give myself time to “decompress” once I’ve declared the end of my work day. Especially with the latter, I don’t always feel present mentally, which is interesting. I guess even if a physical commute is gone, the mental one remains. Others have to help you here too, and not leap on you once you emerge from your study in the evening. You’re physically at home, but your mind needs a few minutes to catch up.

A strong work/non-work separation keeps your work life and your home life healthy. It also fosters a inner feeling and an outward impression of being a responsible employee, as dedicated as anyone back in the office. This helps keep your team cohesive, no matter where each individual is, and tells your management that you are serious about cultivating a proper remote work ethic.

The Java versioning situation

It’s been quite a long time since I’ve blogged anything here, but I think I should pick back up again. I enjoy it. It’s not like I’ve been idle for a year plus, so I’ve got a few topics I could talk about here. One that’s sort of been vexing me lately is the new Java versioning cadence.

To be honest, it’s shifted so much over the past few months that I’m not 100% confident I understand it. Where it should stand now is as described in JEP 322, and there it seems as if the ill-advised date-based versioning proposal has been set aside, relegated to the “Alternatives” section. It lingers here and there in things I read, but I’ll just proceed assuming it’s gone.

So basically we’re now in a six-month “feature” (i.e., major) release cadence, and every third release is a long-term support (LTS) release. There are some benefits to having a regular release cadence; there’s always a train ready to leave the station that you can board new features onto. I think that helps motivate the introduction of new language features, because it does away with discussion about “is this worth a new release?” – instead, it flips the question to “which release is this ready for?”

Tokyo 3345

The date-based versioning scheme, yeah, though, wasn’t a fan. I tried not to look at it as a curmudgeon oldster or anything, but I just couldn’t get myself comfortable with it. Maybe I’m too much of a semver fan, although even that doesn’t say you can’t just use the year as the major version number. I just prefer having languages version themselves independently of when they happened to show up.

Even the new scheme has a bit of an issue because that first number in the version string isn’t tied strongly to the introduction of new features or breaking changes. It’s just a one-up counter, every six months. I suppose some Java release in the future won’t have any major changes in it, but that counter will have to bumped anyway. This runs counter to organizations’ expectations that when that first number changes, it’s a big deal.

From my experience, big organizations that doesn’t do tech as their main line of business don’t grok the intricacies of version numbering. Their security teams and IT organizations just devise straightforward rules to follow, and one of those that they learned over the past decades is that when that first version number changes, you have to do a lot more acceptance / security testing before you let it in, because that means there are significant changes to the software. It’s been learned as a message from the vendor that this new release is not just a run-of-the-mill update.

Java doesn’t play by those rules anymore. I can see a (reasonably) paranoid organization balking at this swift change in version numbering. A counterpoint, though, could be browsers like Firefox and Chrome, which bump their numbers up with abandon … and Firefox at least does LTS releases. Hopefully they have served as harbingers for this alternative take on versioning.

Another odd but somewhat logical consequence of this new cadence is that those non-LTS releases of Java go EOL in six months. This makes sense from the language point of view, to motivate customers to stay current, especially for security fixes. But it’s a PITA for a software vendor, such as my employer. When Java 9 came out, should we have embraced it and moved to it as a minimum version for our software? Definitely not. Why?

  • We were just moving up to Java 8 as a minimum, because our software had promised Java 7 as the minimum for our customers. We won’t bump up the minimum Java version without a major release of our own product. Ugh.
  • What could we have done for customers who hadn’t accepted Java 9 yet? It’s not unheard of to wait a year before considering adoption of a major language revision, and Java 9 hasn’t been out a year yet (as of right now).
  • When Java 9 went EOL, what would we do? Declare you need Java 10? We’d be in for another round of testing ourselves, and probably need to cut new (major) releases. And how about those customers, still reeling from the rush up to Java 9?

And that’s the kicker. At the time of this writing, Java 9 has already gone EOL. Today, to be using a supported Java, you should be using either Java 10 or Java 8. Java 9, we hardly knew you.

A root problem here is that the enterprise world, which my employer seeks to support, isn’t yet ready for this cadence. They want stability, and we want to give them stability, so that they can manage risk for operational systems. An end-user application like a browser has a different risk profile than a language running mission-critical applications. For the latter, if the Java version it runs on is working, then it’s best not to touch it except for bug fix releases.

The operating assumption I’m going with nowadays, then, is to essentially ignore the non-LTS releases, for our own sanity and those of our customers. Really, that’s the purpose of an LTS release. If you are in a really fast-moving environment, you can upgrade with the speed you crave; otherwise, stick with the LTS releases and don’t worry about it.

That means that Java 11, coming out in September, is what we care about next, and we’d better gear up soon to test it, for when Java 8 gets yanked away. This will still cause some hand-wringing and fretting. In a way, though, we could use a little motivation to update more quickly. Not so much for the language features (which I’d like to play with), but for the security features.

Thinking about Firefox in particular, I remember it was a big deal when they switched to the Chrome-like versioning cadence. However, their seamless upgrade experience makes it work. The Java language could use something like that, but it needs to bring along with it the experience that moving from one major version to the next is no longer A Big Deal. Hopefully, after a year or two of enterprises being hitched to the new release train, that happens.