De Devschuur Coffee Corner - Iteratie ⓫

[Hydra]

wackmaniac schreef op vrijdag 13 oktober 2017 @ 15:55:
Wat wel opvalt dat het met name de techneuten mensen die moeten kunnen nadenken zijn die niet in een kantoortuin willen werken.

FTFY.

[Crazy D]

Het nadeel van een kantoortuin vind ik dat je erg geneigd bent mee te luisteren/mee te praten. Wat je productiviteit niet bevordert. Of juist dat mensen je meteen bij een overlegje betrekken. Wat ook niet altijd lekker is voor je productiviteit.

Hoewel ik nu niet in een kantoortuin zit maar wel een kamer met 6 man en waar veel overleg is.... kansloos voor je productiviteit, letterlijk halve dagen kwijt aan aanhoren van discussies tussen anderen, die je er vervolgens toch nog even bij betrekken "want je weet er wast van af, of je hebt altijd overal een mening over". Doe mij dan maar mijn eigen hokje en plan gewoon een overleg in, liefst staand dan houdt iedereen het lekker kort, en daarna snel weer nuttige dingen doen.

[Ryur]

Defector schreef op vrijdag 13 oktober 2017 @ 15:19:
[...]


En wat zei het management toen jij dit aanstipte in het vragenrondje na de aankondiging?

Wat ik veel zie bij veranderingen naar kantoortuin:
De 'werkvloer' (dus in dit geval de ontwikkelaars) gaan naar een open kantoor/kantoortuin & juist het MT gaat dan richting 'hokjes'.



(Note: ik snap de keuze, kantoortuin kost minder geld qua aanschaf, maar op de lange termijn kost het meer -> minder productief)

[Onbekend]

Bij ons werkt een kantoortuin (8 developers) wel redelijk. Je hebt wel regelmatig discussies die je hoort, maar wel over het ontwikkelwerk zelf en andere zaken die bijna iedereen aangaan.
Je eigen werk leidt er wel onder, maar gezamenlijk heb je wel meer gepresteerd doordat je tijdens "de vergaderingen" je eigen werk kunt doen als er niks bijzonders wordt besproken, maar je wel je collega snel verder kunt helpen.

[ Voor 6% gewijzigd door Onbekend op 13-10-2017 20:09 ]

[cracking cloud]

Crazy D schreef op vrijdag 13 oktober 2017 @ 18:27:
Het nadeel van een kantoortuin vind ik dat je erg geneigd bent mee te luisteren/mee te praten.

Dit dus. Ik denk dat dit de kern is. Maar je kan jezelf ook trainen om niet mee te luisteren. Dacht in het begin ook dat me dat niet zou lukken, maar het lukt nu best goed.
Natuurlijk is iedereen anders, het schijnt dat ongeveer een kwart van de developers het liever helemaal stil heeft op kantoor (bron)

[Crazy D]

cracking cloud schreef op vrijdag 13 oktober 2017 @ 20:08:
Dit dus. Ik denk dat dit de kern is. Maar je kan jezelf ook trainen om niet mee te luisteren. Dacht in het begin ook dat me dat niet zou lukken, maar het lukt nu best goed.

Als het over andere dingen gaat geen probleem, maar als het wel jouw bezigheden raakt/betrekking heeft op, vind ik dat een heel stuk lastiger.

[Down]

Defector schreef op vrijdag 13 oktober 2017 @ 15:19:
[...]


En wat zei het management toen jij dit aanstipte in het vragenrondje na de aankondiging?

Het vragenrondje komt denk ik na de verhuzing .

Ik heb om opheldering gevraagd en werd gerust gesteld met de opmerking dat het erg mooi, strak en modern is allemaal. Tja. Management krijgt wel hun eigen kantoortjes zo te zien.

[Neko Koneko]

Managers: de meest nutteloze uitvreters in elke organisatie Kosten het meest, voegen het minst toe. En maar rondsjeezen in de dikke leasebakken en belangrijk doen.

* Neko Koneko heeft een gigantische hekel aan managers.

[Verwijderd]

Down schreef op vrijdag 13 oktober 2017 @ 23:55:
[...]


Het vragenrondje komt denk ik na de verhuzing .

Ik heb om opheldering gevraagd en werd gerust gesteld met de opmerking dat het erg mooi, strak en modern is allemaal. Tja. Management krijgt wel hun eigen kantoortjes zo te zien.

Met twee tot vier developers in één hok vind ik niet zo vervelend, aangenomen dat ze het niet te gezellig maken onderling. Met maar dan 8 mensen wordt het al snel chaotischer.

Je zou verwachten dat het voor het MT het handigste is als jij op je productiefst bent, maar de praktijk wijst helaas vaak anders uit.

Ik ben in het verleden vanwege een verbouwing op kantoor ooit van een eigen kantoor in zo'n tuin met 20 a 30 man terecht gekomen, en helaas stond de koffieautomaat ook nog 3 meter naast mij. Ik denk dat je je wel een inbeelding kan maken wat dat met mijn productiviteit deed. Tegenwoordig zit ik met één iemand anders in een ruimte waarbij de werktijden niet helemaal overeenkomen (en ik dus ook wekelijks nog een goed aantal uur alleen zit), wat een verademing.

[Antrax]

Spectaculous schreef:
Met twee tot vier developers in één hok vind ik niet zo vervelend, aangenomen dat ze het niet te gezellig maken onderling. Met maar dan 8 mensen wordt het al snel chaotischer.

Ik herken dit beeld. Wanneer je dan een noise-cancelling headset opzet om je te kunnen concentreren kun je vervolgens op gesprek komen omdat je je zgn. afsluit van de rest van het team

[Verwijderd]

Antrax schreef op maandag 16 oktober 2017 @ 09:10:
[...]
Ik herken dit beeld. Wanneer je dan een noise-cancelling headset opzet om je te kunnen concentreren kun je vervolgens op gesprek komen omdat je je zgn. afsluit van de rest van het team

Dat had zo uit mijn biografie kunnen komen

[ThomasG]

Ik mag niet klagen. Wij hebben het als ontwikkelaars redelijk luxe ten opzichte van de rest. Waarbij de rest het moet doen met flexplekken in redelijk volle ruimtes, hebben wij ontwikkelaars allemaal een eigen werkplek in een ruimte die eigenlijk te groot is voor ons (maar minder praktisch voor de rest). We hebben geen last van elkaar, en hebben onze eigen vergadertafel erbij kunnen zetten. Plus, de koffieautomaat en printer staan op een steenworp afstand op de gang; en hebben omdat we boven in zitten met panorama ramen een mooi uitzicht over de binnenstad van Amsterdam

[whoami]

Ik heb eigenlijk al altijd in een kantoortuin gewerkt. En eigenlijk vind ik dat niet zo erg; al kan ik me inbeelden dat een eigen kantoor wel prettiger werkt en, als je dat eenmaal gewoon bent, je niet meer terug wil.
Dit waren wel telkens ruimtes met een beperkt aantal developers; vorige werkgever een 12-tal developers, nu varieert het. Wat ik dan wel weer vervelend vond, was dat andere mensen (helpdesk, sales, zomaar kwamen binnengelopen en je begonnen lastig te vallen met allerhande vragen).

Al kan je wel vlugger gestoord zijn in een kantoortuin, je pikt wel eens wat dingen op, wat ik dan wel weer interessant vind.

Bij mijn huidige werkgever kan ik wel vrijwel ongelimiteerd van thuis uit werken, dat is dan ook wel weer prettig. (Al beperk ik dat tot hooguit 2 dagen per week; meestal slechts één dag per week)

[ Voor 20% gewijzigd door whoami op 16-10-2017 10:50 ]

[Sebazzz]

Ik denk dat het een gevalletje "niet beter weten" is. Ik heb ook altijd al in een kantoortuin gewerkt dus ik heb er niet echt problemen mee. Als ik mijzelf wil afzonderen zet ik simpelweg mijn koptelefoon met muziek op. Makkelijk toch?

[DeluxZ]

In ons vorige pand zaten we allemaal in hokken met xx personen, in mijn geval met 7 man max. Toen was het bij ons luidruchtiger als nu in een kantoortuin. In ons "deel" is er plek voor 18 man. We hebben dan ook niet echt een kantoortuin waar 30+ personeel kan zitten

[hackerhater]

