[ryanianian]

Yes. And how to build it. I worked with a brilliant but rather lazy contractor once. His code was unmaintainable despite him being obviously competent. His rationale was very explicitly that maintainable code doesn't make for good job-security. You don't want to be held hostage by your own code.

[vsareto]

These guys can be goofballs and only appear competent on the surface. Referrals can be job security as well, and you won't get referrals if you intentionally write bad code.

In other cases, it's skilled people that just don't want to apply 100% effort and are just coasting, maybe for external reasons (some folks can write decent code without 100% effort in the moment due to practice beforehand).

[onemoresoop]

> You don't want to be held hostage by your own code.

If your code is unmaintainable you become hostage to your own code because making changes breaks things, causes frustration, etc

I totally get the idea of job security if you’re maintaining a codebase that only you understand but that is very likely to bite you back quite badly, especially if you’re a contractor: you may not get any new work, the code you write is very visible and can be judged quite quickly by a qualified person

[JohnBooty]

Yeah.

There are obviously times when you can truly "write yourself out of a job." That truly happens.

I think that there are far more times where a transparent and earnest approach to managing technical debt and keeping things maintainable for your clients leads to more work in the long run. Possibly even permanent employment if that's what's desired.

(Of course, this depends entirely upon your communication skills and the client's savvy and receptiveness to such an approach)

Because the usual reality is that any client who needs consulting work in the first place is certainly going to need more of it in the future - maintenance, iterations, new projects, etc.