Een gesprek met Jon Skeet: De Chuck Norris van het programmeren, op de Yellow Duck Podcast

Gepubliceerd: Laatst bijgewerkt:

Wist je dat wanneer Jon Skeet's code niet compileert, de compiler verontschuldigt? En het feit dat als Jon op Google zoekt, het enige resultaat is: "Ik ben zo terug"? Bron: Stack Overflow

Voor degenen die het niet weten, Jon Skeet is een Senior Software Engineer bij Google in Londen, UK. Sommige van de wildste beweringen over hem moeten nog worden geverifieerd, maar wat zeker waar is, is dat hij de enige gebruiker van Stack Overflow is met een reputatie van meer dan 1.000.000.

Sinds 1998 heeft deze man meer dan 34.000 antwoorden bijgedragen aan de site, die meer dan 230.000.000 views genereerde! Dus wat vraag je aan de man die elke denkbare vraag al heeft beantwoord?

Kom erachter door te luisteren naar ons gesprek met Jon Skeet

Marcin Kraszewski ging met Jon zitten en vroeg de man iets nieuws. Het blijkt dat hij nog meer antwoorden heeft, waaronder enkele die je nog nergens anders hebt gehoord.

Heb je het verhaal gehoord van hoe Jon aan softwareontwikkeling is begonnen door een computerspel te bouwen? Hoe zit het met het meest uitdagende probleem dat Jon als ingenieur moest oplossen?

Ons gesprek gaat over dit alles, maar ook over de grootste veranderingen in de software-industrie in de afgelopen tien jaar, wat ontwikkelaars gebruikten vóór Stack Overflow, hoe lang Jon nog van plan is om bij te dragen aan Stack Overflow, een vergelijking van C# en Java, en Jon's favoriete conferenties.

Dit is een unieke kans om deel te nemen aan een ongedwongen verkenning van de persoonlijke reis van een van de beroemdste namen in de softwaresector.

Je kunt Jon hier volgen:

Maar eerst, luister naar ons gesprek met Jon op de Yellow Duck Podcast

Hieronder vindt u de uitgeschreven transcriptie van ons gesprek.

MARCIN: Welkom bij de Yellow Duck Podcast. Ik heb een speciale gast vandaag. Ik ga praten met Jon Skeet, als je niet weet wie Jon Skeet is, hij is een van de top medewerkers van Stack Overflow, hij is misschien wel de top medewerker van Stack Overflow, dat is, als je Stack Overflow niet kent, dat is geweldig. Het is in principe een website waar je antwoorden kunt krijgen op bijna elke vraag, niet alleen gerelateerd aan software ontwikkeling en technologie, maar er is ook Stack Exchange, wat een soort van de moeder site is van Stack Exchange en je kunt antwoorden krijgen op vragen over alles van improvisatie comedy tot wetenschap astronomie al dit spul. Dus Jon welkom.

JON: Dank je wel. Fijn om hier te zijn.

MARCIN: Bedankt voor je komst naar de Yellow Duck podcast. Ik heb een paar dingen die ik je wil vragen. Maar eerst, wil ik, natuurlijk, naar de nummer één vraag gaan die in mijn hoofd zit. Ik heb een beetje onderzoek gedaan naar je activiteit op StackOverflow, die wereldberoemd en zeer uitgebreid is. En mijn vraag is dat u uw eerste vraag op StackOverflow beantwoordde op 26 september 2008, om 12.11 uur, volgens de informatie die ik kon krijgen. Vertel me eens over de omstandigheden rond dat eerste antwoord en we weten hoe je dat hebt gedaan. Hoe ben je Stack Overflow gaan gebruiken. Hoe kwam je aan dat antwoord. Hoe kwam je tot het beantwoorden van dat antwoord. Weet je, waar is het allemaal begonnen?

JON: Dus het was echt een oefening in narcisme tot op zekere hoogte. Ik hoorde voor het eerst over Stack Overflow op Sara Chip's blog. Ze had een review geschreven over de eerste editie van C# in 2008, wat een hele lange tijd geleden lijkt. Ik las haar review en toen las ik een paar van haar andere blog posts en daarin werd Stack Overflow genoemd. Dus ik dacht, laat ik eens kijken en ik zocht op Stack Overflow naar vragen om te beantwoorden. Dus niet veel idee over wat de site eigenlijk was en ik zocht naar vragen over C# in de diepte met name of er waren en er waren een paar vermeldingen hier of daar en er waren vragen over C# en ik dacht goed ik kan dit beantwoorden dus ik zal het beantwoorden en soort van, alles ging vanaf daar. Ik had al eerder veel nieuwsgroepen geschreven, zowel C# als Java Nieuwsgroepen voor de afgelopen tien jaar, dus dit leek gewoon een stap in de evolutie van die nieuwsgroepen te zijn. Ik heb nooit van de HTML basis forum software gehouden. Om verschillende redenen, maar niets was zo nuttig als nieuwsgroepen voor mij, terwijl Stack Overflow dat volledig veranderd

MARCIN: Geweldig en we zijn u allemaal erg dankbaar voor uw bijdrage. Ik denk dat u meer dan 35.000 vragen hebt beantwoord, wat een geweldige bijdrage is aan de gemeenschap. Dus we zijn duidelijk iedereen erg dankbaar daarvoor. En ik denk dat het echt interessant is dat je bent begonnen, zoals je al zei, als een algemene gebruiker die zijn website ontdekte en besloot om vragen te beantwoorden. Kun je naar de volgende stap gaan, wat je ertoe bracht om de tweede, derde, vierde en honderden vragen later te beantwoorden, wanneer voelde je dat dit echt iets was wat je wilde doen? Misschien een specifieke focus op Stack Overflow maar in het algemeen. Wanneer voelde je deze passie om echt veel van deze vragen te beantwoorden, alsof je gewoon deze energie had.

JONDat begon zo'n 10 jaar eerder toen ik nog op de universiteit zat en Java-vragen beantwoordde op nieuwsgroepen lang voordat C# zelfs maar bestond en me mengde in discussies die niet zo relevant zijn voor Stack Overflow maar ik heb ontzettend veel gepost op de Java-nieuwsgroepen en een groot deel daarvan was dat ik het leuk vind om mensen te helpen en dit is niet puur altruïstisch. Ik vind het leuk om mensen te helpen omdat het me verbetert als programmeur, het verbetert me zeker als communicator, waarvan ik denk dat het ongelooflijk belangrijk is in Software engineering, en dan is er het effect van niet alleen het helpen van de persoon die de vraag stelde, maar hopelijk ook het helpen van mensen later, wat is waar Stack Overflow echt voor geoptimaliseerd is. En ik denk dat sommige van de problemen waar mensen slechte vragen stellen is dat ze denken aan hun onmiddellijke behoefte in plaats van te denken hoe kan ik een vraag stellen die mij zal helpen maar ook mensen zal helpen die later komen. En als je vanuit dat perspectief begint, dan is dat waar de Stack Overflow gemeenschap omheen is gebouwd en het aantal indrukken dat goede vragen kunnen krijgen is enorm, dus je kunt de hele wereldgemeenschap van programmeurs helpen, wat ik geweldig vind.

MARCIN: Zeker weten. Dus het is een geweldig idee dat was, weet je, ik denk dat het echt iets was dat gecreëerd moest worden. Mensen waren klaar om hun kennis te delen en Stack Exchange en Stack Overflow werden net op tijd opgericht zoals je zei, er waren andere manieren om kennis te delen. Maar ik denk dat dit misschien wel de meest toegankelijke manier is voor elke gebruiker die vragen beantwoord wil krijgen. Het is een zeer effectieve manier en ik denk dat het ook heel goed gemodereerd wordt, tenminste bij lokale volgers.

