

Ask HN: Impossible client? Impossible playing field? - nerdfiles

I'm running into an issue, I s'pose, that seems related to the "curse of knowledge." Everyone tells me in response, "You know too much about the details, etc." But is this really the case? I sincerely wish to ask HN for the fact that I am losing my mind. And it seems to indicate a larger issue, related to the fact that most people literally respond with shock and almost fear when they see me work at my Terminal or vim. I'm afraid to work in public now, honestly, since doing so brings about so much bloody negative reaction. (All of my clients have been this seemingly difficult. I'm starting to worry if I can even work in this city. Months back, say in the summer, a lead developer at cPanel responded with confusion: "What is SASS/LESS/etc?")<p>But please review this e-mail (and I'll keep the typos):<p>To Client,<p>Also, did you go through my last e-mail regarding github? You mentioned changes on the site, and github would be he easiest way to keep track of those changes. It would also ensure that we are on the same page. Please review that e-mail. If you did not receive it, please let me know.<p>I have also looked into digital signage solution that are cheap. We are looking at rough $30-$40 per sign to run a small microcontroller system that can manage those displays. Here is a link to the idea: https://github.com/wireload/screenly-ose<p>---<p>His response?<p>"Hey man- I just saw it this wknd - not really sure I understand it"
======
vitovito
Maybe you're talking with nincompoops.

But maybe -- and perhaps more likely -- you're just a terrible communicator.

Perhaps you have genuinely poor written communication skills, and are
incapable of holding a conversation without the proper social cues that non-
programmers or other coworkers need to feel like you're not exerting your ego.

Communication skills, social skills, soft skills, they are _all skills._
They're not things that necessarily come naturally to people, and they're
things you can practice, and things you can get better at.

I can't think of one good reason to have a casual conversation with _anyone_
and mention GitHub. The only situation is if I'm a GitHub salesperson, or
we're having a very non-casual conversation comparing tools.

Those aren't normal conversations. GitHub is not a tool that normal people
use. Suggesting it to someone who is not a professional developer demonstrates
a complete lack of understanding of your audience, of their skill set, of
their engagement level, etc.

By definition, being a developer takes you out of "normal," so you're not
really well-suited to judge how other people are receiving you. This is why
you feel like it takes "large expenditures of energy on my part" to talk with
them. When, strictly speaking, _no-one has to talk with you._ Talking is
_entirely about the other person._

Growing up, I did speech contests, which teach you how to present and how to
deliver an argument and how to articulate your ideas well in a short span.
Something like Toastmasters would help you practice that today.

That doesn't help you social situations, or in professional relationship
building like business requires.

A friend of mine has a coworker who is socially rude. The coworker constantly
interrupts, and their voice gets higher and higher pitched and they talk
faster and faster when they think you're not "getting it." The problem is, all
the senior developers "get it," he's just so enamored with his idea that he's
not seeing the practical issues. The coworker is really looking for agreement
and praise, not discussion and critique; his statements are leading, and his
questions are rhetorical.

My friend finally sat this coworker down and explained how he needed to learn
how to act like a normal human being having a normal human conversation. My
friend now physically intervenes in conversations and points out every
instance of verbal malfeasance, and the coworker is learning to control
himself and convey his ideas reasonably, to think before he responds, and to
actually consider someone else's perspective for once.

This friend, years ago, would stand over my shoulder and edit my emails with
me.

My friend doesn't scale, but maybe there's someone you trust -- not a
programmer, a normal person -- who can do things like edit your emails for you
-- that's what _editors are for_ \-- and who can shadow you in conversations
and talk with you about them afterwards.

~~~
vitovito
I think it's telling about the audience here at HN that no-one, in a set of
threads about communication skills, called out that my second and third
sentences were positively and unnecessarily _brutal._

Some commenters may say, well, we see the overall point and agree with it,
those two details could be overlooked.

But, the whole point here about empathizing with the client, is that _those
are the two details that matter._

I could have structured this argument a little differently and been much more
positive (a compliment sandwich, they call it) and lost none of the impact.

~~~
GFischer
You're right in that your second sentence was unnecesarily harsh.

However, the third one didn't strike me as so brutal, but I also agree that
the beginning could have been worded better.

This reminds me of several discussions on how many people with some
characteristics of aspergers/autism are bad communicators because they're
worried about being right and not about the other people's feelings - and
believe that saying what they consider to be the truth doesn't offend.

(I'm searching for some interesting articles on the subject, but I didn't save
the links and now can't find them).

I have very bad communication skills myself, that's why I found Carnegie's
points about other people's feelings so important (others might find it
obvious).

Edit: I also think that most people in Hacker News are more inured to
criticism, or able to take it better, and so might be harsher themselves - or
not think it wrong when someone else is harsh like in your case.

------
brudgers
You and your client are two people separated by a common language.

I followed your link to Github. This is the first item:

    
    
       "Improved scheduling with jQuery-based time/date-picker.
       Removed secon"
    

Well not exactly, I skipped over:

    
    
      "Merge pull request #31 from ASoft-se/bugfix_get_assets"
    

Plus:

    
    
      "Clone in Windows"
    

And:

    
    
      "Branch: master" etc.
    

If I'm your client, do you really think I want to deal with that? If I'm your
client do I even care about that level of detail?

There are some sausage factories which are interesting, architecture is
generally one for which people love seeing the process of creation. Most
aren't, as your experience using VIM in public attests.

Your client cares about a few simple things: when it will be done, how much it
will cost, and what it will do. If your email explains those details it will
be successful.

The fact that your client saved trying to understand your solution for the
weekend indicates meaningful effort on their part, but it's not surprising
that they are baffled by Github. It's not for lay people.

Good luck.

------
JamieLewis
As mentioned by vitovito your problem is most likely effective communication.

Take this post for example, there is very little structure, the main points
are clouded by seques that don't lead anywhere, here is how I might have
written it instead:

"Hi everyone,

I have been encountering a problem with several of my clients, both past and
current. It seems they become intimidated whenever I start discussing anything
vaguely technical e.g. Version control ala GitHub.

Have any of you come across a similar problem in your line of work?"

It might be worth taking a class or at least picking up a book on
communication, presentation and debating which should cover many of the
problems.

On a separate issue you posted an excerpt from an email. It seems t be that
the client would not be requesting information on version control for a
website (although that may be the case) - in my experience this is probably a
query regarding content management in which a CMS would seemingly be a better
fitting solution - this should be taken with caution as I do not know anything
about this client and so could be completely off course.

------
codegeek
As others are pointing out, I think your issue is being able to communicate
effectively. But then, you might ask what is effective communication
especially in your context? Clearly, your client is not as tech. savvy as you
might want him to be. So instead of mentioning Github directly for example,
you need to think about the end goal that you want to achieve. In your
example, I believe you wnat your client to agree to use Github for tracking
the code changes, communication etc. But instead of saying that directly, you
could say "Hey as you mentioned that the site needs periodic updates, I
propose using a tool that will reduce the time and error to put a fix and
update your site regularly. This tool is available online and can be accessed
both by you and me anywhere through internet. We can do it without this tool
but it will increase the time to make changes to the site and ultimately cost
you more"

Now you have given the "what" to the client and not the "how". The "what" is
thte importance of using the tool (github) but you don't want to say that
directly. The client will see that you are giving them an option to reduce
their risk/time to update the site which is the end goal, not github. Github
is just a medium that u decide for the client.

The next question from the client could then be "Ok so what would it take to
get this tool up and running. how much? how long? " But now, you are already
half way through.

------
SkyMarshal
My first instinct is, when a client doesn't know what Github or something like
that is, just use it and teach them later if you must. For issues like this
that have relatively limited downside, better to ask forgiveness than
permission and just get on with it.

Regarding his response, that usually means call him and explain it in a
conversation. Hackers tend to be email-oriented b/c it's asynchronous, but
many business people tend to be phone-oriented.

Short terse emails like that where they don't elaborate on why they don't
understand or ask any followup questions tend to be a strong signal that
they're not email people. So just schedule a call and explain instead.

------
orangethirty
Anytime you have communications problems just do the following. Tell them "Hey
$name, I'm really focused on getting this project done the way you want it.
But I seem to have misunderstood some past points. Could you refresh my
understanding of the goals we have to work towards? Thanks!"

They will either:

\- Ask you what your doubts/issues are.

\- Make up their minds as to what the next step is.

* Or fire you. :) Either way, you dont want to work with people who you cannot communicate with.

