Contributed by: Anand Hariharan (Director of Engineering, Clarice Technologies)

Anand has over 10 years of hands on experience with software development and delivery from concept to release. Prior to joining Clarice, he worked at Symantec Corporation, and helped architect and develop high availability solutions and other enterprise software. He joined Clarice to work on consumer software and has built and mentored teams within Clarice to deliver solutions to customers. His interests are traveling, photography and music.

Years ago, I started on my first job without an email address to my name. Six months into the job, I finally managed to create a free email account with Hotmail. I was elated to be part of the small community of internet users in India, so I wanted to coin an appropriate signature for my emails. After thinking long and hard, I came up with: “Will write code for food”. Yes, that’s right, I am a programmer at heart, and I will write code for food.

Clarice is a company that places significant importance on User Experience (UX) of the product. Naturally, our website reflects this. Prospective hires that visit our website keep asking me: “So you build UIs? Is that it?” The question is quite honest, but it’s the underlying thinking that gets to me each time. In many of their minds, user interface programming is best left out of the resume.

The perception that UI programming is for the faint of heart while “I save the world with my Servlets/Spring/C++” is very prevalent among our fresh graduates. It is this attitude that I feel needs to be addressed, because it demonstrates a thinking pattern which is not conducive to learning and innovation. Someone unwilling to try all types of job descriptions would also probably hesitate making that interesting but radical change which needs you to explore alternate possibilities and step out of your circle of comfort.

Some of the most interesting problems I’ve faced and solved involved user interfaces. If you want to learn threading, try writing a responsive user interface. I guarantee you, by the end of the project you will know threading as well as anyone can. I had this exact problem early in my career, where a team writing a simple database migration tool wrote some code that would display a dialog box during the update. The problem they had was that the dialog box wouldn’t update the text on it during the process. The dialog would just be displayed blank and would repaint only after the complete database update happened (which took around 5 minutes to complete). This problem was being ignored by the team (and the client!). I was called into the project to help with finishing it up, and I came across this problem. I still remember how fixing this little problem cemented my understanding of threading and why the problem happened in the first place. The fix was simple, but the learning rewards were tremendous.

A co-worker recently updated his IM status as follows: “I hear and I forget, I see and I remember. I do and I understand.” Profound. Reminds me of something I keep saying to my team-mates. “Karoge nahin toh kaise samjhega?” (How will you know if it works or not unless you try it?). The short message I wanted to put out was: “Try it before you reject it”. Naturally, people have different strengths, but if you don’t test yourself how will you know? My personal experience with UI/UX work has been extremely satisfying. I can say with conviction that the UI/UX exposure that I have had at Clarice has taught me things I may not have learnt in the next 10 years working on software without a focus on UX.

All that said – strive to be a person who provides “solutions”. At the end of the day, answering “Yes” to “Can you write a Servlet/Entity Bean?” or “Can you write me a multithreaded server in C++?” is much less useful than answering “Yes” to “Can you solve my problem?”

For the technically inclined, here are professional skills I have learnt in the past few years due to Clarice’s UX focus and being a UI programmer:

Understanding the Customer:
I learnt how to put myself in my customer’s shoes. How to understand what prompts the customer to request something we think is bizarre.

Feeling the Pulse of the Product:
I learnt how important analytics are to the product the hard way (by not building it in). What is the most used feature? What causes users to abandon their train of thought? What features should we invest in for the future?

I learnt how important it is to simplify tasks for the user. How important it is to have the user focus on one thing at once. How to make assumptions about things that the user may not need and validate them with analytics.

Keeping Customers Interested:
I learnt that it pays to add things iteratively; not only from a development and delivery standpoint but as a tool for user retention in the consumer world. Customers like it when there are updates which add much needed features, and more importantly, they love it if they suggested it.

A user interface is the first point of contact between the client and the product. The best software products can be rendered useless if the human interface is missing. To me, I have learnt that user interfaces touch lives, and make a hugely positive (or negative) impact on the success of the product.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>