Fire your bad customers
In the past, being an independent consultant for around a decade, I let 2-3 clients go.<p>One of those, letting the client go turned out to be a huge mistake, since the reasons turned out to be a temporary blip.  In so many words, the great executive later returned, some things that were concerning&#x2F;unacceptable while the exec was away were presumably reversed, but I&#x27;d already moved on.<p>Another, they just had an unsalvagable massive mess of a code base that an undergrad made, and they didn&#x27;t appreciate how bad it was, and that it needed more than incremental work.<p>Before and after the regretted cut-loose client, I also didn&#x27;t take on at least a few clients who I had misgivings about.  Some of those were probably due to once-bitten, twice-shy.<p>Some problems I&#x27;ve learned to avoid, and I&#x27;ll phrase them here as positives (I&#x27;ve found both the negative and positive examples):<p>* Clients who realize they need more than a low-end programmer.  Like many people, I have a lot of experience working higher-end than that,<p>* Client respects you as an expert or competent professional.  That doesn&#x27;t mean they defer to you automatically.  What you want to avoid are situations like someone key at the client thinking they always know better, on all topics.  Which is a not-unusual phenomenon.  One version to avoid is when they are the expert on all things, and they think they&#x27;re only hiring worker drones to save time on things they know better on.<p>* Client is intelligent and constructive.  If they&#x27;re saying technical things that don&#x27;t make sense, and when you attempt to discuss, to understand and possibly inform, you hit a brick wall, then you might have a lot of brick walls in your future if you take them on as a client.<p>* Client has enough money, is willing to spend it on you, and looks like they&#x27;ll have enough money for a while.  Complementary to this, I of course wouldn&#x27;t take a contract like, say, someone self-funding a startup, and no matter what I did for them, it didn&#x27;t look like they&#x27;d be viable.<p>* If client is a CS-ish professor (which I bump into probably more than most, since I have a fondness for some aspects&#x2F;ideals of universities, and live in university neighborhoods)... Only take the client if you can find a situation close to that of a colleague of mine: works with a PI who respects him as both skilled and as a collaborator.  It&#x27;s not uncommon for a CS-ish professor to think they know more about practice than practitioners, and they get some (misleading, incestuous) validation from others in academia.  I respect professors by default, and some are close friends, but egos and inaccurate perceptions about the world outside academia seem not-unusual.  Also, universities are accustomed to cheap, captive labor (except for select higher-ups, and sometimes endowment hedge fund managers).<p>* Watch out for the casual oracle (I don&#x27;t know whether there&#x27;s an existing term?), and also be careful not to be the casual oracle.  By which I mean a decision-maker has a friend or someone who they keep going to to check things you tell them, and this person overrules you.  Normally, this would be fine, especially as a discussion, but what I&#x27;m talking about is like a rogue doctor, who diagnoses patients without ever having examined them, talked with a doctor who has, or even glanced at their ED chart, yet ends up overriding the actual doctors of the patients.  I&#x27;ve seen this a few times firsthand (in tech, not with doctors), so it seems to be a thing, and I also had a friend once quit over it.  If it&#x27;s a thing, I don&#x27;t know whether it&#x27;s only an artifact of not respecting the person doing the work, or something else.  A few times, I&#x27;ve also realized that I was being asked to be the casual oracle, and I tried to be humble and qualify, but now that I recognize this thing, I&#x27;ll be even more careful.