Coding level verlagen vanwege collega's?

[.Vii]

Hi all,

Momenteel zit ik op het werk met een probleem. Na een hele lange tijd de enige "programmeur" te zijn binnen het bedrijf en functioneel app. beheerder te zijn hebben ze eindelijk iemand extra aangenomen die ook kan programmeren. (webbased php, sql ed.).

Echter heeft deze persoon nog nooit gehoord van de termen, composer, git, unit testing ed. mijn manager geeft aan dat het coding niveau moet worden verlaagd zodat hij ook kan mee gaan programmeren zodat we een fallback hebben wanneer ik weg val. (Dat was uberhaupt het idee).

Echter voel ik daar zelf niet zo heel veel voor, de beste man is gewend om in procedurele code te programmeren en niet in OOP stijl.

Wat is jullie mening hierover?

[spone]

Kan je het niet omdraaien? De collega on-the-job wegwijs maken in de concepten van OOP en de technieken die gebruikt worden zodat deze mee kan komen met de huidige standaard?

[ Voor 3% gewijzigd door spone op 22-09-2018 09:05 ]

[MAX3400]

Jouw manager zal ongetwijfeld inzichtelijk hebben wat de deliverables zijn. Als die gehaald kunnen worden door "dommer / simpeler" te gaan werken, waarom niet?

Aan de andere kant; blijkbaar is jouw manager ook ongeschikt want Git valt niet direct onder "hoe goed snap je code" dus er is amper/geen inzicht hoe data wordt opgeslagen / gereviseerd?

[t_captain]

Hier is maar één nuttige oplossing: manager eruit, en met het bespaarde salaris een nieuwe developer aantrekken.

Dat iemand geen ervaring heeft met git, dat is nauwelijks voor te stellen anno 2018. Misschien als iemand uit een zuivere MS achtergrond komt en altijd TFS heeft gebruikt.

Maar niet weten wat een unit test is? Die collega zou wel eens veel meer tijd kunnen kosten dan het werk wat hij je uit handen neemt.

[FreezeXJ]

Als jouw manager denkt dat ook zonder unit tests, versiebeheer en een beetje degelijke coding style z'n deliverables (beperkt aantal bugs, geen issues bij meerdere versies in productie en een redelijke ontwikkeltijd) te halen dan is ofwel het bedrijf veel te duur uit met een capabele programmeur en moet jij vertrekken, ofwel heeft hij geen idee hoe het werkt en moet de manager vertrekken...

Aangezien je het vermoedelijk niet zo hard wilt spelen lijkt me plan 1 om je nieuwe collega een beetje bij te spijkeren, git uitleggen en het nut van unit tests uitleggen lijkt me het probleem niet. Over de stijl kun je dan een mooie discussie voeren.

[HollowGamer]

Misschien kun je beter opzoek naar een andere baan met meer uitdaging?
Ik verwacht dat je daar ook meer kunt verdienen. De omgeving is zeker belangrijk, maar een boreout is dan helaas ook mogelijk.

[ Voor 47% gewijzigd door HollowGamer op 22-09-2018 12:48 ]

[418O2]

HollowGamer schreef op zaterdag 22 september 2018 @ 09:26:
Misschien kun je beter opzoek naar een andere baan met meer uitdaging?

Dit. Je beperkt je eigen groei al door alleen te werken, als je dan ook nog docentje moet gaan spelen wordt dat alleen maar erger. Daarbij vermoed ik dat de beloning ook gauw achter blijft als je de enige developer bent.

[.Vii]

Hiya,

Ik ben ook bezig hem bij te brengen wat git ed. allemaal is zodat hij daarin mee kan komen. (gelukkig ziet hij ook vrij snel de voordelen in). Echter als je met laravel framework werkt en je kent de basis van OOP niet dan is het een stijle leerweg die hij moet volgen.

Hierbij heb ik hem ook aangegeven dat het niet volledig geleerd kan worden onder werkt tijd en dat je er zelf ook tijd in moet steken om OOP te kunnen en het laravel framework onder de knie te krijgen.

Uitdaging voor mezelf binnen dit bedrijf zijn er genoeg. (naast het programmeren doe ik ook beheer en onderhoud van de applicaties wat ik ook super tof vind om te doen).

De manager weet op hoofdlijnen wat ICT is en wat er moet gebeuren, hij is goed in mensen bij elkaar brengen welke wel de kennis in huis hebben om goede beslissingen te maken, echter de personen daar weer boven lopen nogal moeilijk te doen op het gebied van het moet door en moet nu door.

Een maand ontwikkeltijd om alles goed neer te zetten met unit testing ed. is veel te lang vind het bedrijf, het moet sneller en duidelijker wat er gemaakt wordt. (Heb al eens de opmerking gehad dat de comments in mijn programmering moeten worden nagelezen door iemand van een operationele afdeling of zij het snappen toen heb ik ze wel vierkant uitgelachen).

Het gaat niet zo zeer of ik macht heb en het hard kan spelen, op zich kan ik het best hard spelen vanwege dat ik in een niche markt van de ICT werkt waar ICT'ers heel schaars zijn met de kennis van de applicaties welke gebruikt worden (alternatief is de leverancier ala 250 euro per uur excl. btw).

Daarbij de beloningen heb ik inderdaad niet, naar vorig jaar lang zuren is mijn salaris markt "conform" getrokken (wat wel een flinke verhoging met zich meebracht) echter is dat wel voor applicatiebeheer en niet ontwikkeling :-).

[418O2]

Wat ik zou doen is hem langzaam introduceren.

GIT moet hij gewoon snel leren, daar kan je niet omheen. Wat je kan doen is zelf de unit tests schrijven en dat hij de code uitwerkt. Laat hem de simpele klussen doen en kijk af en toe met hem mee. Maak afgebakende taken en laat hem die uitvoeren. Doe code reviews, beide kanten op, zodat je hem kan begeleiden en de kwaliteit kan beoordelen. Laat hem ook jouw code zien zodat hij daar van kan leren.

Op deze manier kan jij de complexe zaken aanpakken en kan de ander wennen en up to speed raken, zonder dat je slechter werk aflevert. Misschien kan je met je manager afspreken dat jij leerstof aandraagt (artikelen, tutorials) waar de ander door leert. Als hij elke dag een half uur tijd heeft om te 'studeren' kan het snel gaan als er aanleg is. Desnoods in eigen tijd, neem aan dat die ander ook wil investeren in zijn toekomst.

[ Voor 33% gewijzigd door 418O2 op 22-09-2018 09:39 ]

[Yucon]

Als je je nieuwe code aan zijn niveau aan zou passen kan hij je oude code nog steeds niet onderhouden. Daar zit de oplossing dus niet.

[eric.1]

Ligt er een beetje aan in wat voor termijnen gedacht wordt. Hoe snel moet hij mee kunnen komen en wanneer geheel zelfstandig in de weer kunnen?

Opzich Git en Composer zijn niet de grootste problemen om onder de knie te krijgen. OOP is wel een dingetje (snap niet helemaal waarom hij daar nog nooit van gehoord heeft, is wel..... vrij standaard tegenwoordig?).

Sowieso coding-niveau verlagen; lijkt me een heel slecht idee.

Korte termijn-visie; gewoon de verkeerde aangenomen.

Lange termijn; mogelijk potentie.

[Anoniem: 403357]

Als je nieuwe collega Laravel niet kent of snapt (kan gebeuren, niet iedereen kent elk framework natuurlijk) dan kan die toch op cursus? Je hebt genoeg cursussen van 3 of 5 dagen waar een junior genoeg aan heeft om mee te starten. Vervolgens kan hij een week of twee lekker door jou code bladeren en dan kunnen jullie samen verder.

Verder vind ik wel (en dit is absoluut niet denigrerend bedoelt), maar als je als ontwikkelaar in PHP het niet voor elkaar krijgt om in een paar weken Laravel eigen te maken ik me wel een beetje afvraag waar de persoon vandaag is geplukt, want het is geen rocket science. Iedereen die het gebruikt heeft het ooit geleerd. Als dat gewoon niet lukt is het misschien goedkoper om iemand anders te zoeken voor de functie.

[.Vii]

De beste man heeft jaren lang zelf een applicatie onderhouden die er opzich goed uitzag. Wanneer ik een coding sample van de applicatie vroeg, schrok me enigzins al kapot dat het procedureel was. Dit heb ik ook aangegeven bij mijn manager dat dit mij wel heel veel zorgen baarde.

Des al niet te min had de beste man een "leuke glimlach" erop staan waardoor hij is aangenomen. Naast programmeren moet hij ook functioneel beheerder worden waardoor het dus een diverse functie inhoud heeft.

Mede daardoor is er voor hem gekozen.

De snelheid dat hij moet komen is zoals bij heel veel bedrijven eigenlijk per direct. Ik zelf heb weinig tijd om hem te begeleiden ondanks meerdere verzoeken dat ik dat wel wou. Echter geeft het bedrijf meer prioriteit aan door ontwikkeling en dat er nieuwe zaken worden opgeleverd dan een waardige opleidingstraject. (ondanks dat wordt aangegeven dat deze er wel is...)

Een opleiding wil men nog niet overwegen vanwege dat hij nieuw is en onder het mom van "jij hebt je het zelf toch ook aangeleerd..." nu ben ik zelf van nature nieuwsgierig naar nieuwe technologieën en mogelijkheden hoe ik zaken kan verbeteren echter mijn prioriteiten liggen nog iets anders (alleen vriendin geen kinderen) en de beste man heeft al twee kinderen van 16+ rondlopen...

Ik denk ook zelf dat de enige manier is hem proberen om hoog te krijgen naar het niveau en hem dus inderdaad afgebakken stukken programmering geef om te schrijven en dit zelf te reviewen + unit tests voor te schrijven en hem dit laten nakijken + zelf laten draaien zodat hij daarin thuis gaat komen.

[CT]

Ik zou een 'stap' terug nemen en naar de situatie zelf kijken:

Jij was de enige programmeur en blijkbaar was het belangrijk dat er extra handen moesten komen omdat er teveel werk was/is en/of het idee dat er geen 'tweede'-man is bij afwezigheid heeft de 'manager' doen besluiten een extra persoon aan te nemen?

