Hacker News Reader

Comment by nerdfiles | Hacker News Reader

I really, really do not wish to come off this aggressively, but are we following the reasoning: mentioning github > probably a bad writer/should re-assess abilities to communicate?

Really?

View on HN

I don't think "mentioning Github" is the only piece people are using when deciding to question your communication skills. The word "microcontroller", except in certain extremely specialized situations, should probably not be used with a client. I understand it's a hard pill to swallow. I mean, you're both speaking English. Why does it seem like you're not speaking the same language?

In a way, you're not speaking the same language. Try assuming your clients have no concept of not just programming, but any of the process of building an application or solution to a problem that uses technology. Don't discuss details. They are probably paying you so that they don't have to worry about the details.

By way of example: I have the reverse problem with my wife. She is a nurse. When telling me about her day, she used to fly through a great deal of technical details using an amazing number of acronyms and abbreviations that I found not just unintuitive, but completely incomprehensible. I genuinely care about how her day was, but I found myself exclaiming in exasperation, "I have a clue what any of that means!" She now explains only what is necessary to get the point across, and defines acronyms as she goes along, if necessary. That works, but, in your situation, I'd abstract my communication at least one more level than that.

Think about it from the client's perspective - using Github issues might be your preferred way of tracking the changes he requests, but it is unlikely his preferred tool. He just wants to email you the changes he wants and have them made - the implementation is not his concern.

As soon as the client feels like he doesn't understand what you are saying, you stop becoming a problem-solver and start becoming a problem. In addition to whatever responsibilities he has on his end, now he needs to try to figure out what you are saying. The key to a happy client is removing problems from their plate.

Here's a different way to communicate the same things as your original email:

    $CLIENT, you mentioned that you wanted a few changes 
    to the content of the site. If the changes are easy
    to describe, you can just email them to me and I will
    take care of it. Otherwise let's sit down/have a 
    phone call about the changes.

    I've also done some research into the digital 
    signage that we discussed. I found an option that 
    will cost $30-$40 per sign, is that within your 
    budget? I can present all the options I've found 
    at our next meeting.

Notice that I tried to avoid any deep technical details (e.g. after you email me the changes, I will add an item to the bug tracker and do feature-branching to implement the changes then deploy to the staging server). My version is not perfect either, but I think it would be better received.

I read your version, and I get an entirely different gist than what I got from reading nerdfile's for part 1. I thought he was talking to the customer about using version control. In your version I get issue tracking. I've had both conversations (issue tracking & version control) before with non-technical people.

An easy thing nerdfiles could have done was to attach the email in question. In that situation, there's no need for the client to dig through their emails to find something they may or may not have deleted, may have ignored, or had end up in their junk folder. Then you can trade out "If you did not receive it, please let me know" with "I've attached it for your convenience".

Reply on news.ycombinator.com