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.

New Chapter at Banjo Digital

I’m happy to share the news that I’m joining up with Banjo Digital, an AR/VR firm in Austin that creates experiences for simulation/training, education, product design, and marketing. I’ll be serving as Technical Director, and will be starting next week. I’m excited about the move and look forward to doing great work together there!

On the Market

After 6 educational & exciting years at Mutual Mobile, I am once again officially on the job market!

My ideal position right now would be that of a Technical Director or CTO for a small company. However, I do love development, and would be glad to put my shoulder to the work in Unity, iOS, or web as well. I plan to stay in San Marcos for at least another year, so working remote, in San Antonio, San Marcos, or Austin would be my best options.

I’m currently updating my portfolio, and you can see my resume here. Please email at sean@mcmains.net if you spot anything you think I should have my eye on.

Getting Unity and Arduino Working Together

Yesterday I set myself a goal of getting Unity talking to Arduino, the microcontroller that’s hugely popular in the maker community. I was interested in doing so because several of our VR projects have been site-specific installations that could benefit from a large LED scoreboard, physical actuators (rumble motors, heat lamps, fans, etc.) to heighten the experience, or just a “This person flailing his arms around can’t see you; please stand back!” warning light.

Fortunately, given than both Unity and Arduino are very popular, this path is fairly well-trodden already. The most common approach is to establish a serial connection between the computer running Unity and the Arduino board. This is straightforward to do, though it requires tweaking a few settings in Unity to allow access to the serial libraries.

For the Arduinos that have USB port, the physical connection is as simple as plugging in a USB cable. For the boards that have only serial pins, wiring in a converter chip will be necessary to bridge the two. I used the Arduino Uno since it supports USB and I didn’t feel like soldering.

The next decision is whether to write your code from scratch or to use a library to ease this task. If you’re more of a DIY person, the amount of code you have to write isn’t outrageous. Alan Zucconi has an excellent article that will guide you through what you need on both systems.

If you’re looking to get up and running quickly, however, you may prefer one of the options available in the Unity Asset Store. These come with all the code you need for many use cases already written, a variety of examples, and niceties like custom UI in the Unity editor. I ended up using Marc Teyssier’s excellent Uduino package, which has good documentation and supports digital input and output, analog input and output, and servo motor control out of the box.

(I ended up having trouble at first, as my board wasn’t setting the pin mode to digital output when the code commanded it to. I wasn’t sure whether this was a problem with my board or with the code, but adding some additional commands to the Arduino code to make sure that the pin mode got reset cleared up the problem.)

I rigged up a simple relay circuit, created a sample scene, and before too long, had a light in my living room turning on and off with the scene lighting in Unity. Viola!

This is merely a proof of concept — a technical spike to sort out some unknowns. Now that we’ve got these waters mapped, I hope to add some production physical effects to future projects. Excelsior!

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!

Getting More Feedback

So, you want more feedback from the people you work with.
 
It’s critical to know what things you should be working on and how you’re progressing toward those goals. Our high-level goals are often well defined: write the login functionality for an app, sell 5 new contracts this month, etc. But how we do these things depends on the people around us and how well we work with them. If you’re part of a team, you need to know what they want from you to do your work best together.
 
The first challenge, of course, is getting any feedback at all. People are busy and have a hard time scavenging a few minutes to think about that sort of thing, much less figuring out good ways to communicate it.
 
The second challenge is getting honest feedback. Many of us want to be “nice” and to avoid saying things that are uncomfortable whenever we can. (If I’m honest, for me that usually has as much to do with cowardice and conflict-avoidance than with kindness.) So it’s important to think about how to make the process both as easy as possible and as safe and comfortable as it can be.
 