Deze manager heeft waarschijnlijk gevraagd "Hey .Vii, waar moet de nieuwe kandidaad aan voldoen?" en jij gaf een lijstje? Stond er op dit lijstje geen git, composer etc?

Je hebt je twijfels al uitgesproken na het zien van zijn profiel, en vervolgens is de kandidaat toch aangenomen, leuk en aardig. Maar wat is precies je rol binnen het bedrijf? Wat staat er in je arbeidscontract? Ben je verplicht trainingen / leiding te geven?

En..
Hoe belangrijk is de applicatie waar nu aan wordt gewerkt?
Als je morgen ontslag neemt, gaat het bedrijf dan failliet als ze niet direct iemand aannemen die ineens wel voldoet aan jou eisen?

[.Vii]

CT schreef op zaterdag 22 september 2018 @ 10:24:
Ik zou een 'stap' terug nemen en naar de situatie zelf kijken:

Jij was de enige programmeur en blijkbaar was het belangrijk dat er extra handen moesten komen omdat er teveel werk was/is en/of het idee dat er geen 'tweede'-man is bij afwezigheid heeft de 'manager' doen besluiten een extra persoon aan te nemen?

Deze manager heeft waarschijnlijk gevraagd "Hey .Vii, waar moet de nieuwe kandidaad aan voldoen?" en jij gaf een lijstje? Stond er op dit lijstje geen git, composer etc?

Je hebt je twijfels al uitgesproken na het zien van zijn profiel, en vervolgens is de kandidaat toch aangenomen, leuk en aardig. Maar wat is precies je rol binnen het bedrijf? Wat staat er in je arbeidscontract? Ben je verplicht trainingen / leiding te geven?

En..
Hoe belangrijk is de applicatie waar nu aan wordt gewerkt?
Als je morgen ontslag neemt, gaat het bedrijf dan failliet als ze niet direct iemand aannemen die ineens wel voldoet aan jou eisen?

In de vacature stond inderdaad dat het belangrijk was dat je "web standaard" kende omtrent PHP programmeren, verder niet gespecificeerd wat dat precies inhield, tijdens het sollicitatie gesprek is dit wel ter spraken gekomen waarin hij al aangaf dat hij hier geen kennis van had.

Ik heb verder geen invloed gehad op de sollicitatie procedure, ik heb mijn mening moeten geven over het programmeer gedeelte en dat heb ik gedaan dat ik er mijn twijfels over had of het wel geschikt was en of hij wel mee zou komen.

De applicatie is door de tijd heen kritisch geworden binnen de organisatie. Het is niet zo dat als ik weg ga dat een dag later de hele boel omvalt (daarvoor heb ik het stabiel genoeg geprogrammeerd). Echter wordt het wel in 1 klap een black box voor de organisatie wat erin gebeurd vanwege dat alle kennis dan weg valt hierover.

Ik ben overigens niet verplicht trainingen ed. te geven, echter staat er wel in het contract in de trend van "Het kan voorkomen dat werkgever de werknemer vraagt werkzaamheden te verrichten welke niet in zijn functie profiel zijn opgenomen". Dus uit eindelijk kan je daar alles onder laten vallen.

[CT]

Ja die zin is wel redelijk standaard, maar dat gaat vaak over wat billijk is, bijv. helpen bij normaal inwerken van een collega of andere huishoudelijke zaken die vaak sporadisch voorkomen.
Staat er verder niks over eventueel 'jezelf verder ontwikkelen' in het contract?

Want wat de manager nu van je vraagt (het verlagen van het niveau) betekend dat je jezelf niet meer kan ontplooien en dus de uitdaging ook weg is. Dit zijn vaak enorme breekpunten tijdens een functioneringsgesprek bijv. het getuigd ook (naar mijn mening) van mismanagement.

Wil je graag leiding geven / trainingen e.d.met de daarbij behorende functie omschrijving en loon?
Wil je meer uitdaging in je werk en je skills verder ontplooien met wat je nu doet en zou het dan niet prettiger zijn als ze een (meer) ervaren persoon aannemen zodat je iemand hebt om mee te 'sparren'?

Want je bent duidelijk niet blij met de ontstane situatie, niks ten nadele van de aangenomen kandidaat, dus ik zou beginnen met een gesprek erover met de leiding gevende en aangeven wat je zelf wilt en waar je naartoe wilt.

Want door het code-level te verlagen en je nu zonder tegenstribbelen in een nieuwe rol te laten zetten zal op lange termijn niks voor jou gaan opleveren vrees ik..

[incaz]

Ik zou toch gaan lobbyen voor een fatsoenlijke bijscholingscursus voor de nieuwe medewerker. "Jij hebt het jezelf toch ook aangeleerd" is misschien te counteren met "ja, maar dat kostte veel tijd die we nu beter kunnen besteden aan het snel en goed opleiden van iemand, ipv de lange omweg te nemen."

En verder zou ik zeggen: comrpomiteer je werk niet. Als dat maakt dat je daar niet meer kunt blijven werken (en ze zouden echt gek zijn om een goede programmeur weg te sturen), dan liever met opgeheven hoofd en code die goed is en die zij naar de knoppen helpen, dan dat je jezelf verliest omdat jij onder je standaarden gaat werken. Er is vrijwel niets zo demotiverend en ondermijnend als dat: slecht werk leveren en weten dat het slecht is. En met wel een goede grip op git, composer, laravel en unit testing, heb je een veilig genoeg uitgangspunt lijkt me.
Durf te zeggen dat het een breekpunt voor jou is. Dat je met alle liefde en plezier wilt helpen de kwaliteit hoog te houden, je nieuwe medewerker in te werken en wegwijs te maken, maar dat je 1. geen professioneel opleider bent en niet het hele scholingstraject voor je rekening kunt nemen, en 2. dat je echt niet overgaat op een slechtere, instabielere manier van het opzetten van code omdat jij ook je professionaliteit hebt.

[eric.1]

.Vii schreef op zaterdag 22 september 2018 @ 10:55: ... Echter wordt het wel in 1 klap een black box voor de organisatie wat erin gebeurd vanwege dat alle kennis dan weg valt hierover.

Dan is de documentatie toch niet geheel op orde ?

Volgens mij is dat een situatie die je altijd moet zien te voorkomen. Voor hetzelfde geld word je morgen ziek; poof bedrijf weet niets meer over die applicatie.

Tevens kan die documentatie de nieuwkomer helpen?

[Morty]

.Vii schreef op zaterdag 22 september 2018 @ 09:03:
Hi all,

Momenteel zit ik op het werk met een probleem. Na een hele lange tijd de enige "programmeur" te zijn binnen het bedrijf en functioneel app. beheerder te zijn hebben ze eindelijk iemand extra aangenomen die ook kan programmeren. (webbased php, sql ed.).

Echter heeft deze persoon nog nooit gehoord van de termen, composer, git, unit testing ed. mijn manager geeft aan dat het coding niveau moet worden verlaagd zodat hij ook kan mee gaan programmeren zodat we een fallback hebben wanneer ik weg val. (Dat was uberhaupt het idee).

Echter voel ik daar zelf niet zo heel veel voor, de beste man is gewend om in procedurele code te programmeren en niet in OOP stijl.

Wat is jullie mening hierover?

Je zal met argumenten moeten komen waar je manager iets mee kan. Dat jij graag git wilt gebruiken, unit testen maakt, en OOP programmeert, en liever niet verandert is voor je manager maar beperkt relevant. Je zal hem moeten uitleggen waarom die dingen essentieel zijn voor het bedrijfsbelang. Kom daarom met argumenten over robuustheid, onderhoudbaarheid, en uitbreidbaarheid op lange termijn. Overtuig hem dat het 'verlagen van het niveau' uiteindelijk veel meer geld gaat kosten. (of dat daadwerkelijk zo is hang natuurlijk af van de specifieke applicatie en hoe groot en bedrijfskritisch deze is, maar dat kan ik zo niet beoordelen)

[iamcj]

.Vii schreef op zaterdag 22 september 2018 @ 09:03:
Hi all,

Momenteel zit ik op het werk met een probleem. Na een hele lange tijd de enige "programmeur" te zijn binnen het bedrijf en functioneel app. beheerder te zijn hebben ze eindelijk iemand extra aangenomen die ook kan programmeren. (webbased php, sql ed.).

Echter heeft deze persoon nog nooit gehoord van de termen, composer, git, unit testing ed. mijn manager geeft aan dat het coding niveau moet worden verlaagd zodat hij ook kan mee gaan programmeren zodat we een fallback hebben wanneer ik weg val. (Dat was uberhaupt het idee).

Echter voel ik daar zelf niet zo heel veel voor, de beste man is gewend om in procedurele code te programmeren en niet in OOP stijl.

Wat is jullie mening hierover?

Als ik het hele topic lees, denk ik maar 1 ding. Als jij niet trouw blijft aan je eigen principes wordt je daar waarschijnlijk ongelukkig. Eerst heb je het zelf niet door en dan ga je je aan steeds aan meer dingen storen, maar ja het werk zelf is toch leuk, ga je toch stress ervaren en ben je straks 2 jaar verder moegestreden. Dus ga nu voor je principes staan. Waarschijnlijk doen ze daar niets mee of maar de helft. Ga dan een andere baan zoeken waar je ze het wel "snappen", want de vraag op zich geeft al aan dat je manager er niets van snapt.

Ik heb nu na 3 jaar gedoe en sleuren eindelijk weer een manager die meedenkt. Het is zo'n verademing om gewoon lekker naar je werk te kunnen gaan en je energie te stoppen in zaken waar het over moet gaan.

Je bent een dief van je eigen leven, geluk en portemonnee.

Als je daar toch wil blijven, doe dat gewoon wat jij denkt wat je moet doen om een goed product af te leveren. Uiteindelijk help je daar het bedrijf meer mee, dan om te proberen om met spagetti aan hun ongefundeerde deadlines te voldoen.

Het is de taak van jouw manager om de druk niet bij jou te leggen, maar om de verwachtingen van zijn bazen te managen.

[Yucon]

Heeft hij een gedegen scholing gehad? Of is het een doorgegroeide hobbyist? In dat laatste geval zit er, samen met je opmerkingen over leeftijd en over 'functioneel' misschien wel gewoon in redelijkheid een bovengrens qua niveau waar je in je aanpak rekening mee zult moeten houden.

[MijnAccount]

