Je eerste maand bij een startup laat een indruk achter. Er is geen langzame inwerkperiode, geen week waarin je oriëntatievideo's kijkt terwijl je wacht tot de IT-afdeling een laptop heeft klaargezet. Op dag één wordt er van je verwacht dat je dingen bouwt, sloopt en repareert die echte mensen ook daadwerkelijk zullen gebruiken. Ik leerde dit snel nadat ik bij Treevah kwam werken, een bedrijf dat tools bouwt om werkzoekenden te helpen hun sollicitaties te organiseren. Dertig dagen in een omgeving in een vroege fase leerde me meer over softwareontwikkeling dan welke klaslokaal of competitie dan ook.
Het ritme is meedogenloos
Bij Treevah wacht het werk niet tot je je plek hebt gevonden. Het team werkt hard om het product van alpha naar beta en uiteindelijk naar productie te brengen, wat betekent dat elke taak gewicht in de schaal legt. Er is geen ruimte voor placeholder-werk of opdrachten die in de inbox van een professor belanden. Wanneer je een feature releast, gaat deze rechtstreeks naar gebruikers die proberen deadlines, interviews en follow-ups bij te houden terwijl ze op zoek zijn naar hun volgende baan.
Het tempo is uitputtend. Je beweegt elke dag razendsnel en de werklast stapelt zich sneller op dan je verwacht. Deadlines zijn niet abstract; ze zijn gekoppeld aan mijlpalen die bepalen of het bedrijf meer werkzoekenden kan helpen of hiaten in de huidige ervaring kan dichten. Die zwaarte put je uit. Maar het zorgt ook voor een helderheid die moeilijk te vinden is in grotere organisaties. Wanneer ik een taak afrond, kan ik een rechte lijn trekken tussen wat ik heb gebouwd en een persoon die nu het makkelijker heeft om hun zoektocht naar een baan te beheren. Dat gevoel van eigenaarschap is zeldzaam, en het zorgt ervoor dat de vermoeidheid het waard voelt.
Vaardigheden groeien sneller in productie
Voor deze zomer ging veel van mijn energie naar spreken in het openbaar en hackathons. Beiden leerden me hoe ik ter plekke kon improviseren en ideeën onder druk kon presenteren. Vooral hackathons trainen je om in enkele uren werkende demo's in elkaar te knutselen. Maar er is een verschil tussen een weekendproject dat juryleden indruk maakt en productiematige code die bestand moet zijn tegen contact met honderden echte gebruikers.
Een maand lang gefocust zijn op webontwikkeling bij Treevah overbrugde die kloof. Op school komen projecten met vangrails. De scope is vastgesteld, de vereisten worden op een presenteerblaadje geserveerd, en als je databaseschema instort, kun je dat wegverklaren in een presentatieslide. Binnen een startup moet je schema standhouden, omdat echte werkzoekenden er echte sollicitatiegegevens in opslaan. De feedbackloop is onmiddellijk en onverbiddelijk. Wanneer een pagina traag laadt of een formulier niet opslaat, geeft niemand om je cijfer; ze geven erom of ze zojuist een kans uit het oog zijn verloren.
Die druk dwingt tot groei. Je leert schonere code te schrijven, niet omdat een beoordelingsformulier dat eist, maar omdat jij degene bent die het om middernacht moet debuggen. Je leert scherpere vragen te stellen tijdens een code review, omdat het deployen van een defecte build betekent dat echte gebruikers tegen een muur aanlopen. De kansen hier zijn simpelweg groter dan bij schoolprojecten. De fouten kosten meer, en dus blijven de lessen beter hangen.
De confronterende realiteit van bugs
Als er één mythe is die ik wil onderuit halen, dan is het wel het idee dat elke softwarebug een dramatische logische fout is. Sommige zijn dat natuurlijk wel. Maar veel van de bugs die ik bij Treevah tegenkwam, waren irritant klein. Ze zaten voor het op het oog verborgen en verspilden uren van mijn leven.
Twee patronen bleven terugkomen. De eerste was dubbele CSS-regels. Wanneer meerdere ontwikkelaars gedurende verschillende sprints aan dezelfde component werken, zwellen stylesheets aan. De ene persoon voegt een margin utility class toe, terwijl een ander een waarde hardcodeert in het componentbestand. Geen van beide is op zichzelf fout. Maar samen veroorzaken ze layout shifts of specificity-oorlogen waardoor een knop er prima uitziet in Chrome, maar kapot is in Safari. Dat opsporen betekent de browser dev tools openen en regel voor regel door de computed styles kruipen, in plaats van elegante algoritmische logica te lezen.
De tweede was het definiëren van elementen buiten hun parent divs. Een modal trigger of een dropdown kan aan de verkeerde node in de DOM worden toegevoegd. Het scherm ziet er bijna goed uit, dus je gaat ervan uit dat de structuur klopt. Dan ontstaat er een z-index conflict, of een click event bubbelt naar de verkeerde handler, en plotseling kan een gebruiker een popup niet sluiten die hun sollicitatieformulier bedekt. Dit zijn geen informatica-puzzels. Het zijn ruimtelijke en structurele foutjes die zich opstapelen wanneer je snel werkt.
Sommige van deze bugs kostten weken om te vinden. Ik staarde naar de code, overtuigde mezelf ervan dat de logica klopte, en dwaalde af in doodlopende zijpaden die nergens toe leidden. De frustratie is echt. Je hebt het gevoel dat je iets voor de hand liggend mist, en dat is ook zo. Maar de voldoening van het eindelijk ontdekken van een dubbele regel of een verkeerd geplaatste sluitende tag is verrassend