Sunday, April 29, 2018

On what makes a great software developer

I was reading through some software questions on Quora this weekend, and came across one that asked 'what makes a poor software developer'.



One thought crossed my mind right away as I read through complicated answers detailing minutiae about how to write code. And my thought had nothing to do with a developer's literal ability to write code, and everything to do with how they feel about writing code.

In software, or in any other complex skill, what differentiates those who reach the upper echelon of their field, and those who don't, is interest.

Interest is the key. If you have a genuine interest in software you'll be motivated to learn more about it, and if you're motivated to learn more about it, eventually you'll become a great developer.

Think back to Wayne Gretzky's famous childhood when he'd spend hours upon hours skating on the rink in his backyard. The kid loved to play the game, and that love of the game translated into practice, and that practice translated into skill. Or look to Roger Federer whose childhood was much of the same, translating into great ability.

There are no shortcuts to becoming great at anything besides practice and hard work. Natural talent helps, but natural talent can only take you as far as your mind is willing to go. In other words, there is no way to practice a skill consistently enough to become great at it, unless you actually want to do so.

And so you'll find that the one common denominator of great software developers is that they like what they're doing.

Saturday, April 14, 2018

Is empathy the missing link in user experience?

Some happenings at work in recent weeks have got me thinking about UX and empathy. It's been oft-repeated on blogs and websites, but it's such an important, maybe critical, point that I thought it worthwhile to put some more words on the topic out there.



In my view one of the major disconnects in the software industry is the gap between programmers sitting behind a computer and the real world impacts of the code they write.

What you often see in an IT department is this: a programmer gets a work order from a business person, a tech lead, a manager, or someone else in the hierarchy of their work place, like a signal passed down from the business Gods. They then spend some time understanding the work before hurriedly getting it done and moving on to the next thing.

In practice the programmer's time is spent on a treadmill where work is only looked at as a barrier between two states: in progress and complete. This is where the disconnect lies. Success is measured in terms of what's completed, rather than how well the end user is being served.

The issue here is that a developers job isn't to write code, it's to write effective code. And writing effective code means providing the customer with what they need. And so in practice the primary role of a developer is to understand what their customer wants, and then only secondly actually build it.

This is where empathy comes into play. Empathy can be defined as the ability to understand and share the feelings of another, but taking the poignant connotations out of the term it can be described as 'understanding another'. To build effective software a developer needs to take the first step of understanding their customer: what their wants and needs are, what their level of understanding is, what jobs they need to get done, what it is that they're actually going to do with the end product.

Imagine you've just shipped restaurant software to production. Your testing went well and everything worked as expected. Then your manager schedules some time for you to view your product in action.

Suddenly, when viewing it being used you notice how ineffective what you've built actually is. Waitresses are struggling to figure out your interface, and the restaurant is experiencing lower productivity because the assumptions you've made aren't quite right.

While at the restaurant you're seeing the experiences of your users. Their struggles with your software, how badly they want a better working system. All at once the real world impact of what you're writing is front and centre. No longer is your work order just a vague description of implementation details, it's something real that is going to affect real people.

And so empathy acts as a simple, but powerful heuristic when building applications. If you develop without thinking about the real experience of your end users, what are your decisions premised in? Granted, there are sometimes other things to consider than user experience, but if your main job is to support your user: you should look to them first.