~~~
chris_dcosta
"Either way, you dont want to work with people who you cannot communicate
with."

Don't agree with this at all. There will always be non-technicians who you
have to communicate with. If you can't express what it is you need to
communicate in non-technical language it is _your_ problem, not theirs.

i would rightly fire someone who refused to at least try to make an effort to
see it from my point of view, and continue.

~~~
orangethirty
What I meant is that he should not work in places where communication is not
important. Meaning companies where there is a culture of them versus us. Of
course its important to be able to communicate to non-technical people. It is
a required skill. So, can I have my job back? :)

------
nerdfiles
First mail:

I can still work with any site content or typographical issues until we meet
next (which may be after I heal over the weekend). So I should be healed up
before next week.

We can collaborate on the minor issues of the site using [link to issues page
for repo] or we can collaborate through e-mail. This way we can have a digital
paper trail.

The link to github is also available on the bottom footer of your site. I use
github to manage my development of your site, so it may be beneficial to
become familiar with its issue tracking system:
<https://github.com/blog/831-issues-2-0-the-next-generation>

Github's issue tracking system has become much celebrated, and issue tracking
itself is a very important part of developing sites.

------
nerdfiles
Mentioning anything like github or modern tools, on average, puts me in a
position where I am either shocking or apparently showboating in a
conversation. Everything is testosterone, and my mild speech impediments make
it next to impossible to converse with people without large expenditures of
energy on my part.

