Doomcoding: Defensive Coding and Design Against Indians and Outsourcers - Design, tooling and choices we make can make us vulnerable

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Further: inside the same datacenter/region, consider dropping your connections down to UDP from TCP, and hand-managing your sockets to enforce your own keep-alive regime.
lol now that's just evil, and I love it. No jeet is going to entertain writing socket code directly.

Code soap into your code.
Oh god no, not SOAP. That shit will make any sane developer scream and run. "Let me load and parse an 8MB definition XML at start up just to make a single API call to some botched IBM 'micro'service." Nah. Pass me the whiskey and I'll do it better myself.
 
lol now that's just evil, and I love it. No jeet is going to entertain writing socket code directly.


Oh god no, not SOAP. That shit will make any sane developer scream and run. "Let me load and parse an 8MB definition XML at start up just to make a single API call to some botched IBM 'micro'service." Nah. Pass me the whiskey and I'll do it better myself.
I think he means literal soap, as in the stereotype that Indians don't wash their hands after using the bin.
 
Knee-jerk thoughts:

2. I feel like functional programming is more AI proof. Lisp having macros may make it the best choice, but the ML dialects should also work.
FP is jeetproof because its not the primary method taught in schools and especially not bootcamps. It requires deeper thought and understanding of the problem, so its relegated towards higher end teams and specialized tasks. OOP centric languages like Java are specifically designed to make ot easy to swap out individual contributors and build with lots of different people - this is perfectly for the lower end offshore teams. Systems languages are also largely immune for similar reasons.
 
Learn COBOL. There are legacy mainframe systems out there dating back to the '70s in a whole bunch of government departments, defense contractors and large corporations that aren't broken and have way too much data on them to migrate onto newer systems.

Of all the languages, COBOL is the most pajeetproof due to its near-vertical learning curve.

It's a very small niche, but the greybeards who make up a large chunk of active COBOL programmers aren't getting any younger and the remaining COBOL coders out there can name their price.
 
Learn COBOL. There are legacy mainframe systems out there dating back to the '70s in a whole bunch of government departments, defense contractors and large corporations that aren't broken and have way too much data on them to migrate onto newer systems.

Of all the languages, COBOL is the most pajeetproof due to its near-vertical learning curve.

It's a very small niche, but the greybeards who make up a large chunk of active COBOL programmers aren't getting any younger and the remaining COBOL coders out there can name their price.
Those jobs pay dog shit, despite the popular myth to the contrary. Listings I've seen are only paying between $70k-$90k for senior-level coders.
 
Those jobs pay dog shit, despite the popular myth to the contrary. Listings I've seen are only paying between $70k-$90k for senior-level coders.
Anyone actually doing COBOL these days is probably doing it on a negotiated contract basis. Those may very well be ghost listings with no intention of having anyone actually apply to them.
 
Learn COBOL. There are legacy mainframe systems out there dating back to the '70s in a whole bunch of government departments, defense contractors and large corporations that aren't broken and have way too much data on them to migrate onto newer systems.

Of all the languages, COBOL is the most pajeetproof due to its near-vertical learning curve.

It's a very small niche, but the greybeards who make up a large chunk of active COBOL programmers aren't getting any younger and the remaining COBOL coders out there can name their price.
Generally not true IFAIK. Most remaining mainframe jobs seem to have been moved overseas, such as HP NonStop support in Brazil for some reason. US COBOL jobs usually require both expert level mainframe skills and senior level domain knowledge.
 
