A wise project leader at DEC once told me there is a vast difference between “easy” and “straightforward”. Knowing in advance how you could solve a problem does not make it easy to implement.

It has taken me much longer to learn to go for easy, and yet it is a mark of maturity to know how to do it right the first time so you don’t have to rip up designs (or “designs”) constantly to knock out your next feature. That’s not re-debugging, that’s another example of knowing a lot of lacing knots.

(See you at the next Boston Xcoders/CocoaHeads!)

Velcro-fastened shoes! Although I am not sure I’d trust them for a competitive tennis match, but they are superior to lace-up shoes when I am in programmer mode. They don’t come unvelced all day! (I’m trying to get the word “velc” into the OED with the defintion being “to secure by joining the hook tape to the loop tape.”)

One thing that fascinates me is the mirage of what “easy” is. Sometimes I take on a task that looks easy, but it turns out to be much harder to do. This is often the fault of the API. For example, there is a single C function that is perfect for my current task, but it is deprecated and using it makes your log window (that may easily be visible to users) fill up with warnings. The vendor didn’t replace the function with a more modern equivalent — they just point you to a whole bunch of more specialized functions that would go into a giant switch statement. What was once an easy task has become a tediously long one!

On the other hand, sometimes I look at a hard task and, for whatever reason, I can solve it quickly and easily. Those cases are rarer than the others, but they do help salvage your ego from the beating you have been taking for struggling with “easy” problems. I had thought that experience would eventually help you learn to recognize the difference between “easy” and “hard” problems from the start, but you’re still going to be wrong many times!

Given the choice between writing menial, mechanical code or designing a new API or feature, a lot of people will gravitate towards the latter because you actually get to do something. I’m not sure what the solution to this is (since somebody has to take out the trash), but Google might be onto something with using the 20% side project as a creative outlet.

I think this is also what I like about Core Data and Bindings.

Your writing style is superb and tackles complex subjects, like computer programming, with insightful analogies and medaphors. I always feel that I’ve learned something and the time spent has not been wasted. Your posts are detailed yet pertinent, and at the same time, enjoyable.

Keep ‘em coming!