hurried freelance feet
Couple of thoughts on freelancer's rush to jump from project to project
First of all, I want to apologize, dear subscriber, for the previous email. I said that you will be prompted by Substack to subscribe when I imported all the subscribers over here. Substack didn’t prompt you, but subscribed you immediately. If you want to leave you can always unsubscribe by clicking the link at the bottom of these emails. If you are not a subscriber yet, you can always subscribe to get more essays like this straight in your inbox.
Freelancers change clients and projects often, but there’s a ton of value in sticking to a project as it gets traction1. People that switch too soon are removed from accountability: they lose skin in the game by not staying long enough to bear the costs of their short-term decisions.
This is one of the reasons why dealing with technical debt or thinking about performance is not a priority for most freelance developers, as they have never experienced what a lot of debt or poor performance can do to a project.
They are incentivized to switch because switching a client usually means a bigger jump in compensation than what could be achieved at the current client. Switching clients every six months instead of sticking to a single client usually produces a big difference in a bank account in three years, as one can usually negotiate a much higher raise than 3-5% yearly at a single client.
Another reason why this is not a priority for freelance developers is because thinking about debt or performance is rarely a priority for leadership, as it is usually prioritizing palpable features instead. Thinking about maintenance and sustainability often means thinking longer-term than even the leadership, which is often most concerned about chasing lucrative exits in a couple of years or even months. Senior developers know that project’s exposure to reality introduces entropy, so if this entropy is not dealt with the project gets less enjoyable to work on as time goes by. The reason for thinking long-term like this is usually selfish: they just want to keep enjoying their work on a project.
There is tension between leadership that usually only prioritizes shipping new features and senior developers who want to write sustainable code. The only people benefiting from one developer’s code quality improvements are fellow developers, who often don’t care that much either, as they are busy shipping new features as quickly as possible.
In most companies, developers who ship new features are promoted, but those that maintain or optimize them are invisible, although maintenance or optimization often requires more skills than shipping the first unpolished version of a feature. Building new features is more palpable to the developers as well, so they feel more valuable doing so. For most developers, a day spent building features is usually more gratifying than a day hunting down the cause of a performance issue or a bug that shouldn’t have happened in the first place, and is sometimes even fixed before anyone at the company notices. There is what I call The Rescuer Effect2 at play as well: developers that introduce problems and then publicly fix them are appreciated more than developers that prevent problems from happening in the first place and never introduce them. Another incentive for short-term thinking.
As freelancers jump from project to project so quickly, a lot of companies regard them as lower-quality developers. Constantly building greenfield projects is not challenging enough, so their skills are not on par with developers that have been dealing with harder problems that arise afterward. What doesn’t help either is that these greenfield projects often don’t get any traction at all, so freelancers end with CVs filled with projects never having any users or being dead after they have left. Which is another reason why a lot of companies regard them as lower quality.
Our dopamine-craving brains seek novelty and that’s another reason why switching projects or clients is so tempting. Freelancers usually love greenfield more than brownfield, but brownfield can often more greatly improve one’s skills.
Thanks to Stanko Krtalic and Mateja for reading drafts of this essay.
The definition of “freelancer” is someone who switches projects and clients often, so by sticking to a project one would cease to be a freelancer and that would be very valuable to one’s skills.
If you know about an existing name for this effect, please let me know in the comments below.