10 Years at Apple

January 17, 2020

Photo of Apple’s 10 Year tenure award

10 years at Apple.

My anniversary was actually in Feb 2019 (I’m quickly approaching my 11th anniversary), but I received this tenure award only recently.

Headline features I substantially contributed to in the past decade:

  • Mobile Device Management
  • Photo Stream
  • Shared Photo Stream
  • File Provider
  • Universal Clipboard
  • Drag and Drop on iPad
  • Mac Catalyst

If you use any of this, you’re soaking in my code right now!

Made in the Shade

August 1, 2019

Photo of yellow BMW M4 in the shade

See this photo in my flickr album

Copyright ©2019 Dave Rahardja. All rights reserved.

Shipping API Under Time Pressure

March 23, 2019

When shipping API under time pressure, you may be tempted to reach for the most expedient way to get your feature out on time. Here are some strategies to avoid getting caught in a tangle of future technical debt. All this advice is based on buying yourself time post-release (or kicking the can down the road, if you prefer), but they sure do work.

  • Have a vague idea of what an ideal API might look like in the far future. Make sure what you release this year doesn’t make it hard to approach that ideal later.

  • Name your API very specifically (VeryParticularWidgetBehavior, instead of WidgetBehavior), to allow for future evolution that address more general problems in its domain.

  • Don’t add dependencies on other libraries just because you can “leverage” (abuse) otherwise unrelated chunks of their existing API. Boilerplate duplication is often better than adding another dependency. Library dependencies will outlive your API.

  • Stick with established patterns. Resist the temptation to add surprising relationships for the sake of expediency.

  • If your API must be shipped in a compromised state, minimize its reach. If it turns out to be bad, you will be thankful that it doesn’t have tentacles in the rest of your API.

Get to Prototype

February 8, 2019

Ideas, without prototypes, are nothing.

It’s vital to get an idea to prototype as soon as practical. An idea sitting in your head languishes in impotence, unrealized and unexamined.

A prototype allows others—and you—to appraise an idea in detail. It allows collaboration, improvement, and criticism. It lets other people contribute to it. It sparks new ideas in other people, who can then prototype their ideas, and so on.

Prototypes are what allows innovators to actually innovate.

The psychic barrier between idea and prototype can be immense. Making a prototype means committing to a specific implementation. It collapses the infinite potential of an idea into a specific point in space and time. And it lays bare the merits and flaws of your idea for all to see, point at, and ridicule—but also admire and improve upon. It’s an essential step in bringing any product to reality.

Ideas, without prototypes, are nothing.

The Difficulty of Short Term Software Estimation

December 29, 2018

I’m constantly amazed at how bad I am at estimating short-term software effort (I’m better at medium-term estimation, e.g. 1–2 months). If I’m honest, I often underestimate effort by a factor of 3(!) when estimating work that takes 1–10 days.

This is due to the disproportionate effect of interruptions and minor roadblocks on short-term projects. Because the task itself is so small, any impromptu meeting, unplanned chore, or having to work around a tool failure takes up a huge proportion of the feature’s schedule.

These effects are amortized on longer project timelines, but they are devastating to short projects.

Dave’s Uncertainty Principle: the smaller the feature, the more likely your estimate will turn out to be wildly optimistic.

< Newer Posts