The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
This reminds me of the argument between a husband and wife. She was talking about mixed feelings, but her husband insisted that the concept was nonsense, because everything was ultimately positive or negative.
"Out of all your friends", she replied, "you have the biggest dick."
If it's the start of a project then face to face.
If it's a major or monthly update and I'm in a senior role then usually video conference.
If it's a major or monthly update and I'm not in a senior role then I'm usually not involved.
Day to day stuff via email, very rarely use the phone for anything, it's much better to have unambiguous communications and a paper trail
If the client company has hot women then face to face. Always face to face.
Mostly via a support team so I never have to meet the actual clients. All clients for all projects are in-house (I work for a county government) so I rarely meet clients - although I have for some smaller projects.
- I would love to change the world, but they won’t give me the source code.
That depends, how far away is the client, how much needs to be discussed, how important is the discussion, how well does the client pay...
I prefer face to face, but I prefer not spending hours in traffic even more
For me it's almost always phone/email/remote desktop.
I handle frontline support for the software I develop and 'rent/lease' to clients around the US. Over 20 years this now includes 2 major desktop apps, the 100 or so add-on modules/utilities that support them, and around 2 dozen web applications.
Devs dealing directly with the clients may be uncommon, but I believe it has benefits for both parties.
0: The developer gets to practice their people skills.
1: The client gets a direct line to the person who can most likely fix/improve something.
2: The developer sometimes gains domain knowledge.
3: Products improve quickly to eliminate those annoying client phone calls.
Regarding #3, this has been the biggest driver for me...to lessen the length of time I need to be on a call/remote to find and fix a problem. To this end, our main products have some really nice support features for submitting and receiving files for troubleshooting/fixing problems:
a: downsize/zip/upload feature for our managed sql server users to instantly post a customer database. The downsized file is in Access format. Our apps are agnostic (for the most part) so it's possible to stay online with a client while I download and hookup to his current database to find a problem.
b: download/run script files. The main apps also have the ability to download and run script files for anything from automating imports, to fixing a specific problem, to pre-configuring a new module.
c: easy to use updaters.
Having an automated deployment chain here is essential. It has occurred when an issue has been debugged, fixed, recompiled, and redeployed, (signed/sealed/delivered), and downloaded in < 10 minutes without leaving the remote. Stupid mistakes happen, but are dealt with swiftly!