Top Ten Reasons Babies are better than iPads

The ChallengerTop Ten Reasons Babies are better than the iPad

  1. Babies eventually grow up to be better than their fathers.
  2. Babies get cuter as they get older.  Think those fingerprints on your screen will get any cuter?
  3. Babies don’t have a daily purchase limit.
  4. After you get a baby, most people are satisfied for awhile and don’t want to upgrade for a long time.
  5. Babies make other people smile when they see them.  iPads just make people ask, “What’s that?”
  6. iPads look dorky in strollers.
  7. Putting an iPad on your back makes you look like a Borg.
  8. Babies don’t care if you use Flash, Objective-C, or Lua.  Babies just want you to talk to them in any language.
  9. Babies don’t require you to dress in black turtlenecks, khakis, or attend MacWorld for any reason.
  10. Babies are a LOT more fun to make than standing in line to buy an iPad


Top Ten Reasons iPads are better than BabiesThe Champion!

  1. iPads never require college educations.  The closest you get is $4.99 for the Encyclopedia app.
  2. You can shut the iPad off at 10pm and turn it back on at 7am every day, without social services knocking at your door.
  3. When the iPad is hungry, you can plug it in and leave it alone for two hours.
  4. One word:  Diapers.
  5. The iPad will never go on a first date or drive your car.  Ever.  Not even with iPhoneOS 4.0.
  6. You’ll never hear the iPad asking where it came from.
  7. The iPad will never walk in on you having sex.
  8. Trying to swipe a baby will land you in jail.
  9. Best game with a baby:  Peek-a-boo.  Which gets boring pretty fast.  Solitaire, on the other hand…
  10. You can’t make menstruation jokes about babies.

31 Snowclones About Software Development

Proving once again that my sense of humor is only funny to me, I bring you 31 snowclones about Software, Computers and Technology.

No, I’m not talking about snocones although I’m sure there are more than 31 flavors, most of them horrible like Bertie’s Everflavor Beans (One vomit snocone please!).

Snowclones are just a reference to a cliche that has been slightly altered for a new situation, like “In a Panic Room, no one can hear you scream!”, referencing the 1979 Alien movie tag line, “In Space, no one can hear you scream.”  The snowclone here is “In X, no one can Y.”

For your amusement, I’ve collected these snowclones relating to software.  Enjoy and add any others you’ve heard in the comments…

  1. Ruby/OCaml/Haskell/Python is the new Java.
  2. Manual? We don’t need no stinking manual!
  3. Or the new one for interpreted languages: Compilers?  We don’t need no stinking compilers!
  4. This is your brain.  This is your brain on perl.  Any questions?
  5. GOTO Considered Harmful” Considered Harmful’ Considered Harmful?
  6. Bastard Operator from Hell
  7. I’m not an ISO-9000 certified tester, but I play one at my day job!
  8. If you’re a Sun employee: I, for one, welcome our new Oracle overlords.
  9. Or, if you’re a Yahoo employee: I, for one, welcome our new Microsoft overlords.
  10. Untested code is the dark matter of software.
  11. Lines and Transfers and Bits, oh my!
  12. I’m in ur source codez, fixin ur bugz
  13. Open is the new closed
  14. These are not the MacBooks you’re looking for (wave hand while saying it)
  15. Data synchronization is hard.  Let’s go shopping!
  16. Or maybe, LISP is hard.  Let’s go shopping!
  17. What Would Bill Gates Do?  (WWBGD)
  18. If Linux is wrong, I don’t wanna be right.
  19. Whatever flips your bits.
  20. Got root?
  21. There’s no place like
  22. Don’t hate me because I’m a DBA.
  23. Dammit Jim, I’m an architect, not a project manager!
  24. There’s no crying in Cocoa Touch Development!
  25. And by “*” I mean “gets around 760,000 hits on Google.”
  26. Eric Raymond is the Margaret Mead of the Open Source movement
  27. One bitchin, fully-debugged algorithm does not an releasable application make.
  28. Linux developers are from Mars, Windows Programmers are from Venus.
  29. Rabid Atheistic Hackers for Jesus.
  30. If I had a nickel for every Haskell program I could find, I’d be broke.
  31. Holy segmentation fault, Batman!

Developer Lessons from Diablo II

Diablo II (DII) may be an old game but it’s a classic.  I’m one of thousands who gave up hours and hours of my life to it.  I have very fond memories of those times, staying up late with my friends on the phone, hacking evil monsters to bits, making the world safe again.  I think it’s a great form of geek therapy where no matter how bad your day was at work, taking out all the monsters on the Arreat Summit would somehow make things feel right and good in the world.

And with all that time invested in the game, there were a few lessons that are very applicable to real-world software development.  With Diablo III now generating a new wave of excitement for Blizzard’s series, I thought I’d share my insights from my favorite game of the early 21st century.

Take care of the monsters that spawn other monsters first

In the second act where you’re in the Kurast jungle, there are these incredibly annoying and potentially dangerous witch doctors.  Each witch doctor can summon more helpers that continue to attack you and drain your resources.  If you’re surrounded by 10 witch doctors and those incessant little critters they spawn, you’re in for a world of hurt, especially if you just focus on the spawned critters.  You need to hit the witch doctors first, ignoring the rest of the group, before you start attacking what’s left.

Lesson learned: Any problem that is creating additional, more painful problems, needs to be addressed early on in the process before worrying about others.  For example, if you have some serious bugs that continue to crop up and cause your team to spend cycles constantly nursing production systems along, but the fix is going to be hard and take away from your current development, perhaps the fix is worth the time considering the amount of time wasted in keeping the system healthy.

