A Year Of Travel Living

“Hey, how about we rent out our house for a year and go live elsewhere, maybe even in a Spanish-speaking country for a while?” That’s essentially how our conversation started. And what ensued from that conversation?

Expectations

Our journey started with a few pre-conditions:

  • I found myself taking on a contract where I was working from home.
  • My wife, Juliet, is retired.
  • Juliet and I were endeavoring to learn Spanish to help create opportunities for more friendships.
  • Our kids have all grown and moved away from the area.
  • Other factors were conspiring to give us an inkling that we might consider moving to a new city.

With these pre-conditions, one evening we attended a Spanish-speaking meetup in Oceanside. There I heard the story from a man in his 40s who went to live in-country with his wife for a year to learn Spanish. With our pre-conditions in place, we realized that living in-country to learn a language wasn’t just for college-age singles. It could be us!

This was the catalyst that led to lots of discussion, clarification of our goals and ultimately to a plan that involved renting out our house for a year, living in Ensenada, Mexico for 3 months, followed by stays in a few US cities – mostly near where our adult children live.

We didn’t initially plan to live in an RV. But with the number of destinations we had in mind for our year, we realized that an RV provided the simplest solution to moving our stuff around – as well as the right model for renting living space.

Here are some of the expectations I had:

  • A 200 sq. ft. RV is very small compared to my 3700 sq. ft. home. I don’t need a lot of space so I think it’ll be fine. But how would I do in this small of a space?
  • We had a couple of destinations picked at the start: (Ensenada, Jackson MS and Cincinnati OH). But what other destinations should we pick? It’s not that often one has this kind of opportunity, so let’s take advantage.
  • I have worked at home on many projects and for extended periods of time. I know how to be productive. I will apply the same techniques in the RV. I just need Internet and power and a space for my laptop.
    • Acknowledging that additional needs and distractions will arise, I reduced my expectation to have around 30 billable hours per week instead of 40.
  • My go-to exercise is running. I should be able to do this anywhere.
  • Community might be difficult to maintain

We’re now 11 months into this exercise. How well were my expectations met?

The Space

At the start of this journey, I had full expectation that I would do fine in a small space – even dropping from 3700 sq. ft. to less than 200 sq. ft. of living space.

And by some measures, it turned out just as I expected. I rarely feel the need to have another room to go to. I have a great, comfortable bed. I can take a shower without crouching. I have enough room to cook and clean up.

It may sound daunting to live in a 200 sq ft space. But there a couple of advantages in an RV over typical spaces. Everything is explicitly designed for this tight space. The closets, the bathroom configuration, the kitchen. Everything.

In addition to the RV itself, we spent a couple of weeks outfitting the RV with all kinds of space-efficient devices: wall-hanging shoe-holders everywhere to hold random stuff. Hooks to hold measuring spoons and cups and other utensils. Mason jars that doubled as drinking glasses and food storage. A set of pots with removable handles that stack as one. Wall-mounted spice rack. Instant Pot. And we used 3M Command Strips all over the place.

We even brought Alexa with us – sticking the echo dot under the kitchen cabinet. We used double-stick velcro for that one. It’s super handy to have an expert to ask all of those burning questions.

There were a few habits we incorporated to help make it work. For instance, since the cutting board fit nicely over the sink, it gave us more counter space. But it meant that we had to always clean up right away after each meal. This fits our personal style anyway. But once in a while the freedom to delay cleanup can be nice. We’ve just never had that freedom during our year in the RV.

At the start of our journey, I worked in the RV a lot. I even found a way to configure a stand-up desk arrangement for the times I wanted to work standing, And even though I was productive with this configuration, it became impractical to continue as a regular habit.

What surprised me the most was the dynamic of sharing the space with Juliet. She is definitely capable of ignoring me so that I can focus. But it is hard for her to do that for an extended amount of time when I am sitting 5 feet away from her. And I am capable of ignoring her. But I did not want me ignoring her to become the norm for our together time.

This by itself was enough justification for me to search out a coworking space – which I found readily in every place we lived. And it was a good solution most of the time – something I discuss more in Productivity later. A secondary issue justifying a coworking space was the spotty availability of WiFi which I discuss later in this post also.

Transportation

During the first half of our travels, we had 2 vehicles with us – one SUV which also pulled the trailer. The other a Prius. We caravaned together to get between locations. This was a pain for Juliet who hates driving. But it meant that we could each keep independent schedules. It was especially helpful in Jackson where wedding planning and prep were a normal part of our time there.

