Most recent blog posts
On temptation
Feb 22, 2012
We commonly think of temptation having the upper hand when people are down, weak, and fragile. In this state our emotions seem more powerful than the muscle of our conscience and willpower thus making us more vulnerable to the temptation of making regrettable mistakes, or giving up whatever work we are doing.
A mentor of mine once told me that there is another state of mind in which temptation can easily usurp us: when we’re strong. This may sound like a paradox, but you’ve heard it before. It’s the classic hare and tortoise fable. Get too far ahead and you become lazy.
I’ve been going to the gym recently, in an attempt to complement my relatively inactive lifestyle. One week I went to the gym several times, each for a substnatial workout. Felt pretty good about myself too. Can you guess what happened the next week? I didn’t go at all. I succumbed to laziness because I felt like I had achieved a lot the previous week.
Another example. I was working last year on an app for myself. Since this was a side project, the time I spent working on it were irregular and squeezed between the rest of my daily schedule. Some weeks I worked on it consistenly, others not at all. The same scenario was at play as the gym example: after a week of solid investment in the app, the subsequent week (or two, or more) was lazy at best.
It’s also not just in human lives we can see this dynamic. In business strategy, there’s this concept of leapfrogging, in which a new entrant to a market overtakes the incumbent leader in market share. One of the main reasons the incumbent fails to maintain their position is essentially arrogance. They becoming too comfortable with their success and ignorantly dismiss the new entrant as a threat based on their current position. Rather than give an example of a company who fell to this sword, I’ll do the opposite. IBM is a company who dominated hardware in the 1980s, largely thorugh an (initially) exclusive agreement with Microsoft. They were able to carry this success forward in the 90s as well, even after they lost exclusivity with Redmond. Toward the end of the 90s, however, they realised that the future of the hardware industry would not remain the cash cow it had been for two decades. So they sold off their consumer hardware business to Lenovo to become primarily a software and consultingbusiness.
What’s the solution? “Don’t hold on to your achievements” comes to mind. “Slow and steady wins the race” is another. But as all wisdom it’s easier said than done and most of the time we know the right thing to do already. We just choose to do otherwise in the moment.
So choose differently.
On back-end vendors
Feb 16, 2012
I get how companies like StackMob are trying to make it easier for developers to get their apps up and running quickly and take a lot of the hassle out of setting up boilerplate services. I’ve played around with StackMob and the tools certainly seem helpful and easy to use. Wholistically, I think they’re doing a good thing.
The disappointing side of the rise of these kind of services is that new developers may be tempted to opt in for a vendor like StackMob to provide an API endpoint rather than face the challenges and thought-processes involved in writing it themselves.
Writing a core service yourself gives you fine-grain control over your business logic. StackMob does let you upload custom code, a feature I admittedly haven’t tried yet, but the concept seems clumsy (you have to JAR up your code then upload it).
Further, needless to say, you learn a lot when you do something yourself. You don’t just gain mastery over the technical steps involved, you can also achieve big conceptual milestones when you need to deeply think about a problem on your own. There’s a big difference between hearing someone tell you that HTTP is a stateless protocol and learning what that actually means.
In doing something like setting up a REST endpoint you will probably reach the same ultimate destination as the current best-practice thought, simply because you will make mistakes that teach you why these patterns are considered best practice. More power to you.
At the end of the day, think of it this way: which would a potential employer value more: your familiarity with a vendor SDK or some lessons learned from the school of hard knocks?
The problem with job applications using a GitHub account
Feb 02, 2012
Not all of us have very much (or very recent) code there.
Personally speaking, most of the code I’ve written (and therefore most of the systems I’ve built) in the last 2 years is the property of my employer at the time and I either do not have access to the code any more, and/or I am not allowed to show anyone outside the company.
I admit I could be contributing more to open source – in which case I would have something to show on GitHub, but for one reason or another, I haven’t done much thus far. It’s unfortunate because I think evaluating a developer’s code is a great way to gauge competency and depth of understanding.
Guess I should start contributing more open source.
iTunes lack of streaming service is a game-changer
Feb 01, 2012
I’ve been using Rdio for the last few weeks and have recently signed up as a subscriber after trying it out. Having access to virtually any artist or album on demand, with the ability to sync with my iPhone for offline listening is seriously rad. I’ve almost never opened iTunes (for music, that is) in the last few weeks and unless Apple can offer a superior subscription-based streaming service, I don’t see that changing.
MySQL scales because Facebook uses it.
Jan 24, 2012
When people talk about MySQL and it’s ability to scale they often refer to Facebook’s extensive use of it to power most of their database infrastructure. What many fail to mention is that Facebook’s MySQL implementation is split into around 4000 shards that sit behind 9000 instances of Memcached that are required to service the traffic volume. So simply stating that MySQL scales fine because Facebook uses it is rather shallow and quite inaccurate.
It’s a shame that posts like these only paint the “MoreSQL” movement as simply a rebuttal of the NoSQL hype rather than an eloquent discourse on the many benefits of using a relational database.