Ik ben het eens met veel van bovenstaande reactie. Ik moet denken aan de titel van het boek "Sell or be sold". Ik twijfel niet aan je programmeer skills. Dit is een fantastisch moment om te oefenen aan je sales skills om voor jezelf een werk omgeving te maken waar jij het best in presteert en waarin het beste product wordt opgeleverd. Bij een kleine IT afdeling is dat weer heel anders dan bij een grote.

Je hebt je baas niet kunnen overtuigen om iemand anders aan te nemen, jij moet het fixen. Uiteindelijk kost dit jouw baas geld dat hij niet de juiste persoon heeft aangenomen. Jij hebt er alleen frustraties onder werktijd van. Fix dit voor jouw baas.

[t_captain]

Web standards, en dat vervolgens afdoen met “php”. Daar gaat iets fout.

Iemand die web standards echt beheerst, is goed op de hoogte van TCP/IP, HTTP, HTTP2 en websockets.

Van gebruikers, sessies en requests, van authenticatie en authorisatie.

Van HTML5, CSS3 (bij voorkeur ook SASS) en moderne javascript versies.

Heel belangrijk aan zowel front-end als back-end: asynchroon programmeren. Bij front-end verplicht, bij back-end een issue zodra je wat meer performance nodig hebt.

[|sWORDs|]

Als je git niet in een paar uur kan leren dan ben je in mijn ogen niet geschikt voor de IT.

[incaz]

|sWORDs| schreef op zaterdag 22 september 2018 @ 19:08:
Als je git niet in een paar uur kan leren dan ben je in mijn ogen niet geschikt voor de IT.

Altijd fijn, dat soort vooroordelen. Tegenmening: iedereen die met git werkt en zichzelf niet dagelijks ergert heeft snapt niets van gebruiksvriendelijkheid en is niet geschikt voor de IT.

[CH4OS]

Ik zou het ook omdraaien; zorgen dat die nieuwe collega zsm up to speed is met zaken als git, unit testing, you name it. Zou je moeten verlagen zodat hij wel mee kan doen, kan dat ook effect hebben op de applicatie, vraag me af of men daarop zoveel wil inleveren, maar lijkt me niet. Ook is het voor die nieuwe collega beter om nieuwe dingen te leren, dan breidt diegene de kansen uit bij toekomstige sollicitaties e.d. Meer kennis kan nooit kwaad, lijkt me.

Zelf ben ik zo ook begonnen bij een oud werkgever van me. UIteindelijk hebben ze mij een heleboel geleerd, aangaande Zend Framework 2, git, unit testing en zelfs OOP (wist wel wat dingen, maar lang niet zoveel als nu). Ik ben dat bedrijf daar erg dankbaar voor, dat is kennis en kunde dat ik altijd met me zal meenemen, immers.

incaz schreef op zaterdag 22 september 2018 @ 19:21:
Altijd fijn, dat soort vooroordelen. Tegenmening: iedereen die met git werkt en zichzelf niet dagelijks ergert heeft snapt niets van gebruiksvriendelijkheid en is niet geschikt voor de IT.

Git is momenteel dé standaard voor code- en scriptversioning, als je als ontwikkelaar / systeembeheerder git niet kent wil ik niet zeggen dat je niet geschikt bent voor de IT, maar dan begin je wel met een punt achterstand, zeg maar.

t_captain schreef op zaterdag 22 september 2018 @ 12:49:
Web standards, en dat vervolgens afdoen met “php”. Daar gaat iets fout.

Iemand die web standards echt beheerst, is goed op de hoogte van TCP/IP, HTTP, HTTP2 en websockets.

Van gebruikers, sessies en requests, van authenticatie en authorisatie.

Van HTML5, CSS3 (bij voorkeur ook SASS) en moderne javascript versies.

Heel belangrijk aan zowel front-end als back-end: asynchroon programmeren. Bij front-end verplicht, bij back-end een issue zodra je wat meer performance nodig hebt.

Dat verschilt heel erg per bedrijf. Zelfs of iemand junior, medior of senior ontwikkelaar is verschilt per bedrijf enorm. Ook 'goed op de hoogte zijn van...' valt daaronder. Op mijn werk hoef ik niet heel erg op de hoogte zijn van HTTP/2, HTTP(S) of TCP/IP en websockets. Nu weet ik wel ongeveer wat je ermee kan of wat het is, maar om te zeggen dat ik niet kan werken omdat ik niet 'goed op de hoogte ben' ervan, nee, dat vind ik ook zeer zeker niet. Maar komt misschien ook omdat wij onze servers hebben uitbesteed aan een externe partij.

[ Voor 52% gewijzigd door CH4OS op 22-09-2018 19:57 ]

[Gonadan]

Zelf heb ik hetzelfde gehad met meerdere nieuwe teamleden. Steeds opleiden maar ze raken nooit bij, sterker nog, de afstand groeit feitelijk alleen maar. Zeker als er nog nieuwe junioren bij komen die een relevante achtergrond ontberen.
Een tijdje heb ik dus gedaan wat sommigen adviseren, uitdaging zoeken en opleiden. Uiteindelijk gaat het toch wringen en voelde ik mij er niet met gelukkig bij, dus alsnog de stap genomen om eruit te stappen en weer op niveau te gaan werken.

Inferieure kwaliteit leveren omdat management niets van ontwikkeling snapt zou ik nooit mee kunnen leven. Dan zou ik gewoon buiten de deur gaan kijken

[incaz]

CH4OS schreef op zaterdag 22 september 2018 @ 19:29:
Git is momenteel dé standaard voor code- en scriptversioning, als je als ontwikkelaar / systeembeheerder git niet kent wil ik niet zeggen dat je niet geschikt bent voor de IT, maar dan begin je wel met een punt achterstand, zeg maar.

Alleen was dat de stelling niet.

[CH4OS]

incaz schreef op zaterdag 22 september 2018 @ 19:57:
Alleen was dat de stelling niet.

Ik sloeg misschien wat stappen over in mijn vorige reactie. Maar ik bedoel dus dat het mij verbaasd dat iemand als ontwikkelaar komt, die geen git kent. Wat dat betreft hoort git eigenlijk bij de basics tegenwoordig voor een systeembeheerder en voor een ontwikkelaar.

Ik vind het dan wel wat ver gaan om te zeggen dat als je geen git kent, je eigenlijk niet geschikt bent voor IT, maar ik vind wel, dat je dan - zeker bij een sollicitatie - een punt achter staat tov sollicitanten die wel git kennen.

Voordeel is wel, dat git an sich echt niet moeilijk is, dus dat is zo opgepakt en aangeleerd.

[ Voor 26% gewijzigd door CH4OS op 22-09-2018 20:05 ]

[incaz]

CH4OS schreef op zaterdag 22 september 2018 @ 20:00:
Ik sloeg misschien wat stappen over in mijn vorige reactie. Maar ik bedoel dus dat het mij verbaasd dat iemand als ontwikkelaar komt, die geen git kent.

Je reageert vooral op iets wat ik niet schreef.

Wat dat betreft hoort git eigenlijk bij de basics tegenwoordig voor een systeembeheerder en voor een ontwikkelaar.

Ik ben er ook bang voor... en het geeft de bedroevende staat van IT als branche wel een beetje aan: goed in techniek maar buitengewoon slecht in de koppeling met de mensenwereld.

Ik vind het dan wel wat ver gaan om te zeggen dat als je geen git kent, je eigenlijk niet geschikt bent voor IT

Maar niemand zei dat dus.

Voordeel is wel, dat git an sich echt niet moeilijk is, dus dat is zo opgepakt en aangeleerd.

Dat lijkt me niet echt correct.

[Gonadan]

@CH4OS als je kennen bedoelt geef ik je gelijk, als je volledig beheersen bedoelt slaat dat nergens op.
Git is met name in de open source wereld populair geweest en pas relatief kort ook de standaard geworden in bijvoorbeeld TFS. Het is wat mij betreft veel te kort door de bocht dat je het gebruikt moet hebben om een echte IT'er te zijn.

Weer je daarnaast echt niet wat het is of heb je er amper over gelezen dan heb je gewoon onder een steen geprogrammeerd.

[CH4OS]

incaz schreef op zaterdag 22 september 2018 @ 20:10:
Je reageert vooral op iets wat ik niet schreef.

Jij haakt in op een mening van iemand en gaf daarbij een tegen reden. Ik stap vervolgens bij die discussie in en haak daarbij aan vanaf jouw reactie met tegenargumenten waarom het wel in de basics hoort van een systeembeheerder / ontwikellaar en vervolgens gaat het om iets wat je niet schreef? Juist ja.

Ik ben er ook bang voor... en het geeft de bedroevende staat van IT als branche wel een beetje aan: goed in techniek maar buitengewoon slecht in de koppeling met de mensenwereld.

Als je in de IT wilt werken, maar de basics niets beheerst is dat net als willen rennen terwijl je niet eens kan lopen.

Maar niemand zei dat dus.

Heb je de reactie waar jij in eerste instantie op reageerde dan wel überhaupt gelezen?

Dat lijkt me niet echt correct.

Waarom denk je dit? Ik heb zelf diverse tools draaien thuis wat Python scripts zijn, die allen gehost zijn vanuit een git omgeving. Jezelf git aanleren is écht zo moeilijk niet.

Gonadan schreef op zaterdag 22 september 2018 @ 20:15:
@CH4OS als je kennen bedoelt geef ik je gelijk, als je volledig beheersen bedoelt slaat dat nergens op.
Git is met name in de open source wereld populair geweest en pas relatief kort ook de standaard geworden in bijvoorbeeld TFS. Het is wat mij betreft veel te kort door de bocht dat je het gebruikt moet hebben om een echte IT'er te zijn.

Euh, Git is heden ten dagen ook zéér populair. Bij de meeste (95%) vacatures voor ontwikkelaars zie je Git daarom ook wel als eis staan. Vaak zie je dat dan in trant van dat iemand ervaring dient te hebben met git, svn of vergelijkbare technieken. Daarom dat ik vind dat het anno 2018 wel in de basics hoort te zitten. Geen man overboord als dat niet zo is, git kun je an sich immers vrij snel jezelf aanleren, moeilijk is het echt niet. Echter geeft het ook wel een onderbuik gevoel over het niveau van de ontwikkelaar in kwestie en dat is wat ik bedoel met een punt achterstand.

