Verkeerde denkwijze tijdens werkzaamheden

[Un93m59]

Hey hallo tweaker genoten,

Ik loop voor het eerst stage bij een software bedrijf en loop soms in mijn hoofd tegen interne struggles aan.
Dit ligt niet aan het bedrijf, opdracht of omgeving maar meer met mijn eigen denk wijze/instelling.

Een korte intro over mezelf:
Ik ben van nature iemand die graag werkt, constant productief wil zijn en elke dag doelen opstelt om bepaalde dingen af te hebben. Dit lukt niet altijd en als ik merk dat ik weinig voortgang heb gemaakt, ben ik een persoon die buiten werktijd nog doorgaat.

Ik ben ook iemand die veel nadenkt, er zijn soms periode's dat ik constant aan het nadenken ben over een oplossing waardoor ik een beetje gedemotiveerd raak. Ik zal een voorbeeld geven ter verduidelijking.

Voorbeeld
Laten we zeggen dat ik bezig ben met een full stack opdracht (website bouwen met een leuke backend erachter). Van de klant krijg ik te horen dat hij graag functionaliteit A erbij wilt. Bij deze functionaliteit horen nieuwe en onbekende technologieën voor mij.

Op het moment dat ik dit hoor, ga ik al meteen in me hoofd denken van:

Wat zijn de nieuwe/onbekende technologieën? hoe werken deze???
Hoe ga ik deze implementeren in de huidige situatie?
Wat zijn al mogelijke bottle necks bij de implementatie?
Hoe reageren andere services van de app hierop?

Deze vragen stapelen zich allemaal op, waardoor ik op dat moment langzaam negatief ga opkijken tegen de gewenste functionaliteit. Hierdoor verlies ik motivatie en ben ik eigenlijk minder productief dan gewenst. Ik krijg dan ook een slechte zin qua humeur.

Maar het rare is dat als ik er eenmaal mee bezig ben, dat ik dan juist heel gemotiveerd om het te onderzoeken, implementeren etc.

Een beetje een raar verhaal... maar ik hoor graag jullie mening hierover!, als er vragen zijn stel ze gerust


Groetjes en een fijne dag nog!

[SmurfLink]

Wat is eigenlijk precies je vraag of punt van dit topic? Onze mening over jouw denkwijze peilen?

[ Voor 26% gewijzigd door SmurfLink op 15-10-2020 17:27 ]

[Un93m59]

SmurfLink schreef op donderdag 15 oktober 2020 @ 17:26:
Wat is eigenlijk precies je vraag of punt van dit topic? Onze mening over jouw denkwijze peilen?

Jep

[bregweb]

Ik denk dat je moet leren de probleemstelling in delen te knippen. Dat is ook precies wat je tijdens onderzoek doet. Je leest 1 document, niet 5 tegelijk.

Wat mij ook vaak helpt is het probleem te schetsen op papier, dan komen de deelproblemen er vanzelf uit.

[Diederik]

Ik denk niet dat jouw denkwijze verkeerd is, maar dat het wel aan het bedrijf/proces ligt.

Je krijgt een opdracht, maakt een planning en bent hem aan het uitvoeren.

Dan veranderd jouw opdracht (nieuwe functie) tijdens de uitvoering, waardoor je opnieuw moet gaan plannen.

Logisch dat dat jou van je stuk brengt, het is aan de projectleider om dit op te vangen, en pas na zorgvuldig overwegen of jij nu al opnieuw moet starten, zal hij (of zij) dit bij jou neer moeten leggen.

[Yucon]

Ik denk dat je denkfout is dat je aanneemt dat je elke gril van een opdrachtgever in een uurtje of twee erin moet kunnen zetten.

Dus ja, je vragen kunnen best wel terecht zijn en ze kunnen best worst case uitpakken waardoor je 2 weken nodig hebt. Bespreek dat eens. Mogelijk is die feature dat waard en dan zijn die twee weken geen probleem. Of hij is het niet waar, dan bouw je hem niet en dan is het ook niet zinvol ervoor in paniek te raken.

[SmurfLink]

Yucon schreef op donderdag 15 oktober 2020 @ 17:46:
Ik denk dat je denkfout is dat je aanneemt dat je elke gril van een opdrachtgever in een uurtje of twee erin moet kunnen zetten.

Dus ja, je vragen kunnen best wel terecht zijn en ze kunnen best worst case uitpakken waardoor je 2 weken nodig hebt. Bespreek dat eens. Mogelijk is die feature dat waard en dan zijn die twee weken geen probleem. Of hij is het niet waar, dan bouw je hem niet en dan is het ook niet zinvol ervoor in paniek te raken.

