The take away for me from Dustin’s post is that there is a lot of context that one requires to be able to evaluate someone else’s idea. Ideas, even those espressed as a prototype, convey very little meaning to someone who does not have the background information needed to process them. In this case, I really wonder how much Dustin actually knew about Pinterest’s target market (middle aged women) to actually offer any meaningful feedback.

We can see the importance of context in various other parts of our life. On the morning of January 12, 2007, virtuoso violinist Joshua Bell stood on a Washington D.C. subway platform and performed classical music for passersby for 45 minutes. He collected a total of $32 from his performance. I don’t think anybody knew that Joshua had sold out a theatre in Boston just two days ago, with an average seat cost of $100. Yet, very few even bothered to listen to him (read more about this social experiment). Perhaps everyone was rushing for their work, but it’s hard to dispute that a lot more people would have lingered around if they had been told who this man was and what it would take them to watch his performance on any other day.

If you’re looking for feedback, simply showing a prototype and explaining WHAT the app does is not enough to gain constructive feedback, unless you’re already speaking with a potential customer. The same goes for pitching to potential investors. More often than not, investors will not know about your target market, so the onus is on you to tell them the WHY and HOW parts of your idea.

I used do to a lot of design back when I was in college. I used to obsess over pixel perfection. Often I will show someone a finished design and ask them anxiously “Do you see anything strange with this?”. The reply would be “No it looks great!”. In my head, I will be thinking, “Maybe it’s just me who notices that the second heading is a trifle large and sticks out from the rest of the page”. I used to spend hours perfecting the copy, fonts and colors.

When I stepped into the working world – that’s when I learned the fine act of balancing between perfection and getting things done. Depending on what your job is, being a obsessive perfectionist can be either a blessing or a curse. However, more often than not it’s a luxury. While one appreciates the extra effort spent on going the extra mile on something, often the value one gets out of trying to achieve near-perfection is exceedingly small. Once deadlines are upon you, you’re forced to compromise on your lofty goal of striving for near-perfection.

Over time, I have learned to accept, embrace and love imperfection. I don’t suggest that we should all just settle for mediocrity. But it’s important to understand that perfection is a journey and not a destination. Imperfection is shipping things. Imperfection is getting things done.

These days, when I look at something that barely does its job but is neither elegant nor pretty, instead of feeling disappointed, I feel happy that it’s out there helping me do something. Perhaps somewhere else, someone else is toiling away, trying to perfect the same contraption, but will never launch it.

Hyperbolic? Perhaps, but probably not too far away from reality, as I see so many talented hackers work indefinitely on their side-projects without ever launching them. If you’re one of them, stop obsessing and start shipping.

These were some of the reasons why I hated statically typed languages then:

• Verbosity – the presence of a type system meant that I needed to type more
• Difficult to prototype
• Compilation – time spent on waiting

Over time, not only have I learned to appreciate languages with good type systems, I actually now prefer them for solving certain classes of problems.

Java and C++ (the languages through which I experienced static typing) are not the best representatives of statically typed languages. It’s only after I started diving into Scala, did I start discerning between good and bad type systems. A good type system should not get in your way and should definitely not make you type more than it’s necessary. I have also been dabbling a bit with Go and Rust, and I’m excited about how productive I feel in both of them.

Type inference goes a long way in saving keystrokes, but a powerful type system can offer much more than that. For example, let’s take Scala’s structural types:

  def speakWith(animal: {def speak: String}) = println(animal.speak)
 
  class Dog { def speak = "bow!" }
  class Cat { def speak = "meow!" }
  class Man { def walk = "walk!" }
 
  speakWith(new Dog)  // "bow!"
  speakWith(new Cat)  // "meow!"
  speakWith(new Man)  // compile error

Structural types [1] eliminate the need for an abstract class or an interface/trait. I can simply define a function speakWith which takes an argument (animal) which is of type {def speak: String}, i.e. any object that has a speak method defined in it.

I have heard arguments that such a type system is complex for the average developer to grok. I used to be one of them, but I’m now convinced that most of this talk about complexity comes from forgetting that there is a learning curve for any tool. One is bound to be unproductive during that time.

Contrary to conventional thinking, I actually find statically typed languages to be good for projects that undergo a lot of churn, either because the problem requires an experimental approach or the requirements are hazy (as with the case with a lot of start-ups). Although it’s much easier to start hashing things out in a dynamically typed language, I noticed that as the codebase became larger, it becomes much harder for me to feel confident about the various changes I was making without the presence of proper tests. And, tests are painful to maintain when there is a lot of churn happening. Static typing does not replace tests, but it definitely catches a lot of stupid errors and makes refactoring code really easy. Apart from better IDE support, you also get the confidence that when the code compiles, you can be reasonably sure that atleast syntactically things are alright.

With respect to compilation time, Go is pretty fast even when compiling large projects, but the same can’t be said about Scala (C++ is also notoriously slow). However, using a SSD has helped a lot, atleast in absolute time. Still, even if the compilation phase robs me some time, it’s a trade-off I’m now willing to make if a statically typed language gives me better confidence about the correctness of my programs, eventually leading to less time spent on bug fixing.

