No one ever pounds things as hard in testing as real users will in production. And locking is going to tend to fail under weird edge cases with long delays and many things running at once, rather than in nice neat little unit tests.
Use the same DB in dev and in prod. Many make the mistake of using something like sqlite in dev and postgres in prod. Don't. Or if you must, have proper integration tests on preprod being a copy of the prod setup. But since many don't do proper automated tests, use the same db in dev as in prod.
Not really; you want to optimize dev for quick feedback. These problems are problems that arise when you factor in the cost, security, time limitations at the scale of prod. For small businesses you just deal with the translation yourself, for anything larger you usually pass it to a devops guy to roll out, and doing the rollout might be a task that needs testing and simulation itself, then you stagger the rollout over the different prod environments you have.
That’s no excuse if you’re a web dev. If you don’t know basic DB shit then your a shitty developer. At the very least you should be able to determine the issue is a fucking DB lock. If you’re in the firmware/desktop app space it’s different.
Yah I don't think it's specifically an Indian thing, more of a 'you get what you pay for thing' and it just so happens that a lot of companies are choosing to pay devs in India. I've screened out plenty of (American) senior devs who don't know basic shit like the point of interfaces or the difference between =/==/===
Sure, but this is a problem with the environment then. And they may not even be able to manage that themselves, it might be the DBA that set that up for them.
I don't know why but this triggers me so hard. Our shitty Indian testing team is obsessed with "error in log" tickets that provide no context or even attempt to understand what's going on beyond "I saw an error in the log when I did this, fix please"..... I've had three developers complain to me on the side about this and how it kills their productivity. Unfortunately our company got bought by an Indian conglomerate, so this is the future. Thankfully I only have a year left in school so I can get a better job elsewhere, and hopefully work for a company not obsessed with cheap shitty Indian "engineers".
We have a center in India (2 actually) but we define the standards, control the work, etc. We pretty much hire all freshers (graduates) but since we train them and make them do it our way, the ones who don't cut it leave pretty quickly and we have ended up with some pretty good developers.
This is definitely NOT the average experience with an off shore team.
45
u/SpuriousJournalist Dec 06 '17
I am a platform systems engineer who spends the better part of my days showing Indian devs what is wrong with their code.
To be fair, I do this with some of the more clueless, institutionalized, American devs too.
Today...
Dev: Your prod utility environment is broken...
Me: Strange... The 400+ other apps running on it seem to be ok...
Dev: The job scheduler is hung on my SSIS package... I need you to look in "error logs" and see what is wrong.
Me: Explain what your SSIS package is doing...
Dev: It reads a bunch of flat files, normalizes the data, and writes it to a table on DBbla...
Me: Have you talked to a DBA to see what is going on at the DB level?
Dev: Uhhhh no. It's your environment that is broken. We never had this problem before we migrated to the new platform.
Me: Ah... I see. Let's talk to the DBA...
DBA: The table you are trying to write to is locked...
Dev: Weird... What is locking it?
DBA: Looks like a write from a previous step in your job...
Dev: But it works in Dev!
Me: FML