Why can’t developers just speak English? – A guide to intra-nerd communication.
Communication is the single most difficult aspect of any development process. It can literally cost millions of dollars. Most of the people who can’t write a ‘hello world’ statement that have to tell me what to program think the problem is that they need to understand more about my job. They hear a couple of us developers get into a room and swap intimidating acronyms and phrases like ‘refactor query methods’ and ‘extrapolate abstraction layers’ and think that what they need to do is understand this gibberish. I don’t know if I could truly relate to the reader how terrible this notion is. Please, if you don’t understand what your programmers mean when they talk about ‘instantiation’ and ‘parsing’, don’t try to understand now. Remember, a little knowledge can be a dangerous thing. You want to back as far away from that as possible, or you might as well just pour kerosene into your wallet and light a match. We simply want to know what you want to do, and what you want to happen when you do it.
What did you do, and what did you expect to happen.
The phrase “what did you do, what did you expect to happen” was a product of a meeting between several of my co-workers and I as we were trying to determine a way to phrase the instructions of a bug report for a web application that would minimize such infamous bug fix requests as “site broken”, “doesn’t work”, and “numbers wrong.” None of which are even requests.
Of course, the biggest catch is asking a user to ‘repeat’ what they did. They get asked that a lot, and the responses may sound reasonable to all of the non-initiated, but to us geeks getting that information is exasperating to the extent of promoting suicidal thoughts at best. Computers don’t think like us. They take everything so absolutely literal it can boggle the mind of the technologically naïve. Computers don’t make sense to most people. Even those trained to communicate with computers will frequently lose control and shout at their monitors. The most staunchly religious conservatives I’ve seen who work as web developers will stand up and shout shocking threats at inanimate objects that make me feel nervous, and I have an awful reputation of running my mouth like a sailor in front of the most sensitive folks.
So there was some understandable skepticism that these instructions would promote a user to give us the information we needed. But when people came to us with troubleshooting requests and we asked them to do what they did again and tell us what they thought would happen were unlike anything I had seen before. I could actually, for the first time, understand a client. For the first time I knew what someone really wanted. I felt like I had struck gold, found Avalon, and then rode a unicorn.
It’s not a question, it’s a new philosophy.
So it came to pass that I was in a meeting with four other individuals asking me to do something that seemed to make sense to all of them, but when I asked for some clarification they all looked at each other with some silent question which, from the looks on their faces, I could only assume was “how do we stop this alien monster from sucking all intelligence from our brains?” The answer, of course, is to tell the antisocial alien with the creepy beard and magnifying lens glasses exactly what you want to do and what you want to happen when you do it. I finally understood, this wasn’t just a question that was helpful to getting a user to tell me what they did to break a web application that successfully passed all of my unit tests, it was a concept that I had to practice allowing to pervade all of my thoughts as I communicated with non-developers in order to understand, and make myself understood. The question itself may not be much, but keeping that vision in mind has changed my experiences with evaluating requirements with people who still refer to the internet as “the email.” What’s more, as I evolved in my communications with clients, so did they. They came to understand what I expected to hear from them.
This new philosophy in understanding what a client wants transcended the concepts that I had previously held regarding web development. The client hates the development process. They don’t want the development process to be easier; they want to buy the product like they buy a stapler from an office supply store. What’s more, we already know what clients want to do, and what they expect to happen when they do it. And yet so few people are able to deliver a single product that delivers on this expectation to their clients.
Where this change in thinking has taken us.
Lexy Sites can handle all of the needs of 90% of the clients I’ve developed a website for, but every blue moon a client needs something very specific, and if they want to get it as cheaply, quickly, and accurately as possible I hope this advice helps. First, focus completely on the user interface. This is the furthest you can get from 1’s and 0’s that your developer is going to actually understand, and the closest you can get to writing computer code that you will understand as well. Second, be as clear as possible as to what you expect to happen for all use cases with the user interface. Clients are particularly bad about assuming their expectations are obvious, and developers are particularly bad about understanding how things in a company work beyond the user interfaces of the software they develop.
Communication always takes time and effort. There’s no way around that, and it is particularly difficult to communicate to a developer if you don’t know how to write computer code. Just remember that the furthest away from the computer’s logic that your developer is likely to understand your business is the user interface, and so the battleground in the war of developer-client communication should focus almost entirely on the expectations of the user interface.