Weer je daarnaast echt niet wat het is of heb je er amper over gelezen dan heb je gewoon onder een steen geprogrammeerd.

Ik weet wat het is, TCP/IP heb ik dan zelfs tot in den treuren op school gehad, van de overige zaken weet ik wát het is, maar ken ik het niet op mijn duimpje.

[ Voor 44% gewijzigd door CH4OS op 22-09-2018 20:25 ]

[Anoniem: 63072]

t_captain schreef op zaterdag 22 september 2018 @ 09:10:
Hier is maar één nuttige oplossing: manager eruit, en met het bespaarde salaris een nieuwe developer aantrekken.

Dat iemand geen ervaring heeft met git, dat is nauwelijks voor te stellen anno 2018. Misschien als iemand uit een zuivere MS achtergrond komt en altijd TFS heeft gebruikt.

Maar niet weten wat een unit test is? Die collega zou wel eens veel meer tijd kunnen kosten dan het werk wat hij je uit handen neemt.

Ik moest lachen. Een waarschijnlijk aanzienelijke OOP codebase in Git en dan de opdracht vanaf nu alles procedureel, dat gaat lekker passen. En als je de puinhoop op wil ruimen, helaas want Git was al vaarwel gezegd.

Overigens heb ik met cvs en svn gewerkt en ik ken Git ook alleen maar in theorie. Ben nu bezig thuis een project op te zetten als studie. Ga daar Git voor gebruiken. Maar het is heel goed mogelijk om vandaag de dag geen ervaring met Git te hebben. Ook als je niet uit een MS shop met TFS komt.

[Gonadan]

CH4OS schreef op zaterdag 22 september 2018 @ 20:16:
Euh, Git is heden ten dagen ook zéér populair bij de meeste vacatures voor ontwikkelaars zie je Git daarom ook wel als eis staan. Daarom dat ik vind dat het anno 2018 wel in de basics hoort te zitten. Geen man overboord als dat niet zo is, git kun je an sich immers vrij snel jezelf aanleren. Echter geeft het ook wel een onderbuik gevoel over het niveau van de ontwikkelaar in kwestie en dat is wat ik bedoel met een punt achterstand.

Nee het zegt echt helemaal niets, nul komma nul. Je kunt prima een weergaloze programmeur zijn maar toch nog niet met Git gewerkt hebben. Dat zegt echt niets over je niveau, echt niet. Weet je hoeveel technieken populair zijn en je dan zou moeten kennen om dergelijk onderbuikgevoel te vermijden?

Wat ik wel vind is dat als het letterlijk in een vacature staat je een onwijze pannenkoek bent als je niet even met Git bent gaan spelen. Dat zegt wel iets over je niveau en met name dat van je drive en leergierigheid.

[CH4OS]

[quote]Gonadan schreef op zaterdag 22 september 2018 @ 20:25:
Nee het zegt echt helemaal niets, nul komma nul. Je kunt prima een weergaloze programmeur zijn maar toch nog niet met Git gewerkt hebben.[/qEens, maar vind ik nog wel dat anno 2018 tools zoals svn en git onderdeel zijn van de basics van een systeembeheerder en/of ontwikkelaar.

Dat zegt echt niets over je niveau, echt niet. Weet je hoeveel technieken populair zijn en je dan zou moeten kennen om dergelijk onderbuikgevoel te vermijden?

Er is een verschil met git / svn / cvs i]niet[/i] kennen en misschien een cvs niet op je duimpje kennen, maar er wel ervaring mee hebben.

Laat ik het dan dus even anders formuleren wat ik bedoel;
Ik vind dat cvs (zij het git, svn, tfs en whatever) onderdeel is van de basics van een systeembeheerder en ontwikkelaar. Je hoeft het dan wat mij betreft niet op je duimpje te kennen, maar er wel kennis van hebben en weten waarvoor het gebruikt wordt (liefst met een beetje ervaring er al mee), lijkt mij toch wel erg handig voor dergelijke IT-medewerkers.

[Gonadan]

[quote]CH4OS schreef op zaterdag 22 september 2018 @ 20:30:
~~~

Gonadan schreef op zaterdag 22 september 2018 @ 20:25:
Nee het zegt echt helemaal niets, nul komma nul. Je kunt prima een weergaloze programmeur zijn maar toch nog niet met Git gewerkt hebben.[/qEens, maar vind ik nog wel dat anno 2018 tools zoals svn en git onderdeel zijn van de basics van een systeembeheerder en/of ontwikkelaar.
[...]
Er is een verschil met git / svn / cvs i]niet~~~[/i] kennen en misschien een cvs niet op je duimpje kennen, maar er wel ervaring mee hebben.

Laat ik het dan dus even anders formuleren wat ik bedoel;
Ik vind dat cvs (zij het git, svn, tfs en whatever) onderdeel is van de basics van een systeembeheerder en ontwikkelaar. Je hoeft het dan wat mij betreft niet op je duimpje te kennen, maar er wel kennis van hebben en weten waarvoor het gebruikt wordt (liefst met een beetje ervaring er al mee), lijkt mij toch wel erg handig voor dergelijke IT-medewerkers.

Nu spreek je over versiebeheer in het algemeen. Als jouw stelling is dat je als ontwikkelaar ervaring met een versiebeheersysteem moet hebben dan ben ik dat 100% met je eens. Ik vind alleen dat daar niet per se Git onder zou moeten vallen.

[pasz]

.Vii schreef op zaterdag 22 september 2018 @ 09:03:
Hi all,


Echter heeft deze persoon nog nooit gehoord van de termen, composer, git, unit testing ed. mijn manager geeft aan dat het coding niveau moet worden verlaagd zodat hij ook kan mee gaan programmeren zodat we een fallback hebben wanneer ik weg val. (Dat was uberhaupt het idee).

Echter voel ik daar zelf niet zo heel veel voor, de beste man is gewend om in procedurele code te programmeren en niet in OOP stijl.

Een manager die zich met techniek bemoeit is een probleem op zich. Jij ben de specialist. Wat ik uit je verhaal denk op te maken, is dat je op dit moment eenoog in het land der blinden bent.

Wat je nieuwe collega betreft. Niet iedereen heeft de luxe gehad zich te ontwikkelen tot een complete programmeur. Wat voor jou allemaal basiskennis is, is voor anderen een grote uitdaging. Ik vind het persoonlijk veel belangrijker dat iemand interesse heeft in nieuwe technologie en de behoefte heeft om dingen te leren.

Met andere woorden. Neem je collega rustig mee in alle principes en als hij echt wil, komt het vanzelf goed.

[CH4OS]

[b]Gonadan in "Coding level verlagen vanwege collega's?"Gonadan schreef op zaterdag 22 september 2018 @
Nu spreek je over versiebeheer in het algemeen.

Vandaar dat ik de mening even iets genuanceerd heb en dat ook aangaf met dat ik het even anders ging schrijven, om de mening goed weer te geven. Git lijkt mij overigens wel het meest voor de hand liggend, omdat dat git gewoon (zeker bij de bedrijven waar ik de afgelopen jaren gesolliciteerd heb) het cvs was dat gebruikt werd en dat bij andere vacatures (ook nu nog) het meeste voorbij zie komen.

[ Voor 8% gewijzigd door CH4OS op 22-09-2018 20:38 ]

[incaz]

CH4OS schreef op zaterdag 22 september 2018 @ 20:16:
Jij haakt in op een mening van iemand en gaf daarbij een tegen reden. Ik ga daar vervolgens half in en vervolgens gaat het om iets wat je niet schreef? Juist ja.

Inderdaad: juist ja. Jij reageert op mij door iets te weerleggen dat ik niet schreef, en wat ook de oorspronkelijke reactie niet was.

Heb je de reactie waar jij in eerste instantie op reageerde dan wel überhaupt gelezen?

Ja:

quote: Oorspronkelijke quote, bolding mine

Als je git niet in een paar uur kan leren dan ben je in mijn ogen niet geschikt voor de IT.

Dat ging er dus niet om of iemand git kent, maar of iemand het in een paar uur kan leren.

Mijn tegenreactie is ietwat gecharcheerd maar het lijkt me meer dan menselijk dat je git niet in een paar uur kunt leren en eerder iets dat voor iemand spreekt dan tegen diegene.

Als je in de IT wilt werken, maar de basics niets beheerst is dat net als willen rennen terwijl je niet eens kan lopen.

Git is niet de basis van programmeren. Het is een tool die erg nuttig en belangrijk is om aan de gang te kunnen, die lijdt aan dezelfde kwaal als waar veel IT zelf ook aan lijdt: het idee dat het redelijk is om te verwachten dat gebruikers zich aanpassen aan de onlogica van de makers, ipv dat een tool de gebruikers zo goed mogelijk faciliteert.

Het is inderdaad op dit moment een de facto standaard en je moet het kennen. Maar programmeren zelf kan prima zonder git, en git kennen helpt niets aan je begrip van code (alleen maar aan het onderhouden ervan) en is daarmee geen basis.

Waarom denk je dit?

Omdat de ervaring van vrijwel iedereen is dat git een tool is met een steile leercurve waar je meer ervaring mee moet opdoen voor je de finesses een beetje in de vingers kunt krijgen en voor je een mental model
hebt waarmee je een beetje grip hebt op de verschillende states waarin je code kan zijn en kan samenvallen met de code van andere versies.

Ik geloof in alle eerlijkheid werkelijk niet dat er veel programmeurs zijn die dat van 0 in een paar uur hebben geleerd.

Ik heb zelf diverse tools draaien thuis wat Python scripts zijn, die allen gehost zijn vanuit een git omgeving. Jezelf git aanleren is écht zo moeilijk niet.

Is dat representatief? Meestal treden de problemen pas op als er andere mensen zijn en je merge conflicts krijgt of probeert iets ongedaan te maken terwijl je een ander deel van je werk probeert te behouden.
Dat zijn situaties die bij mij aanmerkelijk minder vaak voorkomen als ik met eigen of relatief kleine code bases of scripts aan de gang ga.

[CH4OS]

incaz schreef op zaterdag 22 september 2018 @ 20:37:
Dat ging er dus niet om of iemand git kent, maar of iemand het in een paar uur kan leren.

