10 Dec 2013

Don’t take it personally

I have been noticing that people tend to feel hurt or sometimes, even insulted, when they’re robbed of an opportunity they thought that they truly deserved. When something doesn’t go in our favor, we tend to blame the “biased” system.

However, most systems are never perfect and are only designed to function well for the majority of the people. To put it another way, systems are often designed to scale. You might be an exception and have every right to feel disappointed to be hard done by the rules of the game. But, don’t take it personally.

No responses

/
tagged with:

1 May 2013

Importance of context – takeaway from Dustin’s post

I came across Dustin Curtis’s latest blog post on how he first thought of Pinterest and Vine as stupid ideas. There is plenty of discussion on this at HN, but I wanted to add one more view point that seems to be missing from the discussion.

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 expressed 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.

No responses

/
tagged with:

7 Apr 2013

Embracing imperfection

Quite a large part of our life revolves around things that are functional, but seldom polished. These things used to bother me. I don’t have OCD, but I equated the rough edges that I saw in things with somebody’s half hearted attempt at something.

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.

1 response

/
tagged with:

24 Feb 2013

The comeback of static typing

I used to loathe static typing. From PHP to JavaScript to Python to Ruby, I was pretty much a dynamic typing fan boy. I was working primarily on web applications with very straightforward business logic using frameworks like CodeIgniter and Django.

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.

25 responses

/
tagged with:

26 Jan 2013

On being a Roman in Rome

When I was 12, I remember asking my dad’s friend whether he gets mixed up between VB, C and Java, all of which he used at work. He had replied saying, “No, you just have to spend enough time on all of them”. Many years later I find myself in a similar position, having spent the last few years writing significant amount of code in Python, Scala, Java, Groovy, Erlang, JavaScript and PHP. I don’t have a programming language fetish – I just found myself moving from one project to another at work and happened to learn a couple of them for my side projects.

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.