Hier sluit ik me bij aan. Soms is ook nee zeggen een goed antwoord, maar vooral zolang je duidelijk bent waarom het dat is. Ga de discussie aan. Prima dat jullie die extra feature willen, maar dit gaat me x meer tijd kosten. Akkoord, of doen we het zonder de feature.

En probeer wat meer zaken op te knippen. Als je iets ziet als 1 groot geheel kan dat intimiderend werken en heb je er geen zin meer in. Knip het op in kleine bouwblokken zodat het veel minder groot lijkt en haalbaarder is.

[atsan]

Betreffende je voorbeeld, stagebedrijven kunnen twee dingen doen,
je aan je handje vasthouden en samen het hele proces doorlopen. of je in het diepe gooien en kijken hoever je zelf kan zwemmen.

beide niks mis mee, echter je dient te leren omgaan met het onbekende. Zou gewoon een pva opstellen en die bespreken met je stagebegeleider.

[99ruud99]

jij zou een ideale scrummaster zijn
"dit is het probleem"
-> subproblemen / subvragen
en dan gewoon een voor een de vragen uitwerken / afwerken.

[pieter.a]

99ruud99 schreef op donderdag 15 oktober 2020 @ 17:55:
jij zou een ideale scrummaster zijn
"dit is het probleem"
-> subproblemen / subvragen
en dan gewoon een voor een de vragen uitwerken / afwerken.

Ik vind het ook alleen maar goed dat je probeert het hele probleem te overzien. Er zullen genoeg mensen zijn die klakkeloos ergens aan beginnen, een inschatting maken die nergens op gebaseerd is en dan opeens maar 20% op kunnen leveren binnen de ingeschatte tijd.

Naast het opbreken van de vragen zou ik ook aanraden om een lijst te maken met taken die je moet uitvoeren om je eindproduct te leveren. Als je iets moet maken met voor jou nieuwe technologie X kan je sowieso al de volgende taken definieren (de inschattingen zijn als voorbeeld)
- initieel onderzoek met X, krijg een hello world voorbeeld werkend en maak enkele eenvoudige prototypes - 2 dagen
- specifiek onderzoek voor de gestelde vragen - 1 dag
- maak een high level design van je oplossing - 2 dagen
- beschrijf specifieke taken om stapsgewijs van 0 naar eind product te komen, inschatten van onderstaande taken - 1 dag
- implementatie - nader te bepalen
- tijd voor oppakken feedback opdrachtgever - nader te bepalen

Als je niet weet hoe je uberhaubt een hello world project met X opzet is het totaal niet constructief om wakker te liggen van vragen die je op dat moment toch niet kan beantwoorden. Als je van boven af aan 1 voor 1 al die taken gaat aflopen blijft elke stap behapbaar.

[Lensent]

Je loopt stage.
Shake it off...

[t_captain]

Als een nieuwe feature meteen tot een zware aanpassing aan de tech stack moet leiden, dan moet je de software architect een mep verkopen

[Philip Ross]

IK denk dat je inde basis helemaal niet verrkeerd bezig bent. Het probleem van te veel vragen die zich opstapelen kent iedereen die wel eens een project alleen heeft moeten doen.

Het belangrijkste is om vragen op een gestructureerde manier op te schrijven. Zo krijg je je hoofd leeg en blijft de motivatie goed. Zelfs een simpel to-do lijstje help al enorm met dit gevoel.

Een ander voordeel is dat je op die manier de vragen uit kan diepen. Als in opschrijven wat je moet doen om ze te beantwoorden.

Dan heb je een aantal deelvragen en taken en dat is ook meteen de basis van scrum. Maak kleine blokjes en ga die 1 voor 1 oplossen.

[sypie]

Lensent schreef op vrijdag 16 oktober 2020 @ 08:10:
Je loopt stage.
Shake it off...

Nee, juist niet!

Je loopt stage wat betekent dat je aan het leren bent. De vragen die @Un93m59 zichzelf stelt zijn vragen die bij dat leerproces horen. Het maakt daarbij niet uit op welk niveau je bezig bent, MBO1 of Universiteit. Daarbij komt nog dat het een stage is. Iedere regel code die je productief bent is daarbij meegenomen voor het bedrijf. Het product en de planning kan in geen enkel geval afhankelijk zijn van een student, wat helaas veel te vaak wel gebeurt.

[nixjuh]

