Mea Vita: Carpe Diem

My last chemo treatment was in December 1999 and, after five years of checkups, my prognosis was cured --- not remission, but fully cured --- to the point that I went back on active duty in the Marines in 2003 and deployed with them to East Africa in 2005. Today, it’s literally like I was never sick. I am lucky.

Cancer, and my father's unexpected death in 2007, gave me a deeper insight and perspective on life. At that point, I realized I could take two or three years off from corporate America. But I didn't expect a few years to turn into more than a decade of retirement.

People ask me, "What did you do during all that time off?"

My answer's simple, "Nothing," followed up with, "What do you do on weekends? That's what I did most everyday."

Looking back on all that time off, I see that I learned how to be a human being instead of a human doing. While I did focus on my own personal projects like learning to fly, creative writing, and volunteering, it was my ability to be fulfilled while not accomplishing a single task, in a day. Some might call that lazy; I call it the simple life. La dolce vita.

While the pursuit of happiness is our unalienable right, it does require more than that to be fulfilled. It requires meaning and here's how to make meaning.

Carpe diem and live the dash.


Update: Something I completely failed to mention was I always knew my retirement wouldn't be permanent. Sooner or later, I'd have to return to full time work which I just did in August, and I'm loving it. 

More tools seems more complicated, but it actually allows for better filtering of information while establishing well defined boundaries. 

I recently started working as the CTO at It's Borrowed, which is like Airbnb for your stuff. Why not earn money renting out that camping equipment, golf clubs, power tools, or wheel chair that's sitting around in your garage? Looking to borrow a ladder or ice chest? Check the It's Borrowed app.

Since It's Borrowed is a small team of five, I'm also the product manager for our API servers and mobile apps. When I last worked in this capacity at Wyndham we only used e-mail and SharePoint, which was marginal. What made it worse, at Wyndham, was that I had to manually sort and archive e-mails in Outlook, my key communications tool. Otherwise, when my e-mail storage grew to more than about 4 GB, Outlook would stop working reliably. Allow me to digress by pointing out that Outlook's horribly engineered to stuff every single e-mail and attachment into a single file which grows and grows until it eventually collapses in an unpredictable way. Compare that to macOS which organizes your e-mail boxes into an elegant hierarchy of folders; each e-mail (body and attachment), is then stored as a separate file. File systems are much better at managing (CRUD) ten-million 1K sized files than two 5GB sized files.

Workflow Filters

Today's workflow, with Basecamp, Slack, Trello, etc., simplifies my life by managing filters. A ding of an incoming e-mail is an interruption; and a message could be from my manager or my mother, each having a unique sense of urgency and importance.

Here's my workflow when using Slack, Trello, and Basecamp...

Basecamp
When I meet with the business (marketing), we put high level tasks into Basecamp such as "Create an e-commerce shopping cart so people can buy our stuff." Think of the tasks in Basecamp as the business's vision – a high level goal.

Trello
Since I'm the two-way bridge between the business and engineering, I take the vision of the business and break it down into a single engineering task that can fit into a Sprint since we're closely following Agile/Scrum. In Trello, our tech lead has organized boards for each Sprint and the backlog. Each column has a card which is akin to an electronic Post-it note. Inside each Sprint board, we have columns such as Blocked, To Do, In Progress, Review, Done, etc. The blocked column are impediments that I take for action, while the tech lead focuses on the other columns.

Each Sprint begins with the engineers reviewing the backlog along with the CEO and me. The engineers get to pick, from our prioritized list, each task (card) they'll do in the upcoming Sprint. Only the engineer picking the task can assign a weight to a task – a weight, meaning how long it'll take a task to be completed. That part is sometimes a hard pill for management to swallow. But, over time, as engineering delivers on all they promise, management will gain confidence even though they can't interrupt a Sprint with new requirements.

Slack
I think of Slack as Twitter on steroids, across different teams and channels. The key Slack teams are the ones that I have with the engineering department and each individual engineer. Since the engineers fall under the tech lead, I rarely communicate directly with an engineer so as to not interrupt them. This is harder than is sounds when the CEO asks me a pressing question which I could simply have answered by interrupting an engineer. A couple of our channels are automated and tied in to third party services so, at any time, I can see code check-ins or deployments to production in real-time.

The beauty of slack is I can see the history of a channel conversation without having to search through e-mail looking for specific threads.

Discipline is key. As long as the team has the motivation to follow this format then the information will quickly and effectively flow, increasing productivity. It really does work well.

When pondering this issue, holistically, I look for other examples where I've seen similar problems. Instead of looking at it as a software engineering issue, I look at it as a systems engineering issue. This analogy works well when breaking down problems. For example, we can think of data packets transversing the Internet as cars (packets) carrying payloads of people (data). In this example, we see the redundancy of our roads. Destroying a bridge in Syria has no effect on the roads in the U.S. Or, destroying the Internet's "single point of failure," i.e. DNS, would be the dire equivalent of removing every road sign in the world. As systems fail in ways we didn't imagine, other pathways must handle the load resulting in cyber traffic congestion or even failure to access a network node endpoint.

All software needs to be checked for bugs, either by a compiler, coder, tester, or customer. Every new line of code increases complexity, but this is an oversimplification since we usually don't want to compress four lines of code into one. Code written must be debuggable and there's a balance between engineering, over-engineering, and making code intuitive for people to read. One never wants to be too clever when writing code. Too-clever code can end up fooling everyone like debugging a multithreaded race condition. I'm not aware of a formula to compute how dense code is, but an experienced software engineer will get an intuitive feel for it with years of experience. 

As towns and cities require building codes and permits, we may see the same thing in high-tech. Obviously, a bridge failing is catastrophic while Amazon going down is comparatively minor, no one is physically hurt in the latter. Lost revenue is vastly different than lost lives, but, that will change. What if an airplane auto-pilot breaks in-flight? Or, worse, what if it begins misreporting or misinterpreting flight data? In the physical world, our building codes are about safety. Online, our issues are about security – and the two are related. Our online world focus is on attacks rather than infrastructure failings.

While I don't see a need for software performance inspections by third parties, I do see a day when software will be inspected by independent agencies for security.