JON: Ja. De mate van moderatie is zeker een pijnlijk punt met veel gebruikers, niet alleen een paar die hebben geprobeerd om de vraag te stellen en ze hebben hem slecht gesteld niet genoeg details gegeven of veel te veel details gegeven of. Er zijn talloze verschillende manieren waarop je een vraag slecht kunt stellen en ik heb het gevoel dat de moderatie een van de hoogtepunten van de site is dat het de kwaliteit van de site hoog probeert te houden en het zo nuttig mogelijk houdt, maar het is zeker een teer punt en ik denk dat er werk aan de winkel is in termen van het communiceren van de doelen van de site, zodat iedereen in dezelfde richting kan trekken. Het is niet dat iedereen. Ik ben er zeker van dat er een paar mensen zijn die opzettelijk slechte vragen stellen of voor de lol gematigd hebben. Er zullen altijd wel een paar eikels rondlopen, maar ik ben geneigd aan te nemen dat de meeste mensen geen eikels zijn. Ze zijn aardig, ze geven hun tijd en ze willen een site van hoge kwaliteit.

En als we ervoor kunnen zorgen dat iedereen op één lijn zit, zal dat leiden tot een betere ervaring voor iedereen. Dus er is nog een beetje werk te doen in termen van communicatie en allerlei dingen die erg moeilijk kunnen zijn, want als je vastzit aan een probleem en je hebt je nog niet eerder geregistreerd of een vraag gesteld of wat dan ook op Stack Overflow dan is je eerste verleiding een muur van tekst te zien die zegt dit is het soort vraag dat je moet stellen en hoe je dingen moet benaderen en Je denkt dat het me niet kan schelen, ik wil mijn vraag nu stellen, terwijl als je vijf, tien minuten of zelfs een half uur de tijd neemt om door de site te bladeren, door de verschillende hulpbronnen te bladeren. Ik heb een lange blogpost geschreven over dit is wat ik zoek in een vraag die bedoeld is om mensen te helpen vragen te stellen, maar ik begrijp de frustratie en waarom mensen dat allemaal overslaan en het gewoon goed zeggen. Laat ik nu mijn vraag stellen. Ik ga ervan uit dat ik weet wat ik doe en het is erg jammer dat dat hen over de ervaring en als mensen niet het lezen van de hulp die hen is gegeven dan geen verbetering in die hulp kan echt over het feit dat ze het niet lezen. Dus het is lastig.

MARCIN: Het interessante aan Stack Overflow lijkt te zijn dat ik nu tenminste weet dat Stack Overflow alle data beschikbaar heeft. Je kunt gewoon de hele dataset downloaden en je denkt dat dat belangrijk is.

JON: Absoluut. Ja en dat is een doel geweest vanaf dag één.

MARCIN: Denk je dat dat een belangrijk deel is van het feit dat Stack Overflow populair blijft.

JON: weet het niet het is zeker het is een functie. Het is mooi dat bijvoorbeeld, denk ik, alle Stack Overflow-vragen zijn geïmporteerd in Google BigQuery, wat betekent dat mensen query's kunnen uitvoeren op allerlei soorten gegevens en er is een Stack Overflow. Data-analyse tools zijn ook beschikbaar op die manier en dus zijn er allerlei soorten data mining die je kunt doen op Stack vragen en verschillende data wetenschappers hebben precies dat gedaan. Dus het is erg cool op dat front. Het creëert ook een soort gevoel van vertrouwen dat Stack Overflow niet jouw bijdragen bezit. Dat doet iedereen, ze hebben allemaal de juiste licentie, dus zelfs als Stack Overflow zelf als bedrijf failliet zou gaan, zou de informatie niet verloren gaan, maar ik weet niet precies hoe belangrijk het is, ik denk dat het varieert in belangrijkheid, afhankelijk van wie je het vraagt, maar het belang voor de datawetenschap gemeenschap. Ik vermoed dat het een echte schatkamer is geweest, vooral omdat ik geen lid van die gemeenschap ben.

MARCIN: Ik bedoel, ik heb gehoord van een aantal projecten waar ze proberen Stack Overflow te gebruiken om een machine learning algoritme te trainen om software te schrijven of in ieder geval software te debuggen of dat is zeker een interessant gebruik van de data. Wat Stack Overflow betreft, bijvoorbeeld, zijn er waarschijnlijk veel vragen die erg op elkaar lijken en bijna dezelfde vraag zijn, maar niet helemaal. Ziet u een oplossing in de nabije toekomst, misschien met behulp van machine learning of iets om de hoeveelheid dubbele of bijna dubbele inhoud te verminderen

JON: Juist, dus Stack Overflow probeert al soortgelijke vragen te vinden en suggereert ze terwijl je de vraag stelt, je weet wel: "Heb je naar deze dingen gekeken. We denken dat ze vergelijkbaar zijn." En zelfs nadat je de vraag daar hebt gesteld. Er is een lijst aan de rechterkant die u potentiële duplicaten of gerelateerde vragen en het is relatief eenvoudig voor een vraag te worden gesloten als een duplicaat, want als je een gouden tag is er een gouden badge in een bepaalde tag dan kun je sluiten dingen kijken naar zeer gemakkelijk wat wordt genoemd de dupe hamer. Dus dat helpt om vragen zeer snel te sluiten als ze duplicaten zijn of het kan nog verder worden gestroomlijnd ... Het is moeilijk, omdat een machine learning is nooit van plan om 100 procent accuraat, dus je wilt niet dat mensen te verhinderen vragen te stellen. Zelfs als je sterk vermoedt dat het een duplicaat zal zijn. Je moet bijna zeker weten of je het echt zeker weet. Heb je echt gekeken naar al deze dingen, maar ik weet het niet het voelt als allemaal iets minder van een probleem. Het duplicaat aspect dan mensen die vragen stellen en niet eens genoeg informatie geven of de juiste soort informatie om te kunnen zeggen of het een duplicaat is of niet. En ik hoop dat. Ik weet dat Stack Overflow een paar iteraties heeft doorgemaakt van een soort wizards om vragen te stellen die zeggen: "Hoe ziet je code eruit, welke talen gebruik je. Heb je een kort maar compleet voorbeeld dat het probleem demonstreert". Dat soort dingen. Het is onduidelijk wat er precies gaat werken, maar ik weet dat het team hard aan het werk is om de ervaring van het stellen van vragen te verbeteren, omdat Stack Overflow er fundamenteel op vertrouwt dat er goede vragen worden gesteld.

MARCIN: Zeker en omdat ik aanneem dat er altijd vragen zullen zijn die gesteld moeten worden, ongeacht de technologie en hoe lang ze al bestaat. Wat is de belangrijkste reden. Wat is de drijfveer, weet je, het feit dat er altijd nieuwe vragen zullen zijn, zelfs over C# die je, zoals ik al zei, hebt beantwoord en verschillende andere onderwerpen, weet je, 35.000 antwoorden, maar er is nog steeds meer. Ik denk dat dit gaat om de aard van software engineering of dat je gewoon niet alles kunt abstraheren.