Herkenbaar verhaal. Mijn hoofd werkt ook zo, toen ik net begon met werken liep ik tegen hetzelfde probleem aan als jij dat ik overal beren op de weg zag en daar langzaam negatief van werd. Tijdens projecten werd dat dan vaak wel minder als bleek dat er meer mogelijk was dan ik dacht. Ik ben hierdoor ook tijdelijk in een depressie geraakt een aantal jaren geleden. Hiervoor ben ik bij een psycholoog geweest en daar heb ik enorm veel aan gehad. Wellicht wat lessen die ik hiervan heb geleerd waar jij hopelijk ook wat mee kan:

• Probeer niet te veel aan die denkwijze te veranderen, of je er te aan ergeren. Zo ben je nou eenmaal en dat wijst vaak op een sterk analytisch vermogen. Probeer hier je sterkte van te maken in plaats van je valkuil.
• Kijk vooral ook naar de mogelijkheden in plaats van de gevaren/risico's, een klant zal je heel dankbaar zijn als jij vooraf al aangeeft waar ze rekening mee moeten houden. Stel dan ook de juiste vragen zodat je zelf weet welke kant je op wil gaan met het project. Dit kan als stagair wellicht wat lastig zijn soms, maar doe anders deze mentale oefening bij jezelf.
• Probeer energie te halen uit het leren van nieuwe dingen. Zie het dus als een toffe uitdaging en ga er lekker mee aan de slag. Je zult ook merken hoe vaker je dit doet hoe meer je weet, en hoe beter je in kan schatten wat er wel en niet kan. Dit zal in het begin wellicht een beetje eng zijn, maar het belangrijkste is vertrouwen hebben in jezelf in dezen.

Deze zaken hebben mij heel erg geholpen om positief in het leven te staan. En daar ben ik nog steeds elke dag dankbaar voor! Hopelijk heb je er wat aan!

[Hydra]

Un93m59 schreef op donderdag 15 oktober 2020 @ 17:20:
Op het moment dat ik dit hoor, ga ik al meteen in me hoofd denken van:

Wat zijn de nieuwe/onbekende technologieën? hoe werken deze???
Hoe ga ik deze implementeren in de huidige situatie?
Wat zijn al mogelijke bottle necks bij de implementatie?
Hoe reageren andere services van de app hierop?

Dat is de normaalste zaak van de wereld. Ben zelf ook developer (al een jaar of 18), en jezelf dit soort vragen stellen is gewoon een onderdeel van je werk.

Deze vragen stapelen zich allemaal op, waardoor ik op dat moment langzaam negatief ga opkijken tegen de gewenste functionaliteit. Hierdoor verlies ik motivatie en ben ik eigenlijk minder productief dan gewenst. Ik krijg dan ook een slechte zin qua humeur.

Klinkt een beetje als "analysis paralysis". Oftewel; je raakt het overzicht kwijt omdat je het te groot maakt voor jezelf. Het is dus belangirjk om in grote lijnen uit te vogelen wat je moet doen en dit in hap-klare brokken op te delen en een voor een op te pakken. Als je voor een nieuwe feature A, B en C moet doen, begin je gewoon bij een ervan (ik begin meestal met de meest lastige / meeste unknown unknowns). Het is onpraktisch of onmogelijk om alles alttijd vooraf te weten.

Maar het rare is dat als ik er eenmaal mee bezig ben, dat ik dan juist heel gemotiveerd om het te onderzoeken, implementeren etc.

Precies. Je moet dus gewoon met een van de dingen aan de slag gaan. Is heel normaal.

[Widow]

Op zich allemaal terechte vragen die je stelt in de TS. Kijk het is wel zaak om dit te structureren. Vaak heeft men bij een bepaalde feature een globaal idee hoe iets moet werken en wordt die vraag bij jou neergelegd, van zie maar wat het moet worden. Ik weet niet of dat bij jou ook het geval is, maar het is altijd zaak om features duidelijk uit te werken. Wie voert bepaalde handelingen uit, hoe sluit alles op elkaar aan, welke resultaten moet het opleveren, waar zijn die resultaten voor nodig? Niet technisch, puur gericht op activiteiten die mensen uitvoeren. Daarna kun je gaan nadenken welke informatie nodig is voor die feature, en met welke technologie je dat gaat realiseren. Meestal ben je dan op een punt dat je wel bepaalde mogelijkheden ziet in het geheel, waarna je een plan kan gaan opstellen.

