4 ms·

I've found contract work tends to increase technical debt rather than decrease it. Contractors never say no. It's not their fault. They're not paid to say no. I

by danjoc 9y ago

I've found contract work tends to increase technical debt rather than decrease it. Contractors never say no. It's not their fault. They're not paid to say no. It doesn't matter if the work is "remove this emissions counter when x occurs," they just do what they're told. No push back. Push back means no contract. If my PM asks me to hard code something, I understand the business well enough to know when it's a bad idea and when it's okay. Sometimes I say no, that's a 3 month project. They run out, get a contractor, who says yes, 1 week. Now I'm stuck with a 12 month repair job instead, because it has to be fixed in production. I don't play ping pong or chat around the coffee maker either. I'm too busy cleaning up messes and trying to set things right so the server doesn't catch fire and force me to come in on my weekend. Some days, I hate programming full time. I wish I was a contractor who would say "Sure, 1 week." I'd get all the glory. "Wow, that was fast. What a brilliant programmer." I'd hate myself for what I did to other programmers though. Bottom feeders, indeed.

jayhuang 9y ago
It's really quite unfortunate. But while true in most cases, it's also not always the case. Having done contract work/consulting for many years, I actually say no quite often. It's surprisingly common for business, especially small and medium sized ones, to make changes that do not improve their business, or even hurt it. Some read an article online saying "big red buttons increase conversion", and want that along with a full revamp of their system, even though it may not improve anything for their business. I believe that any consultant worth their salt should be cognizant of this, and look out for their client's interests. There is often a gap between what a client says they want and what they really want. Being able to identify that difference is key in delivering value and having leads come in without additional effort. Everyone can mash together a solution, but it's incredibly rare for a business owner to find a contractor who looks out for them and prevents them from throwing cash at a non-issue. Most business owners have worked with many contractors, and when they find someone who truly cares, most reciprocate.
jeff_petersen 9y ago
> Contractors never say no. It's not their fault. They're not paid to say no. I'm a contractor, working for a consulting firm, and we say no all the time. Sometimes it's not a hard no, but more of a gentle nudge in a better direction. But we often advise our clients away from certain requests because that's what we're paid for. We're the experts and they value our expertise, that's why they hired us. I know for a fact that what you describe exists, because about a quarter of our jobs involve cleaning up after someone like that, but I wouldn't say it's a feature of contractors in general but of cheap contractors.
- laythea 9y ago
  This is very true. Like most things in life, we get what we pay for - usually. It's the difference between an engineer and a "code slinger".
- lostcolony 9y ago
  You said a key word here. "Consultant". I would say you, too, are a consultant, by dint of working for a consulting firm. A consulting firm, at least, a good one, cares about reputation. There's also a huge level of buy in from the business. You said it, -you're the expert-. That's a fact the business hiring you recognizes, and is why they're paying consulting fees. So yes, you're empowered to say no. A standalone contractor, however, was not hired for his/her expertise, but to instead be slotted in to an existing project to churn out features, or fix things. The company hiring them has invested far less, sought out far less, stands to both gain and lose far less if things sour, and will have no qualms terminating them if so inclined. I've seen it firsthand, over and over again. Contractors are second class citizens to employees. But employees are second class citizens to consultants.
