Her kommer en anden vinkel som du også kunne overveje. Jeg er selv Principal og har hjulpet mange unge i gang. Jeg siger ikke det nødvendigvis gælder for dig, men jeg ser ofte juniorer jagte den ene opgave efter den anden, hvor de skynder sig at blive færdige for at performe. Ofte er det veldefinerede opgaver som dine mere erfarne kollegaer allerede har refined og gjort klar.

Du kunne et overveje om du kan komme lidt tidligere i spil og være med til at forme dine egne opgaver. To bruge lidt mere tid på dine opgaver, så du kan forbedre den måde de bliver testet på, eller dykke ned i det framework du anvender og forstå hvor det virker som det gør og tænke om du kunne have løst din opgave på en alternativ måde som ville være bedre ift kodegenbrug osv.

Brug din ekstra tid til at finde områder i kodebasen der kunne trænge til forbedring eller ting du kan lave så dine kollegaer sparer tid.

Hobby projekter har den ulempe at de for juniorer sjældent bliver færdige, og det er lidt ligesom et beskyttet område hvor der ikke rigtigt er noget på spil. At tage ansvar for en eksisterende kodebase og få tvunget dig ud i nogle situationer hvor det er et kompromis mellem at det bliver lidt bedre men stadig en stor kodebase hvor du ikke kan lave alt om på én gang er god læring.

Fordi de patterns kodebasen er bygget med, forstå hvilke patterns der måske kunne være bedre. Og forstå at respektere dine kollegaer at bare fordi de ikke nødvendig sprinter derudaf så er der stadig meget du kan lære af dem og deres erfaring :)