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.
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).
> 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
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.
2. for non-trivial/long-lived projects, figuring out how to build it in a way that makes scaling, iteration, and maintenance something other than a total nightmare. (of course, many projects are one-off projects that don't need to be engineered for the long haul)
(Product) managers decide what to build. Engineers decide how to build it. You make it sound as if software engineering has no value. Clearly this isn't true as small local banks will have awful sites and apps despite the problem statement being pretty clear cut. The most successful tech companies also happen to be the ones that have attracted the top engineering talent. Generally, ime, an engineer you pay $150k is worth more than two engineers at $75k.
> Product) managers decide what to build. Engineers decide how to build it.
That’s not how software is done though.
Product managers are in a constant negotiation with engineers to decide what to do. There is a lot of back and forth and exchanges to arrive to a set of stuff that can then be built.
The company I work for has an interesting setup. Marketing drives what products we need via marketing research, Product Owners(PO) represent those products and further research the problem space, Product Managers(PM) are coupled with an engineering team and the PM negotiates with the team around estimations, priorities, and planning. But ultimately the team decides what it does, but they are held accountable for delivering business value.
As a team, we can't just go all vigilante, but we can push back and have at times gone over other people's heads to make sure the proper people understood the problem. Most of the time we got what we thought was best for the customer by going over people's heads, but there's been plenty of times that a middle ground was reached.
The main thing is to not just say "we can't". Our job is to deliver solutions, not products. If there is a problem with priorities, we find an acceptable way to make things "work". Maybe that's adjusting timelines, or features, or just asking the customer how important that timeline is to them. I can't tell you how many times I've been told about "deadlines" that the customer never actually said was a deadline.
Us: Yo cust, can we slide that project 2-4 weeks?
Them: Sure. Heck, move it back 2 months if you want, but we absolutely need to start testing on our end in 3 months.