13 Tips for Working Remotely

I’ve worked in a lot of different environments over the years. Working with a distributed team is one of my favorite ways to get things done, but it comes with its own sets of challenges that aren’t obvious at first blush. Here are 13 things I wish I’d known when I started working with colleagues who are geographically dispersed:

  1. Overcommunicate: Communication happens pretty naturally when you’re sitting next to someone, but when you’re remote, it takes more of an effort. Make that effort! Respond quickly to email and Slack, even if it’s just to say “Got it!” or “Working on it; I’ll have it done Tuesday!” When you get a request from a remote teammate, you need to explicitly tell them that you are working on it and when you expect it to be done. They have no other way of knowing.
  2. Give your Team the Benefit of the Doubt: We all make mistakes sometimes! Don’t take it personally if team members forget to include you once in a while. Do, however, graciously let them know how you feel and certainly when it impacts your ability to work effectively. It’s easier to tackle issues earlier when they’re small.
  3. Presentation: Think about what creates a professional impression, and make it happen, both with teammates and with customers. At a minimum, this will include having a good quality microphone/headphones and webcam for video conferences, using a solid high-speed internet connection, and looking as professional as you would in the office. (These are in addition to practices that are universal, regardless of whether you’re in the office or not: turn up to meetings on time, speak and listen carefully, etc.) You might also think about what’s behind you on your video calls, having good lighting so that folks can see your face well, having a low-noise environment so that others can hear you well, etc. Use video as much as possible; being able to see others’ faces gives us lots of insight into their thoughts and feelings that are otherwise easily missed.
  4. Arrange Pairing Sessions: It’s especially important when working remote to deliberately keep relationships vital with coworkers, which is helpful for building trust and working smoothly together. One effective way to do this is by working together on a task for a period of time. “Hey, I’ve got this design due Thursday and I’d love to have another set of eyes on it. Could we work together on it for an hour or two Monday?” This also helps spread knowledge about projects around your team and company.
  5. Initiate Social Time: Getting face-to-face time with your colleagues is important, and is tougher to do at a distance. Join others for a weekly Zoom happy hour, a lunchtime Jackbox game, or just a check-in. Start one of these if they don’t already exist.
  6. Use High-Bandwidth Communications, But Record Decisions: Reaching consensus can be hard, and the delays that email introduces make it even tougher. Whenever possible, have conversations with video in real-time. When you’ve reached consensus, then write a quick summary of that chat and share it in Slack or other appropriate channels. This ensures that you and the other people in the conversation have a common understanding of the conclusion you reached and that others are aware of, understand, and get the benefit of your discussion.
  7. Let Your Team Know Your Status: Whenever you sign on or off, even if it’s just to go run an errand, let your team know and when you’ll be back. This helps others plan their time around your availability.
  8. Focus Time: One of the benefits of setting up your own work environment is that you can limit distractions. If you need to go head-down on something for a few hours, do it! Let your team know that you’re going to be concentrating for a period of time and set Slack to Do Not Disturb. (Assure the team that they’re welcome to break in if there’s an emergency.)
  9. Set Aside Physical Work Space: Having dedicated space for work not only makes it easier to create a good environment but also helps get into the work mindset. Important things to pay attention to when you’re setting up your space: safety, comfort, necessary tools, and a minimum of distractions.
  10. Keep it Classy: Humans are not perfect communicators. Text-based communication misses 80% of face to face communication that is non-verbal. Thus, we need to be especially careful to communicate in a way that’s respectful and kind when we’re remote. Verify your assumptions and sense-making. Saying “please” and “thank you” goes a long way.
  11. Stick to a Schedule: Having a regular schedule not only helps your team, as they’ll know when you’ll be reachable, but also helps you. Regular hours tend to result in better sleep, more focused work, and the ability to feel good about putting work aside at the end of your scheduled time. (Though of course, when you need to make an exception to your regular schedule, don’t hesitate — just let your team know!)
  12. Take Breaks: A team in an office takes breaks during the day; we need those breaks at home too. Have a walk, play with your dog, get a snack! (Just let your team know if you’ll be unavailable for more than 10-15 minutes.) Also, don’t mistake having your office at home for an expectation that you’ll be working all the time; take your weekends and evenings off.
  13. Set Up Your Work Hours in Calendar: Most calendar systems have a handy feature that will let meeting organizers know when they’re trying to schedule a meeting outside your work hours. Set it up! This will let others know in a low-friction way when they can expect you to be available (and when they shouldn’t).