Singletoned 9y ago
I find quite the opposite. Having worked as a permie and as a contractor, I have found that contractors can be much more likely to push back. They are much less susceptible to the group-think that afflicts permanent developers, and (possibly due to their higher cost) their opinion can be taken more seriously.
linkregister 9y ago
> It doesn't matter if the work is "remove this emissions counter when x occurs," they just do what they're told. Nice one. That is pretty topical. I wouldn't be surprised if it was a contractor who wrote it in (without knowing the context) because the original engineers declined. Edit: I believe the poster was referring to the Volkswagen scandal, since it appears some HNers aren't understanding what I'm talking about.
stuaxo 9y ago
I'm a contractor and always push back. The person who will have trouble understanding the code and delivering features isn't someone down the line, it's me in just a couple of weeks time. The only way I can deliver consistently is to fix things as I go. To be fair, I've had contracts finish early because of taking this approach. Most contracts are not just 1 week, but for months. If I just bash out any old shit then not only will the next dev be cursing me but I won't get any better along the way. If you don't do a good job, then why bother at all? Maybe you should try contracting, if you don't like it or there is bad office politics you always know you will be somewhere else in a matter of months.
groundCode 9y ago
I think dysfunction like you describe comes from organisations that don't value developer opinion. I don't particularly blame some contractors for taking advantage of that and making a living from it, but it reflects the organisation, not the contractors per se. My last company was like that and contractors played the role of "yes"-person all the time. Where I am now, though is very different. Everyone discusses ideas and decisions are not taken without considering options. Contractors get stuck in with everyone else and don't just shovel bad solutions to problems.
yourapostasy 9y ago
> Contractors never say no. No. :-) If the contractor/consultant was good, what you are likely experiencing is at the endpoint of a longer and larger process. Behind doors closed to you, in the procurement meetings you probably aren't privy to, the PM is presenting to the contractor a set of constraints that presume your adverse timeline. The good contractors will point out drawbacks A, B, and C if the time constraint is not relaxed. A manager somewhere will likely dismiss that and say "we understand and accept the tradeoffs". Usually that is exchanged over email because the contractor wants a paper trail. And usually that exchange never is shared with the technical staff, much less make it into the project documentation. This is poor leadership (and in human nature), ostriching away inconvenient engineering realities, and in my experience one of the primary reasons you end up with what you described. There are crappy body shop-supplied contractors, to be sure. But you usually can exert a veto at the technical vetting stage over that. However, it is the rare organization that includes the technical staff in the entire procurement process. You are also possibly not communicating your "no" effectively enough. Usually this happens when your efforts at managing upwards and drawing boundaries are not getting the attention you desire. You can fix this in all but the most egregiously dysfunctional organizations, but it is hard work for most technical individual contributors, because it requires developing social, communication and emotional skills that are difficult to master for anyone. The remedy delivery varies on a case-by-case basis. Sometimes it is as simple as working with the contractor to ring fence the solution they are procured to deliver, deliberately treating everything the code touches as tainted through specially marking it in debugging output so you can easily troubleshoot it later. Sometimes you have to wade into project management meetings and explain in ELI5 language without sounding condescending the tradeoffs being juggled, and hold accountable the decisions without letting a hint of "I told you so" creep into your tone. You will always have to ensure you stay on top of what you are working on now, what you plan to work on in the pipeline, time commitments for each, and be able to tell week to week the impact on delivery timelines for everything based upon recent developments, and boil it all down to management as "if we do this, then that means these other goals will delay by this much", where the goal is expressed in business terms when possible. Yes, this means you are doing project management. Yes, this means you are doing much of the work of your project manager. Then why have a project manager, you ask? Because their job is not to help you; that's mostly incidental if it happens. Their job is to help communicate what is happening in the project to your managers. As a young whelp, I used to have a "c0d3 == l1f3" approach to my work, and doing any of this other work was sheer agony, as I sucked at it at first. It got a lot easier for me when I modeled all of it as different communications protocols with different manager types, and experienced that if I put in the work to reach out with these different communications styles, lots of managers became my enthusiastic sponsors (and by extension, when I made the jump to consulting, this helped my selling skills). YMMV, of course. Hope this alternate perspective helps.

by danjoc 9y ago

jayhuang 9y ago

It's really quite unfortunate. But while true in most cases, it's also not always the case. Having done contract work/consulting for many years, I actually say no quite often. It's surprisingly common for business, especially small and medium sized ones, to make changes that do not improve their business, or even hurt it. Some read an article online saying "big red buttons increase conversion", and want that along with a full revamp of their system, even though it may not improve anything for their business. I believe that any consultant worth their salt should be cognizant of this, and look out for their client's interests. There is often a gap between what a client says they want and what they really want. Being able to identify that difference is key in delivering value and having leads come in without additional effort. Everyone can mash together a solution, but it's incredibly rare for a business owner to find a contractor who looks out for them and prevents them from throwing cash at a non-issue. Most business owners have worked with many contractors, and when they find someone who truly cares, most reciprocate.

jeff_petersen 9y ago

> Contractors never say no. It's not their fault. They're not paid to say no. I'm a contractor, working for a consulting firm, and we say no all the time. Sometimes it's not a hard no, but more of a gentle nudge in a better direction. But we often advise our clients away from certain requests because that's what we're paid for. We're the experts and they value our expertise, that's why they hired us. I know for a fact that what you describe exists, because about a quarter of our jobs involve cleaning up after someone like that, but I wouldn't say it's a feature of contractors in general but of cheap contractors.

laythea 9y ago
This is very true. Like most things in life, we get what we pay for - usually. It's the difference between an engineer and a "code slinger".
lostcolony 9y ago
You said a key word here. "Consultant". I would say you, too, are a consultant, by dint of working for a consulting firm. A consulting firm, at least, a good one, cares about reputation. There's also a huge level of buy in from the business. You said it, -you're the expert-. That's a fact the business hiring you recognizes, and is why they're paying consulting fees. So yes, you're empowered to say no. A standalone contractor, however, was not hired for his/her expertise, but to instead be slotted in to an existing project to churn out features, or fix things. The company hiring them has invested far less, sought out far less, stands to both gain and lose far less if things sour, and will have no qualms terminating them if so inclined. I've seen it firsthand, over and over again. Contractors are second class citizens to employees. But employees are second class citizens to consultants.

