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?")
But please review this e-mail (and I'll keep the typos):
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.
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
"Hey man- I just saw it this wknd - not really sure I understand it"
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.
Well not exactly, I skipped over:
"Merge pull request #31 from ASoft-se/bugfix_get_assets"
"Clone in Windows"
"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.
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.
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.
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.
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:
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.
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.
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.
"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.
Agreed, but regardless of who's at fault with the lack of communication you still won't WANT to work with them. The concept being that you should want to do your work and be happy, so fix your communication problems regardless of who's fault they are.
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? :)
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".
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.
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?
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.