Mijn tegenreactie is ietwat gecharcheerd maar het lijkt me meer dan menselijk dat je git niet in een paar uur kunt leren en eerder iets dat voor iemand spreekt dan tegen diegene.

Git is echt zo moeilijk niet. Een uiterste basis kun je dan heus wel leggen met een paar uurtjes. Je kent het dan natuurlijk niet op je duimpje, maar ik denk ook niet dat dat een probleem is.

Git is niet de basis van programmeren. Het is een tool die erg nuttig en belangrijk is om aan de gang te kunnen, die lijdt aan dezelfde kwaal als waar veel IT zelf ook aan lijdt: het idee dat het redelijk is om te verwachten dat gebruikers zich aanpassen aan de onlogica van de makers, ipv dat een tool de gebruikers zo goed mogelijk faciliteert.

Maar dat is niet wat ik bedoel. Naar mijn mening hoort kennis van een cvs (of cvs in het algemeen) in het (Zwitserse) zakmes te zitten wat van een systeembeheerder of ontwikkelaar is. Anno 2018 wordt dat dusdanig veel gebruikt, dat je echt wel kan stellen dat kennis ervan zeker wel thuishoort in de basics van de systeembeheerder / ontwikkelaar. Jij maakt er zelf opeens van dat het bij de basics van het programmeren hoort, maar dat heb ik niet zo gezegd.

Omdat de ervaring van vrijwel iedereen is dat git een tool is met een steile leercurve waar je meer ervaring mee moet opdoen voor je de finesses een beetje in de vingers kunt krijgen en voor je een mental model
hebt waarmee je een beetje grip hebt op de verschillende states waarin je code kan zijn en kan samenvallen met de code van andere versies.

Ja, het heeft wat curve, maar die is echt niet zó steil als jij doet schetsen dat het is.

Ik geloof in alle eerlijkheid werkelijk niet dat er veel programmeurs zijn die dat van 0 in een paar uur hebben geleerd.

Documentatie erbij pakken en wat dingen doen op de commandline, brengt iemand al heel ver. Van daar uit kun je vervolgens verder uitbouwen, eventueel met hulp van de diverse fora en how to's op internet, die zijn er legio.

Is dat representatief? Meestal treden de problemen pas op als er andere mensen zijn en je merge conflicts krijgt of probeert iets ongedaan te maken terwijl je een ander deel van je werk probeert te behouden.
Dat zijn situaties die bij mij aanmerkelijk minder vaak voorkomen als ik met eigen of relatief kleine code bases of scripts aan de gang ga.

Het geeft op zijn minst kennis en kunde; je weet waar het voor is en je weet hoe je bepaalde dingen doet en waarom; het geeft dus wel degelijk feeling. Dat is nog altijd beter dan niets, lijkt mij zo.

Voor wat betreft conflicts e.d; Ik ben zelf vooral van al doende leert men en ik denk dat zo'n manier ook de beste methode is om Git te leren, natuurlijk wel met een collega erbij die over de schouder meekijkt om te zien of alles dan desondanks nog wel in goede banen wordt geleid om het op te lossen.

[ Voor 4% gewijzigd door CH4OS op 22-09-2018 20:46 ]

[Gonadan]

Even terug naar de OP

PHP is geen programmeren. Heeft hij het denkniveau en de ambitie om echt richting OO te gaan?

De manager zegt code niveau verlagen. Als hij alles moet snappen moet je dus alle huidige code herschrijven naar script. Reken je manager die kostenpost eens voor.

[Erapaz]

Hele discussie over git, maar het woord pull request is nog niet gevallen?
Dan kan je collega lekker los gaan op de code en versiebeheer. Hierna reviewen jullie samen zijn (en jouw) werk en als jullie tevreden zijn merge het naar de branch waarvan je je test en productie builds maakt.
Dit is een veilige manier om iemand snel de nieuwe omgeving eigen te maken. Het maakt ook heel inzichtelijk wat er precies gebeurt.
Onderschat verder de meerwaarde van pair programming niet. Hij kan dan van jou leren en tegelijkertijd zal hij jou ook helpen, ondanks dat hij bepaalde ervaringen mist. Twee zien meer dan 1 en als hij een beetje logisch kan nadenken zal hij ook van toegevoegde waarde zijn in het interpreteren van de requirements en bijv. het bedenken van testcases.

Software development is zoveel meer dan programmeren alleen!

[gebruikershaes]

@Erapaz +1
He tkan soms frustrerend zijn om iemand steeds uit te leggen hoe het werkt, zeker als je onder tijdsdruk staat.
Maar wat ik zelf merk is dat je door het uitleggen ook beter nadenkt over je eigen keuzes en oplossingen. Hier wordt je zelf ook beter van. Dus het zou zomaar kunnen werken.
Ik zou zeggen kijk het nog ff aan, maar ga je niet verlagen in niveau, want daar wordt niemand gelukkig van.

[incaz]

Gonadan schreef op zaterdag 22 september 2018 @ 20:47:
PHP is geen programmeren. Heeft hij het denkniveau en de ambitie om echt richting OO te gaan?

Ah, meer vooroordelen. Je kunt prima OO programmeren in php.

CH4OS schreef op zaterdag 22 september 2018 @ 20:45:
[...]
Git is echt zo moeilijk niet. [...]
Voor wat betreft conflicts e.d; Ik ben zelf vooral van al doende leert men en ik denk dat zo'n manier ook de beste methode is om Git te leren,

Ik zou haast zeggen dat je nog niet hebt meegemaakt dat het best wel eenvoudig is om tijdens een fout iets te doen waarmee je recente code permanent kwijt raakt. Een verkeerd geplaatste revert, reset of checkout kan nare gevolgen hebben.

Zelf heb ik daar dus vooral van geleerd dat git een gebruikersonvriendelijke tool is die dingen doet die ik als programmeur niet aanvaardbaar zou vinden: destructieve changes te gemakkelijk maken.
(Van de andere kant, dat schijnt een beetje extra waarde te geven, het idee dat je dan kunt bewijzen dat je een 'echte' programmeur bent omdat je met gebruiksonvriendelijke tools kunt werken. Een soort snobbisme.)

natuurlijk wel met een collega erbij die over de schouder meekijkt om te zien of alles dan desondanks nog wel in goede banen wordt geleid om het op te lossen.

Ah. Dan wordt het een stuk makkelijker wellicht. Maar dan is het weer niet echt een basic.

[CH4OS]

incaz schreef op zaterdag 22 september 2018 @ 21:10:
Ah, meer vooroordelen. Je kunt prima OO programmeren in php.

Of PHP wel of geen programmeren is hangt af van de definitie van programmeren die je hanteert, maar laten we die discussie hier niet voeren, zijn er al genoeg geweest, denk ik zo. En het voegt ook niets toe aan het vraagstuk van .Vii.

Ik zou haast zeggen dat je nog niet hebt meegemaakt dat het best wel eenvoudig is om tijdens een fout iets te doen waarmee je recente code permanent kwijt raakt. Een verkeerd geplaatste revert, reset of checkout kan nare gevolgen hebben.

Al doende leert men, dus ook (of misschien wel juist) van de fouten. Dus dergelijke dingen heb ik wel degelijk al gehad.

Zelf heb ik daar dus vooral van geleerd dat git een gebruikersonvriendelijke tool is die dingen doet die ik als programmeur niet aanvaardbaar zou vinden: destructieve changes te gemakkelijk maken.

Ik gebruik zelf git het liefste via de commandline, dat maakt het voor mij een boel makkelijker en duidelijker. Dergelijke zaken heb ik verder dan ook niet echt gehad anders dan bij merge conflicts en ik de boel verkeerd mergde en mijn aanpassingen weg waren.

Ah. Dan wordt het een stuk makkelijker wellicht. Maar dan is het weer niet echt een basic.

Een merge conflict is in mijn optiek inderdaad ook geen basic cvs / git.

[Gonadan]

incaz schreef op zaterdag 22 september 2018 @ 21:10:
Ah, meer vooroordelen. Je kunt prima OO programmeren in php.

Nee, geen vooroordeel. Je kunt inderdaad enigszins OO scripten in PHP. Maar hoe groot schat jij die kans gezien de OP?
Voel je niet aangevallen want het is geen waardeoordeel, meer een inschatting van het huidige niveau van de collega en waar die mogelijkerwijs heen wilt.

[incaz]

CH4OS schreef op zaterdag 22 september 2018 @ 21:15:
[...]
Of PHP wel of geen programmeren is hangt af van de definitie van programmeren die je hanteert,

Nee hoor. Je kunt prima OO programmeren in PHP en dat valt helemaal onder welke definitie van programmeren ook tenzij je het expres erbuiten probeert te framen.

maar laten we die discussie hier niet voeren, zijn er al genoeg geweest, denk ik zo.

Zolang dat soort vooroordelen herhaald worden, denk ik dat er ook tegenin gegaan moet worden. PHP is niet automatisch minderwaardig en de IT is een sector met veel te veel van dat soort rare elitistische neigingen. En dat doet de kwaliteit van het vak schade.

Al doende leert men, dus ook (of misschien wel juist) van de fouten. Dus dergelijke dingen heb ik wel degelijk al gehad.

Didactisch is het een hele inefficiente manier van leren. Dus geen idee waarom je dat zou willen.

Een merge conflict is in mijn optiek inderdaad ook geen basic cvs / git.

Mooi hoe het onderwerp steeds opschuift. Nu hebben we het ineens over basic cvs.

Gonadan schreef op zaterdag 22 september 2018 @ 21:21:
[...]

Nee, geen vooroordeel. Je kunt inderdaad enigszins OO scripten in PHP.

Onzin. PHP ondersteunt al geruime tijd gewoon keurige OO-paradigma's. Niet 'enigzins', niet 'scripten' maar gewoon OO.

Maar hoe groot schat jij die kans gezien de OP?
Voel je niet aangevallen want het is geen waardeoordeel, meer een inschatting van het huidige niveau van de collega en waar die mogelijkerwijs heen wilt.

Natuurlijk is het wel een waardeoordeel. Niet ineens doen alsof het dat niet is.

En verder: ik schat de kans dat de nieuwe medewerker er veel van kan vrij klein in. Maar de huidige OO code base kan ook prima in PHP zijn - in de startpost staat geen informatie voor of tegen. Wil je OO programmeurs, dan moet je checken op OO kennis, geen vooraannames doen op grond van de taal.