Bedenk ook dat klanten lang niet altijd exact weten wat ze willen. Of dat ze denken het te weten, maar het niet meer is dan een sales demo die ze ooit hebben gezien. Ga er van uit dat features en requirements altijd worden bijgesteld gedurende een project omdat mensen leren wat wel/niet werkt en op basis daarvan aanpassingen willen. Daarom is het ook van belang om vooraf een opdrachtgever goed uit te vragen. En bouw dingen op een manier dat je later makkelijk zaken kan aanpassen. Ik heb net een project afgerond bij een klant, in eerste instantie een heel pakket neergezet en laat ze er maar mee werken en uitproberen of alle use cases ook werken zoals ze hebben bedacht. Daarna komt altijd het commentaar van "feature A moet stap 5 niet meer uitvoeren, feature B moet worden uitgebreid met dit en dat, en we willen een nieuwe feature die een keuzemenu geeft voor blabla".

Soms is het dus handig om in 20% van de tijd 80% van het resultaat neer te zetten zodat klanten kunnen ervaren hoe het systeem echt werkt. Als ze dingen bijstellen zit je pas op 20% van de tijd die jij voor het project hebt, en heb je nog 80% van de tijd over om dat te realiseren

[Yucon]

Hydra schreef op vrijdag 16 oktober 2020 @ 09:26:

Klinkt een beetje als "analysis paralysis". Oftewel; je raakt het overzicht kwijt omdat je het te groot maakt voor jezelf. Het is dus belangirjk om in grote lijnen uit te vogelen wat je moet doen en dit in hap-klare brokken op te delen en een voor een op te pakken. Als je voor een nieuwe feature A, B en C moet doen, begin je gewoon bij een ervan (ik begin meestal met de meest lastige / meeste unknown unknowns). Het is onpraktisch of onmogelijk om alles alttijd vooraf te weten.

Het probleem uitschrijven in plaats van het spinneweb in je hoofd te maken wil ook helpen. Vaak is het dan veel helderder, en je hebt gelijk al meer in handen om met anderen te kunnen overleggen.

[Tweezitsbank]

Eea is voor mij (developer) wel herkenbaar. Soms vanwege angst voor het onbekende. Dat wordt als het goed is minder naarmate je meer ervaring opdoet en vaker taken tot een goed einde hebt gebracht. Wat mij weleens helpt is om een taak anders te bekijken. Is een taak:

• Een bak werk die ik als developer moet uitvoeren?
• Of een coole feature waar iemand blij mee gaat zijn?

Indien dat laatste (en dat is het als het goed is altijd) dan wil ik dit vaak ook voor elkaar krijgen en dan is mijn benadering naar deze taak ineens een heel stuk positiever.

Buiten dit ben ik ook niet bang om vragen te stellen. Als ik iets niet weet dan verwacht ik tijd te krijgen om het uit te zoeken of dat iemand me uitlegt hoe iets werkt. Is die tijd er niet? Prima, ik kan na 20+ jaar developen nog steeds niet toveren dus verdwijnt bij mij de noodzaak om de deadline te halen voor deze taak.

[MarcoC]

Wat is er mis met de vragen die in jouw hoofd zich afspelen? Het beantwoorden van die vragen is je werk, daar word je voor betaald (even geredeneerd vanuit het perspectief van voltijdbaan ipv stage).

[Immutable]

t_captain schreef op vrijdag 16 oktober 2020 @ 08:25:
Als een nieuwe feature meteen tot een zware aanpassing aan de tech stack moet leiden, dan moet je de software architect een mep verkopen

En wat als die persoon een charismatische persoon die vaak de architectuur verkoopt aan het management als de beste uitvinding na gesneden brood? En management slikt alles, omdat ze geen hol verstand hebben van techniek? De software architect, erg charismatisch is en last heeft van het "not invented here" syndroom? Waardoor heel veel fundamentele zaken van het bestaande architectuur zelf geprogrammeerd zijn maar met heel weinig functionaliteit en zeer slechte performance. Terwijl een opensource oplossing wel 100 tot 1000x meer performance heeft en praktisch alles ondersteund en meer wat je nodig wil hebben. Terwijl we nu tegen allerlei performance zaken aan lopen.
En dat we gebruik maken van bepaalde taal die niet bedoeld is voor deze markt(Beter zou zijn, een systeem taal), en ook nog eens een grafische framework gebruiken van het jaar 2001(letterlijk) ? Dus we hebben geen kinetic scrolling, geen swipen geen animaties e.d. terwijl het wel gebaseerd is op touch...

De software architect hier is absoluut niet dom, en weet heel veel. Maar maakt veel rare keuzes, en wil alles zelf maken. Door deze architectuur is de boel niet flexibel, en kost het enorm veel man uren om iets te maken voor een klant.
Ik zelf ben een man van de technologie, sociaal zeer kansloos persoon want ik weet dat ook al heb ik gelijk ik geen gelijk krijg vanwege mijn slechte manier van dingen verwoorden naar het management. En omdat ik niet graag op mensen hun tenen trap. Ben bang dat die persoon zich aangevallen zal voelen