On COVID Contact Tracing Apps

I’ve heard some friends express concerns about these being used for government surveillance. As a civil libertarian, I share your reservations.

I’ve also been a mobile developer for nearly a decade and have done a good deal of professional work around the location-tracking and proximity detection technologies that these rely on, so know firsthand what these apps can do.

My short take: if an app asks for access to your location data or contact list, granting that will give more info than you want to share. If it instead asks to use the privacy-preserving contact-tracing capabilities Apple and Google built into the latest versions of their operating systems, it cannot be used to track your location or any personally-identifiable information, and you can use it with confidence.

None of these have been released in the US yet, but they should be coming soon. I’ll share further info on them when they are.

1945 is Now on Tabletop Simulator

Some of you may remember that, a few years back, my son Liam and I designed, and my eldest daughter Emily illustrated, a card game. The elevator pitch was “like Risk but with cards,” and we christened it “1945.” It has remained a family favorite since we created it.

It’s been out of print in its physical form for a while now due to some shenanigans with my printer, but I’ve just finished porting it to be playable in Tabletop Simulator. If you’ve got TS (which is near-essential for board game fans during this time of social isolation) you can now play 1945 for free!

Happy quarantine!

1945 on Steam Workshop

Heading to HEB

I’m happy to share the news that I’ll soon be starting a new role at HEB, the much-loved Texas grocery chain, as a Sr. Developer on their Curbside team. While I’ve really enjoyed and appreciated my time with some outstanding and amazing human beings at Handsome, I’m excited about this new professional chapter for a couple of reasons:

First off, I find the craft of software development — building intricate, beautiful mechanisms out of logic and aether — to be deeply engaging and interesting. I will be able to focus on that aspect of my work more squarely here than has been the case since I started taking on management roles several years back.

I am also a great fan of having the centers of one’s professional and personal lives close to one another. Being able to invite colleagues over for dinner, avoiding endless hours on the interstate, and burning less fossil fuel merely to be places are all important to me. Since we moved to San Antonio this year, working 10 minutes away feels like a big quality of life improvement.

In addition to being close, I’m excited about the specific location where I’ll be working: the headquarters campus is a lovely site of an old arsenal that was founded in 1859 to supply the forts on the Texas frontier. It’s along the San Antonio River, downstream a bit from the main segment of the Riverwalk, along a boating-friendly stretch that will allow me to toss a kayak in the water and go paddling after work. And HEB has plans for a beautiful, expansive tech center on campus to open in a couple of years.

Finally, the company has a tremendous reputation for being a great place to work. I’ve long appreciated their commitment to serving the communities in which they operate, donating more than 5% of their gross earnings, helping food banks, etc. I’m glad to see that they have a similarly good reputation as an employer, and are investing deeply in building their technology capabilities and team.

I’ll be starting on February 10; I’m eager to invest my professional energies in service of a company for which I have respect and high expectations for its future, in the city that I grew up in, love, and still feels like home.

Impressions of Dan Carlin’s “War Remains”

This afternoon, I went to visit War Remains, Dan Carlin’s VR Theater experience focused on World War I. Dan is, of course, the voice of the immensely popular podcast “Hardcore History,” in which he recounts historical events with unparalleled approachability and empathy. While he has previously shared remarkable accounts of “The War to End All Wars” in his podcast, his latest endeavor brings parts of that era to life in a more visceral way than he’s ever managed before.

Carlin narrates the whole experience, which starts with the viewer being teleported to a gondola hanging beneath an observation balloon while aircraft wheel around and anti-aircraft fire erupts. In addition to the immersive audio and video one expects with VR, the viewer is also treated to a breeze whipping by while the floor wobbles beneath.

From there, we move to a trench on the front lines, where you watch a group of soldiers succumb to the “meat grinder” of incoming fire. We take shelter in a bunker, where we can see (and feel) medical bags, a morse radio, and various other bits of paraphernalia while shells burst around, shaking the floor and the walls. Passing through a door and pushing the dangling hand of a corpse aside yields another segment in the trenches, rounding out the experience while tanks roll past and shells crash around. Finally, poison gas begins to fill the trench and the scene fades, yielding to Carlin’s meditation on the modern-day world as a product of a battle-scarred generation while stylized bombs descend in slow motion all around.