JON: Nou het zijn meerdere dingen deels is het dat de taal aan het veranderen is dus ik schrijf momenteel over C# 7.2 en moet zelf nieuwe dingen leren zodat ik er dan over kan schrijven. Dus het zou heel natuurlijk zijn voor mensen om vragen te stellen over C# 7.2 of je weet wel andere dingen die redelijk nieuw zijn C# 7.0 is nog steeds redelijk nieuw. Dus als talen evolueren en nieuwe frameworks en bibliotheken en allerlei andere dingen. Er zullen altijd nieuwe gebieden zijn voor mensen om vragen over te stellen. En dan zijn er mensen die vragen stellen over bestaande gebieden en sommige van die vragen zullen nieuw zijn en sommige zullen niet nieuw zijn en sommige kunnen verkapte nieuwe vragen zijn. Zo is bijvoorbeeld in C# de precieze manier waarop lambda-expressies variabelen vastleggen, met name voor elke iteratie variabelen, veranderd in C# 5 en dat veroorzaakte vóór C# 5 een hoop vragen toen het niet ideaal was zoals het werkte. En veel van die vragen zijn in feite duplicaten van elkaar, maar eigenlijk heb ik er heel wat beantwoord omdat er veel zijn die niet duidelijk met elkaar in verband lijken te staan. Pas als je het antwoord weet, kun je zien dat het om hetzelfde probleem gaat, maar dan vermomd. Er zullen dus altijd dingen zijn waarvan alleen de beantwoorder weet dat u eigenlijk met hetzelfde probleem zit als iemand anders en of die vragen als duplicaten gesloten moeten worden is waarschijnlijk een punt van discussie. Maar ja, er zullen altijd nieuwe mensen komen in Software engineering en dat is fantastisch en ik denk dat sommige van hen Stack Overflow meer als een leerbron zien. Ik zou ze aanmoedigen. Ik denk dat Stack Overflow een geweldige bron is om problemen op te lossen. Het is geen geweldige manier om een taal te leren, je kunt niet een Java compiler of zelfs een IDE en Stack Overflow nemen en op die manier Java vanaf nul leren. Dat zal gewoon geen efficiënte manier zijn om de taal te leren. Terwijl een boek of een tutorial een veel meer gestructureerde aanpak is en dan is Stack Overflow geweldig voor. Er was een voorbeeld en ik verwachtte dat het dit zou doen, maar in plaats daarvan deed het iets anders. En hier is waarom ik denk dat het zich zo zou moeten gedragen en het gedraagt zich eigenlijk op een andere manier. Kan iemand mij precies uitleggen wat hier aan de hand is. Dat soort vragen zijn geweldig voor Stack Overflow, dus het is zeker een soort aanvulling op andere leermiddelen, maar ik denk niet dat het geweldig is als een eerste leermiddel. Of als de enige manier om een taal te leren, maar er zullen altijd mensen zijn die dingen voor de eerste keer leren. En zoals ik al zei, als je relatief nieuw bent in een taal of technologie dan zal het een stuk moeilijker voor je zijn om. Verwante vragen omdat je op dat moment niet eens precies weet waar je vraag betrekking op heeft, dus ik verwacht niet dat de reeks vragen of de stroom vragen snel zal opdrogen. En dat komt deels door nieuwe mensen, deels door nieuwe technologieën en deels door de oude rotten die dingen doen die ze nog niet eerder hebben gedaan, dus ik kan nog steeds in C# aan het schrijven zijn en een nieuwe vraag stellen over C# en ik denk dat ongeveer de helft van mijn vragen over C# zelf gaat, wat mensen misschien zal verbazen. Er is niets beter dan een taal redelijk goed te kennen om je bewust te zijn van dingen die fout gaan of echt onverwacht zijn en dan is het echt nuttig om vragen te stellen op Stack Overflow en te zeggen hey ik had echt verwacht dat dit zou gebeuren en ik heb een goede reden om dat te verwachten vanwege al mijn eerdere ervaring, maar het betekent wel dat je hier uiteindelijk vragen stelt over technologieën waarvan je normaal niet zou verwachten dat ze fout gaan.

MARCIN: En op Stack Overflow het idee van het vinden van een antwoord online is dat hoe lang is het al een soort van integraal onderdeel van software engineering. Omdat het vroeger zo was dat je vast zat aan, laten we zeggen, laten we zeggen dat je documentatie had, misschien een paar message boards, een paar nieuwsgroepen. Maar het lijkt erop dat veel professionals regelmatig gebruik maken van Stack Overflow en veel van hun projecten en dat is waarschijnlijk de reden waarom Stack Overflow dat heeft aangepakt met hun licenties en dat je in wezen moet vermelden dat het van cycles komt waar je de code vandaan hebt. Hoe zijn software engineering en Stack Overflow volgens jou in de loop der jaren veranderd?

JON: Ik denk dat Software engineering gedeeltelijk veranderd is omdat we allemaal meer technologieën gebruiken en minder goed gedocumenteerde technologieën gebruiken, dus iedereen gebruikt tegenwoordig links en rechts bibliotheken van derden of de meeste mensen doen dat en bibliotheken worden geleverd met een variëteit aan gradaties van documentatie en tot op zekere hoogte heeft Stack Overflow het bijna overgenomen van documentatie in sommige situaties. En er was het Stack Overflow documentatieproject dat uiteindelijk werd geannuleerd omdat het gewoon niet helemaal werkte voor de situatie, maar Stack Overflow maakt tegenwoordig zeker meer en meer deel uit van de dagelijkse toolkit van software-engineers. En een deel daarvan is omdat Stack Overflow zo snel reageert. Ik herinner me in 2008 2009, toen Stack Overflow nog heel jong was. Jeff Atwood zei dat je soms een vraag moet stellen en 20 minuten moet wachten op een antwoord. En ik was gewoon weggeblazen denken over 20 minuten dat is zo'n ongelooflijk korte tijd. En hij heeft gelijk dat als je een goede vraag stelt, je meestal binnen 20 minuten een antwoord krijgt. En dat was vroeger niet het geval op nieuwsgroepen. Ik weet niet zeker of het aan het aantal mensen ligt dat dingen leest of aan het feit dat de wereld sneller gaat, maar in elk geval wachtte je in een nieuwsgroep vaak een hele dag voordat je een antwoord kreeg, terwijl ik er tegenwoordig langer over doe om een vraag te schrijven dan dat het duurt voordat ik een antwoord krijg. Ik zal er dus zelden minder dan een half uur over doen om een vraag te schrijven omdat ik onderzoek doe, een compleet voorbeeld samenstel en de vraag zo duidelijk mogelijk stel en dat kost allemaal tijd. Maar zeker binnen een half uur, dus als het me een half uur kost om de vraag te schrijven dan heb ik minder dan een half uur later op zijn minst commentaar dat zegt: Ja, dat ziet er vreemd uit. Dat is nieuw. Ik weet niet zeker wat hier aan de hand is of een echt antwoord dat de oplossing van het probleem uitlegt. Dus ja, het feit dat het zo lage latency effectief maakt het zo veel meer levensvatbaar. En dat is als je een nieuwe vraag moet stellen. 90 procent van de keren dat ik een probleem heb waar Stack Overflow me mee helpt, hoef ik de vraag helemaal niet te stellen omdat iemand anders hem al eerder heeft gesteld. Ik merk dat vooral met gebieden waar ik minder bekend mee ben zoals Python of Bash scripts of iets dergelijks, ik heel vaak wat onderzoek doe op Stack Overflow en het antwoord vind op precies de vraag die ik wilde. Het is geweldig.

MARCIN: Heb je gemerkt dat mensen die aanbodontwikkeling ontdekt hebben en er meer over willen leren, maar gewoon de eerste taal leren? Heb je gemerkt dat ze niet genoeg tijd investeren in het leren van de kern. Zoals ik al zei, de kerndocumentatie en de taal echt leren kennen voordat ze naar iets als Stack Overflow gaan?