Wat doe je dan?
(Zelf eens met de gedachte gespeelt om zelf het systeem na te bouwen, maar dan met mijn ideeën. Alleen dat kost mij privé heel veel tijd die niet betaald zal worden...) En dan misschien te verkopen o.i.d. aan het bedrijf.

(Verder herken ik me in TS, ik denk ook altijd meteen van wat voor impact het heeft diep in het systeem en architectuur... want ik MOET wel omdat de architectuur niet flexibel is, en heel weinig ondersteund.)

[ Voor 13% gewijzigd door Immutable op 16-10-2020 12:56 ]

[Devil]

Dat gevoel wat je hebt klinkt erg als stress. Door je eigen gedachtes verlies je even het overzicht en dat zorgt voor een sterkte stress response. Ik zou je inlezen in het onderwerp (stress) en kijken of er online cursussen zijn. Omgaan met stress is ook iets dat je moet leren.

[Yucon]

Immutable schreef op vrijdag 16 oktober 2020 @ 12:48:
[...]


En wat als die persoon een charismatische persoon die vaak de architectuur verkoopt aan het management als de beste uitvinding na gesneden brood? En management slikt alles, omdat ze geen hol verstand hebben van techniek? De software architect, erg charismatisch is en last heeft van het "not invented here" syndroom? Waardoor heel veel fundamentele zaken van het bestaande architectuur zelf geprogrammeerd zijn maar met heel weinig functionaliteit en zeer slechte performance. Terwijl een opensource oplossing wel 100 tot 1000x meer performance heeft en praktisch alles ondersteund en meer wat je nodig wil hebben. Terwijl we nu tegen allerlei performance zaken aan lopen.
En dat we gebruik maken van bepaalde taal die niet bedoeld is voor deze markt(Beter zou zijn, een systeem taal), en ook nog eens een grafische framework gebruiken van het jaar 2001(letterlijk) ? Dus we hebben geen kinetic scrolling, geen swipen geen animaties e.d. terwijl het wel gebaseerd is op touch...

De software architect hier is absoluut niet dom, en weet heel veel. Maar maakt veel rare keuzes, en wil alles zelf maken. Door deze architectuur is de boel niet flexibel, en kost het enorm veel man uren om iets te maken voor een klant.
Ik zelf ben een man van de technologie, sociaal zeer kansloos persoon want ik weet dat ook al heb ik gelijk ik geen gelijk krijg vanwege mijn slechte manier van dingen verwoorden naar het management. En omdat ik niet graag op mensen hun tenen trap. Ben bang dat die persoon zich aangevallen zal voelen

Wat doe je dan?
(Zelf eens met de gedachte gespeelt om zelf het systeem na te bouwen, maar dan met mijn ideeën. Alleen dat kost mij privé heel veel tijd die niet betaald zal worden...) En dan misschien te verkopen o.i.d. aan het bedrijf.

(Verder herken ik me in TS, ik denk ook altijd meteen van wat voor impact het heeft diep in het systeem en architectuur... want ik MOET wel omdat de architectuur niet flexibel is, en heel weinig ondersteund.)

Je lijkt drie dingen over het hoofd te zien.

- goed is goed genoeg
- er zijn ook factoren buiten je zichtveld
- liever niet natuurlijk, maar dingen mislukken nu eenmaal ook wel eens. Als jij aan het programmeren bent kom je er ook wel eens achter dat iets dus niet zo moet. Nou, dit is het equivalent. Maar dan voor die architect.

[Hydra]

Immutable schreef op vrijdag 16 oktober 2020 @ 12:48:
En wat als die persoon een charismatische persoon die vaak de architectuur verkoopt aan het management als de beste uitvinding na gesneden brood?

Dan is hij verantwoordelijk voor die keuzes en heb jij de mogelijkheid nieuwe shit op je CV te zetten

[Yucon]

Hydra schreef op vrijdag 16 oktober 2020 @ 14:10:
[...]


Dan is hij verantwoordelijk voor die keuzes en heb jij de mogelijkheid nieuwe shit op je CV te zetten

dat vat het inderdaad mooi samen

[Ionicawa]

Ik denk dat jouw denkwijze prima is.

