Don't ever disparage another developer. As a rule, this is true whether freelancing or working full time, and it makes you look worse than it does the developer you're targeting.

Imagine that you've taken over an existing project. You're poking around the codebase, and you see something that raises an eyebrow: maybe there aren't any tests, or naming conventions are inconsistent, or their controllers have been stuffed a little too full. Maybe the last developer just approached things differently than you would have.

You meet with the client to share your assessment, and you start to feel a little tug, an urge to stick the knife in: "Your last dev really kinda screwed you over by not writing tests."

It can be tempting to use that last developer as a common enemy, their perceived incompetence a threat that brings you closer to your new client. (Agencies often do this, especially in competitive markets.) But let's review what's really happening here:

1. You're Explicitly Attacking Someone Who Can't Respond

When you do this, you project insecurity by throwing punches at folks who aren't there to defend themselves.

It may be true that the work isn't where you believe it should be, but you also don't know the constraints that your predecessor was fighting. Time crunches, shifting requirements, inconsistent client feedback, personal issues outside of work: it might be a miracle that they made it as far as they did.

But even if it's not, your client is paying you to move their project forward, not to cast judgment on what's already been done. Prove that you're a better developer by being a better developer. Make a plan that achieves your client's goals and efficiently execute that plan—don't complain about decisions made before you joined the project.

2. You're Implicitly Attacking Your Client's Judgement

Criticizing a past developer's work means that you're also implicitly criticizing your client's judgment. At one point, your client hired and trusted that developer—and maybe even liked them personally!

If your first move is to highlight all the things that the last developer did wrong, you also imply that your client was wrong to trust them and should've done more to evaluate the work as it was happening. That may not phase some folks, but many more will take it as a slight—especially those clients that come from a non-technical background.

3. You're Setting Your Project Off on a Negative Foot

At the start of a new relationship, you have an opportunity to instruct your client on how you'll communicate with each other. By setting a positive, constructive, and forward-looking tone, you'll quickly establish a foundation of professional trust. This foundation will carry you through the life of the project—and will put you on stronger footing if you do need to have a difficult conversation at some point.

By proactively inviting negativity into your relationship, you undermine that foundation. Complaining begets complaining: the more prevalent that dynamic is, the more you risk having it turned against you.

This dynamic, to be clear, does not mean you need to soften feedback, avoid conflict, or misrepresent the state of the code to your client. (Jason Lerndorf has a tremendous article on the importance of clear, direct, sometimes-uncomfortable feedback in building trust.) It's a difficult needle to thread, but you can be honest about—and respectful to—the work that came before you.

Here are a few examples of ways to reframe feedback you might want to deliver:

Each of these examples is doing three specific things:

• They look forward. You acknowledge the current state of the project—and where you can improve—without casting judgment on the decisions that brought it there.
• They all focus on value. Your client likely doesn't care about tests; they care about a stable, bug-free experience so they can make more money. They don't care about DRY code; they care about developer efficiency so they can spend less money. Frame your recommendations using your client's interests, not your own.
• They deliberately use the first-person plural. Phrases like "we can" and "our project" re-enforce the fact that you and your client are on the same team, moving towards the same goals.

Before you start any new project, take a moment to remind yourself of this reframing exercise. It's a subtle shift in thinking but will ensure you set that new project up for success.