Pluspunten
Er werken een aantal zeer getalenteerde mensen bij Hopper - het verschilt per team, dus uw aantal kilometers kan variëren. Het bedrijf heeft een onbeperkte aftakas. Je leert hoe de reisindustrie werkt, wat misschien interessant voor je is. Hopper heeft zich gecommitteerd aan een relatief moderne microservice-architectuur met een Scala-backend, dus daar valt veel te leren.
Minpunten
Hopper houdt enorm van STO (eigendom met één schroefdraad) (ze hebben dit opgeheven, evenals veel "kernwaarden" van Amazon). Dit betekent dat elk team theoretisch verantwoordelijk is voor een of meer productfuncties, wat zich doorgaans vertaalt naar enkele componenten in de mobiele apps (iOS/Android) en een of meer microservices (waarvan er tientallen zijn). In de praktijk, aangezien er één codebasis is voor iOS en één voor Android, heb je tientallen afzonderlijke teams die allemaal code bijdragen met weinig manier om consistentie in de gebruikersinterface of in de code zelf af te dwingen. Het testen van eenheden is ontoereikend en prijs jezelf gelukkig als je daadwerkelijke opmerkingen in de code vindt. Leidinggevenden op hoog niveau hebben mensen verteld dat "uw mening er niet toe doet - het is alleen wat de klant wil". Dit is een concept dat de wenkbrauwen doet fronsen en doet denken aan het oude citaat van de autofabrikant: "Als ik mensen had gevraagd wat ze wilden, hadden ze snellere paarden gezegd." Hopper neemt in plaats daarvan alle beslissingen op basis van A/B-tests. Dit is prima om te beslissen over sommige aspecten van de applicatie, maar er is geen A/B-test voor nodig om te begrijpen dat niet alle klanten Hopper standaard willen "fooien" bij het boeken van een vlucht van een luchtvaartmaatschappij (vrij donker patroon) of dat het prijsdisplay van het hotel is verwarrend. Er is geen centrale engineeringfunctie - alles rapporteert aan de STO-leider, wat in de praktijk betekent dat engineering rapporteert aan het product. Dit betekent dat er een constante druk is om kortzichtige beslissingen te nemen om het volgende productkenmerk te leveren, wat onvermijdelijk inhoudt dat er korte metten worden gemaakt en dat er meer technische schulden ontstaan. Op een gegeven moment zal er een afrekening komen en ik zou voorzichtig zijn om daar te zijn als dat gebeurt. Het is vooral slecht in sommige teams waar de STO-leider geen technische achtergrond heeft en geen waarde hecht aan het testen van eenheden, solide code-review-praktijken of algemene architectuur. Ongeacht je anciënniteit of ervaring, er wordt van je verwacht dat je tickets gewoon van de Jira-achterstand haalt als een soort kok op korte termijn. De hemel verhoede dat je probeert om op de lange termijn te kijken en te pleiten voor het opzetten van betere architectuur, testkaders of tools om je werk te ondersteunen.