A few years back, one big lure of Python or Ruby used to be the functional constructs that they offered like higher order functions. However even Java has now caught up, with Java 8 introducing lambda expressions and an enhanced collections API. Hence, moving forward, I believe I will find very little reasons to hate static typing as much as I used to. It’s really exciting to see how languages like Rust and Scala approach type safety without compromising on productivity. I’m going to continue to use Python, Javascript and Ruby where it makes sense (either because of the community or the libraries), but dynamic typing is no longer my number one reason to use them.

[1] – thanks to Mushtaq for introducing me to Scala’s structural types.

You can follow me on Twitter right here.

To be truthful, the first few times I had to pick-up a new language, I was not particularly thrilled about moving outside my comfort zone. Wading through a new language and some unknown framework was pretty daunting. It slowed me down significantly, and as someone who likes to get things done, it was not pleasant struggling to remember how to express my logic in an alien language. Over time, I have become a lot better at quickly getting up-to-speed with new toolsets, and on hindsight, I’m glad that I have been able to create meaningful things with all these languages. I don’t profess to have mastered all of them, but every language that I have learned has opened my mind and challenged the way I approach programming.

Just as my dad’s friend said, I don’t get mixed up between all these languages in terms of their syntactical differences. When I write Python I indent and when I write Java I curly-brace. What is however difficult is writing idiomatic code in each language. Imagine creating a AbstractSingletonProxyFactoryBean class in Python. You don’t want to be that guy, especially when working in a team with experienced Python developers.

It’s not easy being a Roman in Rome, though. Inevitably, ideas and concepts from one language affects the way you think and they percolate into another. I have been writing lots of Java lately, and I did not realize until recently that I’m not writing what I have commonly observed to be idiomatic Java. Here are some quirks:

• My classes tend to have lots of static methods. This is a direct consequence of too much functional programming. I definitely find programs that have less state simpler to reason about.
• Business logic is hence sometimes encapsulated in such static methods, rather than through the use of proper models which contain both state and logic.
• When I split a large static method into a bunch of smaller ones, I almost exclusively pass the arguments in a way that’s not unlike a continuation-passing style (which is how I write JavaScript).
• For classes that serve merely as data containers, I make all their fields public rather than using getters and setters on private fields. In the same vein, I sometimes forget to declare private methods as private – too much Python.
• When possible, I try to even avoid creating such data containers, and instead preferring the use of Maps and Lists.
• Heavy use of finals, probably influenced by all those vals from Scala.

I have mixed feelings about some of the observations above. In many ways, they definitely have made my programs robust, but probably at the loss of some idiomaticity. To be fair, I also think that idiomatic Java code can be pretty idiotic so I hope that gets me some brownie points.

I general, I would like to follow what I will call the party rule. If someone else is hosting a party, I try to turn up in the correct dress code (so long it’s not ridiculous like wearing some abstract proxy factory bean). If it’s my party, I get to define how the classes shall be dressed.

You can follow me on Twitter right here.

By now, most people tuned-in to the lean start-up bandwagon already know about the importance of hitting the market first, iterating quickly on a product and so on. If you’re building something for just testing the waters, it really does not matter if your tech stack cannot scale beyond 100 concurrent users. It also does not matter if you don’t test-drive your application, or if you borrow a free theme or use Twitter bootstrap (still beats enterprise software by miles). Scaling problems might eventually plague you in the future, but from experience, that’s often a happier place to be than convincing folks to fork out their cash for something that they don’t need.

Whenever someone writes a rant about a technology that they are having pains with (hello MongoDB), I pause to ask myself whether the author is trying to use a knife to chop a tree, as more often that not, most rants expect something to be fast, simple, elegant, horizontally & vertically scalable and also help them paint rainbows in Sahara desert. In reality, that doesn’t work, and a lot of people do know it. Yet, somewhere along the way, we get so vested in our tools that we expect it to dynamically grow with our application needs.

It’s hard to dispute that repeatedly failing at something tends to increase our chances of succeeding at it. This is the basic premise of Gladwell’s 10,000 hour rule of success as well: over time, we learn from our mistakes and get better.

There is however, one more aspect of repeated failure that’s a lot more subtle, and worth mentioning here: repeated failure helps us understand what it takes to succeed, and in the process even redefine the notion of success. Success is a fairly arbitrary term, and in a complicated field of work, it’s usually not very easy to define it in an isolated, cut and dry fashion. We also tend to have multiple goals, often in conflict with each other. For instance, you might fail to solve a simple problem, but in the process partially solve a different problem, having far greater impact on your other goals. Or you might even realize that you did not in fact want to succeed at what you wanted for various reasons. Both of these have occurred to me in the past few months.

While reflecting on the talk, I realized that the actual problem here is that people take OO too far. I don’t know how OO is taught elsewhere in the world, but from my own experience, a large part of this abuse can be attributed to the way OO is preached in various CS courses. A lot of emphasis is placed on grilling into young heads the virtues of OO and it’s place in the big enterprise world, without actually explaining why OO works when developing large applications. And, do courses on OO actually highlight when it does not work?