When we dropped to one vehicle so that Juliet wouldn’t have to drive between locations, I definitely felt the impact to my productivity. We were always working out how I would get to my coworking space without leaving Juliet without a car for the day.

Aligning Goals

Our goals in the cities where our children live were pretty well aligned. We would live and work there and do things together on the weekend or evenings depending on everyone’s availability.

But the other destinations required a lot of discussion and refining of goals to get alignment. Juliet wanted to take in the sights and events that people associate with each destination. But I am working. So it’s not really an option to go sightseeing all the time. And often when we did arrive in the new city, the time we might have had for sightseeing was used up just by getting set up, finding the services we needed to get plugged into (coworking, workout locations, grocery, etc.)

Ultimately, it was a bit of resignation of the limits of what we could accomplish from a sightseeing perspective. We could still accomplish our goals of trying out a few different cities. But we definitely weren’t going to come back with a map of the United States showing that we had visited every significant site in even a handful of states.

Everyone is influenced by their peers. And for us, some of our peers were the people vacationing full time in their RV. This created enough pressure that we had to have this conversation a few times about our own goals. And not just about destinations, but about activities we planned when we arrived. Often when people show up in a city, there are some events and/or attractions that are standard. But many of these are day-long activities easily accommodated by being on vacation. We are not on vacation (most of the time), so we had to figure out what could fit into an otherwise ‘normal’ week.

Along with trying out cities, visiting friends and family was an important part of selecting our destinations, but we had to limit this to some extent. I talk more about this later in the section on Productivity.

Choosing An RV Park And Experiencing A City

In each of the cities we visited, we wanted to be close to the city center. But by living in an RV we found our choices very limited and the idea of living where we could use mass transit and experience the city on a daily basis was just not possible. Often the RV parks located near city center were not kept well and/or had no availability. This meant we ended up staying far from city center and significantly altered our experience. In Cincinnati we ended staying in Lebanon, OH – about 45 minutes from downtown.

Because our goals differed from typical full-time RVers, many of the tools created to help people find RV parks were not useful to us. To us location was primary. Most other aspects of an RV park were secondary. This also factored into us not getting much value out of RV park memberships. These tend to focus on giving you a great experience without much regard to location.

In cases where we visited family in small towns, we sometimes had as few as 1 RV park to choose from. Thankfully we always found an opening!

Staying Connected

Internet access in the RV was a bit of a challenge. For my low data rate devices (Echo Dot, security camera, temperature sensor), I have a persistent connection with a Cellular wi-fi hotspot. But for higher bandwidth needs, I found that I had to figure something new in each locale. On rare occasions, the RV Park WiFi was good enough. Most of the time not. For my work, I could make up for that by renting a coworking space.

We brought an Apple TV with us, but found we could rarely use it, even to watch Netflix. It consumed too much bandwidth for my Cellular Hotspot and most of the time the RV Park WiFi wouldn’t connect or didn’t have the bandwidth to support streaming. Juliet especially missed this a lot.

Exercise

To stay fit, these were our main avenues:

  • Walking – mandatory just to take care of Panda, our 80 lb mix of Lab and Australian Shepherd. We walked a lot.
  • Running – fairly easy to fit in when the weather cooperates
  • Whole body workouts – required a lot of determination to make happen

We brought our dog Panda with us. At home he had a large yard to run around in. But on the road, we never had that luxury and walks or trips to a dog park were his only outlet for exercise. So we walked a lot.

In Ensenada, we joined a local gym and I could get workouts in there on a regular basis.

In Jackson, we allowed Wedding prep to completely drown out exercise.

In Cincinnati, there was a crossfit gym next to my coworking space. After observing the training style, we both decided to join and both found this to be a great way to get a good workout regularly.

When we left Cincinnati, we ended up going slightly different directions with our fitness regimen. I found a Crossfit gym in each of the next cities we went to. And Juliet signed up with Orangetheory. Orangetheory provided the most consistency and her membership allows her to go anywhere. With Crossfit, I had to sign up with each gym in each new city.

Productivity:

I found good coworking spaces in all of the places where we lived for more than a few days. This helped me to be more productive, solving 3 of my challenges: access to good internet, a place to ‘go to’ to work, and giving me a separate space from Juliet during working hours so as to improve our time together.