JON: Ik denk dat het moeilijk te zeggen is welk deel van de mensen dat doet, maar ik zie zeker dat sommige mensen dat doen en niet eens de taal leren kennen en de hulpmiddelen krijgen. Maar ik heb het gevoel dat er een gebrek is aan onderwijs binnen scholen universiteiten van diagnostische proces en dit is waarom ik een soort van beetje een tirade over zeker in het Verenigd Koninkrijk zijn er veel meer computerwetenschappen cursussen in software engineering cursussen en voor alle feit dat ik ben ik ben erg dankbaar dat er computerwetenschappen cursussen en we zeker computerwetenschappers nodig. Er is waarschijnlijk meer behoefte aan software-ingenieurs die niet echt de details hoeven te kennen van hoe een compiler werkt, maar die echt wel een cursus zouden kunnen gebruiken over hoe je een probleem oplost en het verder onderzoekt. En als je er niet in slaagt het op te lossen, dan is dit hoe je er naar vraagt. Of dat nu vragen aan je collega's is of vragen op Stack Overflow of het vinden van een bug of wat dan ook het is zo simpel aspecten van het diagnostische proces van niet proberen om meer af te bijten dan je kunt kauwen. Als je nieuw bent in een taal, doe dan eerst wat eenvoudige dingen. Ik heb de neiging om te gaan met iets als console apps voor een ding in plaats van onmiddellijk te duiken in web apps en mobiele apps bijvoorbeeld die volledig afhankelijk is van de taal natuurlijk als je een taal die volledig is gericht op web-ontwikkeling dan misschien een console dat gaat onmogelijk zijn, maar waar mogelijk gebruik maken van de eenvoudigste omgeving die je kunt. De omgeving waar debug je zoveel mogelijk gaat helpen, waar je geen 100 regels boilerplate nodig hebt om twee regels code te laten lopen, dat soort dingen is echt nuttig om jezelf effectief op te zetten voor succes, zodat je één aspect van een taal kunt leren, één aspect van een bibliotheek tegelijk, in plaats van te verdrinken in een zee van oké. Ik heb 100 honderd regels code en ik begrijp er niets van en ik krijg een foutmelding die ik ook niet begrijp en ik weet niet waar ik moet beginnen. Het probleem is dat je ergens begint waar te veel dingen zijn die je niet begrijpt. Dus ja in een snel veranderende wereld en ik ben hier net zo schuldig aan als ieder ander als ik probeer om nieuwe technologie te leren voor al het feit dat ik zeg dat ik eenvoudig zou willen beginnen. Ik denk vaak, ik heb maar één ding dat ik moet doen, dus ik duik er gewoon in. Dus doe ik ook het verkeerde maar ik weet genoeg dat als ik vastloop ik dan terugtrek en probeer iets eenvoudigers te doen maar in een snel bewegende wereld is het verleidelijk om er meteen in te duiken want hé ik moet nu iets gedaan krijgen maar ik vind dat het veel productiever is en op de lange termijn als je gewoon een stapje terug doet en echt eerst probeert te lopen voor je rent.

MARCIN: Ben je ooit in een situatie geweest, misschien was dit vroeg in je carrière, waar je een probleem begint op te lossen dat al opgelost is en dan realiseer je je later dat dat eigenlijk een opgelost probleem is, dat je gewoon een API kan gebruiken of je kan een vertrouwde bibliotheek gebruiken.

JONJa, en soms lijkt er een soort aversie te bestaan tegen de third-party bibliotheek. Een klassiek voorbeeld is het manipuleren van XML. Mensen zeggen dan: "Ik hoef alleen maar ampersands te escapen, dus ik gebruik gewoon strings en bouw de XML direct op". Dan komen ze erachter dat ik nog iets anders heb dat een probleem veroorzaakt en vroeg of laat heb je honderden regels code die volledig vermeden kunnen worden als je gewoon een XML bibliotheek gebruikt en die veel robuuster en veiliger is voor allerlei zaken. Dus ja, mensen moeten bibliotheken van derden gebruiken. Als je ze zorgvuldig hebt uitgekozen, zijn er echter ook een heleboel tamelijk waardeloze bibliotheken. Maar het kiezen van een goede bibliotheek kan het verschil maken in een project.

MARCIN: En zou je zeggen dat dat iets is dat wordt opgedaan met ervaring, wat is wat ik bedoel is dat de de soort van wijsheid om te kunnen zeggen moet ik echt code schrijven om dit specifieke probleem op te lossen.

JON: Tot op zekere hoogte. Het is deels een kwestie van ervaring en deels een kwestie van jezelf inhouden want als je ziet dat je iets zou kunnen doen en het betekent dat je wat code moet schrijven en je denkt dat het leuke code zou zijn om te schrijven. Dan is er altijd de verleiding om die code te schrijven, zelfs als je dat eigenlijk niet hoeft. En ik kom zeker in die verleiding. Zelfs wanneer ik het echt niet zou moeten doen en soms zal ik een snelle tool schrijven in C# ook al is het niet de meest geschikte taal om die te gebruiken omdat het de taal is die ik het best ken en dus misschien maakt dat me meer effectief op korte termijn. Mogelijk ten koste van de productiviteit op lange termijn. Ik denk niet dat we ons daar al te veel zorgen over moeten maken. Laten we onszelf niet te veel op de borst kloppen over dit soort dingen, maar wel een oogje in het zeil houden. Er valt veel te leren door een stapje terug te nemen van jezelf en jezelf te bekijken en te zeggen waar gebruik ik veel tijd op manieren die uiteindelijk niet productief zijn en hoe kan ik dat een beetje verminderen in de loop van de tijd zonder te proberen te denken oh dat moet betekenen dat ik een vreselijke ontwikkelaar ben en dat ik software engineering helemaal moet opgeven. Probeer gewoon jezelf te verbeteren in de loop van de tijd, de hele tijd.

MARCIN: Geweldig. Goed. Nu denk ik dat wat ik wil doen is een beetje proberen een beetje van een klein beetje geschiedenis voor zover als als je zou kunnen ons vertellen iedereen heeft een verhaal van toen ze begonnen met programmeren. Dus wat is jouw wat is jouw verhaal van wanneer ben je er eigenlijk in geraakt? Wanneer raakte je geïnteresseerd in zoiets als software engineering of programmeren of coderen of hoe je het toen ook wilde noemen?