cracking cloud schreef op vrijdag 13 oktober 2017 @ 20:08:
Dit dus. Ik denk dat dit de kern is. Maar je kan jezelf ook trainen om niet mee te luisteren. Dacht in het begin ook dat me dat niet zou lukken, maar het lukt nu best goed.

Niet perse! Mensen met een autistische inslag, zoals ik, kunnen dit niet!
Ik haat kantoortuinen, zeker als sales er ook nog bij zit.
Waarom doen veel bedrijven dit toch?

Nu heb ik in mijn eerste baan veel thuisgewerkt en ben nu partime ondernemer.
De rust en wat je dan voor elkaar krijgt

[ Voor 11% gewijzigd door hackerhater op 16-10-2017 11:42 ]

[Hydra]

Niemand nog hierover iets gezegd? Valt me tegen

TL;DR: WPA-2 is op dit moment net zo lek als WEP.

[hackerhater]

Tijd voor WPA-3, meer valt er niet over te zeggen

[roeleboel]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[m-vw]

Neko Koneko schreef op maandag 16 oktober 2017 @ 08:34:
Managers: de meest nutteloze uitvreters in elke organisatie Kosten het meest, voegen het minst toe. En maar rondsjeezen in de dikke leasebakken en belangrijk doen.

* Neko Koneko heeft een gigantische hekel aan managers.

"Management is een vorm van verborgen werkloosheid." - René ten Bos, Denker des Vaderlands

* m-vw kijkt naar z'n eigen functie

[alienfruit]

Kantoortuinen zijn gewoon waardelos? Maar een ruimte met 30 man dat is toch niks? Ik heb vaak op open verdiepingen gewerkt aan een 'breakouttafel' tussen de call centre medewerkers in omdat er niet genoeg werkplekken waren. Later kwamen om op een rustige verdieping om vervolgens naast zo'n breakouttafel te zitten waar ze om de haverklap vergaderen. Rete irritant. Doe mij maar kleine kantoortjes

[Harrie_]

Die kantoortuinen zijn bedacht door managers die het idee hebben dat, wanneer je maar een groot en vooral divers team samen in één zaal mietert, iedereen automatisch met elkaar begint te communiceren als een soort collective hivemind en alle problemen dan als sneeuw voor de zon verdwijnen. In die utopische werkelijkheid is het kennelijk zo dat iedereen vanuit de wirwar van informatie, geluid en prikkels alle relevante zaken weet te extrapoleren

[alienfruit]

Kunnen ze beter die managers samen zetten. Maar goed, mijn directe bazen zitten ook gewoon in de kantoortuin en niet in een kantoortje. Als je als management besluit de kantoortuin weg in te slaan moet je zelf ook meedoen.

[ Voor 68% gewijzigd door alienfruit op 16-10-2017 12:59 ]

[ZaZ]

Hydra schreef op maandag 16 oktober 2017 @ 11:47:
Niemand nog hierover iets gezegd? Valt me tegen

TL;DR: WPA-2 is op dit moment net zo lek als WEP.

We zijn tweakers hier. Veel te druk bezig op zoek naar naaktfoto's van de buurvrouw op hun netwerk.

[ThomasG]

Harrie_ schreef op maandag 16 oktober 2017 @ 12:56:
Die kantoortuinen zijn bedacht door managers die het idee hebben dat, wanneer je maar een groot en vooral divers team samen in één zaal mietert, iedereen automatisch met elkaar begint te communiceren als een soort collective hivemind en alle problemen dan als sneeuw voor de zon verdwijnen. In die utopische werkelijkheid is het kennelijk zo dat iedereen vanuit de wirwar van informatie, geluid en prikkels alle relevante zaken weet te extrapoleren

Het kan werken, als er genoeg ruimte tussen de werkplekken zit en de ruimte niet te gehorig is. Veelal zit iedereen dan echter te dicht op elkaar, en is er een soort echo in de ruimte. Veel kantoortuinen zijn volgens mij gewoon ontstaan uit ruimte gebrek, omdat je door het ontbreken van de muren een paar mensen meer kwijt kan.

[Sebazzz]

We hebben hier geluidsdempende vloerbedekking. Dat scheelt echt een hoop

[hackerhater]

Dat zou kunnen werken, maar de meeste kantoortuinen zijn harde wanden en harde vloeren.
Hallo echo's en ver dragend geluid.

[armageddon_2k1]

wackmaniac schreef op vrijdag 13 oktober 2017 @ 15:55:
[...]


De vraag is inderdaad waarom er gekozen is voor een kantoortuin. Heb jaren in een heel open kantoor gezeten en ik had er zelf weinig moeite mee. Wat wel opvalt dat het met name de techneuten zijn die niet in een kantoortuin willen werken.

Ik ben ook techneut, maar niet IT. Ik zit in productontwikkeling en hebben dus fysieke prototypes liggen, moeten naar testlabs gaan etc etc. Ook wij hebben een kantoortuin en ik vind het in 90% van de gevallen goed werken omdat we heel snel kunnen overleggen.

Echter, die ene 10% moet ik echt hard nadenken om te zorgen dat alles consistent is in documentatie en veiligheidsrisico's en werkt het echt niet. Koptelefoon op een gaan met die banaan, maar dan nog zijn er mensen die gaan zwaaien. De drempel om te discussieren ligt heel laag. Dat is positief en negatief.

Ik denk dat het voor een 'programmeerbaan' (om het even oneerbiedig te zeggen) echt niet chill is. Je moet hard nadenken en focus hebben. Het is moeilijk om abstract te denken met afleiding om je heen.

P.s.: Vloerbedekking en veel planten hier en een hoog plafond. Echt hoog. 7 meter of iets dergelijks. Dat helpt ook wel.

[ Voor 5% gewijzigd door armageddon_2k1 op 16-10-2017 13:31 ]

[Harrie_]

armageddon_2k1 schreef op maandag 16 oktober 2017 @ 13:30:
[...]
Ik denk dat het voor een 'programmeerbaan' (om het even oneerbiedig te zeggen) echt niet chill is. Je moet hard nadenken en focus hebben. Het is moeilijk om abstract te denken met afleiding om je heen.

Dit.

[Vincentio]

Over kantoortuinen gesproken:
Microsoft bouwt boomhutten voor zijn werknemers

Als techbedrijf moet je er wat voor over hebben om werknemers aan je te binden. Microsoft bouwt daarom boomhutten voor zijn medewerkers.

De nieuwe werkplekken, die zijn ontworpen door Pete Nelson van het tv-programma Treehouse Masters, moeten werknemers helpen om ‘in contact te komen met de natuur en elkaar’, schrijft Natalie Singer-Velush op het Microsoft-blog. “Uit onderzoek blijkt dat aanwezigheid in de natuur de creativiteit, de focus en het geluk verbetert”, stelt Microsoft in een begeleidende video.

[hackerhater]

Echt sommige bedrijven bij sollicitaties.
Vonden mijn project niet overal senior niveau.
Buiten dat ik ze had gezegd dat dat framework nog beta-code is, is het een 6 jaar oud project.
Een framework waar je duidelijk kan zien wat nog van V1, V1.5 en nu V2 is.

Natuurlijk zijn er nog oudere onderdelen die niet zo netjes zijn. Deels "If aint't broke, don't fit it" en deels voor backwards-compatibility (+ @deprecated)

[armageddon_2k1]

Vincentio schreef op maandag 16 oktober 2017 @ 14:24:
Over kantoortuinen gesproken:
Microsoft bouwt boomhutten voor zijn werknemers


[...]

Was nog ergens een potje over denk ik en dat moest op, anders wordt het potje volgend jaar kleiner.

[wackmaniac]

hackerhater schreef op maandag 16 oktober 2017 @ 14:34:
Echt sommige bedrijven bij sollicitaties.
Vonden mijn project niet overal senior niveau.
Buiten dat ik ze had gezegd dat dat framework nog beta-code is, is het een 6 jaar oud project.
Een framework waar je duidelijk kan zien wat nog van V1, V1.5 en nu V2 is.

Natuurlijk zijn er nog oudere onderdelen die niet zo netjes zijn. Deels "If aint't broke, don't fit it" en deels voor backwards-compatibility (+ @deprecated)

Waarom kijken zij dan naar een project van 6 jaar oud? Als je dat laat zien dan kan je er vanuit gaan het niet representatief is voor je huidige niveau. Toch?

[hackerhater]

wackmaniac schreef op maandag 16 oktober 2017 @ 14:49:
Waarom kijken zij dan naar een project van 6 jaar oud? Als je dat laat zien dan kan je er vanuit gaan het niet representatief is voor je huidige niveau. Toch?