I think my most productive location was Jackson, MS – at least until the week of our daughter’s wedding. In Jackson I had a desk in what was essentially a private room, and we each had a car so didn’t have to coordinate rides with Juliet. The dedicated desk allowed me to leave my large monitor there, which helps with productivity especially when coding.

My least productive locations were the places we stayed a week or less. With that short of time, the time scarcity led us to choose to spend time with friends/family. It would be the same if they came to my town to visit. Except by doing multiple of these, it was like having family show up in town every week. At some point, it’s too much time away from work.

In the cities where we spent a month or more, it was very natural to fit family activities on evenings and weekends and not hit work productivity the same way. This ultimately influenced our decision-making process for where we would go. We had to be kind of ruthless in limiting the cities we would include in our itinerary.

Life maintenance took a bigger chunk out of my time than I expected. Getting haircuts took more time. Getting the car serviced took time. Driving between cities takes time. Disconnecting the RV and reconnecting on the other end takes time. With travel prep and setup, it’s easily a 3-day hit to move between two cities that are a 1 day drive apart. If you combine that with family visits, it can look like this:

After finishing 6 weeks in Cincinnati, our next major stop would be Austin. But we wanted to pass through Kansas to visit my sister and her adult children. We would be going through St. Louis, so we spent two nights there with a full day to explore the arch – and get groceries, cook, etc. Then 3 nights in Emporia, Kansas – next to a busy rail line and two highways (that never stopped at night). Then a long day driving to Austin – estimated at 11 hours, turned into 13. (I broke my own rule and traveled on Friday – paying the price with 2 extra hours in traffic).

We arrived late Friday night, then spent the weekend getting set up, visiting with friends and orienting ourselves. Monday and Tuesday were spent visiting coworking spaces, getting our SUV fixed (we blew a radiator hose on the drive from Kansas) and getting a start at becoming productive again.

I didn’t budget for times like that – a week and a half of zero productivity – even though on the back side it seems like I could have. At this point in our journey, I could see the Kansas week wasn’t going to be a work week. But it I didn’t quite have that perspective when we started out.

Of course, productivity is not just about hours worked. A case in point…

In Cincinnati, I met people in the coworking space and at a couple of meetups that introduced me to other activities going on in the area. I learned about a startup conference happening that prompted us to extend our stay in Cincinnati. It was attending this conference and preparing for it that ultimately led me to make a major course correction on my startup project. It’s almost impossible to measure the benefit of that kind of productivity. I could have spent months working on something and ultimately killing it, essentially wasting those months instead of killing it early and being able to use all that time in other more productive endeavors.

Conclusion, And A Few Unexpected Things

The projects I was working on when I started this journey didn’t last as long as I predicted. My clients had business issues that deferred work I was planning to do for them, so I worked less for others than I thought I would. I had projects of my own that I was able to dive into – something I really appreciated having the time to do. However, we ended up using a lot more savings than we originally planned to make it through the year.

I miss my neighborhood and the communities I was part of in San Diego. It’s not that this was totally unexpected. But it’s hard to appreciate the feeling of disconnectedness you’re going to experience when it is theory vs when it actually happens. Especially for this reason, I am looking forward to transitioning back to living in our home.

As wonderful as it has been to write some code and do some of my own projects, I miss working daily with a team of dedicated people. I’m very glad we embarked on this journey. But I’m also looking forward to the next stage of my career – energized and ready to adopt someone else’s great idea as my own and help it become a success in the marketplace.

 

Do I Have Time To Attend A Workshop?

How could taking time out to attend a workshop on entrepreneurship help? I don’t have time for that. I have so much to do!

That was the thought / question bouncing around in my head for the weeks leading up to the Startup Week and the OCEAN startup conference in Cincinnati where we had been staying. I had a lot of work to do and I would have to put it on hold to attend this workshop and conference. But I had committed and decided to follow through with attending it.

Earlier in my career, I easily fell prey to the fallacy of working longer and longer hours in an attempt to increase my productivity. Since then I have read plenty of studies to show this is fallacy. My favorite (and highly recommended) book on the topic is Deep Work. Yet in spite of all that evidence, it still seems counterintuitive. So it requires deliberate thought and action on my part to keep a healthy rhythm in my work / life, let alone take out time for a workshop and conference.