Here are a few approaches I’ve found that work well:
 
  1. Ask a specific question out loud: “Hey, I want to be doing great work here. How do you feel I’m doing, and what’s one thing I could improve?” By asking verbally, we keep it quick; answering only requires a minute or two of someone’s time. By asking for a single thing to improve, we can also remove much of the concern that our colleagues have about coming across as mean or critical.

    When we ask for something specific, we allow others to offer an improvement as a favor rather than a criticism. Doing this verbally means that there’s no written record of what they say, which helps ease the pressure as well.

  2. Ask the same questions in Email, Slack, or another written format: This takes longer, both for you and for the people from whom you’re asking for input. Colleagues will be less candid, as they might have concerns that their comments are “on the record,” and you’ll get fewer responses.

    On the upside, you will get more thoughtful feedback as your respondents take more time to reflect on their answers. You will also have a record to which you can refer as you’re working to figure out how to improve your work.

  3. Use an anonymous feedback tool: There are several that help you gather feedback while assuring your respondents that you won’t know from whom it originates. (I’ve used http://www.get3sixty.com/ and like it pretty well.) Anonymity helps your colleagues express themselves freely without putting a strain on your relationship. This results in more candid feedback.

    Include more questions if you want a richer picture of others’ perceptions of you and your work. If you keep the questions consistent over time, you can use the answers to track your own progress. But remember, the more information you ask for, the fewer people will likely respond. Keep the time needed to respond under a minute to get the most results.

  4. Ask your manager: Why do I list this last? Because of the telephone game. You’ve played it as a kid. A line of people passes a message, whispering it from one to another. By the time it gets to the end, what emerges often has hilariously little to do with the original meaning. Likewise, the fewer people between the source of feedback and its recipient, the clearer the message you receive will be.

    Having your manager gather feedback for you is useful for performance appraisals, other situations where you need an official record, or when you’re having a tough time getting candid feedback on your own. But the closer you can get to the source, the better the feedback you will receive will be.

If you’d like more guidance and feedback from your team, give one of these approaches a try and see how it works. Try soliciting feedback from your teammates every two months or so, though your individual cadence may vary depending on your situation. If there’s a specific area you’re trying to improve, you might check in more often to see how you’re progressing. With a well-established team, you may need less frequent feedback . But if you want to improve, getting regular feedback and coaching from the people closest to you is one of the best ways to do it.

Christmas Letter 2013

(This is the non-illustrated semantic HTML edition. Also available: the fancy photos-included PDF edition.)

Dear family and friends,

It has been quite a year for our family. We’ve enjoyed some great times together  with family and friends, a few promotions, a terrific (though slightly bittersweet) family vacation, a visit with alligators, an eviction from our house, a repatriation, and a new addition to the family. Read on for all of the details!

Kathy began the year working at Horizon Bay, an elder care facility around the corner from our house, as a caretaker. While she has a fantastic affection and gift for interacting with older folks, this was not a completely ideal appointment: it demanded a fair number of overnight shifts and other times that were inconvenient for her and the family, and it didn’t make much use of Kathy’s Therapeutic Recreation degree. After proving her worth and presenting her case to her boss, he appointed her Program Director for Clare Bridge, the Alzheimer’s community at Horizon Bay — a role that hadn’t existed before. She has received a number of accolades in her new position and, more importantly, loves it.

Emily continued her schooling, taking a few more art classes at ACC where she turned in some excellent work and continued to expand her artistic skills. In the middle of summer, she completed a long-planned move to Baltimore, which has the dual attractions of an art school that she’s interested in and portions of her family that she wanted to spend more time with. Her first few weeks there were a trifle rough: her car was broken into the first day she was there and the rougher sections of the city had her feeling a bit ill at ease. After selling the car and moving to a better section of town, she began to feel much more comfortable with the city, and is now enjoying it a great deal. She’s taking classes there and has been working a job at The Pratt Street Ale House for several months now, and has enjoyed the opportunities to visit with family and friends up in that part of the country.

Abigail is now in her Senior year at the high school. She’s taken up swim team this year, and has done quite well. She is turning in solid times on her events and enjoying her team and teammates a good deal. She has also been learning ukulele (it’s easier on her fingers that guitar was) and continuing to do some singing. One of her favorite classes at school has been a Special Education PE class, where she helps the kids there to stay fit and engage with others. Her plans for next year are still a bit murky, but we’re talking about and weighing the advantages and expenses of work, travel, college, etc.

Liam is halfway through his Freshman year. He has found the transition to High School easier than he expected, though the demands of marching band came as something of a surprise to him. In the month before school started, the band would arrive at 7:30, march until noon, and then practice inside until 5:00. During the first week of that, he would come home, eat a bit, sit in a chair in the living room answering questions in monosyllables, and stumble off to bed around 8:00. His playing is excellent, and he earned second chair among all the French Horn players at his school, beaten out only by one senior. He’s pulled straight A’s so far, and has also been learning some programming in his spare time, writing a few iPhone apps with a little coaching from Dad.

Maggie is now in 7th grade. She continues be a great favorite of her teachers thanks to her sweet nature, generosity, and willingness to work hard. She loves animals, and was delighted at the opportunity to have a lengthy horse riding lesson over the summer thanks to some friends of ours. (It was accompanied by a shooting lesson as well, at which she did startlingly well.) She also continues to enjoy art a great deal, and created several lovely pieces for family members at Christmas. Stories are also a favorite of hers. She’s enjoyed reading and rereading Maximum Ride and Harry Potter this year, in addition to reading through Jurassic Park, Terry Pratchett’s Dodger, and All Creatures Great and Small with her Dad.

Sean is finishing up his second year at Mutual Mobile, where he has been writing iPhone and iPad apps. He recently moved to an Associate Director role, which means less day-to-day programming and more strategic work and caring for people there. He’s also playing music with O’Malarkey, a local Irish band, whenever he can squeeze in the time, and has been enjoying cooking for family and friends more this year. The building of a 25′ tall trebuchet, some delightful long hikes, and a train trip to Chicago with Liam and Sean’s brother rounded the year out nicely.

Over the summer, knowing that Emily was planning her move to Baltimore, we pulled together a last big family trip: a week in New Orleans, where we had spent a day as a family a few years back and all really enjoyed. The vacation was terrific. We stayed on the edge of the Vieux Carré, and enjoyed rides around town on the streetcars, trips to the botanical gardens, aquarium and insectarium, and one of the most memorable meals we have ever enjoyed. (At Jacques Imo’s — “Warm Beer, Lousy Service” and highly recommended.) A particular highlight of the trip was a boat tour through Honey Island swamp, where we met a family of friendly warthogs and saw a number of alligators up close.

Alas, when we returned to San Marcos, it was to a home with a broken toilet supply line which had flooded a good portion of the house. Some of our good friends were checking on the homestead while we were gone and discovered the problem before it got even farther along, but it still ended up causing tens of thousands of dollars of damage. We moved to a three bedroom apartment for “no more than 45 days.” That ballooned to three months before we finally got home. Fortunately, USAA (our insurance company) was very helpful, one of our church friends was gracious enough to build us a beautiful new built-in bookcase, Kathy was able to replace the abhorrent pink tile that has lurked in our bathroom since we moved in, and the house now looks better than when the whole ordeal began.

During our exile, Maggie got stuck sleeping on the couch for much of time time which, understandably, became tiresome for her partway through our stay. As a thank-you for her forbearance, we (perhaps rashly) promised her a kitten upon our return home. Hewing to the family tradition of absurdly named animals (“Fluffy” the hermit crab, “Llama” the gerbil, “Hasenpfeffer” the rabbit), she christened her new black kitten “Mayonnaise”. He’s quickly made himself at home, and has even won over Liam, the most pet-skeptical among us.

 

As we review our year, it is apparent how blessed we are to have such terrific family, such wonderful friends — what a different year it would have been without those of us who give us regular support, and those we know are further off in the wings, ready to offer friendship when it’s needed. Thanks for being a part of our lives, and for allowing us to be part of yours.

May all the joys of this blessed season be yours in full measure. Merry Christmas!

The Clan McMains

(San Marcos Chapter)

 

Accessibility: What It Is, Why It Matters, and How to Do It

I did a presentation at CocoaConf Dallas today on how, as a developer, to make your iOS apps usable by people with visual impairments. It was a lot of fun, and seemed to be well-received by the conference attendees. If you’d like to see the slides, you can download them here:

Download Accessibility Presentation

In addition, I announced an open source component I wrote to make accessibility testing easier for developers. It’s called SMAccessibilityOverlay. By adding it to an app under development, you can temporarily display an overlay that quickly shows what areas of the screen have been marked as accessible, and what labels are associated with those regions:

Accessibility Overlay Screenshot

If you’d like to try it out in your app, you can download it from GitHub here. I’d also be delighted to have input on it, either in the form of suggestions (good) or code contributions (better) or encouraging beer purchases (best).