Het is een framework wat gestart is 6 jaar geleden. Daar is op doorgebouwd tot de dag van vandaag.
De nieuwste onderdelen zijn juist van hoog niveau.
Parsers die vloeiend blade-syntax (templates), entities (doctrine codering) e.d. kunnen lezen.
De autoloader die de code van het oude systeem en het nieuwe volgens PSR kan inladen + automatische dependency injection.
En ook nog in debugging modes (dus geen cache) sneller dan symfony kan

Alleen zijn er onderdelen die een stuk ouder zijn, maar zolang ze hun werk doen en duidelijk zijn,
waarom veranderen/vervangen?

[ Voor 17% gewijzigd door hackerhater op 16-10-2017 14:56 ]

[Alex)]

Dat je code hebt die het doet is één, maar je moet ook nog goed kunnen vertellen waarom het dat doet. Misschien bedoelen ze dat?

[hackerhater]

Diegene waar ik mee praatte was de eigenaar en hij zou het bespreken met zijn lead.
Ik had gezegd dat een project met beta-code was en meerdere versies in de code.
En waarom die syntax overnemen heb ik ook uitgelegd. Het maakt het makkelijker het framework te gebruiken als je bestaande syntax gebruikt (grotere kans dat de programmeur het kent).
Maar of dat gerelayed was?

Maar sowieso, het is een github repo.
Je kan zo zien wat nieuwer en wat ouder is.

[ Voor 24% gewijzigd door hackerhater op 16-10-2017 15:09 ]

[Harrie_]

Vincentio schreef op maandag 16 oktober 2017 @ 14:24:
Over kantoortuinen gesproken:
Microsoft bouwt boomhutten voor zijn werknemers

Lekker buiten in het zonnetje; de gemiddelde developer kan daar volgens mij helemaal niet tegen

[Not Pingu]

hackerhater schreef op maandag 16 oktober 2017 @ 15:08:
Diegene waar ik mee praatte was de eigenaar en hij zou het bespreken met zijn lead.
Ik had gezegd dat een project met beta-code was en meerdere versies in de code.
En waarom die syntax overnemen heb ik ook uitgelegd. Het maakt het makkelijker het framework te gebruiken als je bestaande syntax gebruikt (grotere kans dat de programmeur het kent).
Maar of dat gerelayed was?

Maar sowieso, het is een github repo.
Je kan zo zien wat nieuwer en wat ouder is.

Als je zelf al allerlei kanttekeningen erbij moet plaatsen, kun je je afvragen of je dat wel als voorbeeld moet gebruiken van je kennis.
Heb zelf ook wel eens meegemaakt dat een kandidaat vol trots eigen source code laat zien, maar ik er niet van onder de indruk ben, en als antwoord krijg 'dat het al oude code is en niet representatief'. Laat het dan gewoon niet zien, het is niet verlicht om eigen code te laten zien.

Of schrijf een nieuw projectje en zet dat op Github. Als je per sé code wil laten zien hoeft het niet meteen een gigantisch project te zijn.

[hackerhater]

Tjah ik heb niet bepaald de tijd om naast mijn gewone werk, mijn eigen bedrijfje e.d. en het onderhouden van dit gebruikte! framework nog een ander stuk code te maken en te onderhouden.

Het gros van de code heb ik nu eenmaal geen copyright op en kan ik niet laten zien.
En waarom het nog beta-code is: tjah ik had niet verwacht geen contract verlenging te krijgen dus ja de code is niet helemaal presentabel op dit moment.

[Alex)]

hackerhater schreef op maandag 16 oktober 2017 @ 15:42:
...het onderhouden van dit gebruikte! framework...

Dat iets wordt gebruikt betekent niet per definitie dat het goed is hè.

[hackerhater]

Alex) schreef op maandag 16 oktober 2017 @ 16:30:
[...]

Dat iets wordt gebruikt betekent niet per definitie dat het goed is hè.

Nope, maar het betekend dat ik het project niet zomaar kan laten vallen
En dat ik rekening moet houden met backwards compatibility om niet een hoop mensen pissed te maken.

[Alex)]

Genoeg mensen die precies dat doen hoor.

Kijk maar naar de Javascript-wereld...

[hackerhater]

True, maar laat ik zo zeggen:
Daar is mijn standaard te hoog voor.
Maar meer mensen op het project zou fijn zijn, de load wat spreiden.

Naar mijn mening zijn general purpose frameworks veel moeilijker dan gewone programma's.
Omdat je met zoveel dingen rekening moet houden, de flexibiliteit erin houden, duidelijke API's, etc.

[ Voor 41% gewijzigd door hackerhater op 16-10-2017 16:43 ]

[Alex)]

hackerhater schreef op maandag 16 oktober 2017 @ 16:40:
Daar is mijn standaard te hoog voor.

Maar dat weet degene aan wie je jezelf probeert te verkopen niet. Die ziet iemand die d'r eigen werk afkraakt met opmerkingen als 'dit is oud' en 'dit is beta'.

[hackerhater]

De oude stukken laat ik natuurlijk niet zien tijdens een demonstratie.
Dan laat ik die nieuwe stukken zien. Ik ben niet gek.
Ik zeg als ze de repository verder willen bekijken dat dit de dev-versie is en dat dus niet alles netjes is.

1 ding heb ik wel veranderd tegenover doctrine:
Als je in "mijn" entities database acties wilt doen: Zet de query-builder/DAL in je enity-constructor en ga je gang.
Dat is namelijk iets wat me in Symfony altijd geirriteerd heeft:P
Dat je niet de optie hebt in een entity rechtstreeks tegen de DB te praten.

[ Voor 15% gewijzigd door hackerhater op 16-10-2017 16:51 ]

[orf]

hackerhater schreef op maandag 16 oktober 2017 @ 16:40:
Naar mijn mening zijn general purpose frameworks veel moeilijker dan gewone programma's.
Omdat je met zoveel dingen rekening moet houden, de flexibiliteit erin houden, duidelijke API's, etc.

Voor mij is een general purpose framework een behoorlijke red flag. Prima manier om jezelf te ontwikkelen maar bijna nooit geschikt als vervanging van een populair framework.

[hackerhater]

orf schreef op maandag 16 oktober 2017 @ 16:52:
[...]


Voor mij is een general purpose framework een behoorlijke red flag. Prima manier om jezelf te ontwikkelen maar bijna nooit geschikt als vervanging van een populair framework.

Tjah dat is ooit zo geworden vanuit mijn eerste werkgever. Ooit een collectie (van mij) klassen die ze gingen gebruiken.
Wat netter gemaakt en onder de GPL gegooid en uiteindelijk kwam daar dus V1 uit.
Zou ik het nog een keer doen als ik het over kon doen? hell no.

[orf]

hackerhater schreef op maandag 16 oktober 2017 @ 16:53:
[...]


Tjah dat is ooit zo geworden vanuit mijn eerste werkgever. Ooit een collectie (van mij) klassen die ze gingen gebruiken.
Wat netter gemaakt en onder de GPL gegooid en uiteindelijk kwam daar dus V1 uit.
Zou ik het nog een keer doen als ik het over kon doen? hell no.

Maar waarom laat je dan niet iets heel anders zien? Als ik developers om voorbeeldcode vraag, hoeft het niet eens te werken of gebruikt te worden. Ik kijk naar leesbaarheid, patterns en hoe abstract of concreet iets is. Het liefst juist geen project met veel regels code, maar gewoon wát code om even naar te kijken.

[hackerhater]

Ik heb geen andere recente code, die ik mag sharen, die mijn niveau laat zien.
Ik heb daar simpelweg de tijd niet voor.

Ik snap best waarom je een eigen framework een red flag noemt, het is een makkelijke valkuil.
Buiten mijn eigen spullen ken ik ook Laravel en Symfony. Care dus.

[armageddon_2k1]

Maar, wat nou als je 10 jaar ervaring hebt met alleen proprietary code.... die kan je niet delen. Dus hoe kan je dan laten zien hoe 'goed' je bent?

[RayNbow]

armageddon_2k1 schreef op maandag 16 oktober 2017 @ 20:07:
Maar, wat nou als je 10 jaar ervaring hebt met alleen proprietary code.... die kan je niet delen. Dus hoe kan je dan laten zien hoe 'goed' je bent?

Met een... CV?

[armageddon_2k1]

goedemorgen!