Het kunnen inzien van de complexiteit van een nieuwe requirement is alleen maar goed. Je kan deze zorgen delen met de opdrachtgever: "Als we dit doen, dan hebben we technologie A nodig, ik heb daar niet de kennis van dus dit kost voor mij B extra tijd om daar bekend mee te raken, daarnaast moeten we dit integreren binnen onze huidige software/technologie wat risico's C, D en E met zich meebrengt en minimaal F tijd kost. Om beter in te schatten of de risico's voor grote problemen gaan zorgen wil ik daar eerst onderzoek naar doen, dit kost G tijd. In totaal kijken we dan al minimaal naar H tijd. Wil je dit nog steeds doen, of zullen we kijken of er een alternatief is?"

Zo plaats je de verantwoordelijkheid bij de opdrachtgever, in plaats van dat je de opdracht maar gewoon accepteert en je dan druk gaat maken hoe je dat gaat realiseren. Als je dit liever eerst met collega's bespreekt dan vertel je de opdrachtgever "Ik ga voor je uitzoeken hoeveel werk dit is". Door de complexiteit te communiceren met anderen ben jij niet meer de enige die de last draagt en het brengt misschien ook creatieve oplossingen waar je zelf niet aan had gedacht! Als het goed is zou dat je meer rust moeten geven en minder negatieve gevoelens jegens de opdracht

Dat brengt mij wel bij één probleem die je schetst, namelijk dat je elke dag doelen hebt die je wilt bereiken en dat je niet stopt totdat je ze hebt bereikt.
Ten eerste moet je grenzen stellen, dus je gewoon houden aan de reguliere werktijden. Soms lopen dingen gewoon even niet zoals je wilt en kan je je doelen voor de dag niet halen, je hoeft jezelf daarvoor niet te "straffen". Teleurstelling hoort er bij en misschien kan je met zelfreflectie een oorzaak vinden en dit oplossen (als je zelf controle hebt over de oorzaak). Onderzoek wijst uit dat overwerk meestal niet je beste uren zijn en dat je die uren ook weer moet inhalen anders kan het een negatieve invloed hebben op je gezondheid en daardoor op je productiviteit tijdens de normale kantooruren. Overwerk heeft dan ook vrij weinig zin, tenzij er echt een deadline is die gehaald moet worden. (Maar dan moet die tijd op een later moment wel gecompenseerd worden natuurlijk)
Ten tweede, als er tijdens de dag dingen veranderen buiten jouw controle om, pas dan daarop ook je doelen aan. Als je voor jezelf het doel stelt om een feature vandaag af te maken, maar er plotseling een vergadering tussendoor komt dan is het niet jouw schuld dat de feature niet af is. Hetzelfde geldt als requirements veranderen. Het is niet jouw schuld, dus jij hoeft niet nog 's avonds door te gaan met werken om het alsnog af te krijgen.

Als laatste wil ik nog zeggen dat men vaak niet gemotiveerd is om te beginnen aan een grote berg met werk maar dat dat gevoel verdwijnt zodra je er echt aan begint. Daar hebben heel veel mensen last van en dit valt onder zelfsabotage. Wat kan helpen is om het werk op te knippen in verschillende onderdelen en dit echt als losse taken zien, bijvoorbeeld een risicoanalyse om een nieuwe technologie te integreren, leren hoe de nieuwe technologie werkt en als laatste de implementatie en integratie zelf. Die onderdelen kan je ook weer verder onderverdelen totdat je goed behapbare taken hebt.

Kortom: communiceer, stel grenzen, pas doelen aan als ze niet (meer) realistisch zijn, en maak het werk kleiner!

[TheBoneJarmer]

Je vragen zijn zeer terecht en goed dat je ze stelt. Ik vind het eerder zorgwekkend dat je ze moet stellen. Het klinkt alsof ze je vragen een enorme change door te voeren. Voor een enkele feature vind ik dat wel wat te zot voor worden. Al helemaal voor een stagiair.

Hoe ze het bij mijn jobs altijd aanpakten was dat iets groots opgedeeld werd in meerdere features waar meerdere engineers aan werkten. En bij de introductie van een nieuwe tech werd altijd eerst heel het team mee betrokken in een meeting. Daar werd op een uur tijd kort uitgelegd wat de tech is, waarom ze het nodig hadden en hoe ze het willen implementeren. En als het team akkoord was, ging ze pas die tech leren. En daarna pas begonnen ze ermee te werken.

En dat wordt allemaal opgevolgd door een project manager die met een project management system zoals Jira tickets aanmaakt en assigned. Zoals het voor mij nu overkomt is dat ze té veel hooi op je vork doen. En ik kan mij voorstellen dat het inderdaad niet bepaald motiveerd.

