Flutter taught me Flutter wasn't the point

Dit artikel is oorspronkelijk geschreven in het Engels.

‍

In een eerdere blog schreef ik over het aannemen van een groeimindset. Ik beschreef mijn ervaringen met de mentaliteit op de verschillende scholen die ik heb gevolgd, en hoe een vaste mindset zo diep verankerd zit in de samenleving van vandaag. Ik noemde ook mijn ambitie om mijn eigen manier van denken te veranderen, en had goede hoop om de cultuur bij Baseflow te gebruiken als een soort sandbox: een veilige omgeving waarin experimenteren werd aangemoedigd. Nu zijn we twee jaar verder, en er is veel veranderd.

Natuurlijk is er ook veel vooruitgegaan in de wereld van tech, maar dat is te verwachten. Voor mij zat de grootste verandering in mezelf. Ik merkte dat veel mensen benieuwd waren hoe die verandering er in de praktijk uitziet. Daarom ga ik niet in op de abstracte concepten van de groeimindset, maar gebruik ik een recent voorbeeld om te laten zien wat het voor mij betekent in de context van softwareontwikkeling. Ik leg mijn denkproces uit, welke emoties ik typisch voel, en reflecteer op hoe ik dingen twee jaar geleden zou hebben aangepakt. Juist in die vergelijkingen wordt de progressie zichtbaar.

‍

Flutter leren

Ik kreeg onlangs de opdracht om "Flutter te leren". Dat riep meteen een paar vragen en bezwaren bij me op. Neem het woord "leren" al. Dat woord schrikt me nog steeds af. Dan is er nog "Flutter", waar ik geen idee van had wat het was. En "Flutter leren" als opdracht is op zichzelf ook behoorlijk vaag. Ik wist dat ik nog wat werk te doen had voordat ik überhaupt kon beginnen. Door het gebrek aan context en doel moest ik zelf grenzen en doelen stellen. Dat inzicht was nieuw: een eerste teken van vooruitgang.

Twee jaar geleden had ik me overweldigd en opzien gebaard gevoeld bij het leren van een taal en framework vanaf nul.

Met een top-down aanpak besloot ik eerst een paar basisdingen over Flutter uit te zoeken. Waar is het voor? Hoe wordt het gebruikt? Welke tooling heb je nodig? Hoe ziet idiomatische Dart eruit? Baseflow heeft een flink aantal Flutter-experts en ontwikkelt doorlopend Flutter-trainingen via de Baseflow Academy. Ik wist dat ik op die interne kennis kon terugvallen. Ik vroeg een paar collega's om advies en bronnen (elkaar helpen staat centraal in onze cultuur), en kreeg goede tips, artikelen (zowel intern als extern) en voorbeelden uit onze eigen codebase. Genoeg informatie en vertrouwen om te starten: "Hello, World!"-stijl.

Twee jaar geleden was ik gewoon begonnen zonder om hulp te vragen, in de overtuiging dat ik het allemaal zelf moest kunnen. Om hulp vragen zou een teken van falen zijn geweest.

Al snel had ik een simpele app gemaakt met een paar widgets en states. Ik had tijdens de tutorials veel vragen, en gebruikte AI als persoonlijke leraar. Hoewel ik geloof dat domme vragen niet bestaan, helpt het enorm om alles te kunnen vragen zonder oordeel. In mijn prompts vroeg ik bewust om geen codevoorbeelden: ik wil eerst zelfstandig code kunnen schrijven en echt begrijpen wat er gebeurt. Ik wist dat dit nog maar het begin was van mijn leertraject, maar besloot me er bewust niet druk over te maken. Geen starend-naar-een-leeg-scherm-syndroom voor mij.

Twee jaar geleden had ik me overbodig en achterhaald gevoeld door de mogelijkheden van AI.

Ik realiseerde me wel dat de manier van werken in mijn bronnen en test-app waarschijnlijk flink zou afwijken van hoe we bij Baseflow werken. Dus besloot ik een kijkje te nemen in de codebase-voorbeelden die collega's hadden aangewezen. De repos die ik bekeek volgen het clean architecture-principe en gebruiken Cubit voor state management.

Twee jaar geleden had ik me geïntimideerd gevoeld door de complexe code en had ik mijn eigen capaciteiten in twijfel getrokken.

