Beyond Technical Excellence, What Are The Key Characteristics Of An Awesome Dev? (And How Does UV Train Its Dev To Ensure Awesomeness?)

When looking for a developer, the usual questions on the top of the potential client’s minds — and what interviews usually focus on — is their technical excellence. 

Technical excellence is, of course, a fundamental requirement when looking for a good developer.

But there are a few other key requirements that are important to articulate. Today we’ll look into one in particular — a second requirement, tied with technical excellence — which is the “how” to work. This “how” is often and easily forgotten and overlooked for a few reasons. It’s hard to quantify. It’s hard to pin-down what makes it great or not. When we focus on the “function” it is too easy to forget the importance of the “form”, especially in contexts like businesses that have serious and important objectives. If you’re trying to achieve a complex goal, form without function or function without form is a recipe for failure.

This article will attempt to articulate the “form” — the “how” to work — that UV looks for in its senior developers, while simultaneously training in its junior developers. And there are two hearts of the “how” in our approach (when viewed separately from the technical requirements of the work itself).

The first is the “how” to respond to requests from a client, partner, fellow-developer, team leader, or anyone else, really: the heart of the “how,” in our approach, isn’t just to “do it” but to prioritize strong communication — including the clarity of communication, the frequency and repetition of it. And the heart of good communication is knowing what questions to ask, and when to ask them.

Here is a good example. When getting a request from someone we work with, whether big or small, before just jumping in and doing it, we tend to ask questions like the following, (the sorts of questions we ask not just to the client but to each other):

• “When you said X, it could be done in two different ways; so, did you mean X1, or X2?”
• “Your request will have the consequence of Q, which you may not realize, because it’s subtle and technical. How do you want to deal with Q?”
• “I’m not sure if you realized how complex your request is. I’m happy to do it, just bear in mind it will take so much time that it will stop all the other tickets from happening for that long period. Are you sure it is the top priority?”

We ask questions like this to have a back and forth to force the person you’re working with to really think through what he wants done, in order to maximize the chances that the work achieves the objectives. The “form” is the communication: to know when to ask questions, and what questions to ask.

(There’s the extreme of asking too many questions. We try to find the right balance. One of our favorite strategies is to make assumptions and share them — so there is no excuse to delay the action and no annoying question to ask; but that gives the client or fellow team member the option to suggest a different course of events. “We’re planning on implementing X by doing X, Y, and Z. We’re assuming this is fine and just let me know if you’d prefer another path.”)

The second “how” is thinking through the subtle consequences and non-obvious implications of what we need to do or what is requested of us to do. This adds in a layer of “thinking one step ahead”. Remember Hamlet’s observation that what separates man from beasts is the ability to see before and after? Yes, we do, too.

Let’s do another interpretation of these same three example questions: what they all have in common is that they are adding a level of insight on top of the original request. It’s often impossible for clients to have such a level of insight, if only because they will (definitionally) not understand the technical systems we’re using as well as we do.

To do these requires the understanding of the client and his/her business, understanding of the technology, strong communication skills, a long-term oriented way of thinking. Without all those, you can’t push back in smart ways (so you either don’t push back at all, or you push back in superficial and unimportant ways). But inexperienced developers usually can’t do this either — if only because they lack the experience and sophistication to know what to ask. To quote my favorite movie, Groundhog Day — an endless source of wisdom! — “Maybe God has just been around a long time and knows everything”: in other words, just having the experience to have been around and seen everything allows you to understand complex things very quickly (because you’ve dealt with the nuts and bolts of similar things before, theme and variation). And in our world, amazing software developers do indeed have god-like powers.

This is why, in the UV way of working, we pair junior developers with senior developers. Every team has a very experienced Technical Lead who pairs with less experienced developers to guide them and ensure their wisdom and experience seeps into every aspect of the project work.

An excellent example of how UV uses these two “hows”, these two “forms”, is this one phrase that our developer Marco Perez once used with me, and indeed I even wrote a whole article about: “Let me see how I can make it easier for you.”

Also, note a bunch of assumptions implied in the above. We believe empathy is important, and to do those two well (such as in the three sample questions), you need an empathic approach towards understanding the client or the person you’re working with. We believe respect is important, and thinking about and asking the other person about why they’ve asked us what they have is a deep form of respect.

These two “hows” are important for two reasons.

First, this sophisticated way of working significantly lowers all project risk. By working through little assumptions, implications, and consequences of every request, it has the result of removing a huge portion of the project risk. Why? It removes the vast majority of the element of surprise. There will be no surprise system crawl because we decided earlier which trade-off to make as soon as we realized there would be a trade-off. There will be no surprise “Oh why didn’t you do X?” because we realized that with Q, we’ll also need X, so we planned out if that should or shouldn’t be done.

The second consequence of this is a huge savings in management time — particularly the time the client needs to spend managing us. Being able to ask ourselves these questions is the heart of self-management. Micro-management and significant management time comes in precisely when the people you work with do NOT ask themselves these sorts of questions, to think through the implications and consequences of what needs to be done. Thus you need to do it for them (or if you don’t, a disaster likely ensues!). But by having this approach, we’re able to be one step ahead, on a consistent basis.

There are other details that UV looks for in its developers beyond those listed here. But excellent work and excellent communication are the sine qua nons of how UV works, the atria and ventricles of the UV heart.

PS: UV is one of the world’s leading Salesforce Commerce Cloud integrators. Contact us to see how we can work together.