I have been blessed

Last night I watched the following video about Bill and Melinda Gates, and what they are doing to prevent infant mortality:

They’ve managed to potentially prevent millions of children from dying in the first 24 hours birth.  Part of what they did was actually ask parents for permission to autopsy deceased children.  You can’t see much in the video, but it was still pretty heartbreaking to see a little plastic wrapped bundle, knowing that it was someone’s child.  It made me realize how blessed I am.  I actually had to get up and check on my two little girls and wife that were asleep, just to make sure they were still well.  To think that I’ve got a wife, two amazing little girls, a house, a job, supportive family members, etc…. and I don’t have malaria.  It’s videos like this that make me really realize how blessed I am.  And it motivates me to try and find ways that I can help others.

Disrupting an Industry

A colleague and I had a recent discussion about this: what does it mean to “disrupt” an industry?  I think we’ve all heard it at some point another – usually in a bunch of marketing speak.  But what constitutes a “disruption”?

In my mind, a disruption is some sort of rapid introduction which forces a rapid reaction from the rest of an industry.  If a company fails to react, it may find itself facing a reduced market share or bankruptcy.  A disruption is not a gradual change, nor it is it a soft change.

A few thoughts about the subject have been on my mind:

In order to disrupt an existing industry, it generally takes some sort of new technology which makes an existing task (or series of tasks) easier, faster, or simpler.  Streaming movies on Netflix is an example of this.  Rather than having to get off your couch, walk/drive to the movie store, browse over a series of movies, pay the clerk to rent it, then go back home (only to discover the VHS tape you’ve rented is stretched and garbled), now all you do is fire up Netflix and start streaming a show.  Companies like Blockbuster failed to either accept (or counter) this kind of change, and as a result, didn’t fare so well.

There are a few considerations in regards to disruption:

  1. What gains are to be made with a disruption? If the potential revenue gains are small, there’s a smaller chance that it’s a good target for disruption. It’s not too likely that someone is going to introduce an iPhone app that’ll destroy lemonade stands, partly because there’s little to no revenue in it.  Because there’s little revenue in it, it’s not as big of a target.
  2. How difficult is it to disrupt a given industry?  There’s a lot of smart people out there, and the low hanging fruit is usually the first to go.  For example, when I was a missionary, my old mission president and a colleague created a system for computerizing index cards in libraries.  This was something that hadn’t really been done before (at the time), and as a result, they did well.  Because the market of library card catalog equivalent software is already established, they likely wouldn’t be as successful if they were to do it again.
  3. How “big” is the disruption?   If you created an app to save someone a single click per day, it’s not too likely to catch on.  If you save them an hour of work a day, it’s a lot bigger of a deal.  This is why I say a disruption has to be significant in order to be consider a disruption.  This also involves the number of potential people affected by the disruption.  Saving a single click to half a dozen users per day isn’t going to make you a billionaire.  Saving a hundred million people a single click per day has a potentially bigger impact.*  The value of the impact could be measured as the number of users affected times the impact per user.

A conference I was at recently got me thinking more about this: what industries are ripe for disruption?  What is the next “low hanging fruit” which could be automated or digitized?  This is a difficult question, and to a certain extent, I think is impossible to predict.  I never would have guessed that app that helps you take grainy, washed out pictures of food could be worth a billion dollars.  I also wouldn’t have guessed that a chat app would also have a similar value.

A few things are coming to my mind, which are ripe for disruption:

  • Video chat.  I use Skype a lot at work and home, and I’ve grown to hate it.  Someone is totally going to create a decent cross-platform web based video chat.  Even if it resorts to using black/white imagery, if the frame-rate is good, I think people could go for it.
  • “Real” social networking.  There’s a growing counter-culture movement of people getting outside and actually doing things in person, but in an augmented way.  Pokemon Go is a perfect example of this – it took a video game outside.
  • Wireless headphones.  It may just be my perspective, but there’s very few wireless headphones that actually work well, sound good, have decent battery life, and are reasonably priced.  I think the first <$100 (USD) pair of wireless headphones that look and sound good, and have decent battery life will sell well.  People hate dealing with cords, especially headphone cords.
  • Non-Apple laptops.  Manufacturers are slowly figuring this one out, but I’m amazed it has taken them this long.  Try to find me a decent Windows based laptop that has a 1080p screen, a decent keyboard, decent battery life, and is made from something other than plastic.  That criteria alone narrows it down to maybe half a dozen models.  It’s only a matter of time before someone does it right.  The question is, who will have the guts to actually try making something decent?

* By this, I’m referring to Google’s search engine, which doesn’t even require a user to click “Search” – it just starts searching as soon as they start typing in a query.

Producers vs. Consumers

This is something that I’ve been thinking about lately – how there are basically two groups of people online: producers and consumers.

A producer is someone who makes content.  It could be a blog or forum post, a video posted to YouTube, a Twitch stream, a tutorial, a song, or almost anything.  Anything that someone else can watch, listen to, or read.  A producer can be a single person or a group of people (or even an automated bot).

A consumer is someone who consumes content made by producers.  It could be someone watching a YouTube video, reading a blog post, or listening to a song.

It is incredibly difficult to be both a producer and a consumer at the same time.  Usually you are doing one or the other.  (The exception that comes to mind is listening to music while doing something).  In most cases, you are one or the other – a consumer or a producer.

It is easier to be a consumer than a producer.  Consuming content doesn’t take as much talent, skill, or effort.  Anyone can watch a football game, but not everyone can play football, and that’s fine.  Not everyone who watches football wants to play football.  There’s nothing inherently wrong with being a consumer, unless that consuming is taken to an excess.