[CH4OS]

incaz schreef op zaterdag 22 september 2018 @ 21:50:
Nee hoor. Je kunt prima OO programmeren in PHP en dat valt helemaal onder welke definitie van programmeren ook tenzij je het expres erbuiten probeert te framen.

Zolang dat soort vooroordelen herhaald worden, denk ik dat er ook tegenin gegaan moet worden. PHP is niet automatisch minderwaardig en de IT is een sector met veel te veel van dat soort rare elitistische neigingen. En dat doet de kwaliteit van het vak schade.

Mij is het om het even. Het gaat om het resultaat, boeiend dat de een het programmeren noemt en de ander niet.

Didactisch is het een hele inefficiente manier van leren. Dus geen idee waarom je dat zou willen.

Ik merk in veel van jouw posts dat jij meer als manager reageert dan als een programmeur, dat kan aan mij liggen en als dat niet zo is, jammer dan, maar voor mij leer ik sommige dingen door het zelf te doen en te proberen het beste. Kan jij als inefficiënt bestempelen, maar op deze manier heb ik wel het meeste van wat ik weet van o.a. git, maar ook andere zaken zoals HTML, Javascript, CSS, SQL en PHP.

Mooi hoe het onderwerp steeds opschuift. Nu hebben we het ineens over basic cvs.

Als je het topic had gezien, had ik allang mijn mening verder verduidelijkt en wat opgeschoven.

[ Voor 4% gewijzigd door CH4OS op 22-09-2018 21:55 ]

[Gonadan]

@incaz je stelt je aan. Ik heb geen zin in een discussie over talen maar de verschillen zijn er gewoon. Onder de streep denk je eigenlijk hetzelfde dus ik snap de dwangmatige verdediging niet echt.

[|sWORDs|]

incaz schreef op zaterdag 22 september 2018 @ 19:21:
[...]


Altijd fijn, dat soort vooroordelen. Tegenmening: iedereen die met git werkt en zichzelf niet dagelijks ergert heeft snapt niets van gebruiksvriendelijkheid en is niet geschikt voor de IT.

Cheer up, grapje moet kunnen.

[dakka]

gewoon op kosten van de chef een paar pizzaCoding avonden doen, kijken hoe snel jullie op niveau zitten

CH4OS schreef op zaterdag 22 september 2018 @ 20:00:
[...]
Ik sloeg misschien wat stappen over in mijn vorige reactie. Maar ik bedoel dus dat het mij verbaasd dat iemand als ontwikkelaar komt, die geen git kent. Wat dat betreft hoort git eigenlijk bij de basics tegenwoordig voor een systeembeheerder en voor een ontwikkelaar.

git komt niet echt veel voorbij in opleidingen(of tutorials for that matter)het is echt iets dat je ergens moet oppikken, zoals NPM (maar wat moet een systeem beheerder met git?)

[ Voor 75% gewijzigd door dakka op 23-09-2018 01:51 ]

[Tweezitsbank]

Kennelijk heeft het bedrijf een programmeur aangenomen zonder de (enige) huidige programmeur in dit proces te betrekken. Merkwaardig maar vooruit, je moet het er mee doen nu.

Ik zou er in ieder geval voor waken dat jij je niet verantwoordelijk maakt voor het werk van een ander. Je kunt de basics uitleggen (lees: laten zien waar de handleiding te vinden is van Git/Laravel en weet ik wat meer) maar jij bent niet aangenomen om docent te spelen, daar zijn andere instituten voor. Je zou eventueel conventies op kunnen stellen ("zo gebruiken wij Git") maar daar zou het bij mij ophouden.

Ik heb ook ooit moeten leren om in een team te werken. Ik besefte dat de source code niet mijn eigendom was maar van het bedrijf en dat de andere personen daar net zo goed voor verantwoordelijk voor waren. Je roeit met de riemen die je hebt. Als een product te groot wordt moet je dus zaken uit handen gaan geven. Soms gaat dat goed, soms niet. Maar dat is niet mijn probleem, daar zijn managers voor. Ik heb mijn eigen werk, net als ieder ander.

[Tweezitsbank]

CH4OS schreef op zaterdag 22 september 2018 @ 20:00:
[...]
Ik sloeg misschien wat stappen over in mijn vorige reactie. Maar ik bedoel dus dat het mij verbaasd dat iemand als ontwikkelaar komt, die geen git kent. Wat dat betreft hoort git eigenlijk bij de basics tegenwoordig voor een systeembeheerder en voor een ontwikkelaar.

Ik vind het dan wel wat ver gaan om te zeggen dat als je geen git kent, je eigenlijk niet geschikt bent voor IT, maar ik vind wel, dat je dan - zeker bij een sollicitatie - een punt achter staat tov sollicitanten die wel git kennen.

Voordeel is wel, dat git an sich echt niet moeilijk is, dus dat is zo opgepakt en aangeleerd.

Ik ken genoeg programmeurs die nog nooit met Git gewerkt hebben. Meestal zijn dat mensen die aan een legacy product werken waarbij het teveel moeite kost om dit over te zetten van het huidige beheersysteem naar Git. Zolang je de principes kent van beheersystemen, of deze kunt leren, zou ik het niet zo'n punt vinden als mensen Git nog moeten leren.

Programmeurs moeten kunnen programmeren. Buildservers, versiebeheersystemen en issue trackers zijn ook belangrijk maar uiteindelijk bijzaak. Meestal hanteren bedrijven toch bepaalde conventies met dit soort systemen (al dan niet op papier gezet), in het geval van Git is dat vaak niet meer dan een handvol dos commando's.

[.Vii]

wowa,

wat een explosie aan reacties deze had ik allemaal niet verwacht. Overigens de dicussies welke gevoerd worden vind ik zelf dan weer wel interessant om mee te lezen :-). Het is en blijft een lastige positie welke ik zelf ook heb vooral omdat je naast programmeren dus ook het functioneel beheer van tal van andere applicaties moet doen.

(Waar ook weer de nodige scripting / programmering in VB / T-SQL / Progress in zit) en het dus lastig is om alles te kunnen leren. Zelf heeft het me ook bijna 5 jaar gekost om alles op to speed te krijgen, voordeel is dat ik het super interessant vind en dus ook thuis ga zoeken hoe ik zaken moet gebruiken.

Ik ga het voorstel aan mijn manager doen dat hij een opleiding plan c.q. externe opleiding gaat volgen voor het gedeelte van laravel ondanks dat aangeven is dat dit niet mogelijk is, daarnaast wil ik hem dagelijks 2 uur de tijd geven om zichzelf te ontwikkelen in GIT / Composer / Unit testing en what so ever. Dit wel uiteraard met wat sturing van mij waar hij naar moet kijken....

Zou ook niet anders weten hoe ik van deze situatie iets beters moet maken ..

[Maxxi]

Vraag aan je manager of hij een assistent zou aannemen die geen mail en Excel kent.

En dan beide maar niet meer gaat gebruiken.

[Amphiebietje]

CH4OS schreef op zaterdag 22 september 2018 @ 21:15:

[...]
Ik gebruik zelf git het liefste via de commandline, dat maakt het voor mij een boel makkelijker en duidelijker. Dergelijke zaken heb ik verder dan ook niet echt gehad anders dan bij merge conflicts en ik de boel verkeerd mergde en mijn aanpassingen weg waren.
[...]

Gebruiksvriendelijkheid heeft niets te maken met een grafische interface. Je kan heel goed een programma hebben in een grafische interface met een bagger-interface, evenals command line programma's heel gemakkelijk in gebruik kunnen zijn, zelfs voor mensen die nog nooit een command line hebben gezien...
Overigens, de meeste grafische git-clients zijn of erg buggy, of hebben een slechte interface, of beide.

Git is een hoogst onvriendelijk programma omdat je wordt geforceerd te werken met een onlogisch in elkaar stekend programma met een ondoorzichtige, inconsistente user interface, onbehulpzame foutboodschappen, soms onleesbare man-pages, en vaak gedrag waarbij als er iets fout gaat het ook heel erg fout gaat. Het lijkt eigenlijk nog het meeste op iemand zijn hobby-programma dat ie heeft geschreven omdat hij ontevreden was met de op dat moment beschikbare andere oplossingen.

Net zoals Linux dus (zelfde auteur).

[CH4OS]

Amphiebietje schreef op zondag 23 september 2018 @ 12:00:
[...]


Gebruiksvriendelijkheid heeft niets te maken met een grafische interface. Je kan heel goed een programma hebben in een grafische interface met een bagger-interface, evenals command line programma's heel gemakkelijk in gebruik kunnen zijn, zelfs voor mensen die nog nooit een command line hebben gezien...
Overigens, de meeste grafische git-clients zijn of erg buggy, of hebben een slechte interface, of beide.

Git is een hoogst onvriendelijk programma omdat je wordt geforceerd te werken met een onlogisch in elkaar stekend programma met een ondoorzichtige, inconsistente user interface, onbehulpzame foutboodschappen, soms onleesbare man-pages, en vaak gedrag waarbij als er iets fout gaat het ook heel erg fout gaat. Het lijkt eigenlijk nog het meeste op iemand zijn hobby-programma dat ie heeft geschreven omdat hij ontevreden was met de op dat moment beschikbare andere oplossingen.

Net zoals Linux dus (zelfde auteur).

Ik mis even de user interface bij git op commandline, want dat is gewoonweg geen user interface in mijn optiek. De meeste problemen zijn te voorkomen wanneer je weet hoe git werkt. Ik merk amper problemen met git en mocht ik merge conflicts krijgen, weet ik ze echt wel op te lossen, dus ik denk eerder dat degenen die vinden dat git een ruk programma is zelf git niet helemaal begrijpen en daardoor fouten gaan maken en daardoor zorgen voor een rompslomp en de mening dat Git brak werkt. Er zijn niet voor niets vele (al dan niet publieke) git hosters, waarbij de bekendsten denk ik toch wel Github, Bitbucket en voor de mensen die het zelf willen hosten, Gitlab zijn. Die tools/services zijn razend populair, ook nu nog en dat zal vast niet zijn omdat ze zó slecht werken. Maar ik denk dat dit wel te ver uit de scope is van de vraag van de topicstarter.

[incaz]

