Wetenschappers op FOK! #22

Kinderen
Schrijven

Voor zover ik aan andere careers denk is het met name richting een meer administratieve functie (denk ik afdelings- of sectie-hoofd).

quote:

Op donderdag 27 augustus 2015 17:23 schreef Bosbeetle het volgende:
Code schrijven vind ik dan wel weer leuk Dan kun je tenminste testen of je het goed geschreven hebt. Bij gewoon schrijven vind ik mijn eigen teksten toch altijd ruk en er is geen goede test voor of het klopt.

Wel zelfs als je code prima werkt kan het nog erg slecht geschreven zijn hoor. Spaghetti code enzo, geen documentatie.

quote:

Op donderdag 27 augustus 2015 20:58 schreef Broomer het volgende:

[..]

Wel zelfs als je code prima werkt kan het nog erg slecht geschreven zijn hoor. Spaghetti code enzo, geen documentatie.

Klopt maar ik schrijf geen code om gelezen te worden het gaat mij erom dat de berekeningen mij verder helpen en het doet wat het moet doen...

Al begin ik nu op een punt te komen dat het meer op boekhouden dan op coderen lijkt

Maarja ik heb dan ook nooit leren programmeren.

quote:

Op donderdag 27 augustus 2015 21:15 schreef Bosbeetle het volgende:

[..]

Klopt maar ik schrijf geen code om gelezen te worden het gaat mij erom dat de berekeningen mij verder helpen en het doet wat het moet doen...

Al begin ik nu op een punt te komen dat het meer op boekhouden dan op coderen lijkt

Maarja ik heb dan ook nooit leren programmeren.

Ik heb ook nooit echt leren programmeren. Ik schrijf ook behoorlijk wat waar ik verder alleen zelf aan kom. Maar als ik het warrig geschreven heb en ik wil er wat aan veranderen na twee maanden, is het veel lastiger. Ik probeer nu steeds meer structuur en uitleg eraan te geven, ook voor mezelf als geheugensteuntje.

quote:

Op donderdag 27 augustus 2015 21:15 schreef Bosbeetle het volgende:

[..]

Klopt maar ik schrijf geen code om gelezen te worden het gaat mij erom dat de berekeningen mij verder helpen en het doet wat het moet doen...

Al begin ik nu op een punt te komen dat het meer op boekhouden dan op coderen lijkt

Maarja ik heb dan ook nooit leren programmeren.

Maar wat voor een berekeningen doe je dan? Vind dat wel interessant.

quote:

Op vrijdag 28 augustus 2015 00:18 schreef Broomer het volgende:

[..]

Ik heb ook nooit echt leren programmeren. Ik schrijf ook behoorlijk wat waar ik verder alleen zelf aan kom. Maar als ik het warrig geschreven heb en ik wil er wat aan veranderen na twee maanden, is het veel lastiger. Ik probeer nu steeds meer structuur en uitleg eraan te geven, ook voor mezelf als geheugensteuntje.

Ja dat doe ik ook steeds beter, voortschrijdend inzicht enzo.

quote:

Op vrijdag 28 augustus 2015 00:19 schreef Broomer het volgende:

[..]

Maar wat voor een berekeningen doe je dan? Vind dat wel interessant.

Ik ben vooral statistiek uit plaatjes aan het halen, dus signalen opzoeken, er lijntjes door trekken, intensiteiten meten, plaatjes roteren zodat ze recht liggen, plaatjes fitleren om andere statistiek eruit te halen, etc. en die statistiek weer terug relateren aan waar de plaatjes van waren.

Ook heb ik in R (ism shiny) een interface gebouwd om een grote hoeveelheid data (x en y coordinaten) om te zetten naar verschillende visualizatie methoden en daar relatief eenvoudige statistiek uit te halen. Voor onze gebruikers om ze zelf ook een handvat op hun data te geven.