Often there is some exceptional circumstance that makes me think this time is different – why I really have to keep pushing hard on this task in front of me. In the present case, I had concluded that to really test a product with an audience of users driving to and from work, it needed to be as easy to use as a car radio with almost as rich of content. As a result, the list of things to develop became quite long. And while I was able to do a bit of pruning, the remaining list was not a quick effort by any measure. So I had a *lot* of work to do.

But I also remember what I learned from one very brief but powerful article titled The MVP is dead. Long live the RAT clarifying what an MVP was really intended for. What is an MVP except to test your riskiest assumption?

 

The MVP is dead. Long live the RAT.

 

And therein lies the key. I had made assumptions when I started building my product that I hadn’t yet validated. Could I test some of those assumptions without even building any product?

In fact, I could.

It was my understanding of this principle that led me to focus on identifying and validating my riskiest assumptions. And it was this hard work of clearly identifying my riskiest assumptions that prepared me as I attended a startup workshop to have an open mind and ultimately to make me receptive to the truth I would be faced with.

I had signed up for the workshop and conference mainly for the exposure and networking benefit. But I got so much more. I was reminded of a key truth every business must pay attention to.

 

You don’t want to fall in love with your solution. You want to fall in love with your customer and their problem.

 

As the inventor and developer, I had fallen in love with my solution instead of my customers and their problem.

And this principle isn’t even new to me. Rather, hearing it was just a clear, succinct reminder of something I had already known, but in my zeal to build a product, had neglected to take hold of.

Because I went into this workshop with a clear understanding of some of my biggest assumptions, I immediately knew that the pivot required by acknowledging my misdirected love would lead to a very different kind of business than I set out to build – a kind of business I am presently not prepared to build. So I killed my startup business after investing 175 hours of time (with 60% of that invested primarily to learn different technologies – value definitely received).

It is disappointing to put to death something you have invested time and energy in. But by keeping a good rhythm in my work, I was able to pay attention to the riskiest assumptions. And by getting clarity on the riskiest assumptions, I was able to nix my business idea before a ton of money and time was poured into it.

The ultimate outcome when such a decision is so clear is peace of mind. I do not have to second guess myself and can move confidently on to the next thing knowing I have made the right decision and have kept my losses to an absolute minimum.

* Featured graphic designed by Iconicbestiary

 

An idea worth acting on?

For much of my career, I have led the creation of new software applications.

In each case, something that started off with an idea led to a more detailed concept, that led to a set of requirements and a prototype in some kind of iterative, evolving scenario. And in each of these cases, it eventually transitioned from a one-person project to a multi-person project – ultimately with a whole company numbering tens or hundreds of people built around the product.

I’ve always had a stream of ideas flowing through me. Some I write down. Some I prototype. But very, very few do I act upon at all.

In fact the ideas that I have turned into a product were often other people’s ideas that I embraced, built and then took further.

Why do so few of the ideas get acted on?

Every idea has some motivation, some problem to solve. And every idea will cost something to build. So there is an implicit (or explicit) value calculation that gets done to figure out, “is it worth it?” That can be in terms of money return on investment. It can also be in terms of the social or other value created by the investment.

A few years ago I was having lunch with my friend Cameron and lamenting to him that it was hard to find/make time in my schedule to pray. Without getting into all of the good answers to that question, one that came up went something like this…

  • Cameron: “Have you tried praying while you drive?”
  • Me: “I’ve tried that. I get distracted too easily. It doesn’t work for me.”
  • Cameron: “Try making a prayer track with prompts to remind you of what you want to pray for with silence in between to allow you to pray.”
  • Me: “OK. That might just work. I’ll give it a shot.”

So I did try it. And it worked amazingly well. I put in prompts about my family and various enduring topics like work, small group, etc. It probably took me an hour with GarageBand to put together the track. Not a bad return on my time for as much as I used it.

But then I realized that to make changes, I might be spending another hour or at least a half hour to update this track and get it onto my phone.

What if there were an easier way to update the track?

Out of this was born the idea for an app I call Pray On The Go* … use a record button in an app on your phone to quickly record audio prompts for yourself. Then have the app play them back in order with time to pray for each one. Insert a few music tracks in your list to break your prayer time up a bit.

As I thought about this idea, I started to write down the details. It wouldn’t be easy. I’d have to learn Objective C or get some help writing it. Still, I kept refining the idea until I had a detailed specification.

That value calculation I mentioned earlier took a while to mull over. Even now, I’m not sure this app will ever bring in any revenue. If others find it useful, will they find it worth paying money for? I ultimately decided to invest the time and money and created the iOS app which you can find here.