JON: Dus het was erg vroeg. We kochten Aztec's spectrum 48 K Sinclair's bij Spectrum toen ik ik denk dat het 1984 was, dus ik was acht jaar oud. De Spectrum kwam twee jaar eerder uit in 1982 en in het begin speelde ik gewoon spelletjes en daarna begon ik vrij snel met eenvoudige codering. Dus de Spectrum kwam met een BASIC interpreter ingebouwd. Dus als je de computer opstart, kan je onmiddellijk beginnen met het intypen van code en de Spectrum handleiding die erbij zat was heel erg goed voor het aanleren van programmeren, het aanleren van basic in ieder geval. En ik herinner me een dag toen mijn vader thuis was omdat hij om de een of andere reden ziek was en ik me herinnerde dat ik een onnozel schietspelletje schreef dat gewoon bestond uit hier is een ruimteschip dat waarschijnlijk was opgebouwd uit gewoon wat ASCII tekens en een alien zou verschijnen op een willekeurig punt en je zou je ruimteschip op en neer bewegen en dan op 'face the fire' of wat dan ook drukken het was zo volkomen triviaal en helemaal niet echt vermakelijk om te spelen. Maar dit was de eerste keer dat ik iets schreef dat interactief zou zijn en het was verbazingwekkend het gevoel dat het me gaf was verbluffend. Ik denk deels omdat alle spellen toen vrij ruw waren ik genoot van Jetpack en Lunar Jet Man. enz. Maar dat waren vrij eenvoudige spelletjes, dus het feit dat ik iets eenvoudigs schreef, heeft me niet afgeschrikt. Ik heb een beetje medelijden met de kinderen van tegenwoordig die, als ze mijn advies opvolgen en iets heel simpels doen om mee te beginnen, eindigen met een klein tekstspelletje waarin je misschien een willekeurig getal moet raden en het zegt of je te hoog of te laag komt enz. Als je dat vergelijkt met Overwatch of welk spel dan ook dat je voor je plezier speelt. Het is vrij moeilijk om te zien hoe ze op elkaar aansluiten omdat er een miljoen lichtjaren zijn afgelegd van een simpel tekstdingetje naar 3D-graphics die daar met grote snelheid voorbij gaan met netwerken en allerlei dingen. Maar toen was het geweldig. Dus schreef ik mijn eigen code op die manier. Er waren ook tijdschriften die met lijsten kwamen die je kon intypen. Dus je kocht een boek en in plaats van een bandje voorin met code die je er gewoon in kon laden, typte je het allemaal in en de voordelen daarvan zijn dat het enorm eentonig aanvoelde, maar je leerde wel de hele tijd. Wel, dit is hoe je code kan schrijven zonder dat het bijzonder benadrukt wordt. Dus ik denk dat ik daar heel veel van heb opgestoken en ik herinner me dat een van mijn eerste belangrijke projecten het schrijven van een Logo interpreter was, dus we zaten op de BBC Micro computers op school. We hadden een Logo interpreter waar een soort namaakrobot in zit en je kunt zeggen ga honderd graden vooruit draai 90 graden naar rechts enz. en het zou vellen op het scherm tekenen. Ik hou hiervan maar we hadden het niet op het spectrum dus implementeerde ik mijn eigen omdat ik niet wist dat dit een moeilijk ding was dat veel tijd zou kosten en dat deed het wel maar het was ongelooflijk bevredigend en ik denk dat het een bewijs is van de kwaliteit van het spectrum handboek dat ik effectief trigonometrie heb geleerd van het spectrum handboek omdat we het nog niet gedaan hebben in wiskunde ik was nog maar ik weet niet 10, 11, of 12 jaar oud. Dus ik heb helemaal niet gekeken naar Trigon trigonometrie op school maar het spectrum handboek was duidelijk genoeg dat ik in staat was om genoeg te leren om een logo interpreter te doen van dat. En terugkijkend zou ik de code nu wel eens willen zien. Ik vermoed dat het absoluut fout is. En natuurlijk, het is verloren gegaan in de nevelen van de tijd. Maar achteraf ben ik nog steeds enorm trots op hoe vreselijk die code ook was. Je zou je logo lijst kunnen schrijven. Je kon het opslaan op tape, je kon het opnieuw laden, je kon het uitvoeren, ik was allemaal extreem cool.

MARCIN: En terwijl u deze vaardigheid ontwikkelde, dacht u altijd dat u als software ingenieur zou gaan werken of was u in andere dingen geïnteresseerd en werd u op de een of andere manier gestuurd of hoe bent u eigenlijk het vak ingegaan?

JON: Ik denk dat vanaf de leeftijd van 13 of 14, ik dacht dat dit mijn carrière zou worden. Dus ja. Ik heb geen computerwetenschappen gestudeerd aan de universiteit, ik heb wiskunde gestudeerd en dacht dat ik misschien onderzoek zou gaan doen in de wiskunde. Blijkt dat ik lang niet goed genoeg ben in wiskunde om te promoveren of wat dan ook. Maar ik wist dat het iets met informatica zou zijn. Ik was op school al geïnteresseerd in kunstmatig leven, dus ik heb wiskunde gestudeerd en daarna een jaar lang een master in informatica gedaan. In de vakantie ben ik met een vriend bij Digital Electronics gaan werken en van daaruit ben ik verder gegaan. Ik ben altijd vreselijk geweest in het sturen van mijn carrière, ik heb het gewoon van plaats naar plaats laten gaan omdat ik het naar mijn zin had, dus ik heb plezier altijd belangrijker gevonden dan geld, zeker de erkenning die ik krijg van Stack Overflow en van het schrijven is erg plezierig. Het is nooit een doel in het leven geweest om beroemd te worden of wat dan ook. Maar de bizarre status van micro-celebrity die ik via Stack Overflow krijg is best leuk en een beetje vreemd, maar leuke dingen doen in je werk is altijd veel belangrijker voor mij, dus ik zorg ervoor dat ik een goede balans tussen werk en privé heb en ik kan mijn familie veel zien. Mijn familie is ongelooflijk belangrijk voor me maar ik heb lang niet zoveel aandacht besteed aan mijn carrière als waarschijnlijk meer weloverwogen mensen zouden doen.

MARCIN: Hoe kunnen ouders de belangstelling van hun kinderen voor programmeren ontwikkelen?

JON: Ik heb drie kinderen, waarvan er één geïnteresseerd is in Arduino-dingen en een beetje codeert en ook Python leuk vindt. Een ander kind is onlangs begonnen met Python, maar deed daarvoor scratch, wat interessant is, het is een meer visuele omgeving en ik weet niet veel over de wetenschap of kinderen leren programmeren. Ik heb geprobeerd mijn kinderen te leren programmeren in Python door een zeer stapsgewijze aanpak en ik denk dat het geweldig is voor volwassenen, maar ik ben er niet zeker van dat het de interesse van kinderen genoeg vasthoudt. Tenminste niet de stap voor stap aanpak waar ik voor opgeleid ben. Ofwel ben ik gewoon geen goede leerkracht, wat heel goed mogelijk is, maar ik denk dat het belangrijkste is ervoor te zorgen dat het iets is wat ze willen doen. Dus pas toen ik mijn kinderen niet meer probeerde te leren programmeren, begonnen ze het zelf te doen en leerden ze veel meer. Mijn oudste zoon heeft een heleboel dingen gedaan Arduinos en Raspberry Pi. Ik weet zeker dat ik die dingen nog nooit gezien heb, omdat hij af en toe gewoon zegt: "Mag ik die onderdelen hebben, alsjeblieft? En dan gaat hij willekeurige dingen bouwen en dat was ook de manier waarop ik het geleerd heb. Mijn ouders hebben nooit over mij gewaakt, voor zover ik weet, in termen van wat ik aan het programmeren was. Ze waren gewoon blij dat ik gelukkig was en moedigden me aan om de buitenwereld in te gaan. Zo nu en dan, maar ze waren blij dat ik iets creatiefs deed en van mezelf leerde. Dus als je kinderen genoeg kunt aanmoedigen om iets te vinden wat ze leuk vinden om zelf te doen en dan duidelijk kunt maken dat je ze graag helpt als ze hulp willen, maar dat je ze niet gaat dwingen om het te doen. Op dit moment is het tijd voor een half uurtje programmeren. Dan denk ik dat dat het recept voor succes is. Kinderen houden van leren. Ze houden misschien niet van school maar ze houden van leren en ze houden van creatieve dingen doen. Dus laat ze hun creativiteit de vrije loop en ze zullen je versteld doen staan van wat ze kunnen.