CH4OS schreef op zondag 23 september 2018 @ 13:14:
[...]
Ik mis even de user interface bij git op commandline, want dat is gewoonweg geen user interface in mijn optiek.

Verkeerde optiek want de user interface is dat waarmee de gebruiker de interactie met het programma aangaat. Bij commandline zijn dat dus de commando's, shortcodes, flags, de volgorde van de argumenten, de foutmeldingen, default waarden als je argumenten niet expliciet zet, de uitleg als je krijgt als je --help vraagt, etc.

Ik merk amper problemen met git en mocht ik merge conflicts krijgen, weet ik ze echt wel op te lossen, dus ik denk eerder dat degenen die vinden dat git een ruk programma is zelf git niet helemaal begrijpen

Ik vind git een rukprogramma omdat ik me bezighou met gebruiksvriendelijkheid, en dan sommige dingen gewoon echt niet uit kan leggen. Waarom 2 verschillende commando's voor iets wat vrijwel hetzelfde is? Waarom een bepaalde volgorde van argumenten, die in een andere situatie anders is?

Neem bv https://dev.to/neshaz/whe...revert--git-checkout-18je
Dat begint met de opbeurende tekst:

Git toolbox provides multiple unique tools for fixing up mistakes during your development. Commands such as git reset, git checkout, and git revert allow you to undo erroneous changes in your repository.

Because they perform similar operations, it is very easy to mix them up. There are a few guidelines and rules for when each command should and should not be used. Let's take a look!

Be careful! You can't always redo after an undo. This is one of the few areas in Git where you may lose some work if you do it wrong.

Dit zijn tekenen van een slechte user interface: vergelijkbare operaties maar net niet helemaal dezelfde commands, en destructive data loss. Als ik dit in mijn eigen programma zou herkennen zou ik dit als teken beschouwen dat mijn programma nog niet goed is doordacht en nog niet simpel en eenduidig genoeg is.

Mijn professionele visie is dat het de taak is van IT om de gebruiker te faciliteren. De visie van iets teveel IT'ers is echter dat gebruikers maar gewoon moeten leren wat de logische en onlogische aspecten zijn van een bepaald systeem, en daar maar mee moeten leven. Ik vind dat iets wat de IT als branche schade doet. (En dat veel mensen veel ergernis geeft die niet nodig is. Niet alleen bij git dus voor de duidelijkheid, maar ook alle bibliotheekmedewerkers, docenten, artsen, apothekers, chauffeurs en vele vele anderen die extra tijd kwijt zijn aan het navigeren van een systeem dat niet aan hun noden voldoet.)
Ter illustratie: https://www.volkskrant.nl...social&utm_source=twitter

En er zijn dus it'ers die vinden dat de oplossing is om gebruikers meer uitleg te geven. Ik denk dat de oplossing is om it'ers betere programma's af te laten leveren.

[CH4OS]

incaz schreef op zondag 23 september 2018 @ 13:38:
[...]


Verkeerde optiek want de user interface is dat waarmee de gebruiker de interactie met het programma aangaat. Bij commandline zijn dat dus de commando's, shortcodes, flags, de volgorde van de argumenten, de foutmeldingen, default waarden als je argumenten niet expliciet zet, de uitleg als je krijgt als je --help vraagt, etc.


[...]

Ik vind git een rukprogramma omdat ik me bezighou met gebruiksvriendelijkheid, en dan sommige dingen gewoon echt niet uit kan leggen. Waarom 2 verschillende commando's voor iets wat vrijwel hetzelfde is? Waarom een bepaalde volgorde van argumenten, die in een andere situatie anders is?

Neem bv https://dev.to/neshaz/whe...revert--git-checkout-18je
Dat begint met de opbeurende tekst:
[...]


Dit zijn tekenen van een slechte user interface: vergelijkbare operaties maar net niet helemaal dezelfde commands, en destructive data loss. Als ik dit in mijn eigen programma zou herkennen zou ik dit als teken beschouwen dat mijn programma nog niet goed is doordacht en nog niet simpel en eenduidig genoeg is.

Mijn professionele visie is dat het de taak is van IT om de gebruiker te faciliteren. De visie van iets teveel IT'ers is echter dat gebruikers maar gewoon moeten leren wat de logische en onlogische aspecten zijn van een bepaald systeem, en daar maar mee moeten leven. Ik vind dat iets wat de IT als branche schade doet. (En dat veel mensen veel ergernis geeft die niet nodig is. Niet alleen bij git dus voor de duidelijkheid, maar ook alle bibliotheekmedewerkers, docenten, artsen, apothekers, chauffeurs en vele vele anderen die extra tijd kwijt zijn aan het navigeren van een systeem dat niet aan hun noden voldoet.)
Ter illustratie: https://www.volkskrant.nl...social&utm_source=twitter

En er zijn dus it'ers die vinden dat de oplossing is om gebruikers meer uitleg te geven. Ik denk dat de oplossing is om it'ers betere programma's af te laten leveren.

Je verwart nu echter wel programma's voor een programmeur en programma's voor een eindgebruiker. Bij Git is het gewoon een kwestie dat de programmeur gewoon moet weten wat hij wanneer moet doen en in welke context dus wat het beste werkt.

Van een programmeur mag je naar mijn mening wel verwachten dat hij weet wat hij wanneer moet doen met tools en cvs in het algemeen. Van een medewerker wat sowieso al weinig kaas gegeten heeft van IT in het algemeen kun je zoiets niet verwachten; daar mag je inderdaad blij zijn als diegene weet hoe de door de ontwikkelaar gemaakte applicatie werkt.

Je kunt niet verwachten van de simpele medewerkers in de zorg (nav het artikel dat je linkt) dat die overweg kunnen of moeten kunnen met tools als Git.

[ Voor 6% gewijzigd door CH4OS op 23-09-2018 16:50 ]

[incaz]

CH4OS schreef op zondag 23 september 2018 @ 16:48:
[...]
Je verwart nu echter wel programma's voor een programmeur en programma's voor een eindgebruiker.

Ik verwar helemaal niets, want daar is niets fundamenteel verschillends aan. Ik ben eindgebruiker van git. En als wij als IT al genoegen nemen met zulke onvriendelijke, slecht ontworpen tools, dan zegt dat iets over de waarde die we hechten aan goed ontwerp. (Namelijk: veel te weinig.)

Bij Git is het gewoon een kwestie dat de programmeur gewoon moet weten wat hij wanneer moet doen en in welke context dus wat het beste werkt.

Ik vind dat dus 'gewoon' een vreemde houding: dat er verwacht wordt dat miljoenen eindgebruikers onlogische dingen uit hun hoofd moeten leren omdat het systeem niet beter doordacht is. Zoals gezegd: er lijkt zelfs enig genoegen in te zitten in dat het zo onvriendelijk is - om neer te kijken op de domme gebruikers die het niet kunnen.

Je kunt niet verwachten van de simpele medewerkers in de zorg (nav het artikel dat je linkt) dat die overweg kunnen of moeten kunnen met tools als Git.

Nou is 'simpele medewerker in de zorg' natuurlijk niet echt een respectvol overkomende term.