That was great for me and a few of my friends. But I had to turn away all my friends with Android phones. And not wanting to create two completely different code bases for this app, I decided to rewrite the app using Flutter to target both Android and iOS. Now you can find the Android version of the app here. Eventually I’ll bring this Flutter code base to the iOS app store so that I can keep my maintenance work to a minimum.

The ROI on this investment goes in a few different directions:

  1. I’ve already benefited from the learning experience by actually writing the app.
  2. I’ve created something that may be of value to some people.
  3. TBD: I may yet come up with a way to generate some revenue from this.

But even without the last one, I’m glad I didn’t leave this idea on the shelf.

As I use the app, I definitely find it useful. But I also find that I get bored with it and want it to do more. I really think the ability to pull in more types of content and to share prayer requests would make the app more compelling. So, I find myself once again doing little ROI assessments for things like adding sharing features to make it easy for people to share their audio prayer requests among a small group.

I’ve already started creating AWS Lambda services to support these sharing features where for me the learning ROI is compelling enough to proceed. (Lambda has been long on my list to explore). But I can see the investment expanding significantly and the rest of the ROI is just waiting out there for me to attempt to compute.

I’d love to hear about an idea you’ve had that you have left on the shelf, or maybe even started to dabble in, but in any case, just can’t quite let go of it.

 

*I initially called it Drive Time Prayer. But then realized the application is much broader. This kind of prayer track can be useful anytime your hands and eyes are occupied and your mind is doing a routine task that leaves room for thinking and listening.

Flutter and the Law of Leaky Abstractions
animal avian beak bird

Photo by Pixabay on Pexels.com

A few weeks ago I started a project to rewrite my app Pray On The Go using Flutter.

First I implemented the persistence methods as this would make testing the rest of the app easier. Even though this is local file storage, I used json for persistence anticipating that I will leverage the same format when I eventually start serving up prayer requests from a server.

The json encoding and decoding libraries for Dart (the language used with Flutter) have undergone a lot of change in recent years and it turned out to be some work to figure out the best approach for handling decoding. Much of what is written about json decoding for Dart is outdated because of the changes that have taken (or are taking) place.

The code for creating my classes from json turned out to be simple once I properly understood the model that could be used for parsing json and reviving classes. I just created a fromJson constructor for my primary object class and then created a revivor method that could be used on the list of objects, like this:

dynamic revivePlaybackList(dynamic key, dynamic value) {
  if (key == "playbackElement") {
    PlaybackElement pbe = 
                new PlaybackElement.fromJson(new Map.from(value));
    pbe.index = this._playbackList.length;
    this._playbackList.add(pbe);

    return pbe;
  }

  if (key == "listName") {
    assert(listName == value);
    return value;
  }

  return value;
}

The rather straightforward task of turning the file into a list of objects can then be handled like this:

  _jsonCodec = new JsonCodec.withReviver(revivePlaybackListList);
  String jsonData = await _file.readAsStringSync();
  await _jsonCodec.decode(jsonData);

Happy with my progress on implementing persistence, I wasn’t quite prepared for the difficulty that would come next as I tried to get the screen to update with my changes as the file loaded.

Since I was new to Flutter, I had started off with a simple list example app and then was modifying it both to learn and to implement the functionality I needed. But with my superficial understanding of the model for updating a screen of widgets, I quickly met with frustration as all of the things I tried seemed to have no effect. My mental model wasn’t only superficial – it was broken.

I had to take time out and really understand the stateless and stateful widget tree model that the creators of Flutter designed. In addition to understanding this model, there are nearly 150 widgets defined with about 500 classes that can be combined in all kinds of helpful and unhelpful ways. So the examples I found to help with this process were key. I ended up spending a couple of weeks learning Flutter and trying my hand at turning a simple sample app into something useful.

Once I had that behind me, I started fresh, with better understanding and with more appropriate examples. I’m nearing completion and have put in 80 hours since this fresh start building my app.

As I look over those 80 hours, I see that 24 of them were spent tracking down and solving just one problem; recording on the physical iPhone refused to work. I pursued a lot of dead-end leads trying to track this one down. Ultimately, I ended up debugging the iOS specific code used to implement one of the libraries I had included in my project.

I think Flutter does a beautiful job of creating a UI abstraction that works well in both Android and iOS. Also, the growing library of packages to accomplish other things (such as audio playback and recording in my case) nicely abstracts these functions so that you don’t have to deal with the nuances of each underlying operating system… until you do.

 

