Next time you have the urge to say “I’ll try to do that” to a work assignment, ask yourself if what you really mean to say is “No”.

“Yes, I’ll do it” is actionable; so is “No, I won’t”. But when it comes to planning, “I’ll try” is worth close to nothing, because it holds no one accountable for completing the task.

There are certainly times when exploration of the unknown is warranted. At those times, it would be entirely appropriate to schedule time for experimentation. But more often than not, engineers use “I’ll try” to overextend themselves while still having an out.

Say “Yes”. Or “No”. Or “I’ll need help doing that”. Just don’t say “I’ll try” and leave everyone hanging.

• #FridayDevAdvice

My middle-schooler daughter loves Dungeons and Dragons. She, along with other players, co-DM¹ an online version of the game.

She came to me with a question regarding a new game dynamic that she was considering. Here are its parameters:

• There shall be 30 days in a month
• There shall be two 12-hour periods per day
• As each period arrives, there shall be a 50% chance of bad weather
• During a period of bad weather, there shall be a 20% chance that an enemy NPC appears to attack your group

The question: Given the above rules, how many enemy NPCs can players expect to encounter in a month of play, and how would changing the various probabilities affect the outcome?

Although this is not a very difficult problem, I realized that in order to explain why multipyling numbers worked, I needed to explain the concepts of Expected Values and conditional probabilities. But I soon realized there was another way.

Read more…

• #FridayDevAdvice

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!

• #photo
• #apple

See this photo in my flickr album

Copyright ©2019 Dave Rahardja. All rights reserved.

• #photo
• #cars

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.

• #FridayDevAdvice