Niet mijn sterkste moment.

[BarôZZa]

hackerhater schreef op maandag 16 oktober 2017 @ 14:34:
Echt sommige bedrijven bij sollicitaties.
Vonden mijn project niet overal senior niveau.
Buiten dat ik ze had gezegd dat dat framework nog beta-code is, is het een 6 jaar oud project.
Een framework waar je duidelijk kan zien wat nog van V1, V1.5 en nu V2 is.

Natuurlijk zijn er nog oudere onderdelen die niet zo netjes zijn. Deels "If aint't broke, don't fit it" en deels voor backwards-compatibility (+ @deprecated)

Senior bestaat niet. Dat is een willekeurige term die standaard opgegooid wordt.

Bij het ene bedrijf is een senior iemand die de architectuur kan doen en dus goed in abstracties werkt. Bij het andere bedrijf is de senior iemand die alle ins en outs van een bestaand framework kent (maar niet weet hoe het werkt). En bij de andere weer iemand die ervaring heeft met tig frameworks.

Wat wel vaak zo is, is dat bedrijven je natuurlijk liever wegzetten als medior met bijbehorende salaris.


Maar als je het even niet technisch bekijkt, dan is de eigenschap van een senior juist dat diegene het voortouw kan nemen. Het is iemand die al weet wat er van hem gevraagd wordt, voordat het wordt gevraagd en daarop anticipeert.
Een senior moet dus precies weten wat er wordt verwacht bij een sollicitatie. Je CV is strakker dan dat van een medior en de stukken code heb je al paraat. Het liefst nog met werkende demo's. Uit de vacature weet je welke technieken ze gebruiken, dus ook daar kan je op inspelen.

Heb je dat niet allemaal niet in orde, dan kan je beter wat tijd investeren in het op orde krijgen van je CV + code. Neem een weekend de tijd om een nette module/plugin/library/extensie te schrijven. Dat betaalt zich zo terug. Niemand zit te wachten op smoesjes of bakken oude code. Van een senior wordt verwacht dat hij z'n shit op orde heeft.

[hackerhater]

Tjah zo noemen andere me, ik heb 10 jaar ervaring tot nu toe.
Deels partime, deels fulltime.

Mijn CV ed is het probleem niet geloof me.
Uitgenodigd worden ed is geen enkel probleem.
Het is meer de stap erna en dat heeft deels met mijn autisme te maken.
Deels is het de houding die ik aangenomen heb als jarenlange kartrekker (lees lead).
Dat stuit managers nog wel eens tegen de borst

[ Voor 21% gewijzigd door hackerhater op 16-10-2017 22:40 ]

[Hydra]

hackerhater schreef op maandag 16 oktober 2017 @ 22:39:
Tjah zo noemen andere me, ik heb 10 jaar ervaring tot nu toe.
Deels partime, deels fulltime.

Ik heb genoeg CVs gezien van mensen met meer dan 10 jaar ervaring waarna bleek dat ze vooral 10x 1 jaar ervaring hadden.

Mijn CV ed is het probleem niet geloof me.
Uitgenodigd worden ed is geen enkel probleem.
Het is meer de stap erna en dat heeft deels met mijn autisme te maken.
Deels is het de houding die ik aangenomen heb als jarenlange kartrekker (lees lead).
Dat stuit managers nog wel eens tegen de borst

Je komt hier al ietwat onplezierig over IMHO. Da's een enorme red flag voor een bedrijf. Software Engineering is en blijft een teamsport en een enkele rotte appel kan het hele team omlaag halen.

[kenneth]

hackerhater schreef op maandag 16 oktober 2017 @ 22:39:
Het is meer de stap erna en dat heeft deels met mijn autisme te maken.
Deels is het de houding die ik aangenomen heb als jarenlange kartrekker (lees lead).
Dat stuit managers nog wel eens tegen de borst

Het ligt aan omstandigheden, het ligt aan anderen, het ligt aan, het ligt aan ...

[hackerhater]

Hydra schreef op dinsdag 17 oktober 2017 @ 07:46:
[...]


Je komt hier al ietwat onplezierig over IMHO. Da's een enorme red flag voor een bedrijf. Software Engineering is en blijft een teamsport en een enkele rotte appel kan het hele team omlaag halen.

How so?
Ik ben inderdaad geen type om vrijdag mee naar de kroeg te gaan.
Het zijn mijn collega's, niet mijn vrienden.
Maar heb je problemen met werkspul, hits shit the fan (servers plat ed), etc.
Je hoeft het maar te vragen en ik help je.

kenneth schreef op dinsdag 17 oktober 2017 @ 07:54:
[...]

Het ligt aan omstandigheden, het ligt aan anderen, het ligt aan, het ligt aan ...

Ik weet van mezelf dat ik een dominant karakter heb. Ik ben geen volger, nooit geweest.
Ik weet ook heel goed dat die karakter trek me in problemen kan brengen met leidinggevenden, vooral micromanagers.
En dat punt van autisme, ik heb een officiele SvA diagnose.
Je kan van mij niet verwachten dat ik alle aspecten van communicatie even goed kan als een neurotypical.
Het is en blijft een handicap.

[Hydra]

hackerhater schreef op dinsdag 17 oktober 2017 @ 08:18:
Ik weet van mezelf dat ik een dominant karakter heb. Ik ben geen volger, nooit geweest.
Ik weet ook heel goed dat die karakter trek me in problemen kan brengen met leidinggevenden, vooral micromanagers.
En dat punt van autisme, ik heb een officiele SvA diagnose.
Je kan van mij niet verwachten dat ik alle aspecten van communicatie even goed kan als een neurotypical.
Het is en blijft een handicap.

Tja. En je kunt van mij niet verwachten dat ik zeg "aggus" en je ongeacht je attitude maar gewoon aanneem. Kut voor je dat je een beperking hebt maar een beperking als deze hebben en het dan acceptabel vinden dat je een 'dominant' karakter hebt is gewoon iets wat je kunt fixen. Nadenken voor je iets doet is iets wat je van iedere kenniswerker moet kunnen verwachten en dat geldt ook voor sociale interacties.

Een vriend van me heeft Asperger en daar kun je fantastisch mee samen werken. Maar die kent z'n eigen beperkingen en lost dat gewoon op door actief na te denken over interactie.

[ Voor 8% gewijzigd door Hydra op 17-10-2017 08:30 ]

[hackerhater]

Denk je echt dat ik dat niet doe? -_-'
Ik pas me zeker aan zoverre ik dat kan. Ik ga technische discussies niet uit de weg, maar de lead van het team heeft altijd het laatste woord.

De keren dat ik in de clinch kwam met management was btw om het team uit de wind te houden.
Het management wilden iets wat niet te doen was. Ik ving de klappen op, iets wat de lead-dev hoort te doen.
Ik ben heel erg direct. Sommige mensen vinden dat fijn (geen gedraai om de brij heen), anderen niet.
Ik geef geen zak om of ik leuk wordt gevonden door anderen. Het gaat mij om de mensen onder me en het resultaat.

Maar in kan niet tussen de regels lezen. Het duurt een hele tijd voor ik de ongeschreven regels in een groep door heb en het niet-zakelijke contact blijft stroef.
Een gegeven moment loop ik gewoon tegen mijn handicap aan.

[Hydra]

hackerhater schreef op dinsdag 17 oktober 2017 @ 08:38:
Denk je echt dat ik dat niet doe? -_-'

Geen idee. Ik geef aan hoe je hier overkomt. Da's alles

[hackerhater]

Hydra schreef op dinsdag 17 oktober 2017 @ 08:39:
[...]


Geen idee. Ik geef aan hoe je hier overkomt. Da's alles

Ik doe ook niet bepaald de moeite om hier sociaal over te komen
Om een paar voorbeelden van de laatste paar maanden aan te geven:
Een collega was door werkdruk helemaal van streek. Ik heb haar gekalmeerd terwijl de rest er onbehouden bij stond.
Een andere situatie was dat we net een nieuweling aangenomen hadden, de lead ging op vakantie en ik heb ongevraagd de inwerk-begeleiding overgenomen zodat de nieuweling niet in een zwart gat viel.

Zo'n dingen.
Maar ik ben niet het type om met een glas bier over de koetjes en kalfjes te gaan praten.
Of in een vergadering te praten om het praten. Ik hou anderen zeker niet tegen om het te doen, maar aan mij is het niet besteed.

[Ultimation]

Goedemorgen!