(They were whites. The frontend was outsourced jeets.
I missed this post but wanted to say this is your classic textbook nightmare I always tell people about in the sense that you do a shitload of work on the backend with integrations, database optimization, caching, what have you, only for your legs to get cut off because there is ONLY ONE frontend for this app and now it looks like it's your fault. Once again, they think they are clever for having a "semi-bullshit job" outsourced to jeets, without realizing the basic fact that the ONLY way to get the data from the backend is the frontend, and now you shot yourself in the foot as a company.

A way I like to explain this is imagine if a car company had an engineer that made the newest greatest engine ever and it was actually working perfectly but some lazy piece of shit in the dashboard department is butthurt that the engine guy makes 10 times what they do so they decide to change the dashboard to always mark it as a check engine light is on. To outside management that doesn't have a clue as to how any of this shit works, one seems just as wrong as the other. The difference is that the dashboard nigger and jeets both know that the company doesn't have time to waste and also doesn't have the money lying around to pay you and wait, and it will make them make a shit decision. And for jeets you can't even sue them.

The jeets refused to give any information about what they thought was broken directly to the backend,
And again this should be common sense instant termination because you can just write a big fat return statement and say "lol I did it so it must be their fault". They know that if they talk it out, within seconds it will be clear it is their fault. And they know if they stall, they are using your own salary against you. You can just blank the whole page out and blame it on the backend and managers not into software wouldn't have a fucking clue.

The jeets refused to change the frontend (we coudn't talk to them online).
And again, from the company, your classic dipshit corporate "don't let them talk to each other, we're so smart" that does not exist in ANY OTHER FIELD. Go to a car company and say "don't let the X department talk to the Y department it makes them both work harder". Um.... no it fucking doesn't nigger! But for software, something even more complicated, you aren't allowed to talk to them.

I worked at a company where it wasn't even jeets and the project manager and I had a great relationship at first and we joked about how stupid this is ie not letting people talk to each other and how it would never happen here. Literally two fucking weeks later I start getting in huge trouble all the time for asking basic questions and it turns out they even bought A SEPARATE CLOUD INSTANCE, -JUST- for the frontend, now in the space overnight the frontend dev says he is "not allowed to talk to me directly". Told them to fucking shove the job and stopped logging in. You literally don't believe that shit happens until they actually fucking do it.

And of course looked them up a year later they are fucking gone beyond gone.

I did "research" by removing fields one by one from the backend response and seeing if the site still worked. Everything that was required, I pulled once and copied into every row. It worked, the page took 400 ms to load, down from 10 seconds.
And again like I always say hiring jeets you just THINK you get it cheaper, all that happens is they take a street shit in the code, you waste 3 weeks of everyone's time with a pointless back and forth as they stonewall (because they KNOW they are the ones at fault), then some white dude fixes it completely on his own, company pretends it didn't happen.
 
Learn COBOL. There are legacy mainframe systems out there dating back to the '70s in a whole bunch of government departments, defense contractors and large corporations that aren't broken and have way too much data on them to migrate onto newer systems.

Of all the languages, COBOL is the most pajeetproof due to its near-vertical learning curve.

It's a very small niche, but the greybeards who make up a large chunk of active COBOL programmers aren't getting any younger and the remaining COBOL coders out there can name their price.
Not a good career recommendation and I've seen this pushed far too often. COBOL is a dead language with no future and no skill transfer. Even if this somehow paid well for now, these jobs are only going to decrease in the coming decades if not die entirely. This isn't a cheatcode, its setting your career up for failure in the long-term. Instead of wasting your time learning a dead language to get an exceptionally shitty and miserable job, spend that time actually strengthening your CS fundamentals and learn languages that have a future. If you're actually good at your job you're far less likely to get replaced, and if you are it will be much easier to just get a new job.
 
Is it any good? Is it useful?
I haven't really used Raku yet but I do know for sure that it has really powerful regexes and grammars, which might eventually help with my eventual goal of creating one or more of my own programming languages, and an object system inspired by Common Lisp's CLOS, which I know even less about, but I'm told that it's quite powerful. It was also designed with concurrency in mind from the beginning and doesn't suffer from the GIL like Python (and a more similar offering, namely Ruby). A lot of what I've seen from a quick glance tells me that it has parted itself with a lot of the total and utter cruft of Perl 5 (e.g. strict and warnings on by default). And yes it absolutely has the BOFH aspect of being unreadable to jeets and, really, nearly anyone else who might replace you.
 
I haven't really used Raku yet but I do know for sure that it has really powerful regexes and grammars, which might eventually help with my eventual goal of creating one or more of my own programming languages, and an object system inspired by Common Lisp's CLOS, which I know even less about, but I'm told that it's quite powerful. It was also designed with concurrency in mind from the beginning and doesn't suffer from the GIL like Python (and a more similar offering, namely Ruby). A lot of what I've seen from a quick glance tells me that it has parted itself with a lot of the total and utter cruft of Perl 5 (e.g. strict and warnings on by default). And yes it absolutely has the BOFH aspect of being unreadable to jeets and, really, nearly anyone else who might replace you.
Interesting. Looking through the examples I'll admit I got a chuckle out of seeing π just sitting there, bare and unquoted, as a constant and being syntactically valid. Silly shit like that always makes me smile.

Also, if you're interested in massive concurrency as a core language requirement, along with pattern matching and other functional programming features, have a look at Erlang and/or Elixir (which uses the Erlang engine under the hood). They're not OOP (they aim for pure functional programming as much as possible) but there's an enthusiastic community built around them both (admittedly small, but that's always the case for niche languages). Erlang is famous for its development and use by Ericson for their telecom switches (where 7 nines uptime is mandatory, online no-downtime code replacement was a requirement and massive concurrency was needed), and Elixir (which piggybacks on its runtime)'s big claim to fame is the Phoenix web app framework, which does some very impressive and fancy stuff like Live View, presence, and impossibly fast/responsive user interaction.

They're reputedly not the world's fastest languages for raw string handling, but in terms of concurrency and reliability they're hard to beat. It's definitely fun to see a single process crank up 100k+ processes (Erlang's lightweight version of them, that is) in under a second on a quad-core system and not bring the machine to its knees though.
 
Most remaining mainframe jobs seem to have been moved overseas, such as HP NonStop support in Brazil for some reason.
There seems to be an outsourcing company specializing in SAIL in Mexico too, similarly.

-Have the code on startup look for a file called niggers.txt
-niggers.txt is outside of the git folder, on the root of the drive somewhere etc
I already have a file called niggers.txt in every directory, I'll call it niggers2.txt I guess.
 
Also, if you're interested in massive concurrency as a core language requirement, along with pattern matching and other functional programming features, have a look at Erlang and/or Elixir (which uses the Erlang engine under the hood).
They've been on my radar for a few years now:
Screenshot 2025-09-08 22:59:55.webp

I just need to find an excuse to use them at some point. Immutable data structures only without any exceptions seems daunting but I'm under the impression it's no way near as horrific as it is with Haskell. And, of course, jeets will still not understand any of it.
 
They've been on my radar for a few years now:
View attachment 7887246
I just need to find an excuse to use them at some point. Immutable data structures only without any exceptions seems daunting but I'm under the impression it's no way near as horrific as it is with Haskell. And, of course, jeets will still not understand any of it.
They're both brain-bending languages coming from C/C++, C#, Java and Javascript for sure, but damn if they're not fun to play with anyway. Once you get your mind wrapped around the concept of "if you get back something you weren't expecting, just throw your hands up and crash; the rest of the system is built to cope with it," you'll really enjoy working with them. It's neat working in an ecosystem where "let it crash" is a common mode of operation and a key concept taught with the languages.
 
Even if this somehow paid well for now, these jobs are only going to decrease in the coming decades if not die entirely. This isn't a cheatcode, its setting your career up for failure in the long-term.
In the coming decades.

For someone starting out now, if they're any good at it there's still a good 15-20 years or so of juice left to squeeze, especially as pajeets won't go anywhere near something as arcane as COBOL and the old guys still coding probably wanted to retire 10 years ago but couldn't. That's plenty of time to build up skills in other languages / technologies, and make industry contacts so you can move onto something else once the final COBOL machine is switched off some time in the 2060s.
 
In the coming decades.

For someone starting out now, if they're any good at it there's still a good 15-20 years or so of juice left to squeeze, especially as pajeets won't go anywhere near something as arcane as COBOL and the old guys still coding probably wanted to retire 10 years ago but couldn't. That's plenty of time to build up skills in other languages / technologies, and make industry contacts so you can move onto something else once the final COBOL machine is switched off some time in the 2060s.
Yeah, I was thinking the same sort of people who would learn COBOL today are the same sort who are skilled and enthusiastic enough to learn things like esolangs that don't pay any money at all, resulting in a truly very diverse skill set. Just think of COBOL as an esolang that you can get paid for and don't put all of your eggs in one basket.
 
Learn COBOL if you like, but be prepared to be underpaid compared to what you might be expecting.
 
Didn't structured datasets go out the window a long time ago?
structured datasets are really good when u have multiple teams on the same project, it forces everyone to remain tidy and organized, which jeets can't do
AI stands for "actually indian"
-Have the code on startup look for a file called niggers.txt
-niggers.txt is outside of the git folder, on the root of the drive somewhere etc
-Have niggers.txt contain string data that is some sort of conversion operation off their Windows or Linux username so it will be different every time
-ie convert JohnDoe to base64 or rot13 it or whatever you want to do here
-Hook the data access layer or something critical into the check so that if the file doesn't pass, it removes every odd or even row from the return, or come up with something like that, you could also do a bitwise operation on the current day of the month so that it's inconsistently consistent
-This will cause them to start asking retarded questions on their own and make it seem like they are incompetent
-When onboarding white devs, let them struggle with it for a few hours and ask a bunch of questions to hide the check in the code as one of your questions, step them through making niggers.txt but have it be as part of 10 things you do, so that nobody mentally remembers niggers.txt so that white devs don't accidentally try to help jeets, if they know how to make niggers.txt then they will let the jeets in

Jeets get fucked

Stay the fucking fuck out my white people code
that's brilliant holy fuck
my father used to be a COBOL maintainer for a while, you'd be surprised how much infrastructure runs on it, and it doesnt pay nearly as well as you deserve for doing this thankless job
 
Back
Top Bottom