The Cocoa Nomad Podcast – #16: Creating Your Nomadic Lifestyle: Part 2

In this week’s episode, I talk about why having a routine is important to remain grounded while traveling

You can listen to the Cocoa Nomad Podcast on the following services:

I’d love to hear from you. Reach out with comments, feedback or show ideas on Twitter or Instagram

The Cocoa Nomad Podcast – #13: Creating Your Nomadic Lifestyle: Part 1

In this week’s episode, I share a few tips on getting started with a nomadic lifestyle and how, despite my initial plans, found myself living full time around the world.

https://anchor.fm/dashboard/episode/e4do1s

You can listen to the Cocoa Nomad Podcast on the following services:

I’d love to hear from you. Reach out with comments, feedback or show ideas on Twitter or Instagram

The Cocoa Nomad Podcast: Weekly Retro #3

In this week’s retrospective, I catch my breath after a long travel day (they let me back into the country!), learn that I’m not immune to accepting suboptimal solutions, set my sights on the June T-shirt Challenge and get ready for the announcements of WWDC.

Show Notes:

Greg Gottfried (YouTube)

WWDC 2019

 

You can listen to the Cocoa Nomad Podcast on the following services:

Anchor FM

iTunes

Spotify

Stitcher

I’d love to hear from you. Reach out with comments, feedback or show ideas on Twitter or Instagram

The Cocoa Nomad Podcast #6: Pushing Through the Dips

Starting new things is the easy part. We’re excited and full of passion. But what happens when that passion fades. Will you still keep going? How to keep yourself motivated and avoid distractions with “new, shiny” things?

In this week’s episode, I talk about some sound advice that’s helped me with “pushing through the dips”.

Show Links:

 

You can listen to the Cocoa Nomad Podcast on the following services:

I’d love to hear from you. Reach out with comments, feedback or show ideas on Twitter or Instagram

The Cocoa Nomad Podcast: Weekly Retro #2

In this week’s retrospective, I talk about how my hackathon project didn’t go as smoothly as planned, how changing countries is disruptive to my routine, and how my June Challenge will allow me to get reacquainted with some old tools. 
 
You can listen to the Cocoa Nomad Podcast on the following services:
I’d love to hear from you. Reach out with comments, feedback or show ideas on Twitter or Instagram

Cocoa Nomad Podcast: Weekly Retro #1

Retrospectives are helpful in managing your progress towards goals. They allow you to access what’s been working well and what may need to change. This episode is the 1st of weekly retrospectives in which I’ll share my goals, progress, setbacks and lessons learned.
 
Show Links:

 

You can listen to the Cocoa Nomad Podcast on the following services:

Anchor FM

iTunes

Spotify

Stitcher

I’d love to hear from you. Reach out with comments, feedback or show ideas on Twitter() or Instagram

Puffin: An 80 Hours to MVP Retrospective

After 80 hours of development on Puffin, a work planning/tracking app for IOS, the buzzer has sounded and it’s time to look at what I accomplished.

The purpose for this MVP was to replace the spreadsheet that I had been using to track my work session.

Work Session Spreadsheet
My existing mid-tech method for tracking my work

What I managed to accomplish at the end of 80 hours

What went well?

Gaining clarity on the tracking portion. My attention was initially focused on the standup aspect of the app, so it wasn’t until I created a spreadsheet to track my work sessions that my understanding of what I wanted became clearer. I don’t have a desire to track hours specifically, that feels like a regression to my previous 9-to-5 work life. But I do want is a way to know when I am working and for how long in the overall context of my life. I’ve become more protective of my free time and wanted to make sure I wasn’t spending too much time working on any one project. Conversely, I still wanted to make sure that each project was getting the attention that it deserved.

What didn’t go well?

I spent an inordinate amount of time wrestling with the a few things that I thought would go smoother, namely the calendar. I’m using a 3rd party component because I wanted to save time. I soon discovered that my situation would still require making tweaks. I need a weekly view of the calendar and that means that I still have to adjust some of the settings. I still have to create a way to display the relevant information for a given date range. That said, it presented an opportunity for me to learn more about calendars and date calculations (Yippee!!) and this can be applied to an existing product Gobo.

On the project level, I didn’t do a great job at switching between this project and others. Part of the reason I’m working on Puffin is to create a tool that allows me to move more seamlessly between my projects.

What I learned?

I need to tone down the color usage in my designs.

Simulator Screen Shot - iPhone 6s - 2018-09-24 at 09.29.04
So much Blue!

I have a habit of picking a primary color for each new app idea and having it permeate all aspects of the design. While it works well for the icon creation portion of the project, it tends to make my screens overwhelming. I’ll change my approach to using color more judiciously, which will keep my designs in line with where things are now. I also find that using non-standard fonts is distracting and feel out of place on my device.

On the coding front, I experimented with creating all of my views in code, instead of using storyboards. I’ve tried going full storyboard in the past and now was on the other in of the spectrum. I learned so much about layout with this approach although it was a bit slower. Taking advantage of playgrounds in the early stages should help create a faster feedback loop. I’ll be taking a hybrid approach moving forward as I still see some advantages in using storyboard in my process.