From a storytelling perspective, the experience is remarkable. VR is often called an “empathy engine,” and this was one of the most effective uses of that capacity I have seen. The physical augmentation — wobbly floors, props, shuddering walls, the feel of the breeze playing across your face — engages the whole brain in a way that merely audio/visual VR cannot. And recruitment posters along with the scale and eye chart one would find in a recruitment office all get visitors into the appropriate mindset before they even enter VR.

My only complaint was that the experience felt about half the length I would have liked, both from a storytelling perspective and from a “getting your $45 worth” point of view. There was little narrative arc beyond “Holy moley, World War I was scary.” But given that it is genuinely pushing the boundaries of digitally augmented media and puts its brief message across with unparalleled force, the brevity is forgivable.

One change that would have made the experience even more immersive would have been meaningful interaction with the scenes. In each portion of the experience, the viewer is merely an observer: not quite a disembodied ghost, but not able to affect the scene in any meaningful way. Imagine adding a tracked gun that would allow the visitor to engage some of the advancing infantry lines, or a grenade being tossed into the trench that you would have to pick up and throw back before it detonates. VR allows for rich, non-linear storytelling, so having the experience be essentially “on rails” is something of a missed opportunity.

From a technical standpoint, the experience was fascinating. While the whole physical space was a square about 25 feet on a side, the creators use that real estate very effectively; the only time one feels particularly constrained is in the bunker, where it’s absolutely appropriate. The experience relied on a Vive headset with a PC in a satchel slung over the visitor’s shoulder and the 2.0 version of the Vive Trackers. There were no controllers in use — all of the interactions were done physically with props that were secured in place at various places around the set.

If you’re a fan of VR, Dan Carlin, or World War I, I would highly recommend the experience as a unique way to feel what it was like to fight in The Great War. War Remains is available for viewing in downtown Austin through the end of the month. Buy tickets here: https://www.warremains.com

A Few Thoughts on Basecamp’s Shape Up Methodology

These are my first-blush reflections on BaseCamp’s Shape Up methodology:

  • The six weeks of focused burn/two weeks of cool down and clean up sounds delightful, but also seems like it works best with an established product to which a team is adding pretty meaty features. (Some of our entire implementation projects are 8 weeks front-to-back, so it would be hard to work this way there.)
  • Using very low-fi models (“breadboarding”/”fat marker diagrams”) for initial exploration of the idea seems an excellent practice, both to minimize initial effort and to keep ideas high-level and abstract.
  • I love the idea that the designer and developer are actively working together to create a feature within the pretty broad bounds that the author of that feature establishes. It does, however, require that the designer can actually create the necessary code/files for UI herself. This might be HTML/CSS/JS for web, Scenes for Unity, or Storyboards/SwiftUI code for iOS. Many designers I’ve worked with wouldn’t have been comfortable with this, but it seems like a really efficient way to work if you can get over that barrier.
  • Scoping and hill charts seem like a great way to be able to talk about a feature and to communicate status and progress. I’ll probably steal the idea of hill charts immediately for progress discussions.
  • Handling “shaping” asynchronously with a touchpoint at the betting table also sounds very sensible, though it requires a high level of trust that the folks who will be making bets proactively read and understand the pitches in advance. Thinking through and identifying potential pitfalls in advance is also a useful practice.
  • The idea of not maintaining a backlog is a fascinating one. Since the backlog can become the dumping ground for every idea that anyone has ever had, this seems both liberating and scary, as it seems to open the door for something important to slip by. But as they point out, if it’s really important, it’s probably on someone’s mind enough to champion.
  • This process is different enough from other methodologies and infrequently enough used that it will probably work best with a persistent team, rather than rotating contractors.
  • In short, this seems like a process I would love to work with, but which is best suited to long-running, ongoing products, which most of my work currently is not.

Can Laziness Be a Virtue?


Early on in my career, I worked at Motorola doing desktop support for the 800 people in their Paging Products Group in Fort Worth, Texas. Our team was responsible for the care and feeding of hundreds of Macintoshes, including keeping their anti-virus software up to date. This normally happened automatically over the network, but for one particular update, we were going to need to push an installation package out to all of the machines individually. That job fell to me and my friend Rich.

“Ugh,” I said to Rich. “We’re going to have to pull up our central management console, go down our entire list of machines, and one by one, send them this update. That’s going to take hours of seriously tedious work.”

“No way!” Rich responded. “We don’t have to do all of that boring work ourselves; we can automate it with a macro engine!”

“But Rich, it’ll take longer to build that script that it would take just to do this manually. And we’re on a deadline here.”