Bezig met een product te ontwikkelen waar gebruikers een domeinnaam kunnen kopen / krijgen. Al een week bezig met de juiste domeinboer te zoeken met fatsoenlijke API.

Versio: Bijna perfect enkel limiet op het controleren van de beschikbaarheid van een domein per dag
TransIp: Niet mogelijk automatische verlening aan/uit te zetten via de API, geen ssl certificaten bestellen
GoDaddy: Prijs word pas bepaald bij het bestellen van het gewenste domein, geen mogelijkheid om de gebruiker een prijs van te voren te geven
RealTimeRegister: Geen mogelijkheid een lijst met tld's te importeren en dus een prijs te geven van te voren
DomainNameApi: Documentatie in het Turks, geen mogelijkheid tld's te importeren
NameCheap: Wel een lijst met TLD's, geen prijzen per tld, wel te combineren door een crosscheck te doen met de beschikbaarheid

Algemeen probleem: php libraries zijn bijna niet aanwezig of niet te vinden op Packagist.

Iemand nog een goede tip?

[scosec]

Ultimation schreef op dinsdag 17 oktober 2017 @ 08:54:
Goedemorgen!

Bezig met een product te ontwikkelen waar gebruikers een domeinnaam kunnen kopen / krijgen. Al een week bezig met de juiste domeinboer te zoeken met fatsoenlijke API.

Versio: Bijna perfect enkel limiet op het controleren van de beschikbaarheid van een domein per dag
TransIp: Niet mogelijk automatische verlening aan/uit te zetten via de API, geen ssl certificaten bestellen
GoDaddy: Prijs word pas bepaald bij het bestellen van het gewenste domein, geen mogelijkheid om de gebruiker een prijs van te voren te geven
RealTimeRegister: Geen mogelijkheid een lijst met tld's te importeren en dus een prijs te geven van te voren
DomainNameApi: Documentatie in het Turks, geen mogelijkheid tld's te importeren
NameCheap: Wel een lijst met TLD's, geen prijzen per tld, wel te combineren door een crosscheck te doen met de beschikbaarheid

Algemeen probleem: php libraries zijn bijna niet aanwezig of niet te vinden op Packagist.

Iemand nog een goede tip?

Oxxa wellicht?

[orf]

Ultimation schreef op dinsdag 17 oktober 2017 @ 08:54:
Goedemorgen!

Bezig met een product te ontwikkelen waar gebruikers een domeinnaam kunnen kopen / krijgen. Al een week bezig met de juiste domeinboer te zoeken met fatsoenlijke API.

Versio: Bijna perfect enkel limiet op het controleren van de beschikbaarheid van een domein per dag
TransIp: Niet mogelijk automatische verlening aan/uit te zetten via de API, geen ssl certificaten bestellen
GoDaddy: Prijs word pas bepaald bij het bestellen van het gewenste domein, geen mogelijkheid om de gebruiker een prijs van te voren te geven
RealTimeRegister: Geen mogelijkheid een lijst met tld's te importeren en dus een prijs te geven van te voren
DomainNameApi: Documentatie in het Turks, geen mogelijkheid tld's te importeren
NameCheap: Wel een lijst met TLD's, geen prijzen per tld, wel te combineren door een crosscheck te doen met de beschikbaarheid

Algemeen probleem: php libraries zijn bijna niet aanwezig of niet te vinden op Packagist.

Iemand nog een goede tip?

Je vraagt niet om SSL certificaten, maar benoemt dat wel bij TransIP. Wil je die kunnen bestellen? Zo ja, dan kan ik Xolphin aanraden. Fijne API en veel keus in certificaten. Anderzijds kun je misschien ook wel genoeg met gratis certificaten via Let's Encrypt.

Ik heb goede ervaringen met TransIP en de API. Zeker als ik dat vergelijk met SIDN. Daar registreer ik mijn .nl domeinen, maar technisch zou ik dat veel liever bij TransIP doen. Ik vind de systemen van SIDN heel verschrikkelijk.

Domeinnamen registreer je meestal tot wederopzegging toch? Of registreer je soms ook voor een jaar? Dat zou je eventueel kunnen regelen door direct een opzegging te doen na registratie.

[xleeuwx]

Ultimation schreef op dinsdag 17 oktober 2017 @ 08:54:
Goedemorgen!

Bezig met een product te ontwikkelen waar gebruikers een domeinnaam kunnen kopen / krijgen. Al een week bezig met de juiste domeinboer te zoeken met fatsoenlijke API.

Versio: Bijna perfect enkel limiet op het controleren van de beschikbaarheid van een domein per dag
TransIp: Niet mogelijk automatische verlening aan/uit te zetten via de API, geen ssl certificaten bestellen
GoDaddy: Prijs word pas bepaald bij het bestellen van het gewenste domein, geen mogelijkheid om de gebruiker een prijs van te voren te geven
RealTimeRegister: Geen mogelijkheid een lijst met tld's te importeren en dus een prijs te geven van te voren
DomainNameApi: Documentatie in het Turks, geen mogelijkheid tld's te importeren
NameCheap: Wel een lijst met TLD's, geen prijzen per tld, wel te combineren door een crosscheck te doen met de beschikbaarheid

Algemeen probleem: php libraries zijn bijna niet aanwezig of niet te vinden op Packagist.

Iemand nog een goede tip?

2 API's gebruiken ?

TransIP voor de beschikbaarheid en Versio voor de aanvraag

[Ultimation]

orf schreef op dinsdag 17 oktober 2017 @ 09:10:
[...]

Domeinnamen registreer je meestal tot wederopzegging toch? Of registreer je soms ook voor een jaar? Dat zou je eventueel kunnen regelen door direct een opzegging te doen na registratie.

Probleem daarmee is dat wanneer een gebruiker het domeinnaam verlengt ik de annulering met de hand ongedaan moet maken. De status van de automatische verlening in TransIp moet de keuze van de eindgebruiker reflecteren. Het kan ook zijn dat een gebruiker eerst van een domeinnaam af wil en zich later weer bedenkt. Het process moet volledig automatisch zijn, ik heb geen tijd om per dag verkeerde annuleringen ongedaan te maken.

[Ultimation]

xleeuwx schreef op dinsdag 17 oktober 2017 @ 09:13:
[...]

2 API's gebruiken ?

TransIP voor de beschikbaarheid en Versio voor de aanvraag

Dat vond ik zelf ook een leuke optie en die heb ik ook door mijn gedachte laten gaan. Hoe waterdicht is deze oplossing? Dan moet ik wel de aanwezigheid van tld's bij beide aanbieders vergelijken.

[xleeuwx]

Ultimation schreef op dinsdag 17 oktober 2017 @ 09:18:
[...]


Dat vond ik zelf ook een leuke optie en die heb ik ook door mijn gedachte laten gaan. Hoe waterdicht is deze oplossing? Dan moet ik wel de aanwezigheid van tld's bij beide aanbieders vergelijken.

Wat je kan doen is in je applicatie een array van providers maken (wat hoe dan ook een goede set is).

Bij deze array kan je aangeven of je wilt aanvragen en of wilt checken. En voor welke domein extensies.

Wij kopen namelijk domein extensies verschillend in bij verschillende providers en dit gaat allemaal geautomatiseerd. Zelfs reden geen zin om handmatig te doen en kosten.

Verder kan je als een provider down gaat de volgende in de array pakken en deze opvragen

[ Voor 25% gewijzigd door xleeuwx op 17-10-2017 09:33 ]

[ThomasG]

Ultimation schreef op dinsdag 17 oktober 2017 @ 09:16:
[...]


Probleem daarmee is dat wanneer een gebruiker het domeinnaam verlengt ik de annulering met de hand ongedaan moet maken. De status van de automatische verlening in TransIp moet de keuze van de eindgebruiker reflecteren. Het kan ook zijn dat een gebruiker eerst van een domeinnaam af wil en zich later weer bedenkt. Het process moet volledig automatisch zijn, ik heb geen tijd om per dag verkeerde annuleringen ongedaan te maken.

Het probleem bij niet automatisch verlengen is dat wanneer de gebruiker te laat is, er een grote kans is dat de domeinnaam meteen gekaapt wordt. Er zijn allemaal bots die verlopen domeinnamen (met een redelijke populariteit in de zoekmachines) opkopen. Het is denk ik beter om het gewoon wel automatisch te verlengen, en dat de gebruiker het explicit moet opzeggen.

[Ultimation]