MARCIN: Denkt u dat het idee dat iedereen moet leren coderen, vooral u weet dat ze proberen om meer te introduceren in leerplannen. Is dat een goed idee of is dat onnodig mensen dwingen iets te leren dat ze niet echt willen.

JON: Ik denk dat er twee aspecten zijn één het is goed om iedereen bloot te stellen aan coderen omdat we dit ongezonde stereotype hebben van hoe een computerprogrammeur eruit ziet dat onze industrie echt schaadt. Dus als we mensen kunnen laten kennismaken met coderen en zeggen: dit is wat coderen eigenlijk is en als we mensen er een positieve ervaring mee kunnen geven, dan kunnen mensen die misschien nooit van nature hebben gezegd: weet je, dat is iets wat ik voor mezelf wil gaan doen, het ontdekken. Eigenlijk, vinden ze het geweldig. Dus ik denk dat dat heel gunstig is. En het andere aspect is dat software tegenwoordig zo'n groot deel van de wereld regelt dat ik denk dat het heel nuttig is om enig idee te hebben van wat erbij komt kijken, zelfs op het grofste niveau. Op dezelfde manier als ik denk dat mensen les moeten krijgen in financiële planning, gewoon de basis van dit is waar pensioenen over gaan en dit is waar leningen over gaan en hier is hoe de aandelenmarkt werkt. Niet zodat ze bankier kunnen worden, maar om te kunnen manoeuvreren in een wereld die zo financieel gedreven is, met een idee dat hetzelfde geldt voor politiek en allerlei andere dingen, het soort delen van de werkelijkheid die je wereld zullen beïnvloeden. Het is goed om een basiskennis te hebben. Ik zeg niet dat ik veel weet over politiek of financiën, maar ik ben blij met wat ik weet, want het helpt me om de rest van de wereld te zien. Ik denk dus dat software zeker een rol moet spelen in het feit dat geen enkel kind tegenwoordig uit een middenklasse-gezin in een ontwikkeld land komt en we kunnen hele andere gesprekken voeren over gebieden waar kinderen niet met computers in aanraking zullen komen vanwege armoede enz. maar veel kinderen zullen toch enige interactie met computers hebben. Dus als ze ze zien als dat is gewoon code uitvoeren het is echt ingewikkelde code uitvoeren, maar ik heb een idee van hoe code eruit ziet. En het idee dat je weet wat de cloud is in de zin dat het computers zijn die ergens anders draaien in een datacentrum dat wordt beheerd door Google of Amazon of Microsoft of wat dan ook en dat je de basisbeginselen daarvan kent, kan je helpen om wat dan ook te doen. Je hoeft niet zelf te coderen om te profiteren van het hebben van de basisideeën over hoe computers werken.

MARCIN: En nu met iets als chrome bijvoorbeeld met hun ontwikkelaar soort van toolbar. Je kunt iedereen die het internet gebruikt vragen of je je realiseert dat dit allemaal gebeurt terwijl je deze website gebruikt, weet je, al deze activiteiten, en misschien begrijpen ze dat niet eens. Maar het onthult wat er zich achter de schermen afspeelt. En ik denk dat het soms een geweldige manier is om iemand te laten zien die geen interesse heeft in het onderwerp en je zegt OK. Laat me je gewoon tonen, laat me je gewoon tonen wat er eigenlijk gebeurt op deze website terwijl je hem gebruikt. Ik denk dat het verbazingwekkend is dat we zelfs de console kunnen openen en wat javascript kunnen hacken zonder echt iets te hoeven doen.

JON: Absoluut ja en het op elkaar toepassen. Er zijn tal van andere manieren van het doen van elementaire stukjes code gewoon voor een browser, waaronder in C# nu is er dat Tray.net kunt u beginnen met het schrijven van elk omhoog gewoon in je browser en zeker achter de schermen is er een cloud container ergens draait. Maar je kunt zeker beginnen met het zien van code in ontelbare talen gewoon vanuit je browser. En ik denk dat er iets te zeggen valt voor informatica als je ook die blootstelling hebt. Dus ik heb zeker lezingen gegeven aan welpen en gidsen en zelfs het gilde van mijn plaatselijke Methodistenkerk, die meestal bestaat uit mensen die ofwel gepensioneerd zijn of bijna de pensioengerechtigde leeftijd hebben bereikt en die nooit enige computerwetenschap zouden hebben gedaan, en ik gaf een lezing die hen wat computerwetenschap liet zien zonder dat er computers aan te pas kwamen. Dus dingen als je hebt een stapel stukjes papier hoe kun je die efficiënt sorteren en hoor een paar verschillende algoritmen die je kunt gebruiken. En wat betekent dit voor als je één persoon hebt die ze probeert te sorteren dan gebruik je misschien één algoritme. Als je 10 verschillende mensen hebt, is de gekozen manier dan nog steeds schaalbaar met veel verschillende mensen die helpen. Dus je eindigt met een soort van merge sort of wat dan ook en dingen als algoritmische complexiteit geven real-life voorbeelden van hoe lang het duurt om verschillende dingen te doen. Als je meer input hebt om overhemden aan de waslijn te hangen of wat het ook is, denk ik dat mensen dat soort dingen interessant kunnen vinden als ze er niet door afgeschrikt worden. Maar zodra je begint te zeggen dat je moet rekenen, zullen veel mensen meteen afhaken. Er is dus veel voor te zeggen om dingen beschikbaar te stellen op een niet-bedreigende en niet-betuttelende manier en dat vergt een aanzienlijke vaardigheid op gebieden die ik niet heb. Maar ik heb gedaan wat ik kon, maar ik ben er zeker van dat betere opvoeders het veel beter zouden kunnen. Ik denk dat het heel belangrijk is.

MARCIN: Laten we hier doorgaan. Wat zou je zeggen dat je naast Stack Overflow. Zijn er bronnen waar je echt van houdt. Ik bedoel, ik ben een fan van O'Reilly boeken, maar waar ben jij fan van? Welke bronnen gebruik je wanneer je een nieuwe taal of iets dergelijks wilt leren?

JONDus boeken zijn geweldig voor het leren van talen omdat ze je daar in een bepaalde volgorde brengen en tegenwoordig, natuurlijk, geldt dat ook voor online tutorials zolang ze op de juiste manier zijn geschreven en het kost veel moeite weet ik uit ervaring om middelen te schrijven die je alle kenmerken van een taal leren in een specifieke volgorde die je gaat helpen bij het leren. Iemand zou dus een C# handleiding kunnen schrijven die eigenlijk helemaal niet zo goed is omdat ze gewoon een hersendump hebben gegeven. Dus je moet kiezen en kiezen, maar iets dat gestructureerd is voor jou maakt een groot verschil. Goede API documentatie is altijd zeer welkom. Dus .NET heeft de neiging om vrij goed gedocumenteerd te zijn en de nieuwe API-browser maakt het gemakkelijker om de documentatie te vinden, enz. Ik zou mensen aanmoedigen als ze bibliotheken schrijven om echt moeite te doen om goede documentatie te schrijven die bij die bibliotheken hoort. Het heeft geen zin om de snelste en slimste JSON Serializer ter wereld te hebben. als niemand kan uitvinden hoe je het moet gebruiken. Maar of ik gebruik dezelfde bronnen die andere mensen ook gebruiken of het nu tutorials en boeken zijn of gewoon zoeken naar de juiste resultaten als ik getraind ben om te schrijven hoe kan ik doen wat het ook is. Iets in een PDF zetten of welke taak ik toevallig bij de hand heb. Ja, ik zoek op het internet, ik gebruik Stack Overflow, ik gebruik boeken, ik gebruik tutorials, ik gebruik bibliotheken en hun documentatie. Ja, dat is het wel zo'n beetje denk ik.