o “How about this?” he rejoined. “We split the job up. You do half of the updates manually. I’ll write the automation. And we’ll see who gets done first.”

This sounded fun (and meant I would only have to do half of the updates myself), so I quickly agreed to his scheme.

The next few hours saw a titanic struggle. I busily banged through the long list of machines, triggering the updates, waiting for them to complete, going on to the next, and thinking about how to minimize my keystrokes and do things most efficiently. (After all, my geek cred was on the line.) At the same time, Rich was building and refining his script, going down blind alleys once in a while but generally making solid progress while steadily throwing good-natured barbs my way.

As I approached the end of my list, I looked over to see that Rich finally seemed to have his script in good working order. He kicked it off, and it began chewing through his list at an impressive rate. I redoubled my efforts, doing my best to beat the machine, feeling like the modern equivalent of John Henry, the steel-driving man. (Though I was more a steel-rimmed glasses-driving man.)

At the end of that struggle, we finished up our respective lists within minutes of each other. Rich and I laughingly conceded that it was, for all practical purposes, a tie.

But…

In my heart of hearts, I knew that Rich had really won. Why? For a few reasons:

  • Rich’s solution scaled better. Once he had his script built, he could have tackled my list too with little additional effort or time.
  • The next time we needed to do a similar update, Rich’s work would allow us to accomplish it much more easily.
  • Rich had done more interesting work. There’s nothing fun about doing the same series of a few keystrokes 800 times consecutively. But building a tool to do the same task is comparatively fascinating brainwork.

I kind of proved my point, but Rich equally proved his, and had way more fun doing so.


Traditionally, Sloth is considered one of the deadly sins. There’s much to this; if we are unwilling to work hard at things, we are considerably less likely to get far in life. But there’s a flip side to this, which is that working hard at the wrong things is even more ineffective.

All the vigor you pour into straightening up your desk doesn’t count for much when you’re supposed to be getting your homework done. If you need a hole for a swimming pool dug in your yard, you might be impressed with the industry of the guy who shows up in your yard with nothing but a stout garden trowel. But you won’t hire him for the job, because he’s not working on the right thing. I have a friend whose personal mantra is “Work smarter, not harder.” Sage advice.

When Rich and I had our contest, I was working on a first-order problem: how to update all of these machines. Rich was working on a second-order problem: how to automate a process to update all of those machines. In general, the further up you can go on that sort of hierarchy of abstraction, the more interesting the problems become, and the more effective the solutions are. I worked harder, but Rich worked smarter.

I’m not much of a woodworker, but one of the things I’ve picked up from my friends who are good at it is the importance of making jigs. Jigs are job-specific tools a woodworker creates to make the task at hand easier. If you need to make a series of identical cuts to 100 boards, you can do all of those individually. Or you can first build a little jig that will guide your saw to the right place, making those cuts easier, faster, and more consistent. Good woodworkers will create a variety of jigs as they create a piece of furniture. And as I’ve gotten better as a developer, I’ve found myself writing more and more tools to automate tedious or error-prone parts of my work, creating code that writes other code, rather than writing everything directly.

This is, I’m convinced, the reason that some developers won’t stop using the highly-customizable text editor emacs until you pry it from their cold, dead fingers. Once they have invested sufficiently in automating and customizing the task of editing text or source code, going back to doing it without all of their purpose-built tools becomes slow, inefficient, and error-prone.

Archimedes asserts that with a fulcrum and a large enough lever, he could move the world. So as a developer, you have a choice when you have giant rocks to move: you can push really hard on that rock, pushing on evenings and weekends to get it where it needs to be on schedule. Or you can learn to make levers. (And, because this is software, levers that push other levers.) You can build at a low level of abstraction, or you can learn how to build tools, how to build tests, how to do meta-programming, and when you do something more than twice, stepping back to figure out if you can automate that task.

Let’s stop pushing on rocks, and start building levers. This is how we can use our natural tendencies to be lazy to actually get more accomplished that we would by simply throwing ourselves into a task. And as a bonus, it’s not only more productive but a lot more fun too.

ML Nexus

Howdy folks! I’ve been thinking about and studying Machine Learning off and on for a year or more now, and have recently started writing another blog covering my thoughts on that subject. If you’re interested in that sort of thing and would like to follow along, come join me at ML Nexus! I’d be glad to have your perspective on the things I’m covering there.

Using Swagger APIs with Unity

February 6, 2018 Update: I figured out a workflow with the experimental .NET 4.6 support in Unity to actually make this work with Daydream, and have updated the workflow here. This solves the annoying caveat that I’d previously posted.

