Hacker News Reader

> Freelancers' careers live or die based on where future work is coming from. Happy clients are good for repeat business. Happy clients refer other potential clients. Happy clients are good for portfolios or case studies. Smart freelancers are all about keeping their clients happy in the long term. It's just good business.

Not a freelancer, but this is a classic "market for lemons" situation: designing things for the long term takes a significant amount of extra thought and expertise. If two freelancers give two different quotes, one of which has a higher hourly rate and will take a longer time, there are one of two possibilities:

1. The more expensive quote is way overpriced, trying to extract money out of the buyer and possibly double-dip

2. The cheaper one is a low-quality "cowboy" job that's going to cost way more to maintain in the long run

If buyers in general can't tell the difference, then the market will end up pressuring even the high quality people to cut corners and produce "cowboy" jobs. In other words, it may not be 100% the freelancer's fault they're "not interested in the long term unless forced".

So part of the job of a "wrangler" is to understand what's worth investing in and what's not -- to know that it's worth spending double in this particular area because it's a long-term win -- and to be able to evaluate the output of the work, to make sure that what was delivered actually is higher value.

If buyers in general can't tell the difference, then the market will end up pressuring even the high quality people to cut corners and produce "cowboy" jobs.

There are enough buyers who can tell the difference. Good freelancers just gravitate towards good clients and vice versa.

In practice this simply doesn’t pan out. There are many many terrible freelancers out there. And without someone technical in-house vetting their work, you’ll have no choice but to judge their based on their output. This is a huge problem.

Software needs to be designed with an understanding of the business needs and goals. You need someone who understands how to keep the software well designed (ie. Easy to debug, update and extend in the future).

Judging solely as a user of the software gives you no insight into whether or not a plate of spaghetti code could be holding behind the scenes.

Good code has two traits: It does the job it was designed to do. It is easy to update and maintain.

Everything else you read online is nonsense. And you need someone trusted inside your company to ensure the second trait is being adhered to.

In practice this simply doesn’t pan out. There are many many terrible freelancers out there. And without someone technical in-house vetting their work, you’ll have no choice but to judge their based on their output. This is a huge problem.

Why? There are many terrible everything out there. Eventually you are always relying on the quality of your developers' output and their honesty in explaining it whether they are hired as employees or working freelance.

Crucially that is as true of the technical in-house person as the outside freelancer. I've seen scenarios with my own eyes where an experienced freelancer was better - sometimes much better - than the in-house "senior" people but the latter made critical reports about the freelancer to management. Maybe they were defensive because someone better than them was brought in. Maybe - and I suspect this is more likely in at least some of the situations I'm remembering here - the in-house person was so far below the outside freelancer in ability that they simply didn't realise how much better the freelancer's work was than their own or understand the reasons the freelancer was following certain good practices and the risks they were mitigating by doing so.

So my question to you is this: Why do you believe you can trust someone to evaluate the quality of the work more accurately and honestly just because they are inside your company?

My experience as an in-house dev working together with freelancers and body shops (in Europe) is less positive.

A pattern I commonly see is that they are heavily technology focused and don't really care about the domain, because domain-specific skills are not transferable. They are snake-oil salesmen, every problem can be solved by adopting some hot new piece of technology which can be added to their CV and increase their market value. What's frustrating is that their contribution is in the end often negative rather than merely zero - adopting over-architected solutions looking good on CV will result in great costs. If you have a strong technical leadership, you can catch their bullshit, but in the op's situation, they would be pretty much relying on freelancers' good will and abilities without much of a chance to verify their claims.

To be fair, I've met also a number of very good freelancers, usually staying with the company for years.

This same danger exists also with the normal employees, but I think this "pad the CV, move on" is more common in freelancers since they generally operate on shorter timescales.