4 ms·
I've worked with outsourced programmers before. Most of them are talented and a joy to work with. However, giving them work is often a form of programming... t
by temuze 6y ago
I've worked with outsourced programmers before.
Most of them are talented and a joy to work with. However, giving them work is often a form of programming... they will do exactly what you tell them to do, no more and no less.
For example, unless you describe the tests you want them to write, they may not write tests. If they see a possible refactor or optimization, they won't volunteer to do it. One of the frequent side-effects of this is that the project develops more tech debt and slows down with time.
From the perspective of an outsourced programmer, this makes sense. You're optimizing for efficiency. You're in contractor-mode by default because odds are, your career has been heavily contractor work. You haven't been hired to look at the bigger overall picture and you've never been encouraged to develop the agency to make independent decisions.
The most successful teams with outsourced engineering teams have found ways to better integrate them into the team. For example, I know a few startups with engineers domestically in the US whose main purpose is to interact with large teams of engineers in countries like Belarus. This hybrid approach comes with its own challenges but the cost benefits are huge.
- danjac 6y agoTbf, often contractor developers have tried to do the right thing (e.g. write tests) and been bitten ("I didn't pay for a test suite!"). Individual initiative in the contracting world usually goes unrewarded and is often punished, so you quickly learn to do what you are told, no more, no less. And you have gone the extra mile for deadbeat clients that have left you hanging with unpaid invoices, so why bother wasting potential billable hours? Which is why I avoid contract work full stop, at either end of the table. It actively encourages mediocrity and decentivizes initiative and effort.
- speby 6y agoBoy, if I had a quarter for everytime I've encountered a contractor or offshore team that did something "I didn't pay for" .... I'd be broke because I wouldn't have any quarters! I see you point in theory but in practice, that just does not happen or if it does, it is very rare.
- datavirtue 6y agoIt also pays significantly more for less work and soul sucking drama than the FTEs deal with. Another point I can make, I'm considering joining a contracting firm that actually does real consulting because all of the engineers are senior and are known for contributing excellent big-picture work. They operate on word of mouth and have been maintaining their spots in companies while the pandemic has caused FTE layoffs in those same companies. Employee owned and the benefits are above average.
- _bxg1 6y agoI think what you're describing is a problem specific to contracted programmers, not foreign programmers. Those are different questions. Contracted software development has been shown time and again to be, well, crap. No matter where the contractors reside. And the reasons, like those you describe above, are fairly clear.
- dep_b 6y ago> For example, unless you describe the tests you want them to write, they may not write tests. If they see a possible refactor or optimization, they won't volunteer to do it. One of the frequent side-effects of this is that the project develops more tech debt and slows down with time. Yet when people try to hire me they generally tend to ask about my hour rate first not what you just mentioned. Because for my hour rate you'll get an application that you can easily hand off to lesser skilled programmers later because the code and architecture is really friendly to build upon. But tech debt that never happens is something that's hard to sell.
- T-hawk 6y ago> giving them work is often a form of programming... they will do exactly what you tell them to do Yup. My anecdote: There was a middleware business application. Two database fields were last-changed-timestamp and last-changed-username. The spec document accidentally flipped the definitions, defining the value for last-changed-timestamp = current-username and vice versa. You can guess what got implemented. "I ran this and got a type conversion error. Did you even test this?" "Yes that is what should have happened based on the spec."
- PeterisP 6y agoOh, I've got a relevant story. There was a spec sent overseas for a system where one of the entity descriptions had a typo - in the title instead of 'Customers' it said 'Custoners'. The 'Customers' table was referenced in multiple other places and tests, so the delivered system had no problems with that, the customer functionality worked properly; however, sure enough, in addition to the 'Customers' table the database schema also had a table 'Custoners' with all the fields. Because the specification required that.