It’s natural to be a little lost when a familiar context is completely altered, as has happened to millions (!) of people around the world in the past few months as a result of this truly awful pandemic. Three weeks since the WHO’s declaration, there appears to be an abundance of “experts” offering advice on how to “work from home”.
I’m not a WFH expert, merely a practitioner with decades of experience and while this may seem like an opportunity for many people around the world to show just what can be achieved by a WFH workforce, it’s really not.
For one thing, in almost all cases there was no proper planning. A workforce that suddenly has to work from home is not usually on the business continuity radar. Shouldn’t this be part of “building availability” contingency? Yes, but typical answers to this challenge involve moving to another building, preferably nearby and similarly equipped. So unless you have very deep pockets to reserve an emergency hot-office (as some banks might), you’re not going to be able to deal with the case where almost every office building on the planet becomes unavailable.
As the virus spread across the world, many office workers were given mere hours to decamp to their homes as governments announced lockdowns (or variations on that theme). This ad-hoc introduction of WFH had people suddenly facing all kinds of problems, including:
Everything in the office is not necessarily accessible from home, including all that paperwork in the filing cabinets. (Yes, paper still exists!)
You’ve been promised but not yet received a laptop replacement for your office desktop computer, so now you have to haul that old lump of metal home. On the bus.
Your house uses wifi exclusively, but not your lump of metal PC, so now you will have to go buy a length of ethernet cable at the computer store. Which is shut.
What’s a VPN?
Your asymmetric home broadband seems fast enough to download the office files, but is taking forever to upload the edited versions.
Everybody seems to have their own idea of what is the best video conferencing solution.
Residential networks were not built for this level of traffic.
Some staff live on the lee side of the mountain away from the mobile phone mast, so to receive emails they have to stand on a bucket at the top of the mountain holding the phone in the sky. In the rain.
Nobody has ever explained how to do more than a few days working from home, so by day three everyone has gone completely bonkers. Meetings – for those who figure out how to attend – are haphazard at best and nobody knows where anything is located any more.
The list goes on and on. Some of these problems don’t have answers. If you need the paper files in the cabinet, and the cabinet is still in your shut down office, tough. Some problems take some ingenuity. For example, your lump of metal PC with no wifi antenna could connect to your home wifi access point by sharing your mobile phone’s wifi connection via a USB tether.
Consequently, this is not the great “let’s show what WFH can do” experiment that many have dreamed of. This is more the nightmare that goes: “let’s reveal all the WFH problems!”
Nevertheless, thanks to an overwhelming desire for people to share stories of accomplishment in the face of adversity, in time most of the solvable technical problems will be solved.
In the meantime, I offer some practical suggestions based on years of personal experience, though be warned that this might not align with the “expert” advice you see elsewhere. Naturally your mileage may vary.
WFH : A practitioner’s perspective
Mark your territory. This is important. Do it on day one. Say “this table is mine” and defend it night and day. This territory, wherever and whatever it is, will be where you work. When you are not within the boundaries of your territory, you are not working. Make sure people know this. Make especially sure that you know this.
No meals in the work territory. Seriously. Have you looked inside your keyboard recently? Eat elsewhere, and since elsewhere is not the work territory, you do not work while eating.
Dress for work. At least from the waist up. If your attire has no bearing on your work, wear whatever is comfortable. Sometimes attire can be a useful signal to others around you that this is your work time, which hopefully reduces interruptions. For some, changing attire at the end of the day is a signal to everyone (including yourself) that work has ended.
Put in the effort, not the hours. It’s a sad fact that much of our work is measured in time. I prefer to measure in results, so my day tends to start with a rough idea of what I want to achieve and how much effort I expect to put in. Normally that keeps me busy for hours, but when those hours take place can vary considerably. If I hit a mental block, I just pause, leave the work territory, go do some non-work (e.g. walk to the post box), and then resume the work with a clear head. Sometimes, often in fact, my work starts to flow so I go along with it even if it means working longer hours. In such cases I will have stored up extra results so the following day I can take a little easier, maybe an extra long coffee break.
Reserve certain periods. You need some regular clock hours if you are going to work with a team of (remote) people. In that case, let everyone know what periods you will be available, and what periods are off-limits. Your co-workers, clients, suppliers and anyone else you interact with need to understand that in addition to working from home, you also live at home. They cannot assume that because you are at home you are also at work. The French have the right idea. If you are contacted during living time instead of working time, defer until it is appropriate to be working again. (Use your judgement, of course, emergencies happen!)
Remember to move regularly. The typical office scenario has a certain ebb and flow to it, and you can adjust to that rhythm quite quickly. Breaks are an important part of the rhythm so a healthy office environment will encourage you to take breaks regularly. In the WFH scenario that rhythm can be lost, and you could find yourself buried in work for hour after hour without noticing, taking no break, ruining your posture and eyesight. Stand up. Look out the window. Stretch.
Regulate your distractions. I’m a news junkie. Maybe sports results are your thing. Or cats on YouTube. Whatever is your preferred distraction, make time for it. Like the short walk outdoors, this can be a short walk for your mind. Just remember to regulate it, so that you have specific time allotted during which you are not working and you can compensate for these periods elsewhere in your day. It’s one of the few advantages of WFH that you can do whatever you need to recharge your batteries, and it pays back in better efficiency and less stress (unless your news/sports is going pear-shaped).
Separate concerns. Many work activities involve sensitive information. If you are doing that kind of work, keep it completely separate from any of the non-work activities you do. So if you want to look at cat videos, leave the work territory and use another device.
Talk to someone every day. This, my final piece of advice, is important. WFH means you are not in an office with people physically nearby, and your work could be the kind that can be done from daybreak to sunset without ever needing to say a word to anyone. Email, code checking, push notification, IMs etc., are all quite practical and efficient, but we are not robots and without some human contact we can quickly lose our bearings. So at least once a day, make contact by voice. Add video if you can. And for at least a few minutes of that call, talk about trivia like normal people do at the office. It’s good for your mental health.
This period of WFH has been imposed on so many people around the world and it could be this way for many more weeks or months. When it’s all over, and it will be over, most of the new WFH people will go back to the office. Some might discover that WFH works better for them, and continue that way. Others will be just glad to get back to something akin to normal. In the meantime, guard your territory!
I’ve been a tech consultant for several years. Having come from a long history of CxO-level roles, head-of-this, chief-of-that, chair-of-the-other, I find myself, for the first time, alone. I still have busy days engaging with people, my inbox is as hectic as ever, the IM pings are continuous and my schedule isn’t pretty. Working in teams is something I miss but I’m fortunate that many of my most trusted colleagues have remained in touch. Travel is a thing of the past, thankfully (as it was becoming tedious). There’s nobody to whom I can delegate and nobody to whom I must report other than my clients.
During a recent meeting with some people at a government agency that is tasked with providing advice and tangible support to small businesses I was reflecting on the nature of my role as consultant. They remarked on something I’d observed over the years: great business leaders will recognise their limitations and reach out for help. In the larger companies, that help can often come from within. For the smaller companies, they have to look outside. This is where these government agencies and occasionally consultants like me come into the picture.
Mine is the advice/opinion kind of consultancy, not the executive kind that involves management/oversight. Offering advice is hard work. “Well, he would say that, wouldn’t he?” I look at where a company is, and where it wants to be. Then I ask some probing questions. Then I listen. Followed by some research, probably some more questions and finally I offer reasoned suggestions to get the company from here to there.
Listening is the hardest part. It consumes a lot of time. It’s also a part of the process that I really enjoy because I learn so much. Sometimes a round-table session with the company’s senior staff is the first time they’ve collectively tried to explain to an outsider what they do and how they do it. Such a session can be an opportunity for staff to learn more about the operations of other functions in their company. The CEO is usually involved in these meetings, and will often find them enlightening.
It has taken decades for me to acquire the knowledge and experience to do what I do. I’m so glad to see the positive impacts that result, and I look forward to continuing this work for years to come. Onwards and upwards!
Despite general agreement that lower energy consumption is a “good thing”, on reflection this doesn’t seem to be a real motivator. Convenience, cost, comfort; those could be the real drivers. At least, that’s my observation with respect to my own personal circumstances.
I recently switched to an all-electric car. Was this to save the planet? Was it to reduce pollution? Honestly, no. I just don’t like noisy cars, but range anxiety has kept me away from e-cars for a few years. Until now, when ranges over 400km per charge became available. Now my trips to clients, or even just down to the supermarket, are pleasurably quiet. A 200km round trip the other day was sheer delight. Fuel costs are much lower (less than 25%!), tax is low, maintenance costs are expected to be low, and I even get discounted road tolls. Saving the planet is just a nice by-product.
My workspace has several screens, but I only turn on the ones needed at any given moment. Saving power? No, I just don’t like the glare.
I don’t have a regular commute, so public transport doesn’t figure much in my life, but I do take the bus from time to time. This isn’t because I want to avoid contributing to congestion but because the city is already congested and finding parking can be a pain. Not to mention the advantage of being able to have that glass of wine with my meal, given that I’ll be chauffeured home.
Locally produced fruit/veg is preferred to long-distance imports because it tastes good, not because it avoids the haulage pollution.
What I’ve come to understand is that while it’s nice to feel “green”, much of what motivates us has nothing to do with the long-term societal outcomes. That’s how it seems with regards to energy consumption.
If only I had a good explanation for what motivates me to spend so much time carefully separating my recyclable waste…
Testing Web services in a development environment over SSL/TLS (HTTPS) can be a problem if your development environment doesn’t have a suitable SSL Cert. In such cases, creating a self-signed cert is usually sufficient, but you have to ensure that your client applications (including browsers) trust the cert you created yourself.
Here’s a recipe for creating a self-signed certificate and installing it into Firefox so that the Developer window doesn’t fill up with warnings (such as about Strict-Transport-Security headers being ignored). The recipe assumes you have keytool (usually in the “bin” of your JDK). This is for Windows, but similar steps apply to other OSs.
Now run Firefox, select “Options” from the menu, then the Security section and find the bit where you can View Certificates. In there, import the .p12 file into “Your Certificates” (and you’ll be asked for the password). When you visit a server using your cert for SSL, such as one installed on localhost, Firefox will issue a warning, but you can tell it to make an exception by following the instructions that appear. From here on you will be able to visit your local dev server and not see too many security errors in the DevTools console, which allows you to concentrate on other important things.
Before you deploy to production, it makes sense to test using real SSL certs, and for this you could pay a visit to Let’s Encrypt and get a genuine cert completely free. You’ll need a genuine domain to use LE.
Sometimes the only way to get a development tool installed is to compile it from source. In fact, many Open Source projects will assume this is how you intend to install. Some nice people out there might actually compile it for you and make the binaries available, but unless you have 100% trust in whoever is supplying these, compiling from source might be the best route. Perl, my Swiss Army Knife of choice, has many contributors offering modules that go through an elaborate compile/configure/test routine. Such installation processes can take a few minutes to complete, which is often a good excuse to go get a coffee.
The build scripts accompanying such from-source resources often include liberal dollops of commentary that appears briefly on screen before scrolling out of view. Since these are from tried-and-tested supplies, we expect such messages to be generally reassuring. After all, if there were problems then surely this material would not have been recommended for me to use.
During development it would be normal for the developer to be verbose in the commentary. Error messages in particular, especially as such a message may be the only one you will see before the whole build grinds to a halt, and so you’ll probably need a lot of precise information to help solve the problem that caused the error.
Warnings, on the other hand, don’t slam on the brakes. They just let you plough on through, hopefully leaving the developer with a hint regarding some possible problem that just might need to be examined before letting this material loose on an unsuspecting world. Of course, tests that are performed later in the build might confirm that the earlier warning was not really a problem after all. Good. One warning that can be ignored.
Usually what happens is the developer lets the warning continue, knowing that it’s not really a problem. A warning about loss of accuracy when assigning a floating point number to data type with less decimal places is not a problem when the developer knows that the data in question is only accurate to one decimal place anyway. A warning about an API call being an unofficial internal method is not a bother to a developer who is in fact an insider responsible for the API. Yes, the parameter’s documentation is missing, but it’s already explained in detail in the preamble. Sure that method is deprecated but there are solid reasons for using it in this case. Possible fall-through to default case? But of course, I intended it that way!
And on it goes. Warning after warning. Each being left in place with not even a cursory attempt to mollify the compiler. In most cases there are simple actions that can be taken, such as a small code adjustment or (at worst) inserting of a directive to tell the compiler not to complain about it. (Such adjustments should always be accompanied by developer comments to justify them.)
During development, a newly generated warning could get lost in a sea of existing warnings and thus lead to a later bug that could easily have been avoided.
Finally, the material lands in my lap. Or more correctly, cloned to my system from the master repository. To install it, I must run the build. The developers have already done their tests and the results show that all those warnings are not a problem. When building on my system, if there are problems specific to my context that warrants a warning, then I want to see if. Being told that a certain font is missing from my computer and may lead to garbled messages is the kind of warning that should attract my attention, though if the message is in Japanese then the font is the least of my problems. Sadly, instead of only seeing warnings that might be of use to me, as the user, I invariably get hundreds, perhaps thousands, of warnings that only make sense to the developer.
Why am I mentioning this now? Today I cloned and built Netbeans 10 from source. It’s a massive project with 100s of contributing developers. The build process took nearly an hour. I compiled it from within N8.2. The build log contains over 22,000 warnings (based on a quick grep and count). I tried skimming the log to see if any of these warnings might need my attention. Checking over 22,000? No chance. I gave up.
Warning: number of warnings has exceeded user tolerance.