Singletoned 9y ago

I find quite the opposite. Having worked as a permie and as a contractor, I have found that contractors can be much more likely to push back. They are much less susceptible to the group-think that afflicts permanent developers, and (possibly due to their higher cost) their opinion can be taken more seriously.

linkregister 9y ago

> It doesn't matter if the work is "remove this emissions counter when x occurs," they just do what they're told. Nice one. That is pretty topical. I wouldn't be surprised if it was a contractor who wrote it in (without knowing the context) because the original engineers declined. Edit: I believe the poster was referring to the Volkswagen scandal, since it appears some HNers aren't understanding what I'm talking about.

stuaxo 9y ago

I'm a contractor and always push back. The person who will have trouble understanding the code and delivering features isn't someone down the line, it's me in just a couple of weeks time. The only way I can deliver consistently is to fix things as I go. To be fair, I've had contracts finish early because of taking this approach. Most contracts are not just 1 week, but for months. If I just bash out any old shit then not only will the next dev be cursing me but I won't get any better along the way. If you don't do a good job, then why bother at all? Maybe you should try contracting, if you don't like it or there is bad office politics you always know you will be somewhere else in a matter of months.

groundCode 9y ago

I think dysfunction like you describe comes from organisations that don't value developer opinion. I don't particularly blame some contractors for taking advantage of that and making a living from it, but it reflects the organisation, not the contractors per se. My last company was like that and contractors played the role of "yes"-person all the time. Where I am now, though is very different. Everyone discusses ideas and decisions are not taken without considering options. Contractors get stuck in with everyone else and don't just shovel bad solutions to problems.

yourapostasy 9y ago

> Contractors never say no. No. :-) If the contractor/consultant was good, what you are likely experiencing is at the endpoint of a longer and larger process. Behind doors closed to you, in the procurement meetings you probably aren't privy to, the PM is presenting to the contractor a set of constraints that presume your adverse timeline. The good contractors will point out drawbacks A, B, and C if the time constraint is not relaxed. A manager somewhere will likely dismiss that and say "we understand and accept the tradeoffs". Usually that is exchanged over email because the contractor wants a paper trail. And usually that exchange never is shared with the technical staff, much less make it into the project documentation. This is poor leadership (and in human nature), ostriching away inconvenient engineering realities, and in my experience one of the primary reasons you end up with what you described. There are crappy body shop-supplied contractors, to be sure. But you usually can exert a veto at the technical vetting stage over that. However, it is the rare organization that includes the technical staff in the entire procurement process. You are also possibly not communicating your "no" effectively enough. Usually this happens when your efforts at managing upwards and drawing boundaries are not getting the attention you desire. You can fix this in all but the most egregiously dysfunctional organizations, but it is hard work for most technical individual contributors, because it requires developing social, communication and emotional skills that are difficult to master for anyone. The remedy delivery varies on a case-by-case basis. Sometimes it is as simple as working with the contractor to ring fence the solution they are procured to deliver, deliberately treating everything the code touches as tainted through specially marking it in debugging output so you can easily troubleshoot it later. Sometimes you have to wade into project management meetings and explain in ELI5 language without sounding condescending the tradeoffs being juggled, and hold accountable the decisions without letting a hint of "I told you so" creep into your tone. You will always have to ensure you stay on top of what you are working on now, what you plan to work on in the pipeline, time commitments for each, and be able to tell week to week the impact on delivery timelines for everything based upon recent developments, and boil it all down to management as "if we do this, then that means these other goals will delay by this much", where the goal is expressed in business terms when possible. Yes, this means you are doing project management. Yes, this means you are doing much of the work of your project manager. Then why have a project manager, you ask? Because their job is not to help you; that's mostly incidental if it happens. Their job is to help communicate what is happening in the project to your managers. As a young whelp, I used to have a "c0d3 == l1f3" approach to my work, and doing any of this other work was sheer agony, as I sucked at it at first. It got a lot easier for me when I modeled all of it as different communications protocols with different manager types, and experienced that if I put in the work to reach out with these different communications styles, lots of managers became my enthusiastic sponsors (and by extension, when I made the jump to consulting, this helped my selling skills). YMMV, of course. Hope this alternate perspective helps.