From a financial perspective, you won’t ever get rich being a consumer. If anything, you become less wealthy being a consumer, as you are spending your time (and potentially money) by supporting a producer.  There’s nothing wrong with supporting producers – quite the opposite!  But if your plan is to become wealthy by consuming someone else’s products, I hate to be the bearer of bad news, but it’s unlikely to happen.  Water doesn’t flow upstream.

Lately I’ve found myself more and more motivated to become more of a producer.

The Giraffe Principle

I discovered something a few years back that I call the giraffe principle:

If you are willing to reach, you can get things other people haven’t gotten to.

The first time I really noticed this was in the grocery store, when shopping for fruit.  All of the fruit closest to the edges of the bins was thoroughly picked over, but the fruit that was further away had better selection.  It was ripe, less bruised, and better smelling.*  People were basically being lazy and picking whatever fruit was closest to them, rather than reaching a bit further away and getting a better piece of fruit.  This really could be re-worded:

You can expect the same results with the same behaviour.  Different results will require different behaviour.

If you want to do something great, you’ll have to do something different than the average person.  Rather than watching TV in the evening (like an average person probably does), or checking Facebook 20 times a day, do something else.

In my case, that “something else” has been a few different things: woodworking, web programming, cooking, etc.  I have a huge amount of respect for those that produce content, rather than consume it.  For example (and a bit ironically), lately I’ve been watching a lot of Cody’s Lab, Engineering Explained, and This Old Tony on YouTube.  I suspect each of them are getting a decent little income from YouTube.  It almost makes me want to start recording some of the things I do.

Footnote: when purchasing fruit, don’t be afraid to smell it.  Smell and taste are related, and if it has less smell, it’ll probably have less taste as well.  This works for things like apples or peaches, but not so well for bananas. 😛

Bad Developer, No Twinkie Part 10: Providing Terrible Estimates

This is a tricky one.

At one point or another you will be asked to give an estimate of how long it’ll take to do a given unit of work.  Unless you have tons of experience and practice at this, you’re probably going to give a terrible estimate.  Giving a good estimate is like learning to play the bagpipes: anyone can do it, but only someone with a lot of experience can actually do it well.  And in both cases, no one likes it if it is bad.

So how do you give a “good” estimate?  The easy answer: don’t give an estimate.  At least don’t give an estimate until you feel you have enough information to give a reasonable estimate.  To misquote Donald Rumsfield: ‘There are known knowns.  There are known unknowns.  And there are unknown unknowns.’  If you are basing your estimate only on the ‘known knowns’, your estimate will be wrong.  The more information you can gather, the better your estimate should be.

Other things that you may wish to consider when providing estimates:

1) Don’t give an estimate at all until you have a better idea of how much work it entails.
2) Don’t give an estimate until you’ve secretly done what is being asked, then you will know exactly how long it “will” take.  (This isn’t always an option – especially on anything larger than a few days worth of work).  Then, instead of sitting on your hands for the next while, start working on the next request.  Again, this isn’t a very good idea, but it can sometimes work.
3) Take your initial estimate, then double it.  Then double it again.  Then for good measure, add another 50%.  It’s amazing how many problems go away when the solution takes 6 months and takes half a million dollars.
4) Give a range, and state assumptions for the range.  The lower the estimate, the more assumptions you will need to complete it on time.  The higher the estimate, the looser the assumptions.

Losing Sight of the Goal: Making Stuff

As a software developer, it’s your job to make something.  Maybe it’s a website.  Maybe it’s a mobile phone app.  Maybe it’s a hat trading simulator for the core of a video game.  Either way, your job is to make something.  Sometimes you aren’t writing code.  That’s completely okay.

Maybe it’s just my Canadian background, but have you ever heard the adage about spending 90% of your time sharpening your ax, and 10% actually cutting?  The ratios are likely swapped, but there’s some truth to it.  In doing your job – making stuff – you sometimes need to do a bit of research.  You might not know how something works, so you spend time reading API documentation, Wikipedia articles, or ancient PDFs of algorithms that you need to use, but don’t understand.  You often need to discuss things with co-works, clients, or shareholders, send emails, and write documentation.  That’s time that you aren’t spending writing code, but that is still time spent doing your job – making stuff.

Never lose sight that the goal is to make something – not write code.

Developer Logs/.plan files

One thing that I’ve done, as long as I’ve been working, is keep a personal record of everything I work on while I’m at work.  It’s usually just a text file, and for each day I add a new entry.  A daily entry would look something like:

January 19, 2017:
- (In at 7:56 am)
- Dealt with 5 emails related to project Twinkie.
- Reviewed pull request #1337.  Unit tests failing.  Pass back.
- Had meeting about frobnicating options.  Decided as a team to go with Option B.
- Logged new work tickets for tasks relating to Option B.
- Had brief meeting with Daryl and Larry about Option A.  They say B.
- Run into error with deployment: "System Error: Ran out of printer tape".
    - Resolved by running command: "sudo feed_me_a_cat".
- Review pull request #1338.  Needed small tweaks.  Merged it in.
- (Go home 5:31 pm)

It’s nothing super-detailed, but it at least can be used to refresh my memory of what I did on a given day.  These sorts of little notes have been incredibly helpful in a few situations.  Even in an environment where you don’t have to keep time sheets or specific hours, they can still be really helpful.  For example, if I ever run across a “System Error: Ran out of printer tape”, now I can go back and reference my notes to see what I did to fix it last time.

I even do this for my own personal projects, but in a bit less detail. In my personal projects, I’m not concerned about how much time I spend on something, but I am concerned about writing down little notes that I suspect will help me later on.

Eventually I’d like to make these notes into more of a narrative. Like when you are wandering around in Skyrim or Oblivion, and you come across a note left by a previous adventurer… or like John Carmack’s .plan file notes. They are definitely less technical, but still incredibly useful.