A Proposal for a new type of media source: “True News”

The November 2016 election has made me think about democracy, government, and our society in new ways for the first time in my life. One topic that seems to keep coming up is this idea of truth in the media.

I think most people would say they’d rather read news they know to be true than live in a fantasy world where they read news they like but which they know to be false. It’s basically an alternate take on the famous thought experiment, the Experience Machine, and comes to the same conclusion: truth matters.

In fact, truth may be the single-most important attribute of the news we read. And if you really start to think about it, truth becomes a really slippery concept.

Continue reading

Democracy 1.0

Whoever you voted for in the recent election, most people agree it was one of the most negative elections in their lifetime. People on both sides of the ballot used words like “disgusted”, “exhausted”, and “embittered” to describe their state of mind come November 8.

The candidate who won the electoral college lost the national popular vote. Hundreds of thousands of people have come out to protest that the winner is “not my president.” As a result of the election, virtually all levels of government will be controlled by Republicans, yet Democrats represent roughly 50% of the electorate.

And if that’s not enough, people’s trust in the media and the factual accuracy of the information they read is at an all-time low.

It seems to me Democracy 1.0 ain’t working out so well.

Actually, most Americans call the American system of government “democracy”, but even that term is loaded with nuance. Technically, the USA is a “federal presidential constitutional republic,” owing to the fact that it is a federation of states, that the people elect a president in a fair and free election, that the rights of all citizens are guaranteed by a founding constitution, and that the people do not directly vote on government matters (usually considered impractical), but rather elect representatives who do that for them.

For the rest of this blog post, I’ll just use the term “democracy 1.0” to mean all the above since it’s simpler and more in line with how people use the term in everyday conversation.

So is democracy 1.0 failing us? I think it is in some profound and interesting ways, and the point of writing this post is to explore how.

Continue reading

Thoughts from Ireland

This past week I had the pleasure of visiting my esteemed Gruntwork co-founder where he currently lives in Dublin, Ireland. I had a blast, it was awesome to work in person with Jim, and it was the first time I’ve been to Europe in about 15 years!

Sort of loos like Jim and I are opening a restaurant together. Not sure who the guy in the back is!

Sort of looks like Jim and I are opening a pizzeria together.

In theory, Irish culture and American culture aren’t much different. We both speak English as our primary language, we both eventually left the rule of the UK, and much of Ireland feels like a typical Western country. But there are some really interesting differences, too, and to make sure I don’t forget them, here they are!

Continue reading

Introducing Gruntwork

In November 2014, I started helping software teams ramp up on Amazon Web Services and DevOps. This was gratifying work because a few years prior, I was involved in a project that did a terrible job of DevOps and suffered greatly for it. Now I was helping other teams avoid that same fate.

And what an adventure it turned out to be! I got the chance to work with Intel, Infusionsoft, 3-person startups, a well-funded Spotify competitor and so many other interesting companies doing interesting things. I called the consulting practice Phoenix DevOps because, well, I live in Phoenix, Arizona, and it turns out the concept of immutability (sometimes known as “Phoenix Servers”) is a central tenet of DevOps.

Along the way, I wrote A Comprehensive Guide to Building Scalable Web Apps on AWS, Part 1, and gave lots of DevOps presentations at various meetups and conferences.

During that time I also discovered the outstanding Blog of Yevgeniy Brikman (“Jim”). Jim mentioned one day he was looking for DevOps people and I loved his work, so I messaged him: “Hey, I do DevOps for lots of teams and have no time right now but let’s talk!”

It turned out Jim was doing consulting very similar to what I was doing through his own consulting practice, Atomic Squirrel. And after many conversations and trial projects, we decided we really liked working with each other.

As we compared all our experiences, we realized we’d basically been doing the same thing for every client. Setup a best-practices VPC, automate deployment, setup monitoring/metrics, get ramped up on AWS, etc.

Doing consulting on an hourly basis was one paradigm for helping clients solve these problems, but what if we could solve the problems really well one time and then consult with clients merely to help them adopt what was already built? That would mean we could significantly lower the cost and time needed to get your DevOps on.

Well, that’s what we’ve decided to do! And so today, it is my pleasure to announce that I am officially winding down Phoenix DevOps and joining with Yevgeniy Brikman in a new company we call Gruntwork.

Why call it Gruntwork? Because that’s what this work is for almost every software team. Whatever app you want to build, the infrastructure stands between your vision and your app; almost no one gets excited about automating their infrastructure. Not to mention that it’s hard to find DevOps engineers, they’re often expensive, and they hold all the keys to your kingdom. And when they leave, then what?

So Gruntwork is here to do your grunt work for you, and because of the way we’ve set things up, and the thousands of hours of collective experience we have, we can help you achieve a result that’s more effective and less expensive than the most amazing DevOps person you could hire.

One other aspect of Gruntwork that’s important to Jim and me is that Gruntwork has to be able to completely disappear and you should still be ok to run your infrastructure. Would I base my important project’s entire infrastructure on a new company that was just started by a couple of guys? Only if I had complete control of the source code and could run it without them.