Maar in dit geval gaat om een arts op de spoedeisende hulp / huisartsenpost, en dat is dus niet een willekeurige medewerker, maar een hoogopgeleide professional (hoger opgeleid dan de meeste IT'ers.) Het is alleen een hoogopgeleide professional met andere prioriteiten. En hier zit dus de kern. We kunnen inderdaad niet verwachten dat iedereen moeilijke systemen leert. Niet omdat het maar 'simpele' medewerkers zijn, maar omdat ze andere dingen te doen hebben.

Terug naar version control: het is een probleem dat er geen goed version control systeem is dat zo universeel is dat ongeveer iedereen vanaf mbo3 het probleemloos kan gebruiken. Het is namelijk ontzettend belangrijk. (Toen ik 8 was en tekeningetjes maakte in Dr Halo en 'undo' nog op z'n niet-engels uitsprak, had ik daar al behoefte aan en was ik al aan het klooien met kopietjes en naamgeving.)

Kortom: niets om trots op te zijn dat 'simpele medewerkers in de zorg' er niet mee kunnen werken, maar juist een symptoom van accepteren van ontoegankelijke software.

[CH4OS]

incaz schreef op zondag 23 september 2018 @ 17:00:
Ik verwar helemaal niets, want daar is niets fundamenteel verschillends aan.

Jij wilt overduidelijk dat elke nitwit met elke applicatie overweg moet kunnen, ik zie dat anders en daarin gaan onze meningen nooit overeenkomen. Kunnen we over blijven discussieren, maar in dit topic is dat gewoon zwaar offtopic, vandaar dat ik wederom voorstel om het hierbij te laten, want voor de vraagstelling van de TS voegt het totaal niets toe en wordt voor anderen het vraagstuk ook niet interessant om nog verder te lezen.

Ik ben eindgebruiker van git. En als wij als IT al genoegen nemen met zulke onvriendelijke, slecht ontworpen tools, dan zegt dat iets over de waarde die we hechten aan goed ontwerp. (Namelijk: veel te weinig.)

Nogmaals, ik vind dat een ontwikkelaar van een applicatie best mag weten wanneer hij wat moet doen met de code / git (of any cvs). Ook mag ik hopen dat een dergelijk persoon weet wat het verschil is tussen een git reset en een git revert, bijvoorbeeld en dat hij ook weet wanneer wat het beste gebruikt kan worden. Van een simpele medewerker in de zorg, hoef je zoiets niet te verwachten namelijk; sterker nog, van een dergelijk persoon wordt zelfs verwacht dat diegene totaal ander werk doet. Logisch dat applicaties voor die personen een totaal andere opzet hebben; de context is namelijk totaal anders. En dat is wat het verschil maakt tussen een tool als git en een tool voor iemand in de zorg. Maar dat zal jij ongetwijfeld anders zien, al is dat zwaar offtopic, dus wil ik het hierbij direct ook maar laten.

Ik vind dat dus 'gewoon' een vreemde houding: dat er verwacht wordt dat miljoenen eindgebruikers onlogische dingen uit hun hoofd moeten leren omdat het systeem niet beter doordacht is. Zoals gezegd: er lijkt zelfs enig genoegen in te zitten in dat het zo onvriendelijk is - om neer te kijken op de domme gebruikers die het niet kunnen.

Nogmaals, het gaat om context en wat je van die 'eindgebruiker' wel of niet mag verwachten van kennis en kunde; voor iemand in de zorg is dat dus iets totaal anders dan een ontwikkelaar.

Nou is 'simpele medewerker in de zorg' natuurlijk niet echt een respectvol overkomende term.

Dat is jouw mening, maar je begrijpt dondersgoed wat ik ermee bedoel. Zinloos muggenziften is niemand bij gebaad (zeker om dit soort dingen niet), waar iemand anders jou gisteren ook al probeerde op te wijzen.

Maar in dit geval gaat om een arts op de spoedeisende hulp / huisartsenpost, en dat is dus niet een willekeurige medewerker, maar een hoogopgeleide professional (hoger opgeleid dan de meeste IT'ers.). Het is alleen een hoogopgeleide professional met andere prioriteiten. En hier zit dus de kern. We kunnen inderdaad niet verwachten dat iedereen moeilijke systemen leert. Niet omdat het maar 'simpele' medewerkers zijn, maar omdat ze andere dingen te doen hebben.

Het is een opgeleid persoon, op een totaal ander vlak dan IT. Daar kun je weinig van verwachten op IT gebied. Van een ontwikkelaar vind ik wel dat je mag verwachten dat hij meer kaas heeft gegeten van IT en dan ook met wat ingewikkeldere tools overweg kan en weet wat wanneer wel of niet gebruikt kan worden (of juist niet gebruikt dient te worden).

Terug naar version control: het is een probleem dat er geen goed version control systeem is dat zo universeel is dat ongeveer iedereen vanaf mbo3 het probleemloos kan gebruiken. Het is namelijk ontzettend belangrijk.

Nogmaals, niet elke nitwit hoeft met version control te kunnen werken, zolang de mensen die ermee moeten werken dat wél doen.

Kortom: niets om trots op te zijn dat 'simpele medewerkers in de zorg' er niet mee kunnen werken, maar juist een symptoom van accepteren van ontoegankelijke software.

Dat die mensen niet met de tools overweg kunnen kan twee dingen betekenen;

• Die medewerker heeft geen affiniteit met IT (en daar is overigens niets mis mee!).
• Of de applicatie is niet goed ontworpen.

Als er dus medewerkers zijn die wel met het programma overweg kunnen en net die ene (die geen affiniteit heeft met IT bijvoorbeeld of gewoonweg niet zo snugger is en wat meer moeite heeft ermee om wat voor reden dan ook), dan lijkt het mij zo klaar als een klontje, dat het niet aan de applicatie ligt.

Maar goed, zoals in deze post meermaals aangegeven; dit valt buiten de scope van de vraag van de TS, dat is naar mijn idee te offtopic voor hier en lijkt het me handig om nu te stoppen met deze (in de context van dit topic, zinloze, imo) discussie.

[Transportman]

Je zal een beetje moeten zoeken wat hij op kan pakken en zorgen dat alle facetten behandeld worden (van designkeuzes t/m tets) en dat laten groeien.

Zakt het niveau van de coding teveel en zie je te weinig groei, geef dat aan bij je manager, maar wees ook bereid om weg te lopen om naar een andere baan te zoeken. Want weten dat het beter kan en naar jouw gevoel ook zou moeten is heel demotiverend, en ik ben er vrij zeker van dat als er problemen optreden, ze aan jouw bureau zullen staan voor de oplossing.

[Hielko]

.Vii schreef op zondag 23 september 2018 @ 08:31:
wowa,

wat een explosie aan reacties deze had ik allemaal niet verwacht. Overigens de dicussies welke gevoerd worden vind ik zelf dan weer wel interessant om mee te lezen :-). Het is en blijft een lastige positie welke ik zelf ook heb vooral omdat je naast programmeren dus ook het functioneel beheer van tal van andere applicaties moet doen.

(Waar ook weer de nodige scripting / programmering in VB / T-SQL / Progress in zit) en het dus lastig is om alles te kunnen leren. Zelf heeft het me ook bijna 5 jaar gekost om alles op to speed te krijgen, voordeel is dat ik het super interessant vind en dus ook thuis ga zoeken hoe ik zaken moet gebruiken.

Ik ga het voorstel aan mijn manager doen dat hij een opleiding plan c.q. externe opleiding gaat volgen voor het gedeelte van laravel ondanks dat aangeven is dat dit niet mogelijk is, daarnaast wil ik hem dagelijks 2 uur de tijd geven om zichzelf te ontwikkelen in GIT / Composer / Unit testing en what so ever. Dit wel uiteraard met wat sturing van mij waar hij naar moet kijken....

Zou ook niet anders weten hoe ik van deze situatie iets beters moet maken ..

Wat voor achtergrond heeft de "programmeur" die jullie hebben aangenomen dan? Opleidingsniveau? Want als ie geen ervaring heeft met OO programmeren heeft ie of in 1960 nog een opleiding gevolgd, of überhaupt nooit een relevante opleiding gevolgd? En blijkbaar weinig drive om ook maar iets te leren. Dus moet je je afvragen of dat wel een succesvolle richting is. Maar dan is natuurlijk ook de vraag hoe zo iemand überhaupt aangenomen kan worden, en dat ligt dan wellicht niet alleen aan je manager, maar ook in hoeverre je zelf effectief kan communiceren.

Anderzijds, is natuurlijk ook even de vraag over wat voor applicatie we het hebben, en hoe complex en ingewikkeld het daadwerkelijk is. Je hebt geen top programmeertalent nodig voor een simpele web applicatie waar een paar gebruikers wat data in een formulier gooien, en er een paar pagina's met data uithalen. Als je als enige programmeur in het bedrijf zit zal het toch ook niet al te veel voorstellen?

[iamcj]

.Vii schreef op zondag 23 september 2018 @ 08:31:
wowa,

wat een explosie aan reacties deze had ik allemaal niet verwacht. Overigens de dicussies welke gevoerd worden vind ik zelf dan weer wel interessant om mee te lezen :-). Het is en blijft een lastige positie welke ik zelf ook heb vooral omdat je naast programmeren dus ook het functioneel beheer van tal van andere applicaties moet doen.

(Waar ook weer de nodige scripting / programmering in VB / T-SQL / Progress in zit) en het dus lastig is om alles te kunnen leren. Zelf heeft het me ook bijna 5 jaar gekost om alles op to speed te krijgen, voordeel is dat ik het super interessant vind en dus ook thuis ga zoeken hoe ik zaken moet gebruiken.

Ik ga het voorstel aan mijn manager doen dat hij een opleiding plan c.q. externe opleiding gaat volgen voor het gedeelte van laravel ondanks dat aangeven is dat dit niet mogelijk is, daarnaast wil ik hem dagelijks 2 uur de tijd geven om zichzelf te ontwikkelen in GIT / Composer / Unit testing en what so ever. Dit wel uiteraard met wat sturing van mij waar hij naar moet kijken....

Zou ook niet anders weten hoe ik van deze situatie iets beters moet maken ..

Denk wel na over je argumenten, want iets wat managers over het algemeen goed kunnen is mensen onder de tafel 'praten'. Je hebt dus taal nodig die hij verstaat ergo: jouw oplossing kost meer geld en tijd dan de mijne.

Een goed argument dat ik voorbij zag komen is dat 'alle' huidige code OOP (versimpel naar andere taal of grammatica) is en dat hij daar dus geen onderhoud aan kan plegen. Dan is de optie die over is dat de nieuwe persoon procedurele code gaat gebruiken waarbij hij 'eigenlijk niets' van jouw code kan hergebruiken. Dus nieuwe functionaliteit gaat vanaf nu dus veel langer duren omdat hij het pakket nog moet leren kennen en geen code kan hergebruiken en jij dus vooral bezig zal zijn met onderhoud en applicatiebeheer en het aan elkaar plakken van zijn code en jouw code.

Je krijgt op termijn dubbel onderhoud omdat code gedupliceerd wordt en je ook de aan elkaar plakcode moet gaan onderhouden.

Is het trouwens geen optie als hij het applicatiebeheer van je overneemt, je hebt het over scripting, is misschien wat procedureler?

[Hydra]

Beetje laat wat betreft dit feestje en heb niet alle comments gelezen; maar je baas is typisch het soort baas waar je niet voor wil werken. Die ziet developers gewoon als fabriekswerkers die 'code produceren' en denkt dat een goedkopere misschien wat langzamer produceert, maar dat alsnog doet. Het concept dat slechte developers een netto negatieve bijdrage kunnen hebben is hem vreemd.

Daarnaast ga je het meest vooruit als je je op kunt trekken aan andere, betere developers. Ik zelf zit 15 jaar in 't vak maar probeer altijd in projecten terecht te komen waar ik wat kan leren. Zo blijf je groeien.

Tijd om op zoek te gaan.

[Rukapul]

Modbreak:

Uitgebreide verhandelingen over techniek en tools zijn hier offtopic. Het is ruis wat niet bijdraagt aan de vraagstelling.

[Hydra]

Oops

[ Voor 97% gewijzigd door Hydra op 24-09-2018 10:13 ]

[Furion2000]

@.Vii

Ik ben zelf een jaar geleden gestart als junior junior en herken het probleem van de andere kant. Ik werd in het diepe gegooid binnen een groot pakket met 0 documentatie en zeeën aan legacy code.

Het enige wat je kunt verlangen van de nieuwe aanwinst, waarvoor veel nieuw is, is inzet om het zo snel mogelijk te leren, hem daarbij helpen en tijd gunnen. Teveel nieuwe dingen landen niet in 1x en dat kost gewoon tijd.

Het voelt fijn om belangrijk te zijn, maar dat is een groeiend risico voor de baas en ze willen nu dat je minder belangrijk word (daar komt het op neer). Ze opperen nu een idee om je coding level te verlagen, maar jij vind dat niet het beste idee volgens mij. Nu zou je kunnen bewijzen dat het op een andere manier 'beter' zou kunnen en zeggen wat daar voor nodig is en uitdrukken in tijd/geld …....of niet en je coding level gaan verlagen Dit laatste spreek ik niet uit ervaring, maar puur hoe ik daar tegen aan kijk. Het zou dus complete bullshit kunnen zijn

[.oisyn]

.edit: nvm, topic was veel langer dan ik aanvankelijk dacht

[ Voor 81% gewijzigd door .oisyn op 24-09-2018 17:05 ]