Wat zal dat klotig gewerkt hebben zeg.

Korea - VS is 10.500 KM afstand, dus minimaal 100 msec latency . En dat was naar de laptop farm. Vandaar dan nog naar de feitelijke opdrachtgever , dat kan ook een forse afstand zijn .

Ze moeten wel serieus goed geweest zijn.


300K voor een remote IT werknemer is ook in de VS een heel senior salaris .

(vanuit het perspectief van de werkgever/opdrachtgever was het een US citizen die een 100% remote contract had , nooit op kantoor kwam, vrijwel zeker nooit in vergaderingen zat, zelfs niet voice-only . Dat is een bijzondere functie)

De Noord-Koreaanse werknemer verdiende inderdaad $300.000,- voor dat Amerikaanse bedrijf.
(Ik verdiende ook zo'n slordige 3 ton voor mijn baas, maar ik kreeg niet veel meer dan 30k.)
Zo'n $250k werd dan door die Amerikaanse onderneming overgemaakt naar de 38-jarige koppelbaas en de koppelbaas maakte dan iets meer dan het Noord-Koreaanse minimumloon over aan de Noord-Koreaanse IT-er.
De koppelbaas hield voor zichzelf dan toch minimaal $200k per werknemer over.
De Noord-Koreaanse IT-er moet natuurlijk aan de Noord-Koreaanse regering inkomstenbelasting betalen.
Per jaar per IT-er is dat toch een boutje, een moertje of een nippeltje voor de atoomraketten van het regime in Pyongyang .

Dat is echt niet de betekenis van deze manier van schrijven.
Er staat gewoon dat de werkgever/opdrachtgever 300K betaalde voor een jaar werk van die persoon.

Hoeveel winst/omzet de arbeid van die Koreaan opleverde staat er niet, en is niet te zeggen .

Punt is dat jaaralarissen (cq jaar-zzp contracten of vergelijkbaar) van 300K gewoon erg hoog zijn en niet zomaar aan iedere John Doe (kim park) met een my first python cursusje gegeven worden


Het waren er nogal uit - vervolg citaat


Dat is een hoop geld naar N Korea - ik denk dat meneer de laptop-farm-hoster en identiteiten-regelaar maar een schijntje ervan kreeg.

De N. Koreanen zullen wel gewoon hun N Koreaans staats-hacker-ambtenaren salaris gekregen hebben . Schijnt voor lokale begrippen best goed te zijn.

Maar punt blijft - deze salarissen die door de US werkgever/opdrachtgever betaald worden zijn gewoon voor het topniveau, en niet voor iedere jan lul met een omscholingscursus of remote helpdesk rol.

Je vraagt je dan ook af hoe ze die Koreanen aangenomen/geinterviewd hebben . Ook al regel je een Amerikaans gezicht - je zou denken dat er ook een technisch (video) interview bij hoort, en daar moet je dan wel je seniore developer cv waarmaken .

Tja, dat krijg je ervan als je als bedrijf mensen puur remote laat werken en ze zelfs nooit op een fysiek gesprek laat komen.

Grappig. Ik merk dat ik vanuit de mainframe-achtergrond waarin ik lang ontwikkelaar ben geweest nog steeds als eerste gedachte heb: nee hoor, waarom?

Bij IBM-mainframes heb je tekst-terminals van (meestal) 25x80 tekens, er wordt nog geen 2kB aan inhoudelijke schermdata per richting over de lijn gestuurd per interactie, en dat gaat altijd per volledig scherm en niet per teken dat je intypt, het typewerk wordt lokaal afgehandeld. Een latency van 1/10 seconde merk je dan als gebruiker niet eens op, het tienvoudige ervan is nog heel werkbaar omdat het alleen bij Enter¹ en functietoetsen optreedt en niet terwijl je iets aan het intypen bent.

Natuurlijk is het vandaag de dag zo dat zelfs dan het geheel in een grafische werkomgeving is ingebed, met een terminalemulator, en dat dingen als e-mail, tekstverwerking etc. niet kort te sluiten zijn zonder grafische overhead, zoals met dat terminalverkeer in beginsel wel te doen moet zijn.

Ik zie het nergens staan, maar stel dat ze zich inderdaad op IBM-mainframe-sites hebben gericht dan kunnen ze zichzelf een hoop latency-ergernis hebben bespaard terwijl het tegelijk ook de hoge salarissen zou kunnen helpen verklaren, want mainframekennis is schaars aan het worden.

¹ Voor wie zover doordenkt dat die zich afvraagt hoe je dan naar het begin van een volgende regel gaat zonder de scherminhoud te versturen: op een mainframe-toetsenbord zijn Enter en Return afzonderlijke toetsen. Met Enter gaat de scherminhoud naar de host, met Return gaat de cursor naar het eerst beschikbare invoerveld op een lagere regel. Return zit op de plaats waar op een pc-toetsenbord Enter/Return zit, en Enter zit op de plaats van de rechter CTRL-toets, en die zal door een mainframe-terminalemulator ook typisch als Enter-toets gebruikt worden.

Inderdaad was de 3270-stijl regel-georienteerd (of meer 'block' ) .

De reden was tweeledig : deels om werken over hogere latency verbindingen mogelijk te maken, maar vooral om de interrupt-load te beperken.
Interrups zijn 'kostbaar' een blups data verwerken niet zo veel. Dus het design wilde 'interrupt per toetsaanslag' vermijden .

(voor mij is dit theorie , geen hands-on mee gehad)

https://en.wikipedia.org/wiki/IBM_3270

In de tijd van _trage_ verbindingen was de lijnsnelheid ook een significant deel van de latency, niet alleen de fysieke afstand.

Het kost wat tijd om bitten op de lijn te zetten . 1KB (8192 bits op een 56000 (56kbps) circuit zetten kost al 140 msec .


Het zou kunnen. Dankzij git is het ook mogelijk om development werk heel erg 'off-line' te doen, als je een geschikte lokale test omgeving hebt .

Maar een reguliere 'office desktop' overnemen op 120 msec latency (teamviewer, anydesk e.d.) is beslist ergerlijk .

Gezien het concept 'laptop farm in de VS' denk ik niet dat het 'mainframe voordeel' echt helemaal gehaald kunnen hebben.
Zelfs als ze een mainframe terminal draaiden op die laptop farm is er daarna de latency naar Korea .


Een van de bronnen voor de verschillende line-terminations in text files.

DOS : regel-einde is carriage return + linefeed
Mac Classic : regel-einde is alleen carriage return
Unix : regel-einde is alleen linefeed.