Brute force counts for a lot most of the time…

Subtlety is not really rewarded for the majority of DII.  Your best bet as any class is to pick the weapon, spell or skill that basically will take out the highest number of monsters given the situation.  That “silver bullet” is constantly changing depending on the Act or the area as monster vulnerabilities and resistances change.

Lesson learned: Pulling out your best code tricks for each and every part of the system can potentially be a waste of time.  This is just another way of saying that premature optimization is the root of all evil.  Use the simplest algorithm, framework, or idea that solves the problem.  Go ahead, put that brain dead String concatenation method in there…chances are, it won’t matter all that much in the larger scheme of things.

…But you need to be subtle around the Boss

When you face the Boss creatures on any level in DII, suddenly you’re forced to adopt a clear cut strategy.  Brute force won’t cut it, and even with a larger party you still need to work together and with great care to take down the Boss creature because he will most certain pwn the unprepared.  Certain character classes have advantages when facing the Boss depending on their vulnerabilities.  When I was a Necromancer, facing the Boss at the end of Act I was a real bear for me alone, but my Barbarian friend could easily take him toe-to-toe while I dumped damage into him from afar.  Together we made a big difference.

Lesson learned: You can’t always beat the code down with brute force.  Some very specific problems require a lot of thought, time and energy.  Pick your battles and choose your weapons to attack these problems carefully.  Sometimes, you’re not the best one to deal with the problem…maybe you had a hard time implementing the original solution.  Ask a colleague to step in and pair program it with your, or maybe even offer up their solution ideas for a fresh perspective.

There’s always a new shiny thing to go get

There’s always a better, bigger, faster, shinier, more powerful item to go get.  Whether you’re 10th level or 90th level, the quest for the Bigger, Better Mousetrap will always go on.  You will never have enough Elite Rare items, no matter how many of them you get.  There’s no winning this game but patience and persistence will get you what you seek if you’re willing to put in the time and effort.

Lesson learned: Newer technologies, frameworks and languages are always out there.  They will continually tempt you into thinking that your current technology isn’t nearly as good as What Is Out There.  Never let technologies drive your solutions past the original choices phase unless you’ve discovered a critical flaw in your original analysis.  For example, if you find that your database connection pooling solution simply cannot perform at the level you specified or tested that it would, it would be worth reexamining that particular choice.  Make a choice, stick with it for long enough to finish something with it.  Wait for the right moment to upgrade.

There’s no one best way to play the game

One of the great things about DII and other MMORPGs is the variety of characters you can play–Amazon, Necromancer, Druid, Barbarian, Sorceress, Paladin, Assassin or Monk.  Each has its own unique abilities, skills and fun factor.  I personally enjoyed the Necromancer and the Assassin–the former for summoning hordes of skeletons to do my dirty work and the latter for having the coolest looking claws to take monsters to the mat.  Anyone who says that <insert character here> is the only way to win the game, clearly hasn’t tried the others with similar zeal.

Lesson learned: Trying out new languages and frameworks is a great way to chase away boredom in your career.  Just because you did your last 5 projects with Java doesn’t mean it wouldn’t be interesting or worthwhile to try the same kind of project out with Ruby to see how it varies.  Maybe it will make you a better Java developer because of what you learned in Ruby.  Language snobs are boring and generally one-dimensional.  You’ll be a better developer for stretching your boundaries and limits in things you don’t understand as well as your native language(s).

Blind experimentation is a waste of time and resources, better to leverage others work first

The Horadric Cube was an essential piece of the game in DII but it could be a source of frustration if you didn’t know what really worked in it.  You had two choices with it:  Spend lots of time systematically putting things in and pressing “Transmute” to see what happened (which, depending on the items you stuck in, could be hours or days to re-find if you later discovered you made a mistake), or just look up the recipes online and then start hunting for the right items to make things work.

Lesson learned: Spinning your wheels experimenting with a problem when better and more complete information about it exists in other places is just a waste of time.  Reinventing the wheel might be fun, but it’s unlikely to be the best use of your time when the project clock is ticking away.  Stand on the shoulders of giants and leverage all that great information others have posted on the internet about your framework, language or technology.

Sometimes there is a secret cow level and it’s fun

If you found Wirt’s Leg and a Tome of Town Portal, put those in the Horadric Cube after you defeated Diablo on a level, there was a red portal to a secret cow level:  you got to go whack some cows for a change.  But not just any old heifer.  These were mean cows.  Big, bad cows.  Cows you wouldn’t be tipping anytime soon.  But damn, it was hilarious.

Lesson learned: Unexpected surprises are fun.  And never underestimate the Power of the Bovine.  Celebrate the absurd every now and then.

No matter how deep you are in Hell, it can always get worse

You made it all the way through Diablo II’s Normal level thinking, “Wow…that was hard.”  Until you turned on Nightmare and realized that you ain’t seen nothing yet. Those little rats from the first Act?  Wow, they’ve got serious bite now.  And Baal?  Well, let’s just say that Full On Bad Ass is an understatement.  You might have gotten away with quick and sloppy the first rounds with the Boss scenes, but that’s not going to cut it this round.

Lesson learned: If you think your performance problem is bad in production, consider what might happen if the entire server farm crashed.  Or if you’re dealing with a major crash, what would happen if you had 50% hardware failures instead of just a software problem?  The list goes infinitely deep, each more terrifying that the previous.  Complaining about the problem isn’t going to help.  You might as well be thankful your situation is not worse and deal with what you have.  If you did something that was sloppy during the product development, own up to it, fix it and move on.

There you have it.  Eight fun lessons from Diablo II.  Got a lesson that I missed?  Talk back below!