3 ms·
I'm sorry, what kind of engineers "after years of competing with Indian companies have upped their skills"? Just curious.
by grad_ml 9y ago
I'm sorry, what kind of engineers "after years of competing with Indian companies have upped their skills"? Just curious.
- shagie 9y agoI would contend that engineering FIRMS have upped their skills with more emphasis on soft skills and management feel goods (having people on site tomorrow if asked, training and such. They’re offering a larger value proposition at a higher cost when management has realized that lowest bid doesn’t necessarily mean best value.
- grad_ml 9y agoVery fair argument. Let's dissect the argument, engineering firms have improved their soft skills and value proposition. Assuming these firms are US based and all american, then by going popular wisdom here, how can american firms possibly have poor soft skills than Indian firms! I'm sure there were many instances when quality received from Indian firms were abysmal. However, imo, it's sort of online propaganda-ish that Indian firms are terrible choice, compared to american vendors. Pick and choose your best anecdote. I recall, months back, there was some incident at BA(british airways, I suppose) and whole incident was spinned as Indian contractors in India messed up. Later, VP of the company, clarified that mistakes were made locally(read UK). I feel hatred rather than facts, largely dominate HN, Reddit opinion.
- shagie 9y agoThere are many bargain basement contracting shops in the US too. Find half a dozen just graduated students who decide they're going to go freelance rather than going corporate - and you've got a contracting shop that is making web pages for the local stores or an access ERP-ish for the local business or someone who thinks that they can do the account management for their doctor's office. And yes, the code that one finds after the eventual disaster when something goes wrong is staggering. My anecdote for this is... I worked at a retail company implementing a new point of sales system. For a year before and the first year I was there (different team) there was an Indian "sales engineer" team that the vendor brought in. They weren't able to get the system working and integrated with the existing devices (it has to work with this receipt printer, this mag strip reader, this magnetic ink reader... these are the types of sales that we offer that aren't part of the core system, all rounding of pennies must be in the favor of the customer (1000 pennies in the favor of 1000 customers costs less than one complaint), etc...). When milestones were missed, rather than revising the estimates, for it, the sales engineering team brought in more people. Aside from this courting Brooks's law, it again increased billable hours. Aside from not getting it working, when management canned that approach all of the institutional knowledge of how it did work up to that point was lost. The documentation that was provided was worthless (but they billed their time to create it). Several months later, the project was started up again - this time with a fully in house team. About two months in to the year long deadline (and for us it was a deadline - not just a milestone), we commented to management that we were going to need help getting this running - there was too much to do and not enough time. Within a month we got some consultants from intertech ( https://www.intertech.com https://www.intertech.com ). And while there was some ramp up time with that code base, they were helping and contributing within two weeks. Once the system was on track for the rollout, a large phase 2 project was given to them - returns. The business logic behind returns wasn't simple (do you credit the money back to a card? what if the card is a visa gift card? cash? store credit? restocking fees (none if the item is in stock, some if the item has been discontinued), taxes (purchased in state A, returned at another store in state B), etc...). The backend system chosen to handle this was drools. Now, a outsourcing company here has two choices they can make. They can either try to make something that only they know how to modify and keep milking the project with billable hours until its replaced by another company... or they can try to transfer that information to the client (with training sessions (billable hours) and good documentation (billable hours)). For the in house people who were going to be maintaining the system, we got excellent training and documentation. If they got up and left the next day, we'd be able to maintain it with only a minor hiccup. The cost to maintain it with a few in house developers was going to be less than keeping consultants on all the time. The moral here is that it wasn't so much the "we can provide a solution" that won over the project but also the "we have demonstrated our competence in the first phase and can furthermore provide training to you that will decrease the maintenance costs over the lifetime of the project." Even with the increase of initial billable time - it was going to be cheaper. The value was not only in the demonstrated competence working with the in house team (rather than trying to do it all), but in providing all of the associated support structures and soft things that management can see as improving the value of the service beyond lines of code written.
- krinchan 9y agoOverall, I've seen more full stack skills, polyglots, and a willingness to tailor design and stacks to the problem. Companies want an FTE or two that replaces an entire off shore team and we accommodate to avoid off shoring. We've adapted as a community to have a skillset and evangelize stacks that at minimum compliments off shore if not replaces them. Simply put, after all the basic Dev and ops jobs left, we moved up the value chain. It's a cycle and the off shoring firms will move up the value chain and US devs will further specialize in to ML, AI, speech, Big Data/Data Science, etc. Those areas are quickly being commoditized by the cloud providers, so they're within reach of most US developers. Furthermore, off shoring firms will likely be content to provide the cheaper, lower level rungs of the value chain.
- pedrosorio 9y ago"I've seen more full stack skills, polyglots (...) Companies want an FTE or two that replaces an entire off shore team" Everything points to gaining breadth in order to "move up the value chain". "US devs will further specialize in to ML, AI, speech, Big Data/Data Science" In line with the previous statement, you mean increase their breadth, not specialize, right? "Those areas are quickly being commoditized by the cloud providers, so they're within reach of most US developers." What makes these areas more accessible to US developers than offshore?
- krinchan 9y agoFor the first two, that's probably a better way to put it. Breadth and T-shaped skill sets are all the rage. For the last bit, I tried to hint at that in my original comment. People who achieve that breadth outside the US can normally negotiate directly with employers in the US. This can give them more money and gives the company a more stable resource. The bulk hires from Infosys, Tata, etc. don't have this luxury. For US employees, there's both the drive to keep ahead of offshoring and the fact that so many US employers will invest in their employees. This class of offshoring companies that are suffering don't do that. Which is another point: These are not intended to be generalizations of all offshore teams and offshoring companies. The more breadth and automation an offshore company leverages, the more resilient they are. I don't doubt that Infosys and Tata will survive, but the sheer scale of their employment numbers is going to take a permanent hit and stateside devs are again going to need to become even more jack-of-all-trades with more than one specialization to stay ahead. Behold, the birth of the TT skillset. /s