In interviews, when asked to solve a tricky problem, I find it disturbing that people immediately start off with skeletons of classes. It has become some kind of protocol that one should be modeling everything in classes and objects to come off as a competent software developer. Jack shows a succinct solution to Conway’s game of life problem. A solution that highlights the programmer’s knowledge and elegant use of Python’s yield, but which will probably be rejected as “poor procedural code” in a lot of places.

In many ways, OO has become a safety belt. By having a few classes, atleast no one can fire you for writing procedural code right? If poorly written procedural code is death by repetition, poorly written OO code is death by multiple levels of insane abstractions.

One technique that has worked for me when solving a problem from scratch is to first actually solve it by using functions that perform highly specific operations. As the solution evolves, I start identifying fragments of code that can either be pulled into a separate class for better abstraction or moved from one class to another. This way, my code moves towards object orientation based on actual need, rather than because of a hypothetical high level “modeling” of the problem. This way, I also don’t end up with a class like this:

class Foo(object):
   pass

Simply because I (hopefully) would have felt stupid refactoring something, anything to that.

The users defeated the system in the following ways:

You can contact me off here – jack sp 1967 at g mail (all in one address).

Take the first letter from each of the following words: please don’t count rabbits because they increase everyone’s expectations at great mayhem and internal lost dot clouds over mountains.

When we were implementing the email masking functionality, at one point, I was wondering whether we were going overboard in coming up with all kinds of ways to break the system. In fact, I’m sure I even thought, “Huh, these are probably non-technical folks, so we don’t have to go to really convoluted extents”. Boy, was I wrong.

My favorite exploit included sending the email address using NINE separate messages:

r 
w
a
1
t
at
gmail
dot
com

I’m sure even if we had spent two more weeks on the masking feature, we wouldn’t have been able to catch that one!

NOTE: the above messages do not of course contain the actual email addresses of the users.

When creating a new remote branch, here’s how you can make your local branch track its remote branch:

# creates a new local branch
git branch foobranch  
 
# creates a new remote branch, and makes local branch track that (-u)
git push -u origin foobranch

If you want to set-up tracking for an existing branch, you can do so by:

# set-up tracking for an existing branch
git branch --set-upstream foobranch origin/foobranch

If you are checking out an already existing remote branch, you can set-up tracking in a single command:

git branch --track foobranch origin/foobranch
 
# or, alternatively
git checkout --track origin/foobranch
 
# or
git checkout -b foobranch origin/foobranch

Setting up tracking offers two advantages. Firstly, it reduces the number of characters you have to type to push your changes to a remote branch. More importantly, it prevents you from accidentally typing git push which will end up pushing out the local commits in all your other branches as well (which you might not be ready to push yet!).

Of course, you can also set-up tracking by directly modifying your .git/config file!

This post reminded me of a client for whom we were designing an interface to record eye readings. The client, being an opthamologist himself, was extremely vocal about how the entire user experience should be. He wanted an interface in which you can enter eye readings by clicking on a series of buttons that had various prescription numbers. He showed it to a few people and they felt that it was fairly easy to use – everything was obvious and lucid. I had some reservations in taking a mouse driven approach, and just as I had suspected, this really ended up slowing down people who were using this interface over and over again. What seemed intuitive and having zero learning curve eventually turned out to be pretty slow and cumbersome for regular and repeated use.

When designing user interactions, one should balance the long term productivity goals of a active user and the apparent immediate ease-of-use of the system for new users. Kevin Fox had recently written about how Google seems to be “simplifying the UX for current users at the expense of the new user learning curve”. I’m sure Google had reasons for doing that, but nevertheless, it’s not trivial to optimize a user experience for both new and power users.

On the other hand, there are also lots of applications that treat all their users equally. In reality, user behavior and engagement changes over time, and so do their needs. Yet, run-off-the-mill analytics software only offer a broad picture of user engagement. This is where cohort analysis becomes useful.

A cohort analysis is a tool that helps measure user engagement over time. It helps UX designers know whether user engagement is actually getting better over time or is only appearing to improve because of growth. – Cohort analysis – measuring engagement over time.

With the help of cohort analysis, one could evolve the user experience to make it more productive the for power users, while at the same time, making it easy enough for new users to get going with the system. We already use graceful degradation as a strategy for enhancing the user experience in modern browsers, while still not completely dropping support for people with older browsers. I see optimizing for productivity the same way – user interactions should offer alternative hooks for the power users to exploit without making the external interface complex. A good example of that would be the spotlight tool on OS X. It stays out of the way, but it’s still just a keyboard shortcut away. A well-designed, modern command line interface can really complement the graphical user interface.

Finally, while designing interfaces, one should be making decisions based on facts and data, rather than gut feeling. I will end this post with another anecdote. We’re currently trying to convince a client to get rid of the confirm email address field in their signup page. In addition to making the user fill an additional field, the current form also prevents the user from copy pasting their email address from the previous field. When we asked the client why they are doing that, they replied, “We don’t want our users to accidentally endup typing a wrong email address”.

This is a classic case of trusting the gut blindly, and it’s clearly not the best way to build a user interface. They are pissing off a lot of users, while all the time thinking that they are actually helping them.

You can follow me on Twitter right here.