So, unlike most businesses which strive to build lock-in to your product, we are actively striving to build “not lock-in”. It’s actually kind of hard to do sometimes, but it means that customers can choose to come back to us not because the cost of switching is so painful but because we continue to actively provide them value.

There’s more to share in the Gruntwork story, but I think that’s enough for now and we’ll announce more when we’re ready. In the meantime, I am thrilled to be working with Jim, who’s been a fantastic business partner so far, and I am thrilled to embark on this new adventure!

Thanks for reading. Now time to get some Gruntwork done…

Living on $1 / Day

This past weekend, I volunteered at a clinic in Puerto Peñasco, Mexico (better known to Americans as “Rocky Point”).  The clinic was makeshift, conducted in a church in a local neighborhood.  It was completely free to the residents and funded with donations.

The surrounding residents would be considered low income by American standards, but I sat on many pre-visit interviews with them and most of them don’t think of themselves as struggling.  They’re really just living their lives.

The locals have differences in their lives that I simply haven’t experienced.  In my makeshift Spanish, I learned that one woman, Guadalupe, had been waiting at the free clinic for about 8 hours, not knowing when she would be seen.

Continue reading

What I Learned Teaching Programming to 14-Year Olds

Yesterday I volunteered at CodeDay Phoenix as a mentor.  The goal of the event was to take young kids (mostly middle school and early high school) and give them an opportunity to code something in 24 hours.

As a mentor, my job was to “walk around and help where I could.”

The first group I walked up to was creating a tool to help you come up with something to do for the day.  The idea was that it would take your current location, your preference on whether you wanted to eat, play, build, or socialize for that day, look up some locations in a local database and then make a suggested schedule. It was actually kind of a cool concept!

Continue reading

The User Interface of the Violin

Earlier today, I met a friend for breakfast who’s an outstanding professional UX designer.  I was curious about something:

“How do you balance the need to give people a user interface they’re familiar with and can do something with right away, against the opportunity to innovate and do new things that may take more time to learn?”

He gave a beautiful analogy in response.

“Consider the violin.  It has one of the most difficult user interfaces in the world to use.  But if you’re willing to put in the thousands of hours of practice, you can make such beautiful music with it.  There has to be that trade off.  If we demand of our users a steep learning curve, they had better be able to produce some beautiful music.”

I like that idea because I’ve met many designers who get so mesmerized by the idea of doing something new and amazing that they lose sight of the fact that “the tradeoff” has to make sense.

 

Checks and Balances in Agile Development

Recently, I worked on a sprint as part of our company’s scrum process.  This sprint was somewhat unusual in that I was the sole developer.  Not only that but I knew most of the specs in my head, so our product manager and I agreed it wasn’t necessary to write acceptance criteria for the user stories I would be working on.  Since I wrote the acceptance criteria, it made sense that I would be the one who ultimately signed off on the user stories.

I hate bureaucracy so I was excited about how “lightweight” this process for the sprint was.  But I found something kind of interesting.

When I was wearing my developer hat, I realized how much I enjoyed taking time to learn about other technologies.  I had made a commitment to my teammates to get a certain amount of work done by a certain date, and we came up with estimates to make sure that the work was achievable.

But once I was doing it, my human nature started subconsciously looking for ways to “cheat”.  I still wanted to get the work done, and done well.  I wanted to be acknowledged by my colleagues for having delivered what was expected with high quality.  But I also wanted to sneak in extra time so I could do more tech learning on the side.

Continue reading

Paying a Medical Bill Should Not Be This Hard

When it comes to paying a medical bill, I’ve had a backwards experience.  As the founder of Omedix, I built software that’s collected tens of millions of dollars in healthcare bill payments, but I hardly ever paid any healthcare bills of my own.  I was under 30 and hardly went to the doctor!

Next month I turn 34 and I am fortunate that neither my wife nor I has any chronic medical issues, but now we go to the doctor for the usual annual checkups.  In 2013, our health visits amounted to:

  • Annual well-checks with our primary care physician (PCP)
  • The lab tests our PCP’s requested
  • In her case, annual visit with an OB/GYN
  • In my case, annual check up at the dermatologist (skin doctor)
  • In my case, annual check up at the ophthalmologist (eye doctor)

Today, I’m about 4 hours in and almost done paying all the healthcare bills.  The experience has been…traumatizing.  First, multiple bills are sent for the same service, but with slight differences.  Second, our doctor tried to bill insurance, had the wrong info, sent us a bill for the full amount, was later informed the insurance was wrong, adjusted the bill, and sent an updated one.

Continue reading

Give, Give, Give, Then Get

I’ve decided to try an experiment lately.  At every opportunity where I see I can possibly add value to someone in some way, I try to do so.

This can mean connecting someone with someone else I know, sharing insights from experiences I’ve had that may be applicable, or even mini-projects that leverage my technical skills.

Like any other behavior change, this is a habit that takes some work to build, so I’m not 100% ramped up yet, but at least the habit is building, so hopefully after a few weeks it will just be my default behavior.

Anyway, I’ve had a few interesting observations about it:

Continue reading