MARCIN: En wat zeg je van dit idee dat komt omdat we eigenlijk bijna dezelfde leeftijdsgroep hebben. Het idee dat op een bepaalde leeftijd mensen gewoon managers worden. Heb je dat zien gebeuren. Is dat waar of bent u uniek in dat opzicht dat u nog steeds software ontwikkelt of bent u. Ik denk dat wat zou je daarop zeggen.

JON: Ik ben zeker niet uniek. Ik zou zeggen dat ik actief heb gezegd dat ik mijn carrière niet echt heb gemanaged. Het feit dat ik optimaliseer om plezier te hebben heb ik me een hele tijd actief verzet tegen het managen. Ik ben een half jaar manager geweest en ben erachter gekomen dat er veel voor te zeggen is. In het bijzonder wil ik graag denken dat ik empathisch ben en ik probeer dat ook bewust te zijn, want nogmaals, ik denk dat dat een belangrijke vaardigheid is voor een software engineer om te hebben. Maar het heeft natuurlijk ook te maken met management en dus dacht ik dat het interessant zou zijn om te proberen te managen en dat heb ik geprobeerd en toen was het voor mij passend om terug te keren naar een meer individuele rol als medewerker. Er is genoeg dat je kunt doen in termen van leiderschap als een software engineer zonder te managen. En dat hoeft niet altijd het schrijven van code te zijn, dus ik schrijf waarschijnlijk meer code dan de meeste mensen met een gelijkwaardige anciënniteit omdat ik ervoor gekozen heb dat te doen en ik heb me actief verzet tegen dingen die een bredere impact zouden kunnen hebben maar die voor mij niet zo leuk zijn, zoals je kunt vaak veel tijd besteden aan het schrijven van ontwerpdocumenten en ja, ik schrijf nog steeds redelijk vaak documenten, meestal vrij informeel, maar ik ben geen grote fan van het schrijven van enorme documenten met allerlei stukjes en beetjes die voor niemand relevant zullen zijn. Ik zou veel liever snel tot de kern komen. Maar documenten schrijven om bij te dragen aan meerdere teams die zeggen Oké ik denk dat we allemaal dit probleem hebben. Laten we eens kijken of we samen tot een oplossing kunnen komen die een bredere impact heeft dan dat ik zelf code schrijf om dat probleem op te lossen. Ik denk dat één van de dingen waar je waarschijnlijk naar zou moeten streven als je meer ervaring krijgt, is om te zien waar die ervaring andere mensen kan helpen. Maar tot op zekere hoogte zal dat nog steeds coderen zijn, tot op zekere hoogte zal dat het delen van je kennis zijn met gebruikersgroepen en conferenties en zo. En door intern binnen een bedrijf problemen op te lossen die je misschien duidelijker kunt zien dan andere mensen die misschien minder ervaren zijn of net bij een team zijn gekomen of wat het ook is. Maar als het gaat om de vraag of mensen manager moeten worden of niet, zou ik persoonlijk denken dat het helemaal prima zou zijn als iemand meteen zou beginnen met managen zonder dat hij of zij dat werk zelf heeft gedaan. Als dat iets is waar ze goed in zullen zijn door empathie en leren, kun je leren wat een baan inhoudt zonder het te doen, zolang je je ervan bewust bent dat je het niet gedaan hebt en dus geen directe ervaring hebt. Dus ik denk niet dat er een directe correlatie zou moeten zijn tussen leeftijd en welk deel van de werknemers manager is. Ik hoop zeker dat ik tot ver na mijn pensionering nog steeds code schrijf en waarschijnlijk niet veel aan management zal doen. Als ik op een gegeven moment manager moet worden, zal ik dat zo goed mogelijk doen, maar ik denk niet dat het normaal gesproken een vereiste moet zijn en ik denk dat veel bedrijven het verkeerd doen door mensen te promoveren tot manager die eigenlijk veel gelukkiger en productiever zouden zijn als programmeur.

MARCIN: Wat het idee betreft dat je na 15 jaar software schrijven gewoon manager gaat worden en dat iedereen dat doet, ja, het is waarschijnlijk een verkeerd idee. Ik weet dat er een zekere druk is, tenminste in Silicon Valley in Californië, waar mensen zich zorgen maken dat ze bijvoorbeeld 29 zijn en te oud om aangenomen te worden door bedrijven die geobsedeerd zijn door het aannemen van mensen die 22, 23 of 24 zijn.

JON: Nou, ik zou niet willen worden aangenomen door een bedrijf dat geobsedeerd is om 22-jarigen aan te nemen. Ik zou veel liever werken voor een bedrijf dat mensen waardeert om wie ze zijn wat ze kunnen bereiken en wat ze samen kunnen bereiken. Dus niet alleen hun huidige vaardigheden, maar ook hun potentieel. Dus ik heb dat soort agisme zelf nog niet meegemaakt. Neem me niet kwalijk, maar ik ben me ervan bewust dat het een punt van zorg is. Ik zou zeker zeggen dat ik geen degradatie heb ervaren waar ik me bewust van ben in termen van mijn coderingsvaardigheden. Ik codeer nog steeds even gelukkig en productief als altijd. Voor zover ik weet. Dus ik hoop dat bedrijven rekening houden met dat soort dingen en mensen aannemen die het werk kunnen doen.

MARCIN: Denk je dat er iets goed is. Bijvoorbeeld, als we het hebben over alle andere beroepen. We hebben de neiging om te denken dat als iemand al 30 jaar natuurkunde doet, dat er dan niemand meer zal zeggen dat je niet meer weet waar je mee bezig bent. Is het zo dat software engineering zo nauw verbonden is met technologie en technologie die zich zo snel ontwikkelt dat mensen ervan uitgaan dat als je het al zoveel jaar doet, je er niet meer bij bent of is er iets dat software engineering onderscheidt van alle andere disciplines waardoor mensen het idee hebben dat iemand een bepaalde leeftijd heeft en bepaalde ideeën over die persoon heeft.

