A few weeks ago I started a series on Reasons Why Your Developer Hates You. Check out the first post and others to get some ideas on the reasons I’ve brought up. Today is reason #5 why your developer hates you: “we don’t like when you make us do work”.
I got this statement from a developer colleague & friend in what I thought was a joking manner. And I think it some respects it was meant as a joke, but then when I started thinking about it further it made a lot of sense. I don’t think the phrase, however, captures it all.
We’ve gone through several different reasons why your developer hates you, and those all contribute to today’s point, which I think is a very valid one. Think of it from a UXer’s perspective. You’ve been a part of this team, done a ton of work brainstorming, contributing ideas, forming strategies and solutions and then, after finding at least some success you move on to a different focus. Out of nowhere you get an email or call…. “I need you to update the *insert deliverable here*. Bob thinks that we should do XYZ instead.” There are many different examples for what I’m trying to demonstrate, but basically someone, somewhere has decided that the solution that everyone has agreed upon needs to be changed. This can be a good thing in our view if it’s based on user research, new information, etc. However, when it is based on opinion or “gut feel” then it’s extremely frustrating.
I’m going way out on a limb with this one, so developers *please* provide feedback. But I’m assuming that this is parallel for developers. How so? This is a little bit harder to grasp, but as we’ve talked about before, developers have standards & best practices that they follow in their field as well. When we come to them with a change that is based on opinion (even if it is not our own) then it screws up the whole vision they have for their solution (sounding familiar). This is causing more work yes, but it is also causing “useless” work. Work that will need to be redone later on to improve this solution, which was put in place to improve another solution, and so it goes. But if we brought forth a change based on system research (i.e. I think this will decrease page load by 1 second based on this article) I don’t know that there would be this overall feeling of “stop making me do work”, because this work would not be “useless” but would prove helpful and be based on some sort of background and knowledge.
The idea that someone is mad because you make them work is valid, but not someone who’s hugely talented like my friend that proposed this idea. There has to be something there that isn’t contributing to the greater good that makes someone feel put out.
So I would love to hear thoughts on what you think it is… developer or UXer or both. Why do developers, better yet talented professionals in general, hate when you “make them do work?”
Great feedback indeed. Definitely some interesting views that you touch on. I love the dichotomy you mention between the two. This gives me some great information to reflect on.
Thanks Chris!
I’ve had the benefit of working with, training, and being trained by many developers over the course of my career as a designer/developer — I can honestly say that I have met some of the best and worst developers out there.
There are two types of developers in my opinion: good devs, and lazy devs.
Developers in the first category invest themselves in the conceptualization of a solution; plan their efforts complimentary to the strategy; and execute the final product as efficiently as time and budget allow — even going a few steps further to future proof or optimize their work. That is a mark of an excellent developer.
On the other hand, developers who fall into the second category tend not to contribute to the solution; tend to assume they already know the solution to the problem before hand, and dismiss the concepts/fundamentals of the project out of hand; and execute their personal vision of the solution independently (and often poorly). These are the characteristics of a developer who prefers to be a roadblock to successful project.
The most effective means to differentiate good from lazy is in how the developer(s) in question handle change (which is indicative of their investment in the project).
Let’s face it, change is work — especially in the middle of a project, and it affects everyone involved to some degree (some more so than others); however, change can be a good thing. Where developers are concerned, change can mean the difference between creating a solution that is more efficient and ultimately reduces later work, or it can result in more work depending on how invested the developer is in the approach.
If you’re dealing with the latter of the two types, you may find a high level of resistance to change. It either means that the developer has created a solution to the problem independent of the strategy (roughly translated: “my way is the right way…”), and any changes render their solution obsolete; or it could mean that they simply don’t have the desire to invest time into an effective/efficient solution (roughly translated: “don’t make me work…”).
The bottom line here is that if your developer “hates” you, it is either because they haven’t been invested in the conceptualization of a solution, or that they don’t care to be invested in the solution.
As for myself, I would rather work with a developer who wants to be invested in a solution, than one who I have to lose sleep over.