Toen ik de codebase in dook, merkte ik dat er van alles door me heen ging. Ik herkende patronen in mezelf en besefte dat ik in een bekende val liep. In plaats van mijn oude strategieën en gewoontes te gebruiken, zag ik dit moment als een kans om een nieuw pad te snijden. Voor mij begon dat met het ontladen van de situatie: ik zei tegen mezelf dat niemand, zelfs de absolute experts niet, een nieuwe codebase meteen voor honderd procent begrijpt. Ik zag het voor wat het was: een onrealistisch doel. Ik overtuigde mezelf dat ik voor nu alleen de relevante onderdelen hoefde te begrijpen: de basisopzet en structuur van een clean architecture-app. De rest zou later wel komen. Die interne dialoog hielp me kalmeren, zowel cognitief als emotioneel en fysiek. En toen kwam de ultieme vraag: "Wat nu?" Belangrijk om te vermelden: die vraag kwam voort uit nieuwsgierigheid, niet uit paniek.

Twee jaar geleden had ik de complexe code gemeden en was ik blijven hangen in de kloof tussen de beginner-tutorials en echte praktijkervaring.

Mijn aanname klopte: ik had geen diepgaande kennis van enterprise-principes nodig. Als startpunt voerde ik de directorystructuur van een clean architecture-repo in bij AI, om een leeg project te genereren dat aansluit op de architectuur die we bij Baseflow gebruiken. AI legde netjes uit wat nu niet nodig was en wat essentieel was. Met die schone lei aan boilerplate-code begon ik na te denken over een app-idee. Om de complexiteit beperkt te houden, koos ik voor een todo-app: een extreem gangbare keuze, maar ook een garantie dat mijn AI-leraar hier goed op getraind is. Dat houdt hallucinaties hopelijk tot een minimum, en tips en uitleg relevant. Een todo-app sluit goed aan op mobiele ontwikkeling en states: perfect. Om het interessant te houden, implementeerde ik een aangepast sorteeralgoritme als service, zodat ik het clean architecture-principe echt kon benutten. Ik maakte er een Git-project van en vroeg collega's om feedback.

Twee jaar geleden geloofde ik dat fouten maken slecht was en ten koste van alles vermeden moest worden.

‍

En nu?

Het feit dat ik een solide project heb neergezet geeft me het vertrouwen om verder te bouwen. Daarvoor heb ik een aantal tickets aangemaakt in GitHub. Ik heb geleerd om de scope van features beperkt en haalbaar te houden. Ik heb geen idee hoe ik ze moet implementeren, maar ik ben er vrij zeker van dat het gaat lukken: dezelfde verdeel-en-heers-aanpak hielp me al om de complexiteit van clean architecture en Cubit te doorgronden.

Terugkijken op mijn Flutter-traject heeft me waardevolle inzichten gegeven. Ik doe het nu een stuk beter dan toen ik begon als softwaredeveloper. Ik herken onhelpvolle of zelfs schadelijke patronen en kan er iets mee. Hulp zoeken bij anderen gaat veel natuurlijker nu, en het is onmisbaar in mijn leertrajecten. Ik heb geleerd dat falen niet alleen oké is, maar ook enorm waardevol. Ik ben me bewust van mijn zwakke punten, zonder mijn potentieel of mezelf als persoon en developer te ondermijnen. Ik weet heel goed dat ik nog veel te leren heb, maar ik ben er ook heel zeker van dat dat allemaal komt.

Software ontwikkelen is op zichzelf al uitdagend genoeg. Het heeft geen zin om het nog ingewikkelder te maken door het persoonlijk op te vatten. Persoonlijke conclusies trekken uit falen is een van de grootste obstakels voor een groeimindset.

Als deze blog je aanspreekt, zijn dit een paar vragen die kunnen helpen als je in een vergelijkbare situatie zit:

• Wat is het kleinste stukje van dit probleem dat ik vandaag kan begrijpen?
• Wie om me heen weet hier al iets over waar ik van kan leren?
• Hoe zou deze situatie eruitzien als ik hem met nieuwsgierigheid benaderde in plaats van met oordeel?
• En misschien wel de belangrijkste: wat zou ik proberen als ik niet bang was om het fout te doen?