Het gaat dus van eenvoudig gaussjes fitten tot euler-assen bepalen.

In mijn vrije tijd maak ik synthesizers en gitaar effecten in de visuele programeertaal pure data ook erg leuk om te doen

En ik geef les aan eerste jaars in basis java (for loopjes, array's, random genrators etc zo laten we studenten moleculen simuleren die random bewegen en daar vervolgens weer metingen aan te doen, om zo hopelijk een generatie biologen te kweken die niet bang zijn voor computers en niet alleen maar genetica willen doen)

[ Bericht 0% gewijzigd door Bosbeetle op 28-08-2015 09:18:45 ]

quote:

Op vrijdag 28 augustus 2015 09:05 schreef Bosbeetle het volgende:

[..]

Ja dat doe ik ook steeds beter, voortschrijdend inzicht enzo.

Tegenwoordig heb ik mezelf aangeleerd om gewoon leesbare code te schrijven. dat maakt debuggen of enhancen door anderen zoveel makkelijker. dus niet voor de korte 1-regel oplossingen gaan maar sommige dingen gewoon netjes uitschrijven.

quote:

Op donderdag 27 augustus 2015 17:23 schreef Bosbeetle het volgende:
Code schrijven vind ik dan wel weer leuk Dan kun je tenminste testen of je het goed geschreven hebt. Bij gewoon schrijven vind ik mijn eigen teksten toch altijd ruk en er is geen goede test voor of het klopt.

Same, om precies dezelfde redenen. Alhoewel ik praatjes maken dan weer wel leuk vind...

quote:

Op vrijdag 28 augustus 2015 09:28 schreef Maanvis het volgende:

[..]

Tegenwoordig heb ik mezelf aangeleerd om gewoon leesbare code te schrijven. dat maakt debuggen of enhancen door anderen zoveel makkelijker. dus niet voor de korte 1-regel oplossingen gaan maar sommige dingen gewoon netjes uitschrijven.

het probleem dat ik het meeste heb is dat ik van tevoren de functionaliteit nog niet duidelijk heb, dan maak ik iets dan werkt en dan zegt bijvoorbeeld mijn baas en als je nu hier op die grafiek klikt dan wil ik alle plaatjes zien die bij die bin van dat histogram horen en dan ben ik weer getriggerd om dat te maken maar daar is de backbone niet voor gemaakt... daardoor wordt mijn code vaak nogal hacky en patchy.

De grap is dat dit altijd gebeurt omdat we hier met een stel wetenschappers zitten en dingen nooit af zijn we willen altijd meer weten een afgerond iets is saai.

Slecht is dat he, hoe onze generatie heeft leren programmeren.

En tot een jaar of vijf-tien geleden kon dat nog, met je huis-tuin-en-keuken programmatuur op niveau concurreren. Maar tegenwoordig wordt er veel meer gevraagd.

Ik heb laatst met een professionele programmeur mogen samenwerken, en die lui denken op een heel ander niveau. Dat zijn geen programmeurs meer, maar software-architecten. Hun code is niet alleen veel beter leesbaar, ze denken op een hele andere manier over de software na. Bij ons is de enige drijfveer dat het moet werken, en wel zo snel mogelijk, terwijl zij er over nadenken hoe je de software kunt uitbouwen, zonder dat je alles opnieuw hoeft te schrijven.

Op universiteiten moet dan volgens mij ook het roer om, met name bij de technische disciplines: de helft van het curriculum wordt besteed aan wiskunde en aan een opleiding tot software architect, en de andere helft aan of werktuigbouw, of chemie, of electro, etc. Mijn ervaring is dat juist die architect houding, hoe je kunt bouwen op wat je hebt, je ook een voordeel geeft bij de aanpak van je project, of dat nou als werktuigbouwer, chemicus of electronicus is.

quote:

Op vrijdag 28 augustus 2015 09:59 schreef Lyrebird het volgende:
Slecht is dat he, hoe onze generatie heeft leren programmeren.

En tot een jaar of vijf-tien geleden kon dat nog, met je huis-tuin-en-keuken programmatuur op niveau concurreren. Maar tegenwoordig wordt er veel meer gevraagd.

Ik heb laatst met een professionele programmeur mogen samenwerken, en die lui denken op een heel ander niveau. Dat zijn geen programmeurs meer, maar software-architecten. Hun code is niet alleen veel beter leesbaar, ze denken op een hele andere manier over de software na. Bij ons is de enige drijfveer dat het moet werken, en wel zo snel mogelijk, terwijl zij er over nadenken hoe je de software kunt uitbouwen, zonder dat je alles opnieuw hoeft te schrijven.

Op universiteiten moet dan volgens mij ook het roer om, met name bij de technische disciplines: de helft van het curriculum wordt besteed aan wiskunde en aan een opleiding tot software architect, en de andere helft aan of werktuigbouw, of chemie, of electro, etc. Mijn ervaring is dat juist die architect houding, hoe je kunt bouwen op wat je hebt, je ook een voordeel geeft bij de aanpak van je project, of dat nou als werktuigbouwer, chemicus of electronicus is.

Klopt! Wij hebben ook een programmeur in dienst die hele mooie dingen doet.

Die heeft een simulatie software ontwikkeld met weer een eigen taal die voor biologen eenvoudig te snappen is en die zo hun eigen simulaties kunnen bouwen...

In Maart promoveren
1 september de pedel bellen

quote:

Op vrijdag 28 augustus 2015 10:34 schreef Norrage het volgende:
In Maart promoveren
1 september de pedel bellen

Whoei!

2 maart is er geprikt

Gefeliciteerd!

Bij mij is ook het einde in zicht, dit jaar nog "abgeben" (geen idee of er een Nederlands woord voor is). Verdediging dan ook begin volgend jaar waarschijnlijk.

[ Bericht 0% gewijzigd door Felagund op 01-09-2015 18:58:42 ]

quote:

Op vrijdag 28 augustus 2015 09:57 schreef Bosbeetle het volgende:

[..]

het probleem dat ik het meeste heb is dat ik van tevoren de functionaliteit nog niet duidelijk heb, dan maak ik iets dan werkt en dan zegt bijvoorbeeld mijn baas en als je nu hier op die grafiek klikt dan wil ik alle plaatjes zien die bij die bin van dat histogram horen en dan ben ik weer getriggerd om dat te maken maar daar is de backbone niet voor gemaakt... daardoor wordt mijn code vaak nogal hacky en patchy.

De grap is dat dit altijd gebeurt omdat we hier met een stel wetenschappers zitten en dingen nooit af zijn we willen altijd meer weten een afgerond iets is saai.

De truuk is die functionaliteit vantevoren duidelijk te krijgen, en zelf de roadmap voor je projecten uit te denken ipv slaafs de baas te volgen. En als je dan toch zo'n baas hebt die telkens iets anders wil dan kun je vantevoren met hem samen gaan zitten en de requirements opstellen dmv de MoSCoW-methode. Omdat ik voor klanten programmeer is het eigenlijk wel essentieel om vantevoren die requirements goed vast te leggen omdat er anders verwachtingen ontstaan die niet nagekomen worden.

quote:

Op vrijdag 28 augustus 2015 09:59 schreef Lyrebird het volgende:
Slecht is dat he, hoe onze generatie heeft leren programmeren.

En tot een jaar of vijf-tien geleden kon dat nog, met je huis-tuin-en-keuken programmatuur op niveau concurreren. Maar tegenwoordig wordt er veel meer gevraagd.

Ik heb laatst met een professionele programmeur mogen samenwerken, en die lui denken op een heel ander niveau. Dat zijn geen programmeurs meer, maar software-architecten. Hun code is niet alleen veel beter leesbaar, ze denken op een hele andere manier over de software na. Bij ons is de enige drijfveer dat het moet werken, en wel zo snel mogelijk, terwijl zij er over nadenken hoe je de software kunt uitbouwen, zonder dat je alles opnieuw hoeft te schrijven.

Op universiteiten moet dan volgens mij ook het roer om, met name bij de technische disciplines: de helft van het curriculum wordt besteed aan wiskunde en aan een opleiding tot software architect, en de andere helft aan of werktuigbouw, of chemie, of electro, etc. Mijn ervaring is dat juist die architect houding, hoe je kunt bouwen op wat je hebt, je ook een voordeel geeft bij de aanpak van je project, of dat nou als werktuigbouwer, chemicus of electronicus is.

Dat bleek ook uit enquetes van natuurkunde-alumni van de RUG zo'n negen jaar geleden.

quote:

Op woensdag 2 september 2015 18:11 schreef Maanvis het volgende:

[..]

De truuk is die functionaliteit vantevoren duidelijk te krijgen, en zelf de roadmap voor je projecten uit te denken ipv slaafs de baas te volgen. En als je dan toch zo'n baas hebt die telkens iets anders wil dan kun je vantevoren met hem samen gaan zitten en de requirements opstellen dmv de MoSCoW-methode. Omdat ik voor klanten programmeer is het eigenlijk wel essentieel om vantevoren die requirements goed vast te leggen omdat er anders verwachtingen ontstaan die niet nagekomen worden.

Zo werkt wetenschap niet, we weten van tevoren niet wat eruit gaat komen en ook niet wat we willen. Er zijn wel wat op voorhand duidelijke zaken die je wilt hebben van data (en daarvoor moet geprogrammeerd worden) maar vervolgens geven die zaken weer inzicht in waar er nieuwe doelen liggen. Als dat van te voren precies te bepalen was dan deden we iets wat al duidelijk was en dus niet wetenschappelijk relevant.

(simpel voorbeeld we de hypothese dat een stuctuur in een plaatje langer wordt, dan maak je een programma om de lengte te meten, om de lengte te meten moet je de hoek ook bepalen zodat de lengte goed bepaald kan worden, als er dan blijkt dat de lengte en de hoek afhankelijk zijn van elkaar maar niet in alle gevallen alleen in gevallen waar blijkt dat de sturcturen meer samenvallen in één plek, dan moet je vervolgens dus dichtheden van stucturen gaan bepalen en dat moet in hetzelfde framework etc etc. Als je dat al van te voren wist dan had je het hele programma niet hoeven schrijven... etc. m.a.w. de vraagstelling en moscows veranderen tijdens het project omdat de doelstelling slechts is "duid de data")

[ Bericht 20% gewijzigd door Bosbeetle op 02-09-2015 18:56:43 ]

quote:

Op woensdag 2 september 2015 18:48 schreef Bosbeetle het volgende:

[..]

Zo werkt wetenschap niet, we weten van tevoren niet wat eruit gaat komen en ook niet wat we willen. Er zijn wel wat op voorhand duidelijke zaken die je wilt hebben van data (en daarvoor moet geprogrammeerd worden) maar vervolgens geven die zaken weer inzicht in waar er nieuwe doelen liggen. Als dat van te voren precies te bepalen was dan deden we iets wat al duidelijk was en dus niet wetenschappelijk relevant.

(simpel voorbeeld we de hypothese dat een stuctuur in een plaatje langer wordt, dan maak je een programma om de lengte te meten, om de lengte te meten moet je de hoek ook bepalen zodat de lengte goed bepaald kan worden, als er dan blijkt dat de lengte en de hoek afhankelijk zijn van elkaar maar niet in alle gevallen alleen in gevallen waar blijkt dat de sturcturen meer samenvallen in één plek, dan moet je vervolgens dus dichtheden van stucturen gaan bepalen en dat moet in hetzelfde framework etc etc. Als je dat al van te voren wist dan had je het hele programma niet hoeven schrijven... etc. m.a.w. de vraagstelling en moscows veranderen tijdens het project omdat de doelstelling slechts is "duid de data")

Het is dus de taak van je baas om na te gaan welke mogelijke hypotheses er nog meer zijn. Ik werk in een bullshit sector (zie jouw topique over bullshit banen), de marketing. Het is daar de kunst om niet te sturen op wat marketeers zeggen maar om echt te meten aan de hand van de data die je ontvangt. Zo was er ooit een site die meer animated gifs had dan hyves. Elke marketeer zei dat die wel weinig conversie zou draaien. Maar het omgekeerde bleek waar, hij draaide juist veel conversie. Tegenwoordig is opslag geen issue meer, dus je kunt alle mogelijke data opslaan. Dus dat het framework er niet voor geschikt is zal steeds minder een issue zijn.

[ Bericht 3% gewijzigd door Maanvis op 02-09-2015 21:48:11 ]

quote:

Op woensdag 2 september 2015 21:42 schreef Maanvis het volgende:
Het is dus de taak van je baas om na te gaan welke mogelijke hypotheses er nog meer zijn.

Niet alleen van mijn baas maar ook van mij en de AiOs bij ons... En ook van andere professoren waarmee we samenwerken. En dan nog kun je meestal de uiteindelijke metingen niet gaan voorspellen. Daarom zou bij ons in het fundamentele onderzoek zo'n journal waar je vantevoren de design van je proeven neer zou moeten leggen nooit kunnen werken. Omdat je altijd tegen proeven aanloopt die je van te voren niet bedacht had. (als ik alles van te voren had kunnen bedenken had ik mijn thesis in pak hem beet een half jaar kunnen schrijven.)

quote:

Op woensdag 2 september 2015 21:42 schreef Maanvis het volgende:
Het is daar de kunst om niet te sturen op wat marketeers zeggen maar om echt te meten aan de hand van de data die je ontvangt. Zo was er ooit een site die meer animated gifs had dan hyves. Elke marketeer zei dat die wel weinig conversie zou draaien. Maar het omgekeerde bleek waar, hij draaide juist veel conversie. Tegenwoordig is opslag geen issue meer, dus je kunt alle mogelijke data opslaan. Dus dat het framework er niet voor geschikt is zal steeds minder een issue zijn.

Maar juist als je exploratief bezig bent dan is het vooropstellen van dit gaan we doen niet meer exploratief, dan begrens je jezelf heel erg en kom je uiteindelijk niet verder dan de oppervlakte.

oke,conclusie: in de wetenschappelijke wereld wordt patchy hacky crapcode geschreven en men is te eigenwijs om daar iets aan te doen. Note to self: ga nooit voor de wetenschap code schrijven.

Goed verhaal.

quote:

Op donderdag 3 september 2015 09:38 schreef Maanvis het volgende:
oke,conclusie: in de wetenschappelijke wereld wordt patchy hacky crapcode geschreven en men is te eigenwijs om daar iets aan te doen. Note to self: ga nooit voor de wetenschap code schrijven.

Zijconclusie: in de wetenschap moet je als programmeur iets flexibeler zijn en soms buiten het framework treden om nieuwe dingen voor elkaar te krijgen. Als dat niet je ding is, vooral geen wetenschapper worden. Trouwens de code hoeft niet altijd patchy en crappy te zijn maar vooral zonder restricties... "Dat kan niet" is iets wat je in de programmeer wereld te vaak hoort, En dat betekent meestal "Dat is lastig" of "ik moet daarvoor teveel code aanpassen" en het is aan wetenschappelijke programmeur om goed een verschil te maken tussen wat echt niet kan en wat gewoon veel tijd kost en wat zoveel tijd kost dat het de moeite niet is omdat het dan over 5 jaar nog niet klaar is.