JON: Dat is misschien waar de indruk vandaan komt, maar ik zou zeggen dat het waarschijnlijk onjuist is. Je moet wel bereid zijn om nieuwe dingen te leren. Tenminste als je dat wilt zijn als je in staat wilt zijn om door te gaan op nieuwe en spannende gebieden. Als je al 30 jaar COBOL doet en besloten hebt om niets anders te leren dan COBOL dan weet ik zeker dat je nog productief kunt zijn en dat is prima. Maar je moet niet verwachten dat je een baan krijgt in JavaScript of iets dergelijks zonder enige interesse te hebben getoond om te blijven leren. Aan de andere kant ken ik eigenlijk alleen C# en Java tot een professioneel niveau omdat ik heb gemerkt dat er genoeg nieuwe dingen te leren zijn in C# ik heb niet genoeg tijd om F# en D en Rust en Go en allerlei dingen te leren andere mensen gaan breder en minder diep. Maar het is aan individuen hoeveel ze op zich willen nemen en je moet je ervan bewust zijn dat als je besluit om niet te leren als je besluit om te stoppen met leren dan zul je na verloop van tijd minder waardevol worden. Maar om eerlijk te zijn vermoed ik dat er genoeg legacysystemen zijn dat je voor de meeste talen nog redelijk waardevol zou kunnen zijn, zelfs als je zou besluiten om niet meer te leren. Eerlijk gezegd zie ik niet in waarom je zou willen stoppen met leren, want het is altijd interessant om nieuwe dingen te doen. Maar het kost wel veel tijd en ik denk dat bedrijven bereid moeten zijn om die tijd in hun ingenieurs te investeren, zodat ingenieurs niet het gevoel hebben dat ze dingen moeten leren in de tijd die ze anders bijvoorbeeld met hun gezin doorbrengen. Er is dus een behoorlijke hoeveelheid actieve ontwikkeling die deel moet uitmaken van je baan. Een deel van een goede Sopher-ingenieur zijn in je werkleven is nieuwe dingen leren. Voor de meeste ontwikkelaars zijn er, zoals ik al zei, wat meer verouderde gebieden waar dat niet zo relevant is, hoewel ik zou zeggen dat zelfs Cobol-ontwikkelaars die ermee door blijven gaan en nieuwe dingen blijven leren waarschijnlijk in staat zullen zijn om te zien hoe ze hun Cobol-vaardigheden hier in andere omgevingen kunnen toepassen. Misschien zijn er tegenwoordig containers die COBOL draaien en opeens heb je cloud-gebaseerde containersystemen die COBOL kunnen draaien en opeens kun je al je on-premise machines naar off-premise verplaatsen. Weet je, alleen omdat je een oude taal gebruikt, wil dat nog niet zeggen dat je voor al het andere ook oude technologie moet gebruiken. Dus er is ruimte voor alle soorten mensen die altijd het nieuwe willen leren, zoals een nieuwe taal. Mensen die alle technologische vaardigheden willen toepassen in nieuwe omgevingen en mensen die niet veel waarde zien in het leren van nieuwe dingen. Ja, ik kan zeggen dat ik me daar niet bijzonder in kan inleven, maar Software engineering is zo'n breed vakgebied dat ik er zeker van ben dat er nuttige productieve levens zijn die je kunt doen. Al je bestaande vaardigheden toepassen op steeds weer nieuwe uitdagingen. Ik zou C# 7 voor de rest van mijn leven kunnen gebruiken en nog steeds nieuwe dingen doen, zelfs als ik geen nieuwe eigenlijke taalgebieden leer. Het is niet wat ik wil doen, maar ik ben er zeker van voor andere mensen. Het kan meer de weg zijn die zij willen gaan.

MARCIN: En dat komt allemaal door het feit dat de meeste talen Turing compleet zijn en je dus alles kunt doen met elke taal die je kent. Ik bedoel het is heel algemeen gesproken

JON: Waarschijnlijk ben ik niet echt zeker. Ik denk dat talen evolueren, zeker C# is zeer zeker geëvolueerd voor de gebruikssituaties waarin het wordt ingezet, dus sommige van de functies die nu worden toegevoegd zouden 10 jaar geleden niet zo zinvol zijn geweest voordat cloud computing zeer wijdverspreid werd en we zien andere gebieden zoals gaming dat C# domineert in een bijna onverwachte met platforms zoals Unity. Dus er zijn taal functies die enigszins zijn afgestemd op gaming en lage latency high-performance computing en ik denk dat dat geweldig is. Maar ja, je zou dingen in andere talen of in eerdere versies van talen kunnen doen, maar het is veel productiever en interessanter om nieuwe functies te gebruiken omdat ze zijn ontworpen om met name jouw zorgen aan te pakken.

MARCIN: Wat is je favoriete IDE?

JON: Visual studio

MARCIN: Gebruikt u een bepaalde methodologie?

JON: Get Code Done. Ik gebruik Kanban niet of ik zou niet willen zeggen een specifieke methodologie zoals dat. Ik geloof in testen, niet noodzakelijk test gestuurde ontwikkeling maar op zijn minst test naast ontwikkeling soms test gestuurd het hangt af van de situatie. Ik voel me ongemakkelijk bij het hebben van veel productie code die niet getest is. Dus dat is één aspect van Agile ontwikkeling maar het is niet zo dat ik persoonlijk uiteindelijk alles van Agile gebruik. Ik doe niet veel aan pair programming. Ik heb het in het verleden wel gedaan en vond het erg nuttig. Ik heb in het verleden niet-paar-programmeren gedaan en vond het absoluut prima. Ik vind het wel belangrijk om een goede relatie te hebben met je collega's, dus code review is heel belangrijk voor mij en die code review moet eerlijk en open zijn. Maar dat is niet gebonden aan een bepaalde methodologie.

MARCIN: Welk advies zou je geven aan iemand die zich in dat gebied bevindt waar ze een taal aan het leren zijn voor laten we zeggen drie maanden drie tot zes maanden. En ze hebben het gevoel dat ze niet slim genoeg zijn om het goed te leren. Alsof er gewoon te veel fouten zijn om te herstellen. En weet je wat voor soort advies heb je voor die persoon die er wel interesse in heeft, maar het gevoel heeft dat ze gewoon niet over die hobbel heen komen.

JON: Dus als je nog steeds geïnteresseerd bent en je denkt dat je het leuk zou kunnen vinden als je het maar beter zou kunnen, zoek dan naar mensen. Dus of dat nu het lezen van blogs is of het vinden van een gebruikersgroep vindt mensen met wie je kunt communiceren en die je één op één kunt ontmoeten indien mogelijk, want het kan behoorlijk eenzaam zijn om antwoorden te vinden van achter een scherm. Als je iemand één op één ontmoet, kunnen ze vaak zien dat je een probleem hebt met je mentale model, dat je je iets verkeerd voorstelt, en dat kan heel moeilijk zijn om alleen maar uit individuele stukjes en beetjes te halen. Als je het niet leuk vindt, zoek dan een andere taal, want er zijn genoeg talen.

MARCIN: Welke programmeertaal is superieur, Java of C#?

JON: Persoonlijk zou ik zeggen C# Absoluut. Nu heb ik niet gekeken naar de details van de Java 9 functies en ik weet alleen de job rate functies soort van ish, maar het voelt voor mij alsof C# nam een aantal van de fouten die Java had gemaakt en maakte een aantal van de fout fouten zelf toegegeven. Maar over het algemeen, C# lijkt te zijn geweest het ontwikkelen van sneller en gewoon echt goed het C# team is fantastisch slim en gewoon echt voorzichtig over hoe ze taal te ontwikkelen. Dus we zijn in C# 7.2 en het voelt alsof het is gegaan in een zeer zeer goede richting het wordt beheerd zeer goed zeer goed gespecificeerd. Dat gezegd hebbende weet je Java is beter dan ooit en ik denk niet dat ik denk dat er genoeg in zit dat als je werkt aan een Java code basis je het allemaal weg zou moeten gooien en in plaats daarvan C# zou moeten gaan doen. Maar als ik op enig moment de keuze heb zou ik zeker C# kiezen op elke dag.

MARCIN: Geweldig! Jon Skeet bedankt dat je te gast was bij de Yellow Duck podcast. Als je links hebt die je me wilt sturen, en conferenties die je gaat doen, stuur me dan alle informatie.

JON: Dank u.

MARCIN: Yup, bedankt. Bye!

Post delen

Meer informatie over het inhuren van tech

Abonneer u op onze Learning Hub en ontvang nuttige inzichten rechtstreeks in uw inbox.

Verifieer en ontwikkel coderingsvaardigheden naadloos.

Zie DevSkiller producten in actie.

Beveiligingscertificeringen & naleving. Wij zorgen ervoor dat uw gegevens veilig en beveiligd zijn.

DevSkiller logo TalentBoost logo TalentScore logo