“All non-trivial abstractions,
to some degree, are leaky.”
– Joel Spolsky

 

Joel Spolsky popularized the Law of Leaky Abstractions which every developer before and since has had to wrestle with to get anything useful done. And this one bit me good. The problem I spent 24 hours working on over a week and a half is written up in detail here. The solution turned out to be rather simple. But getting to the actual cause of the problem required digging beneath that nice abstraction to figure out what was going on in Objective C with the iOS implementation. And further complicating the situation for me, the problem never manifested in the simulator!

In the end, having understood the problem in enough detail, I was able to fork the repository for the stereo audio playback library that was causing interference and make a code change that eliminated the problem altogether. The author of the library quickly accepted my changes so I was happy to have contributed to a more reliable ecosystem of Flutter packages even if it cost me the equivalent of 3 full days.

Many more leaks in the Flutter abstraction layer will be found as new packages are created and as people start to use them. And this will definitely take some time. For those who decide to build their app now in Flutter, participation in abstraction leak finding and patching is almost necessarily a requirement.

Given the relative young age of Flutter, I’m actually surprised that I was able to create this app without writing any platform specific code (with the exception of fixing the stereo library of course). I’m very happy with app performance and responsiveness as well as the flexibility I had in fulfilling my design intentions. Flutter will be a leading candidate when I’m ready to create the next app I need – along with the expectation of handling a few leaky abstractions.

 

 

 

Flutter – My Unlikely Choice For Building An App

Early in my career, I needed to build a Windows app and thought we would eventually need to build the same app for Mac as well. To facilitate this direction I chose a framework called XVT to build the app on Windows. In theory, we would leverage this work for a Mac version when the time was right.

I was convinced for a year and a half after I made that decision that it was the right way to go. However, eventually two things made it clear that it was the wrong way to go for our project.

  1. We never built the Mac app. It turned out there wasn’t any demand for it and the effort to do it, even with a framework that was built to support Mac, made the effort not worth it. In those days, the Mac was declining in popularity.
  2. XVT could not keep up with the pace of change in Windows and for that reason, our app always felt a bit behind the times. We ended up rewriting the app without XVT so that we could take advantage of the new features and design elements of Windows as they became available to the general community.

How long do you operate on information gathered from a prior experience? For instance, if you try out a particular type of salsa and don’t like the taste, you may never buy it again your whole life. It makes no difference if the manufacturer changes the ingredients in the meantime. You don’t even know that change happened because you have moved on. You only have so much time and energy to test things out and make your discoveries. We make thousands of conclusions like this. So it’s generally worth relying on those discoveries made years ago – unless there is a compelling reason to re-evaluate.

Primarily through my experience with this one decision to use XVT, for 25 years I have been down on frameworks that advertise developing once for multiple completely disparate platforms. A couple of times I have dabbled with new frameworks like Xamarin. But I was very hesitant and it didn’t seem that the fundamental issues I ran into with XVT had been solved.

Why did I reconsider when I heard about Flutter?

Firstly, my experience with the cost of having separate developers work on building Android and iPhone apps to do the same task keeps begging for a better solution.

Secondly, in my current experimentation mode, I have the need to create an app that I want to work on both iPhone and Android. I have some experience building iPhone apps, but none on Android. And I don’t quite have the time to write this app twice.

Thirdly, Dean Chalk’s article – Why I’m Giving Up Everything for Flutter. My current need, and Dean’s compelling arguments convinced me to read more and to jump in.

So… for the past few days I have been building my proof of concept with Flutter. And I’ve been surprised at how quickly things have progressed. I took a couple of days to learn the basics of the Dart programming language. I’ve found beta and alpha libraries that are quite capable even in their early stage (audio, text to speech, etc.). And I love the Material Design framework and their approach to building clean UIs that look great on both platforms. Even for targeting a single platform, I’ve found it much quicker to get a clean-looking interface than working directly with XCode. Some of the other benefits I’ve discovered are already written about in this Wm Leler post: What’s Revolutionary About Flutter.

Circling back to that original question – to use a framework or build an app twice on native platforms…

With my history, I know that whatever decision I make, whether it was the *right* way to go or not may not materialize until a few years down the road. But early indicators give me hope for Flutter as a viable way to develop many apps.

 

The Recharging of an Engineering Leader