What still puzzles me?

The app is still missing crucial connective tissue. While I’m clear on of the individual components that I need/would like to have, I’m struggling to create a cohesive vision. One of my biggest challenges is determining the correct entry point into the app. I’m not satisfied with the current information hierarchy. There are already too many tabs and I haven’t gotten the planning portions in.

What would I do differently?

My primary focus when I started was in the daily standup aspect. I was attempting to replace my daily journal with an software solution. It wasn’t necessarily the wrong way to go, as I made discoveries along that allowed me to throw away much of my early work. And that’s fine. Early versions don’t have to last. They’ve served their purpose as prototypes that I could use, learn from, and discard. As in writing, I have no issues with “killing my darlings”.

I’d also document the intermediate stages, There is value in being an “app historian” and capturing thoughts and decisions throughout the stages of development. Tracking what assumptions were made at the beginning and how/why they changed could be helpful further down the line. When revisiting features, there may be valuable historical information in determining the optimal time for if/how/when they should return.

Is it worth it to keep working on this? Why?

I’m still deeply interested in seeing this product continue. I find myself using the session tracker portion daily and it has replaced the spreadsheet in conveying how I’ve been spending my time. I’ll continue development by integrating the missing components and discussing them in further posts.

This MVP was a success and I’m looking forward to applying the lessons learned to the next one.

The Least You Can Do

Mom: “Ray, the least you could do is…”
Dad: “The least I could do is nothing.”

I often heard this dialogue between my parents when I was young. My mother would express displeasure about something that my father did/didn’t do. She would express a desire for a little more effort (usually in the form of some small gesture).

“Ray, the least you could do is…”

His response was always the same.

“The least I can do is nothing.”

It was my earliest introduction to my Dad’s personality.
It was sarcastic.
It annoyed my mother to no end.
And to a 10-year old weened on comedy, it was incredibly funny.

I was always looking for ways to inject the phrase into conversations. I even tried to mimic my Dad’s delivery, down to the smirk, head tilt and raised eyebrow.

As an adult, I would learn 2 things:

  • No one I dated would ever find it humorous/clever and no amount of nodding and winking would save me
  • The Least You Can Do is a powerful concept when used for good

On the path of 80 Hours to MVP, I found myself revisiting and repurposing that phrase. Instead of stopping at literal interpretation, I turned it on it’s head. By doing two simple things, I turned what was a joke into an effective approach for maintaining momentum in pursuit of my goals.

The first part is turning the phrase into a question. What is the least I could do? I find that asking questions keeps thoughts flowing and prevents me from getting stuck. For example, when I’m debugging, I ask myself questions to work my way through the current state of a problem to a viable solution. However, that alone would not transform the phrase into a powerful tool.

The second, equally important, part is adding an actual outcome. By providing a narrowly defined outcome, I can devise a pathway to completion. What is the least I could do to achieve the desired outcome?

I find this approach effective at both the macro and micro levels. In determining the success metrics that I defined in the Kickoff Interview, I have provided the macro version. I know what would make this endeavor successful in my eyes. The least you can do is the defining trait for the MVP.

Success requires consistent action. The difficulty is in the implementation and it’s easy to get stuck in the details. If you’ve spent too much time working through issues, frustration and discouragement can set in. Many projects are abandoned when some seemingly trivial tasks become more difficult and start to eat away at your time. It is at this point that you’re most susceptible to quitting.

You must resist the temptation to weigh your endeavors with the scale of frustration.

It is at this point that going back to the mantra of the least you can do proves effective at the micro level.

For example, in implementing the MVP for Puffin, I knew that I wanted reports on my activities. I knew implementing something robust would take too much time. Even implementing a chart library was going to eat into my development schedule as there was still a learning curve. So I asked myself, what’s the least I can do to get some metrics for my work activity? I decided that instead of providing a fancy chart, I could provide aggregate date (e.g.. total # of sessions, total time worked). In doing so, I had one of the solutions the app was designed to provide (how much did I work today?).

Another example of where I use this technique is in fitness. It’s hard for me to stay in shape on the road, since I tend to get tunnel vision on projects and am loathe to actually go to the gym. I solved this problem by asking what’s the least I can do to maintain a basic fitness level? My MVP of fitness is 30 minutes of HIIT training 3 times a week. And even when I’m struggling with motivation, I take it one level lower and focus on the least I can do to kickstart this workout. For me, the answer is usually a minimal action of few basic stretches/jumping jacks just to get my body warmed up. I then build on the inertia and add another small chunk and before I know it, I’ve completed 30 minutes.

Setting minimal metrics provides a clear stopping point as well. If I lack knowledge or experience in an area, I can complete the minimal actions given my current level and return at a later time, when I’ve acquired sufficient skills. By putting an cap on this iteration and enhancing it later, I minimize delays, the accompanying frustrations and maximize efficiency.

Make the least you can do work for you.