Hoe wordt dat bij jou geregeld op werk OP? Hebben jullie daar ook een soort van ticketsysteem of..?

[Un93m59]

TheBoneJarmer schreef op vrijdag 16 oktober 2020 @ 18:28:
Je vragen zijn zeer terecht en goed dat je ze stelt. Ik vind het eerder zorgwekkend dat je ze moet stellen. Het klinkt alsof ze je vragen een enorme change door te voeren. Voor een enkele feature vind ik dat wel wat te zot voor worden. Al helemaal voor een stagiair.

Hoe ze het bij mijn jobs altijd aanpakten was dat iets groots opgedeeld werd in meerdere features waar meerdere engineers aan werkten. En bij de introductie van een nieuwe tech werd altijd eerst heel het team mee betrokken in een meeting. Daar werd op een uur tijd kort uitgelegd wat de tech is, waarom ze het nodig hadden en hoe ze het willen implementeren. En als het team akkoord was, ging ze pas die tech leren. En daarna pas begonnen ze ermee te werken.

En dat wordt allemaal opgevolgd door een project manager die met een project management system zoals Jira tickets aanmaakt en assigned. Zoals het voor mij nu overkomt is dat ze té veel hooi op je vork doen. En ik kan mij voorstellen dat het inderdaad niet bepaald motiveerd.

Hoe wordt dat bij jou geregeld op werk OP? Hebben jullie daar ook een soort van ticketsysteem of..?

Uhm we maken geen gebruik van jira oid, ik heb zelf voor mijn eigen beeldvorming een trello bord gemaakt om het overzicht een beetje bij elkaar te houden. ik heb ongeveer dezelfde constructie als jou denk ik

Ik heb zelf Epics, die ik onderverdeel in features/user stories die ik weer onderverdeel in mini taken.

[Un93m59]

Ik wil iedereen bedanken voor jullie reactie! vond het heel tof om te lezen en ben blij dat er mensen meedenken met mijn probleem

Ik zal even kort samenvatten in reacties waar ik me toch wel goed in kan vinden:

Ik ben inderdaad iemand die elke gil van een opdrachtgever/baas/collega aanneemt, luistert en braafjes uitvoert. (ik durf geen nee te zeggen) Op het moment dat iemand bij me komt voor een vraag tot iets onbekends, dan wil ik na het gesprek al z.s.m een antwoord hebben en duik ik er meteen in.

Ik moet leren om nee te zeggen en gewoon accepteren dat ik sommige zaken niet direct kan regelen (soms heeft het gewoon tijd nodig).

Ik ben er ook mee eens dat ik bepaalde processen in stukjes moet hakken en een voor een de focus moet leggen op taken. Ik heb soms heel veel gedachten in mijn hoofd over hoe ik het ga doen, terwijl ik bij wijze van spreken nog niet eens ermee begonnen ben

Ik ga ook eens proberen om het eens uit te tekenen door middel van iets visueels(tekening/diagram), in plaats van dat ik alles in mijn hoofd het bedenk.

Als er nog vragen zijn be my guest!

Het gaat jullie goed en een fijn weekend gewenst!

[TheBoneJarmer]

Un93m59 schreef op vrijdag 16 oktober 2020 @ 20:18:
[...]


Uhm we maken geen gebruik van jira oid, ik heb zelf voor mijn eigen beeldvorming een trello bord gemaakt om het overzicht een beetje bij elkaar te houden. ik heb ongeveer dezelfde constructie als jou denk ik

Ik heb zelf Epics, die ik onderverdeel in features/user stories die ik weer onderverdeel in mini taken.

Wauw.. Daar weet ik eigenlijk even niet goed op hoe te reageren. Begrijp me niet verkeerd, supergoed dat je initiatief neemt om zelf structuur en orde te brengen in je werk maar wtf? Dat moet toch een complete chaos zijn op vlak van project management.

Naar mijn mening echt dus niet het goede voorbeeld voor een stagiair. Ik kan je vertellen dat er veel bedrijven zijn die wel op die manier werken. Zijnde het met Jira of iets gelijkaardigs. Bespreken jullie 's morgens wel nog samen wie wat gedaan heeft en wat gaat doen? Oftewel een zogeheten standup?

[Un93m59]

TheBoneJarmer schreef op vrijdag 16 oktober 2020 @ 22:01:
[...]


Wauw.. Daar weet ik eigenlijk even niet goed op hoe te reageren. Begrijp me niet verkeerd, supergoed dat je initiatief neemt om zelf structuur en orde te brengen in je werk maar wtf? Dat moet toch een complete chaos zijn op vlak van project management.