I'm honestly at wits end, as is obvious by the organization of this post.

It's not schizophrenia, but over the past year, it has become markedly clear
that I am the only person I actually can talk to... Maybe I'm just in the
wrong crowd. Or maybe the crowd is too small?

~~~
xauronx
How has your life changed over the past year? In reading some of your comments
and replies, you seem kind of defensive. I know it's kind of natural when
you're getting picked apart by your peers, especially in this environment (a
generally respectful crowd). However, I would consider that some of the
communication failures with your clients (whether your fault or theirs doesn't
matter) might be caused by insecurity. I've known a lot of programmers in the
past who were naturally insecure people and this manifested itself in
conversation. Where they would say "Yes, I'll set up a cloud based solution
with redundant storage and a jquery front end" (and feel a bit of satisfaction
about sounding smart) I would just say "Yeah, I'll get it done and send you a
login". After a year of working, everyone came to me internally with issues
instead of the guy who's been here for 8 years.

Anyhow, don't get down on yourself. It seems like you're in a frustrating
situation in general and you tried to air out one grievance to get some
relief. Unfortunately it appears to have frustrated you more. Just realize
that a lot of people here are trying to help. Also, no one here can fix your
client so naturally they're going to concentrate on the only thing they can
help fix: you. You might have to go out of your way to accommodate your
client, but that's why you get paid right? If it isn't worth the money then
stop taking jobs with non-technical clients.

------
nerdfiles
How do I track issues then? I sent the link to the issues page.

What is all this sexy and intuitive UI for if I cannot even mention it? Github
repos look just like file folders in most GUI OSes.

~~~
vitovito
This is a good example of what I meant when I wrote, "talking is _entirely
about the other person._ "

"How do I track issues" is almost irrelevant, because _it's not about you._

It's about the client.

What is the easiest, most comprehensible way for _the client_ , whoever they
are, whatever their level of schooling completed, wherever they live, to tell
you what they need to tell you, whatever that may be?

Making them comprehend an issue tracker (which is a term only programmers use,
normal people don't think of themselves as having "issues" which they need to
"track"), which regardless of the GUI that GitHub built, is still constructed
atop a system designed by _someone who writes Unix kernels for fun_ , is not
that way.

Maybe that way is, they call you on the phone and explain it to you for every
issue. Maybe that takes up too much of your time, so they call your secretary
and you call them back once a week and do a big round-up.

Your job as a consultant is to _figure that out_ and provide it. It's not to
write code. That is secondary to _being able to relate to someone's business
problems._

~~~
nerdfiles
Then I should scratch the CMS, github, and only contact him by phone for
typographical and content issues.

I see now. Thank you. With luck, these experiences will be very much
transferrable to other projects.

~~~
GFischer
I've already recommended it above, but I'm going to reiterate the suggestion
of Dale Carnegie's How To Win Friends and Influence People.

It's even available online :)

<http://erudition.mohit.tripod.com/_Influence_People.pdf>

------
nerdfiles
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?

~~~
swanson
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.

~~~
caw
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".

