Page 1 of 1 in the ProgrammerSkills category
# Tuesday, 30 April 2013

User Experience (UX) seems to be quite the hot topic now, everyone seems to be talking about it. And all of a sudden instead of just saying “Let’s think of a proper User Interface (UI) for our web application!” People start saying “Let’s build a great UX!” Cause as you should already know, anything with the letter X in it sounds cool! (Why else would Apple not want to learn to count to 11?) To me UI and UX are somewhat similar, whereas UI only applies to software you can use UX to explain anything that involves a user. ie. Physical shopping flow.

As a programmer, you might think that designing the UX is a job for the designers and the client. Then you’re dead wrong, the designers might be able to paint a great picture for the client to see but that’s just half of the job! Who is responsible to make sure that the design can actually have data bound to it? Who is the one that has to be the voice of reason and mention that you can’t just bring down the whole product database JUST to make a *seamless* scrolling experience?

The programmer! Who else?

So when you’re working on that next big thing, the following pointers should help you make a positive contribution to making a great UX for your application/web site/whatever.

If You See Yourself Hating The Use Of It, It’s Probably Done Wrong.

The first most obvious rule is that if you look at the proposed UX and the only thing you can see is how painful it would be for you to use it, it most likely not a good idea to begin with.

Don’t Design A UX For YOURSELF, Design It For the USER!

This might sound like it’s conflicting with the first point since it’s mentioned that you shouldn’t hate using it, but it isn’t. Cause the first point states that you mustn’t HATE using it, I didn’t say you must fall madly in love with it!

Most of the time, everyone would think that they’re designing the UX for the CLIENT (I’m talking from the role of an ISV here) That the UX is supposed to meet the client’s requirements. WRONG! The client’s most important requirement is always make something people want to use. Always keep that in mind when making your UX, but how do you know what’s the best solution for the user? Do you conduct usability testing? Customer interviews? Well if you have the time and money that’d be great! But most of the time you wouldn’t, so you go for the next best thing.

You make up your users.

This act of creating personas isn’t anything new, people have been doing it for a long time in the creation of various things. I don’t actually practice the creation of named unique personas, but rather one of the concepts in the use of personas which is :-

Know who your users are and what they’re capable of.

If you feel that your website is likely to be used by tech savy people, then maybe you can put more effort into your search capabilities since they’re more likely to use it to find what they want.

Or if you feel that your users are more of the browsing type, then you need to put more effort into designing the best way to rub promotions in their face or make it more likely for them to stumble upon it.

Ends CAN Justify Means

Sometimes there just doesn’t seem to be a way to make something have a good UX, the process might take too many steps, or a form might have too many input boxes, or maybe the data source you’re validating the user’s data against just isn’t fast enough. You client keeps hounding you over the various internet articles that say how every extra SECOND in processing results in HUNDREDS of lost sales, this problem was described by an article my colleague once forwarded to me as “The worry that every one of the users have an attention span of a squirrel” Instead of trying to argue how it doesn’t make sense that one SECOND can give HUNDREDS more sales, the question that should be asked is.

What is the end result of this flow and how important is it for the user?

Because depending on the results, the user WILL be compelled to jump through all the hoops of even the worst UX in order to reach the end. The best example to give is the online plane ticket website AirAsia, I find that the UX can be vastly improved since it’s unpleasant and complicated even for me. And yet everyone uses it because the end result of a cheap air plane ticket justifies the means of having to slog through a poor UX. Let’s not even talk about what happens whenever they have one of their crazy sales!

Another fictional example is of course, if you told your users that they’d have to finish a test that needed 2 hours to complete in order to BUY an iPhone at 25% of the price would they not be willing to do it? Even if you’re told that the scenario isn’t comparable to what you’re trying to achieve, the point is that users are willing to take extra effort if the end is important enough to them.

And that’s enough for this time around.

Tuesday, 30 April 2013 22:16:06 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Wednesday, 06 June 2012

I came across a very interesting blog post today, important enough for me to decided to repost it here.

How To Stop Sucking And Be Awesome Instead

One of the key points is that you should stop being afraid of sucking if you want to be awesome.

And this is a VERY good point. Too often do I see programmers who can't come out with solutions just because they're afraid that people might think it's a stupid idea, that other people might look down on them if their idea didn't work out. They keep walking down that path and they'll never gain any extra experience because learning from our mistakes is surprisingly effective.

A programmer should never be afraid of making mistakes or that worrying if their code isn't the right way to do something. In programming there are many paths to achieving a solution, and if you don't have the guts to walk down those paths you'll never know which one was the best one.

When other people come to me for advice on something and I see that they're about to fall into a hole based on their attempted solution, if the situation allows it I'll always let the person drop into the hole first. After which I pull them out and ask them to think about how they got to that point and discuss about the alternatives available, I find that this helps instill the lesson a bit more deeper.

Wednesday, 06 June 2012 23:03:44 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Thursday, 30 October 2008

Microsoft's PDC conference is happening right now and already a boatload of announcements have been made about upcoming technologies, platforms and overall cool shit coming from Microsoft.

WAAAAAY too many to mention here so check out the official site at

Thursday, 30 October 2008 10:03:54 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Wednesday, 15 August 2007

So you want to be a programmer? Or more importantly you want to be a GOOD programmer! I'm sure there must be lots of articles out there on the Internet about what makes a good programmer. But I thought.. what the heck, let me put in my 2 cents as well.

This is all my opinion only, and it's definetly not THE final word on what skills and attributes a good programmer should have. So let's start with the most important attribute every programmer should have :-


Just like any other job, and most importantly like any other occupation where something is created out of nothing. You must be PASSIONATE about what you're doing. If you don't derive any amount of satisfaction or joy from your job, you stop caring about doing your best and start over looking solutions that are staring at you in your face.


You might be wondering of course I can read, how else can I be reading this? I'm referring to the ability to read and understand the error messages that are throw out by the compiler or the runtime that your programming language uses. I've been in countless situations where I'm asked what is wrong with a person's code when the solution to their problems is right there staring at them in the face. Take an effort to read the error messages properly and then when you solve the problem remember the situation that caused the error in the first place so you can avoid making the same mistake again.

It's OK To Make Mistakes

Nobody's perfect, it's ok if you made a mistake while your coding. Don't be afraid to make mistakes, but always learn from them so you don't make the same mistake again. I have seen people who are just plain worried about hitting the RUN button cause they're afraid that their code wouldn't work. This rule only applies if you're not doing stuff on a production system when important client data is stored, in such cases IT'S DEFINETLY NOT OK TO MAKE MISTAKES!


I'm always amazed at the fact that they just don't seem to teach students how to use the various debugging tools which are at their disposal. Most of the freshies I've soon have never set a breakpoint, or used a debugging window before. If you're studying programming right now, do yourself a favor and go Google Setting A Breakpoint. Once you know how to debug, you're on your way to being a better programmer.

And that's it for now, stay tuned for more on this TAG!

Wednesday, 15 August 2007 23:40:13 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [1]  | 
Page 1 of 1 in the ProgrammerSkills category