xleeuwx schreef op dinsdag 17 oktober 2017 @ 09:32:
[...]
Wat je kan doen is in je applicatie een array van providers maken (wat hoe dan ook een goede set is).

Bij deze array kan je aangeven of je wilt aanvragen en of wilt checken. En voor welke domein extensies.

Wij kopen namelijk domein extensies verschillend in bij verschillende providers en dit gaat allemaal geautomatiseerd. Zelfs reden geen zin om handmatig te doen en kosten.

Verder kan je als een provider down gaat de volgende in de array pakken en deze opvragen

Ik denk dat ik het slechts bij Versio en TransIp hou. Even de extensies uitfilteren die niet verkocht worden bij TransIp en wel bij Versio en dan moeten we wel goed zitten. Dan kan ik de prijsopvraag ook goed doen samen met de beschikbaarheid.

ThomasG schreef op dinsdag 17 oktober 2017 @ 09:35:
[...]
Het probleem bij niet automatisch verlengen is dat wanneer de gebruiker te laat is, er een grote kans is dat de domeinnaam meteen gekaapt wordt. Er zijn allemaal bots die verlopen domeinnamen (met een redelijke populariteit in de zoekmachines) opkopen. Het is denk ik beter om het gewoon wel automatisch te verlengen, en dat de gebruiker het explicit moet opzeggen.

Tsja, we hebben nog steeds te maken met common sense. Je moet ook echt expliciet als gebruiker aangeven dat deze niet automatisch verlengt mag worden, ongeveer zo:

Auto renewal:
[ X ] Yes
[ ] No

Maar we zouden de gebruiker nog wat nadrukkelijker kunnen waarschuwen. "Als u ... kwijt".

[ Voor 35% gewijzigd door Ultimation op 17-10-2017 10:19 ]

[Rutix]

hackerhater schreef op dinsdag 17 oktober 2017 @ 08:45:
[...]


Ik doe ook niet bepaald de moeite om hier sociaal over te komen
Om een paar voorbeelden van de laatste paar maanden aan te geven:
Een collega was door werkdruk helemaal van streek. Ik heb haar gekalmeerd terwijl de rest er onbehouden bij stond.
Een andere situatie was dat we net een nieuweling aangenomen hadden, de lead ging op vakantie en ik heb ongevraagd de inwerk-begeleiding overgenomen zodat de nieuweling niet in een zwart gat viel.

Zo'n dingen.
Maar ik ben niet het type om met een glas bier over de koetjes en kalfjes te gaan praten.
Of in een vergadering te praten om het praten. Ik hou anderen zeker niet tegen om het te doen, maar aan mij is het niet besteed.

Ja maar je moet snappen dat een negatief beeld veel langer blijft hangen dan een paar voorbeelden van positief beeld. Ik kan me nog herinneren dat we hier een discussie ooit hebben gehad en je toen ook niet echt plezierig was om mee te discussiëren (en dan druk ik het nog zacht uit). Dat beeld is bij mij tot nu toe blijven hangen terwijl je misschien in de tussentijd wel normaal hebt gereageerd.

De manier hoe je over die sollicitatie bijvoorbeeld praat (net of je het beter weet) is ook niet echt netjes. Ik snap namelijk helemaal die opmerkingen die je hebt gekregen. Als ik als interviewer een opmerking maak op code die ik te zien krijg en de opmerking dan is "het is beta code" dan is dat bij mij al een red flag. Beta code betekent niet dat je meteen slechte code kunt introduceren ofzo, het betekent in mijn ogen meer dat iets nog niet helemaal feature complete is.

[hackerhater]

Rutix schreef op dinsdag 17 oktober 2017 @ 10:54:
[...]
De manier hoe je over die sollicitatie bijvoorbeeld praat (net of je het beter weet) is ook niet echt netjes. Ik snap namelijk helemaal die opmerkingen die je hebt gekregen. Als ik als interviewer een opmerking maak op code die ik te zien krijg en de opmerking dan is "het is beta code" dan is dat bij mij al een red flag. Beta code betekent niet dat je meteen slechte code kunt introduceren ofzo, het betekent in mijn ogen meer dat iets nog niet helemaal feature complete is.

Alleen was de volgorde andersom
De eigenaar wilde de code aan zijn lead laten zien (waar ik dus niet bij zou zijn).
Toen had ik aangeven: oke, maar dit is een ontwikkelversie met beta-code.
Die opmerkingen hoorde ik een paar dagen later pas.

"het betekent in mijn ogen meer dat iets nog niet helemaal feature complete is."
Dit is ook exact wat ik bedoelde. Nog niet feature complete, er zitten nog fouten in.
Het is nette code, sommige stukken ingewikkelder in elkaar dan de anderen.

Ik heb altijd geprobeerd complexiteit te vermijden als het niet nodig was (sommige dingen kom je er niet onderuit) omdat het onderhoud en testen moeilijker maakt.

Uiteraard heeft elke programmeur wel wat op te merken over code van een ander
Daar is mijn code geen uitzondering op

[ Voor 14% gewijzigd door hackerhater op 17-10-2017 11:26 ]

[Rutix]

hackerhater schreef op dinsdag 17 oktober 2017 @ 11:01:
[...]


Alleen was de volgorde andersom
De eigenaar wilde de code aan zijn lead laten zien (waar ik dus niet bij zou zijn).
Toen had ik aangeven: oke, maar dit is een ontwikkelversie met beta-code.
Die opmerkingen hoorde ik een paar dagen later pas.

"het betekent in mijn ogen meer dat iets nog niet helemaal feature complete is."
Dit is ook exact wat ik bedoelde. Nog niet feature complete, er zitten nog fouten in.
Het is nette code, sommige stukken ingewikkelder in elkaar dan de anderen.

Ik heb altijd geprobeerd complexiteit te vermijden als het niet nodig was (sommige dingen kom je er niet onderuit) omdat het onderhoud en testen moeilijker maakt.

Maar dan nog mag die lead het toch "niet senior niveau" genoeg vinden? Afgezien dat ik de code niet heb gezien en veel opmerkingen te scharen zijn onder "wij van wc-eend". Zit je ook veel dingen die dus niet goed in dat framework zit te verdedigen. Het kan dus zijn dat die lead dat heeft gezien en jou mening niet deelt.

Ik heb ook veel sollicaties gedaan en als ik een repo kreeg dan keek ik ook niet alleen naar de nieuwe dingen. Jij als sollicitant hebt een repo gegeven met als doel "kijk hierom moet je mij hebben!" maar dan kijk ik ook naar het totaal plaatje. Hoe iets is gegroeid over de jaren heen zegt ook veel over hoe jij jezelf hebt ontwikkeld en dat kan gunstig uitpakken of niet. In dit geval heeft de lead besloten dat het niet gunstig heeft uitgepakt. Als je de volgende keer wilt zorgen dat dit gunstig uitpakt moet je inderdaad alleen een repository geven waar goede dingen in staan.

[kwaakvaak_v2]

kenneth schreef op dinsdag 17 oktober 2017 @ 07:54:
[...]

Het ligt aan omstandigheden, het ligt aan anderen, het ligt aan, het ligt aan ...

in context : https://medium.freecodeca...we-ever-made-4c0a99728fde

Bij deze meeste posts van @hackerhater krijg ik een vrij hoog 'Rick' gehalte door. Misschien tijd om daar eens aan te werken.

Ik heb/had ook nogal wat 'Rick' neigingen, maar dat heeft mij meer ellende gekost dat het opleverde. Tegenwoordig kan ik dingen ook gewoon loslaten en laat het team het oplossen. Als ze er echt niet uitkomen weten ze mij wel te vinden, of als het te lang duurt weet ik hun wel te vinden.

Senior zijn betekent niet dat iemand alles het beste weet, maar dat je het beste uit andere iemanden probeert te krijgen.

[hackerhater]

Niet senior genoeg in zijn ogen oke daar had ik nog mee kunnen leven.
Dat is in het oog van de beschouwer.
Maar ik kreeg ook een opmerking van dat er bugs in zitten en een deel niet draait.
Toen had ik iets van: ja duh?

[DevWouter]

hackerhater schreef op dinsdag 17 oktober 2017 @ 11:36:
Niet senior genoeg in zijn ogen oke daar had ik nog mee kunnen leven.
Dat is in het oog van de beschouwer.
Maar ik kreeg ook een opmerking van dat er bugs in zitten en een deel niet draait.
Toen had ik iets van: ja duh?