Naar mijn mening echt dus niet het goede voorbeeld voor een stagiair. Ik kan je vertellen dat er veel bedrijven zijn die wel op die manier werken. Zijnde het met Jira of iets gelijkaardigs. Bespreken jullie 's morgens wel nog samen wie wat gedaan heeft en wat gaat doen? Oftewel een zogeheten standup?

Standup doen we wel ja en inderdaad voor de reden die je aangeeft

[WTBram]

Ik neig naar het delen van verantwoordelijkheden, met een stagebegeleider of projectmanager. Sparren, zodat je je twijfels bekend maakt, en het een gedeeld probleem wordt, met het team. Voor mij helpt dat doorgaans, dan wordt gezamenlijk beslist wie wat oppakt, en welke hulp diegene nodig heeft. Althans, in een gezond team, met een gezonde manager, en een behoorlijke verdeling van responsibilities.
Dan kan alsnog de conclusie zijn dat jij het mag uitwerken, maar dan krijg je daar ook de assistentie en waardering voor die daarbij hoort, en kan de klant misschien een meerprijsfactuur krijgen.

Of je (jij, team, verkoper, pm) geeft het de klant kado, maar het is bij zo'n kado belangrijk om te vertellen WAT je kado geeft: zoveel uur, een stukje ontwikkeling op eigen kosten omdat het voor je eigen bedrijf ook interessant is. Anders nemen ze het voor lief, en groeit de kans dat ze om meer gratis uitbreidingen vragen. Verwachtingsmanagement naar jezelf, je team, en de klant.

Dat helpt allemaal bij het gevoel van voldoening, controle. Het voorkomen van een overspannenheid draait voor een groot deel over je belastbaarheid: hoeveel inzet steek je erin, en hoeveel voldoening haal je eruit. Als die verhouding scheef raakt, bestaat het risico dat je langzaam of sneller afglijdt, houd dat in de gaten, hoe voel je je erbij.

Houd twijfels niet voor jezelf, als je dat jarenlang blijft doen snijd je jezelf in de vingers. Maak dingen bespreekbaar, daar heb je nagenoeg altijd profijt van. Ga je binnenvetten, zelf verantwoordelijkheid nemen die boven je payscale gaat, dan groeien ook de risico's voor het bedrijf, en je gezondheid. Even op je tenen lopen is prima, maar blijf dat niet altijd doen, geniet ook van wat je al bereikt hebt.

Edit: goed dat je dat delen van je twijfels hier al doet trouwens, nu zou ik dat nog op de plek doen waar het ertoe doet, en waar het invloed heeft!

[ Voor 4% gewijzigd door WTBram op 17-10-2020 07:44 . Reden: Typos en respect ]

[TheUninvited]

Als ik vastloop ga ik het aan een collega uitleggen en probeer ik er zo uit te komen. Meestal als je iets gaat uitleggen vind je al nieuwe oplossingsroutes (Wikipedia: Rubber duck debugging werkt ook goed). Ik raad je dan ook aan om niet alles in je eentje te doen, je hebt hopelijk een aantal collega's die meer ervaring hebben. Die kunnen je ook helpen met filteren wat wel/niet belangrijk is.

Je kunt niet alles in je eentje doen, software bouwen is ook samenwerken. Bij stages gaat dat vaak fout, zelf ook tegenaan gelopen namelijk. Vaak neemt een bedrijf iemand aan maar willen ze er niet teveel tijd insteken en dat is niet de bedoeling. Of de stagiair denk dat het zijn project is en probeert het in zijn eentje af te ronden. Je kunt ook in de Tweakers devhoek misschien eens een probleem voorschotelen kijken hoe zij er mee om zouden gaan.

[sh4d0wman]

Ik herken hier wel wat in. Geen ervaring als software dev maar ik zou verwachten dat er een persoon aanwezig is welke op zijn minst helpt met planning/functionaliteit/prioriteit.

Wellicht helpen de volgende uitspraken:
1. "How do you eat an elephant? Bite by bite.". Probeer dus niet gelijk alles uit te zoeken. Richt je op 1 specifieke vraag voor een bepaalde tijd bv 30 minuten. Daarna heb je of een antwoord of hebt niks gevonden/bent afgedwaald. Vraag dan om hulp.

2. "Crawl before you run." Aangezien er veel informatie te vinden is moet je zorgen dat je de basis van alles begrijpt. Hierdoor kun je beter toetsen of een oplossing correct is.

En natuurlijk KISS, keep it stupid simple. Iets complex is leuk maar als een simpele onliner het ook doet...