One of the topics often written about is how an engineering leader can stay in tune with current developments and remain sharp technically such as in Joan Gamell’s post: From Engineer to Manager: keeping your technical skills. His take on it is spot-on.

In almost every case, a VP Engineering becomes one because she was good at managing as a director and/or manager. And she got selected for that in part because she was a great engineer. But as technology evolves and changes, the technical knowledge that the VP once relied on to make good judgments can begin to have limited value. Thus the need for the VP to continue learning.

Some learning naturally must take place by reading, watching, observing what others are doing and developing at least a basic understanding of the technology. And it doesn’t always rely on you since you’ve learned to put strong developers as leads on your teams.

But there are limits. How do you know when your lead engineer is making a bad judgment call? You have a couple of leads disagreeing over the best approach. How can you help resolve this? There are many useful techniques for this. But sometimes the best thing is to have some deep understanding yourself that comes from working directly with the technology.

This can be challenging to fit into one’s schedule even if you are able to block a few hours a week out for the task. I personally have found it next to impossible to fit enough coding exercises into my routine to satisfy this need. Perhaps that has more to do with the organizations I’ve worked with. But I’ve heard the same refrain from many of my peers.

Extended time away

One answer to this dilemma is to take some extended time away – time in which you can focus heavily on a technology area to develop a deeper understanding. Call it a sabbatical if you like. It’s impossible to get enough technical understanding to be ready to decide everything. But deep technical understanding can help in specific areas.

For me, the focused sabbatical has another benefit. I love to code. It may not make sense for me to take a permanent coding job; I have learned too much to leave the leadership completely to others. But with a sabbatical, I can satisfy my craving to code and come back to the leadership role refreshed and energized.

I’m not interested in taking a VP role at a company where I’m not passionate about the mission of the organization. Finding the right role can take some time *and* seems to be quite compatible with my extended coding sabbatical. I think of it like this. When I went to college to earn a degree in engineering, I was committed to graduating. But for an amazing opportunity, I might have put it on hold. That’s how I think of this time. My main goal is an extended time to indulge my love of coding and learning. I’m hoping that *amazing* opportunity doesn’t come along too soon. In the meantime, I’ll maximize my learning by writing about it.

System Design

I think a lot about design – mostly in how it affects me or affects others. Sometimes that’s an emotional effect. Other times there are material consequences to design choices – either negative or positive. I’ve written about some of these in my former blog.

Lately, I’ve been encountering more situations where a lot of design or optimization has been applied to something which is in fact a component of a system. Yet the system design and optimization was completely neglected.

Of course it is possible that optimizing your component will improve overall system performance. But the opposite is also possible, and even likely. Fix a traffic intersection here, create a worse problem over there and in fact hurt overall performance.

One situation I experienced recently happened with switching my family plan from AT&T to T-Mobile. I experienced these positive design elements:

  • Great plan designed to reward me for holding onto my phones for longer
  • Lowered my monthly bill significantly
  • Gave me a great international experience traveling to Europe

But then poor reception at my house ruined the entire experience for me. T-Mobile has solved the poor reception problem for some people by offering WiFi calling – a feature that lets you make and receive calls using your smart phone over WiFi when a cellular connection is not available or is too weak. However, T-Mobile cannot modify the phone app in the iPhone. Only Apple can do that. So as of yet, WiFi calling is not supported with the iPhone.

To be fair to T-Mobile, I’m sure they *want* to solve the reception problem for me. But both paths open to them are tough nuts to crack. It may not be economically viable to stand up a tower in the hilly terrain with low population density near my house. And I’m sure Apple does what it wants, not what a late-to-the-party carrier wants them to do. Nevertheless all of the design and optimization done to the other parts of the system failed to deliver the overall experience necessary to keep me as a customer. After a month of suffering through missed calls at home, I switched back to AT&T.

AT&T actually doesn’t have good coverage at our house either – at least not without that MicroCell sitting in the study. I used to think a MicroCell was a less elegant solution than WiFi calling. But it works. And when it comes to using the cell phone, the most beautifully designed phone won’t do you any good if you can’t take calls with it.

Update (Dec 2017): Since I wrote this post, T-Mobile came out with WiFi calling for iPhone. And having used the WiFi calling feature a lot since it became available on both carriers, I’ve realized it has saved me from many ‘poor reception’ areas besides just my home. I’m thankful for the people that did not neglect the design of the overall system in this case.

What system design challenges have you encountered recently?