Bekijk het vanuit zijn perspectief: Hij moet oordelen of jij een aanwinst of een risico voor het bedrijf zal zijn.
Als hij dat moet doen met code waar problemen in zitten dan maak je het hem erg lastig om een onbekende voor 100% te vertrouwen.

Om een vergelijking te maken: Een autoverkoper rijdt bijvoorbeeld niet naar een nieuwe klant in een roestbak ondanks dat hij de beste auto verkoopt.

Persoonlijk zou ik nooit vragen of iemand code kan aanleveren, maar eerder een klein project geven, er een paar beperkingen aangeven en kijken hoe die dat op pakt.

Als een partij van mijn code wil zien dan zou ik toch vragen wat hij denkt daaruit te leren. Liever zou ik vragen of ze niet een kleine opdracht hebben (iets van een paar uur) en vragen wat ze belangrijk vinden.

[kwaakvaak_v2]

DevWouter schreef op dinsdag 17 oktober 2017 @ 11:47:
[...]


Persoonlijk zou ik nooit vragen of iemand code kan aanleveren, maar eerder een klein project geven, er een paar beperkingen aangeven en kijken hoe die dat op pakt.

Ik vraag meestal wel om voorbeeld code, maar dat is pas in gesprek 2. In het eerste gesprek heb ik samen met een collega gewoon een gesprek met een kandidaat om te zien of iemand in onze 'cultuur' past. Tuurlijk passeert techniek daar ook de revue, maar het EQ is minstens zo belangrijk als het IQ.

En of iemand introvert, extravert of autistisch is kan ik meestal wel doorheen prikken, maar als iemand in het gesprek al een 'Ik ben een code god' houding heeft, komt er geen gesprek 2 ;-)

[hackerhater]

DevWouter schreef op dinsdag 17 oktober 2017 @ 11:47:
[...]
Persoonlijk zou ik nooit vragen of iemand code kan aanleveren, maar eerder een klein project geven, er een paar beperkingen aangeven en kijken hoe die dat op pakt.

True en dat was ook de normale procedure daar, alleen week de eigenaar daar vanaf na mijn code gezien te hebben. Leuk detail: Voor de functie waar ik eigenlijk voor kwam vonden ze me overgekwalificeerd.
Ik weet dat er gaten in mijn kennis e.d. zitten omdat zo vaak aan het roer heb gestaan zonder iemand om wat van te leren.
Dat is juist de reden waarom ik dat niet wil voor de komende jaren.

Maar om dan een opmerking over de bugs te krijgen als ze er zelf voor kiezen de opdracht over te slaan en je waarschuwt dat het ontwikkel-code is?

[Alex)]

Maar waarom hebben ze de opdracht overgeslagen? Kwam je zelf aanzetten met je framework/repo's, of werd dat gevraagd?

[DevWouter]

hackerhater schreef op dinsdag 17 oktober 2017 @ 11:53:
[...]

Maar om dan een opmerking over de bugs te krijgen als ze er zelf voor kiezen de opdracht over te slaan en je waarschuwt dat het ontwikkel-code is?

Omdat degene die jouw code reviewt niet dezelfde persoon als de baas is.

Baas: "Ik heb een nieuwe Einstein gevonden, welke ook super sociaal, bla bla is. Echt triple-A materiaal."
Team lead: "Welke opdracht wil je dat ik hem geef?"
B: "Niet nodig, hij had iets super cools, het was nog niet helemaal af, maar ik denk dat je daar ook wel wat van kan leren"
T: "Dat is niet de procedure die we afgesproken hebben."
B: "Klopt, maar ik heb ook echt een super goed gevoel. Ik moet nu naar een klant toe, maar laat maar weten wat jij denkt"
Een paar dagen later...
B: "Heb jij al naar de code gekeken?"
T: "Ja, maar er zitten een paar bugs in en het koste me een uur om het werkend te krijgen"
B: "Oh, dat is niet goed of wel soms?"
T: "Als ik die fouten in productie doe heb ik jou 5 minuten later aan de lijn."

En het bovenstaande is echt niet onrealistisch. Je hebt te maken met ego's, onzekerheden, discriminatie, het feit dat sommige mensen niet objectief willen zijn, irritatie, et cetera.

[hackerhater]

Alex) schreef op dinsdag 17 oktober 2017 @ 11:56:
Maar waarom hebben ze de opdracht overgeslagen? Kwam je zelf aanzetten met je framework/repo's, of werd dat gevraagd?

Het framework kwam ter sprake toen we het over mijn cv hadden en zo.
Hij vroeg of ik het bij me had, antwoord ja
En toen kwam het op tafel.

Ik heb het standaard bij me op mijn laptop omdat ze het 9 van de 10 keer willen zien.
Maar tot ze erheen vragen laat ik die laptop gewoon in mijn tas.

DevWouter schreef op dinsdag 17 oktober 2017 @ 12:07:
Omdat degene die jouw code reviewt niet dezelfde persoon als de baas is.

Baas: "Ik heb een nieuwe Einstein gevonden, welke ook super sociaal, bla bla is. Echt triple-A materiaal."
Team lead: "Welke opdracht wil je dat ik hem geef?"
B: "Niet nodig, hij had iets super cools, het was nog niet helemaal af, maar ik denk dat je daar ook wel wat van kan leren"
T: "Dat is niet de procedure die we afgesproken hebben."
B: "Klopt, maar ik heb ook echt een super goed gevoel. Ik moet nu naar een klant toe, maar laat maar weten wat jij denkt"
Een paar dagen later...
B: "Heb jij al naar de code gekeken?"
T: "Ja, maar er zitten een paar bugs in en het koste me een uur om het werkend te krijgen"
B: "Oh, dat is niet goed of wel soms?"
T: "Als ik die fouten in productie doe heb ik jou 5 minuten later aan de lijn."

En het bovenstaande is echt niet onrealistisch. Je hebt te maken met ego's, onzekerheden, discriminatie, het feit dat sommige mensen niet objectief willen zijn, irritatie, et cetera.

Funny verhaal, maar het zou me inderdaad niet verwonderen als die waarschuwing van mijn kant niet doorgegeven is.
Dat het ontwikkelcode is en verre van productie-ready.

[DevWouter]

hackerhater schreef op dinsdag 17 oktober 2017 @ 12:14:
[...]
Funny verhaal, maar het zou me inderdaad niet verwonderen als die waarschuwing van mijn kant niet doorgegeven is.
Dat het ontwikkelcode is en verre van productie-ready.

Dat is het mooie van het verhaal. De tweede zin van de baas geeft aan dat het nog niet af is
Verder doet de team leider nog iets geniepig. Hij projecteert zijn fouten in productie op die van de sollicitant. En dat terwijl jouw code niks te maken heeft met productie of zelfs ook maar bedoeld is voor productie.

Natuurlijk is dit een fictief verhaal, maar het geeft wel aan hoe onbetrouwbaar een review van code kan zijn.

@kwaakvaak_v2 Zou jij ons kunnen uitleggen waarom jullie een voordeel zien van voorbeeld code? Niet om een discussie van goed-of-slecht aan te gaan, maar zodat we ook de argumenten van voorstanders kennen en weten hoe we daar op moeten inspelen. Ik ben namelijk overtuigd van een mening, maar dat betekent niet dat ik onwetend wil zijn

[Hydra]

Ultimation schreef op dinsdag 17 oktober 2017 @ 08:54:
Iemand nog een goede tip?

Amazon? Kun je 't meteen volledig integreren met je hosting.

hackerhater schreef op dinsdag 17 oktober 2017 @ 11:53:
Maar om dan een opmerking over de bugs te krijgen als ze er zelf voor kiezen de opdracht over te slaan en je waarschuwt dat het ontwikkel-code is?

Dat iets niet feature complete is, is wat anders dan dat er echt fouten inzitten. Wat ik vooral treffend vindt is dat je de schuld vooral bij dat bedrijf legt. Anderen de schuld geven leer je niks van.

DevWouter schreef op dinsdag 17 oktober 2017 @ 12:32:
Dat is het mooie van het verhaal. De tweede zin van de baas geeft aan dat het nog niet af is
Verder doet de team leider nog iets geniepig. Hij projecteert zijn fouten in productie op die van de sollicitant.

Ik vind dat nogal gezocht. Ze geeft hen code en op basis van o.a. die code (en haar interview) is ze afgewezen. Vind het nogal raar om de schuld dan maar bij die team lead te leggen.