Swagger (aka OpenAPI) lets you define API structure in a machine-readable way. This allows all kinds of cool functionality: automatic docs, code generation across languages, etc. Here’s the workflow we’ve devised for consuming Swagger APIs in Unity. (Note: I’ve tested this on a Mac, but haven’t tried it on a PC yet.)

  1. Load your Swagger specification into the editor at https://app.swaggerhub.com/. (The easiest way is just to copy and paste it into the editor window.)
  2. Verify that the auto-generated documentation on the right looks correct.
  3. Choose “Csharp” from the “Download → Client” dropdown.
  4. Unzip the downloaded csharp-client-generated.zip file.
  5. Open a terminal window.
  6. Go to the directory of the new unzipped download. (e.g. “cd ~/Downloads/csharp-client-generated/“)
  7. Build your DLL: /bin/sh build.sh or build.bat if you’re on windows.
  8. Your DLL is now in the “bin” subdirectory of the downloaded folder and is called “IO.Swagger.dll”. Copy this to your “Scripts” folder in Unity.
  9. Find “Newtonsoft.Json.dll” (packages/Newtonsoft.Json.10.0.3/lib/net45/Newtonsoft.Json.dll) and copy it to your “Scripts” folder in Unity.
  10. Find “RestSharp.Net2.dll” (packages/RestSharp.105.1.0/lib/net452/RestSharp.dll) and copy it to your “Scripts” folder in Unity.
  11. You’ll also need to round up the DataAnnotations DLL from somewhere in your Unity package (Unity.app/Contents/MonoBleedingEdge/lib/mono/4.5/System.ComponentModel.DataAnnotations.dll) and copy it into your “Scripts” folder in Unity.
  12. Unity loads the DLL and makes the IO.Swagger namespace available to you.

Using it:

Take a look in the docs folder of the project you downloaded from the Swagger editor. It includes nice Markup files with C# sample code documenting the APIs in your new DLL. The sample code makes a great starting point for accessing the DLL’s functionality.

Great Big Obnoxious Caveat:

This doesn’t currently work when running on Android due to this bug in Unity’s .NET implementation. We ended up doing a last-minute rewrite to use Best HTTP instead, which was a crying shame. Hoping this bug will indeed be fixed in the future and make this workflow viable on that platform.

 

Moving to VR

About a year ago, I decided it was time for a career shift. I managed a fabulous team of mobile developers who were a joy to work with, but I missed creating things. I talked to my boss at Mutual Mobile about the problem; he encouraged me to chart out a way back to an engineer role within the company.

I thought carefully about my options. I could go back to iOS engineering, which my previous boss had done. He was delighted with the change and had no regrets whatever about stepping down from management to an engineering job. But I enjoy learning and figuring out new things and, while iOS is a fantastically enjoyable platform to develop for, iOS 10 seemed pretty mature. I moved from web development to mobile because the web stopped feeling like the wild west. Now I had the same sense about mobile.

So I looked at alternatives. Mutual Mobile had a months-old Virtual Reality practice at that point that was gaining steam. While I hadn’t yet spent any serious time with Unity, which the team uses for its work, my son and some of my fellow engineers both had and were clearly enjoying the experience.

I floated my plan to retool myself into a VR engineer to my boss and the VR team, all of whom were gracious enough to give it an enthusiastic thumbs-up. So in early 2017, I began a self-administered crash course in Unity and VR. I found Unity’s online training materials to be excellent, and by the time we executed my official transition to the VR team, I was able to jump in and contribute to the team without a problem.

(I was still green compared to the other two excellent engineers working on our projects, but made up for it by continuing to do management of our engineering and project management teams.)

I’ve now gotten to contribute to a Cardboard project and do all the engineering for an Oculus Rift project. (The former should be available in the mobile app stores soon, and the latter will be installed in the Bass Pro HQ in Springfield in a few weeks.) The team’s also doing work with several other really interesting clients; I’m excited about the work ahead.

Now that I’m past the initial hurdles in Unity, I’m learning things I think might benefit other developers and/or VR enthusiasts. Accordingly, I’m going to post things here to document my learning. My areas of particular interest include: Good Software Architecture in Unity, Cool Stuff our Team is Doing, Using Physical Props in VR, and Accessibility in VR.

If you’re interested in any of these areas or just in creating VR, please get in touch or just follow along. I’m excited about this next phase of my career, and will be happy to have company!