3 ms·
I've been freelancing and doing contract work my entire career - nigh on 13 years now. There's a mass of things I could tell you, but I'll try be succinct and t
by mdpm 15y ago
I've been freelancing and doing contract work my entire career - nigh on 13 years now. There's a mass of things I could tell you, but I'll try be succinct and tell you what I think will be most valuable.
Technology doesn't pay the bills. Clean code, good architecture, solid frameworks - they count far, far less than you wish they did. As developers, we're systems oriented, looking for the ideal approach, the 'right' way. 90% of clients are more worried about the right shade of cornflower blue. Don't lose your idealism about making use of the right tech stack, and where pragmatic, don't miss an opportunity to explain why it's important.
But don't make the mistake of thinking that's what counts for clients. There will be exceptions, but generally the guy with the purse strings isn't technical, and is in no position to appraise your use of tech.
You need to practice business as much as you plan to demonstrate technical competence. Negotiation, selling, conflict resolution (it'll happen), knowing when to walk away (that too) and probably the hardest thing - embracing risk. Many chant the 'fail fast' mantra, but I'd rather point out that our caveman brains are badly suited to accepting that risk is vital. Cold calling is terrifying, as is naming a price, telling a client they're wrong, and so many parts of simply staying alive.
Otherwise, go make some luck.
- StavrosK 15y agoThis is accurate. Depending on your situation, clients appreciate getting things done. A very good client of mine doesn't care what I do, as long as I get it done. It might take me three hours to research how a given legacy PHP CMS works just to do a simple code change, but as long as they can come to me with something and be sure I'll have it done at a not-too-great cost, even if it's not my area of expertise, they're happy and I'm happy.
- HSO 15y ago> Technology doesn't pay the bills. [...] Don't lose your idealism about making use of the right tech stack, and where pragmatic, don't miss an opportunity to explain why it's important. [...] generally the guy with the purse strings isn't technical, and is in no position to appraise your use of tech. You know, I've never understood this line of argument. The way I see it, the client is either clever enough to see technology really is not important to the problem at hand or too dumb to realize it is. If the former, you'd be guilty of overengineering and missing your client's objective (by being too costly, too complicated, etc). If the latter, why would you care to explain and "do the right thing" (the client will not pay for things he doesn't know are important)? There are many technical people who feel underappreciated by their clients or management peers. I think the only solution is to find out if the wizardry really is needed in the first place; if it's not, do the minimum (if you accept at all); if it is, then let the bozo fail and either compete (you know something they don't) or leave for a better client/customer/mgmt. Will pay better and you get to keep your sanity and pride.
- mdpm 15y ago> If the former, you'd be guilty of overengineering and missing your client's objective (by being too costly, too complicated, etc). If the latter, why would you care to explain and "do the right thing" (the client will not pay for things he doesn't know are important)? Too often developers do what we see as 'right' technically, which is not necessarily 'right' for the client / project. It's not something to be 'guilty' of, just something to be aware of. Although there is a balance - I've often fought for things and had them save the client's ass later. And as for explaining why something is important - because the client should have an appreciation for why they hired _you_, not someone else.