[ Voor 80% gewijzigd door Hydra op 17-10-2017 13:19 ]

[DevWouter]

Hydra schreef op dinsdag 17 oktober 2017 @ 12:55:
Ik vind dat nogal gezocht. Ze geeft hen code en op basis van o.a. die code (en haar interview) is ze afgewezen. Vind het nogal raar om de schuld dan maar bij die team lead te leggen.

Het is ook een fictief scenario volledig uit mijn toetsenbord gezogen.

DevWouter schreef op dinsdag 17 oktober 2017 @ 12:32:
Natuurlijk is dit een fictief verhaal, maar het geeft wel aan hoe onbetrouwbaar een review van code kan zijn.

[Hydra]

DevWouter schreef op dinsdag 17 oktober 2017 @ 13:54:
Het is ook een fictief scenario volledig uit mijn toetsenbord gezogen.

Ja, maar ik vind het nogal onwaarschijnlijk dat daar het probleem ligt. Dus het helpt die persoon IMHO niet echt.

[kwaakvaak_v2]

DevWouter schreef op dinsdag 17 oktober 2017 @ 12:32:
[...]


@kwaakvaak_v2 Zou jij ons kunnen uitleggen waarom jullie een voordeel zien van voorbeeld code? Niet om een discussie van goed-of-slecht aan te gaan, maar zodat we ook de argumenten van voorstanders kennen en weten hoe we daar op moeten inspelen. Ik ben namelijk overtuigd van een mening, maar dat betekent niet dat ik onwetend wil zijn

Dat is vrij simpel eigenlijk, ik wil graag zien of iemand ook kan wat ie zegt dat ie kan en voor ons bedrijf is een assessment soms te hoog gegrepen. Gewoon een paar stukjes code zegt ook al vaak voldoende, is het copy/paste style of zelf bedacht. Ik vraag meestal naar relevante code die niet ouder is dan 2 a 3 maanden en laat zien dat de kennis van de systemen die wij gebruiken aanwezig is.

Los daar daarvan, kun je meestal tijdens een gesprek wel merken of iemand ergens goed in zit of niet. Kent iemand bepaalde personen van naam uit één van de opensource projecten die wij gebruiken, en dan niet de project owner. Weet ie van bepaalde issues die spelen. etc. etc.

En ik kan bij twijfel gehaaid zijn door opzettelijk iets fouts te vragen of beweren, en dan checken of de kandidaat mee gaat in mijn leugentje.

[hackerhater]

Ik zit er verder niet mee hoor.
Ben allang verder het solliciteren.

[.oisyn]

hackerhater schreef op dinsdag 17 oktober 2017 @ 14:12:
Ik zit er verder niet mee hoor.
Ben allang verder het solliciteren.

Zodat je daar dezelfde fouten kan maken. Top!

[Tjolk]

hackerhater schreef op dinsdag 17 oktober 2017 @ 14:12:
Ik zit er verder niet mee hoor.
Ben allang verder het solliciteren.

Niet lullig bedoeld hoor, maar het staat me bij dat ik een (half?) jaar geleden een soortgelijk verhaal in de devschuur heb gelezen met jou als lijdend voorwerp. Zoals @.oisyn al aangeeft: probeer niet weer dezelfde fouten te maken, maar kijk eens of je je houding of werkwijze moet aanpassen? Word je misschien een stuk vrolijker van.

[DevWouter]

kwaakvaak_v2 schreef op dinsdag 17 oktober 2017 @ 14:03:
[...]


Dat is vrij simpel eigenlijk, ik wil graag zien of iemand ook kan wat ie zegt dat ie kan en voor ons bedrijf is een assessment soms te hoog gegrepen. Gewoon een paar stukjes code zegt ook al vaak voldoende, is het copy/paste style of zelf bedacht. Ik vraag meestal naar relevante code die niet ouder is dan 2 a 3 maanden en laat zien dat de kennis van de systemen die wij gebruiken aanwezig is.

Los daar daarvan, kun je meestal tijdens een gesprek wel merken of iemand ergens goed in zit of niet. Kent iemand bepaalde personen van naam uit één van de opensource projecten die wij gebruiken, en dan niet de project owner. Weet ie van bepaalde issues die spelen. etc. etc.

En ik kan bij twijfel gehaaid zijn door opzettelijk iets fouts te vragen of beweren, en dan checken of de kandidaat mee gaat in mijn leugentje.

Dat... is eigenlijk niet eens zo slecht argument voor, zeker met die aanpak. Het sluit ook meer aan met wat ik zie als een demo opdracht (maar dan één die ik niet hoef voor te bereiden). Thanks! Ben weer een tikkeltje wijzer geworden

Hydra schreef op dinsdag 17 oktober 2017 @ 14:00:
[...]
Ja, maar ik vind het nogal onwaarschijnlijk dat daar het probleem ligt. Dus het helpt die persoon IMHO niet echt.

Als je de thread terug leest dan begin ik met een waarom beta-code bij een sollicitatie een slecht idee is, en dat volg ik op met een fictief verhaal hoe het verkeerd kan gaan. Dus nogmaals, ik leg nergens de schuld (of het probleem) neer.

@hackerhater Success met de volgende!

[hackerhater]

Dat die code niet echt presentabel was tijdens die sollicitatie wist ik wel.
De aankondiging van mijn ontslag was letterlijk net 5 dagen eerder geweest en dat kwam ook nog totaal onverwacht. Geen gesprekken ervoor gehad, vakantie was ingepland over contract einde heen, was ingedeeld voor een paar interne cursussen, etc.
Geen enkele indicatie dat ze het contract niet zouden verlengen.

En ik had niet verwacht dat die recruiter binnen een paar dagen een gesprek had geregeld.
Ik had nauwelijks de tijd de code zover te krijgen dat het überhaupt op startte
Ik was de week ervoor net aan een nieuwe feature begonnen die nogal breaking was (entitity parser)

[.oisyn]

Wederom een hoop excuses. Bottom line heb je gewoon broken code laten zien, dat had je niet moeten doen. Dat je daar dan vervolgens op wordt afgerekend is niet de schuld van het bedrijf.

[ Voor 28% gewijzigd door .oisyn op 17-10-2017 15:12 ]

[Tjolk]

hackerhater schreef op dinsdag 17 oktober 2017 @ 14:54:
En ik had niet verwacht dat die recruiter binnen een paar dagen een gesprek had geregeld.
Ik had nauwelijks de tijd de code zover te krijgen dat het überhaupt op startte
Ik was de week ervoor net aan een nieuwe feature begonnen die nogal breaking was (entitity parser)

Dan laat je toch een versie zien zonder die feature? Iets met versiebeheer ofzo

[hackerhater]

Ger schreef op dinsdag 17 oktober 2017 @ 15:27:
[...]

Dan laat je toch een versie zien zonder die feature? Iets met versiebeheer ofzo

Als ik het in een losse branch had gemaakt ja
Niet zo slim achteraf gezien, zoals ik al eerder zei het kwam compleet onverwacht.
Mooi voorbeeld van:

[ Voor 17% gewijzigd door hackerhater op 17-10-2017 15:34 ]

[Alex)]

hackerhater schreef op dinsdag 17 oktober 2017 @ 15:33:
[...]


Als ik het in een losse branch had gemaakt ja
Niet zo slim achteraf gezien, zoals ik al eerder zei het kwam compleet onverwacht.

Meteen een reden om altijd git-flow te volgen

[armageddon_2k1]

Iets wat een senior developer toch zou moeten doen altijd

Flauw natuurlijk.

[hackerhater]

Alex) schreef op dinsdag 17 oktober 2017 @ 15:36:
[...]

Meteen een reden om altijd git-flow te volgen

True, op mijn werk doe ik dat altijd.
Voor mijn eigen dev ding had ik iets van, ach wat kan het voor kwaad?
Dit dus

[Alex)]

Iets met een timmerman waar thuis de deuren piepen?

[hackerhater]

En de loodgieter waar het thuis lekt.

[Hydra]

hackerhater schreef op dinsdag 17 oktober 2017 @ 15:33:
Als ik het in een losse branch had gemaakt ja

Je kunt toch gewoon terug naar een versie waar 't nog wel werkte, ongeacht of je in de master werkt of niet?

Alex) schreef op dinsdag 17 oktober 2017 @ 15:36:
Meteen een reden om altijd git-flow te volgen

Voor hobby werk is dat overkill. Je kunt prima met simpele feature branches werken.