Davide Borsatto, PHP Ecosystem Developer di Contentful: questo è il mio lavoro

Questa settimana abbiamo intervistato Davide Borsatto, PHP Ecosystem Developer di Contentful: ci ha raccontato cosa lo ha portato ad abbracciare questa professione dopo il suo percorso di laurea e quali difficoltà sta affrontando lavorando da remoto per un’azienda basata a Berlino.

 

Ci puoi raccontare brevemente in cosa consiste il tuo PHP Ecosystem Developer e come sei arrivato a ricoprirlo dal tuo iniziale percorso di laurea in lingue?

Iniziamo dalla seconda parte della domanda, ovvero come sono arrivato a questa posizione. Devi sapere che io ho un diploma come perito informatico, ma la mia prima esperienza lavorativa in questo settore è stata tutt’altro che positiva, tanto più che mi ha portato a domandarmi se tutti quei problemi che avevo fossero dovuti al lavoro specifico, o al settore. Per questo all’epoca decisi di dare una possibilità all’altro percorso di studi che mi aveva sempre interessato, ovvero lo studio delle lingue.

Col tempo, mi resi pian piano conto che l’informatica è effettivamente parte di me, e la cattiva esperienza era colpa dell’ambiente in cui lavoravo, non del settore stesso. Per questo, verso la fine del percorso di laurea, sono tornato ad essere attratto dalla programmazione, e dopo essere stato contattato inaspettatamente da un’azienda che aveva trovato un mio vecchio curriculum online, ho ripreso a lavorare come sviluppatore.

La cosa positiva di aver conseguito la laurea in lingue è che ora i miei orizzonti lavorativi sono realmente più ampi. Per questo, dopo circa un anno dall’essere tornato ad essere sviluppatore ho mandato la mia candidatura ad un’azienda tedesca, con sede a Berlino. Qualche colloquio in videochat ed alcuni di persona dopo, eccomi lì a lavorare (sorpresa!) come scrittore per il reparto marketing. L’azienda è nel settore SaaS (software-as-a-service) e nel marketing serviva qualcuno che fosse capace di scrivere bene, e avesse reali capacità informatiche a supporto, quindi fui scelto per questo ruolo. Tutto bello, se non che l’attrattiva della programmazione stava di nuovo facendo il suo effetto su di me, per cui (complice anche esigenze personali che mi hanno portato a tornare in Italia) la società ed io abbiamo raggiunto un accordo per farmi cambiare ruolo ed essere aggiunto nel reparto di ingegneria, con una posizione 100% da remoto, nel ruolo di PHP Ecosystem Developer.

Essendo una società che di base offre dei servizi via API, ci preoccupiamo di fornire anche tutti gli strumenti a supporto, per facilitare le integrazioni tra queste API e le piattaforme dei nostri clienti. Per questo la mission del mio team è quella di sviluppare strumenti di integrazione (chiamati SDK, software development kit) per alcune piattaforme chiave, in modo che i nostri clienti riescano ad integrare nel modo più semplice possibile i nostri servizi nei loro sistemi, senza dover occuparsi dei problemi più di basso livello, ai quali pensiamo noi. Io mi occupo nello specifico degli strumenti per il linguaggio PHP, mentre gli altri membri del mio team forniscono supporto a Javascript, Python, Ruby, .NET, Java, e Swift.

 

Quali sono gli aspetti del tuo ruolo che ti piacciono di più? Quali di meno?

Un aspetto che sicuramente adoro è che tutto (o quasi) quello che faccio è rilasciato come open source. Infatti, visitando la pagina Github di Contentful, si può vedere come ci siano un sacco di strumenti e prodotti che rilasciamo con licenze open source, cercando di favorire trasparenza e collaborazione con la community.

Inoltre, c’è un vero focus nella qualità del proprio lavoro, e spesso si riesce ad ottenere compromessi più che soddisfacenti nell’eterna lotta fra deadline imminenti e perfezionismo. La società lavora con metodologie agili, e c’è un continuo meccanismo di feedback in atto per far sì che il lavoro sia svolto il più possibile nelle condizioni migliori, e i risultati raggiunti siano il frutto di uno sforzo collettivo.

In generale, ci sono poche cose che “mi piacciono di meno” del lavoro, e di questo sono infinitamente grato. Ovviamente, lavorare da remoto per una compagnia dove la maggior parte dei dipendenti sono in una sede centrale ha delle difficoltà non sempre risibili. A volte c’è il rischio di sentirsi tagliati fuori, per questo le doti di comunicazione sono fondamentali, così come avere dei colleghi che si sforzano di includere anche i lavoratori da remoto nelle conversazioni in chat piuttosto che limitarsi a quelle di persona. Fortunatamente, il mio team ha 3 persone su 9 che lavorano al 100% da remoto, quindi non mi sento mai da solo in questa situazione.

L’unico altro lato negativo è la saltuaria mancanza di varietà. Lavorando per un’agenzia si lavora continuamente in nuovi progetti con nuove sfide, mentre ora può capitare di restare su un singolo problema per periodi a volte lunghi. Fortunatamente questi problemi sono spesso interessanti e coinvolgenti, ma se proprio dovessi trovare il pelo nell’uovo, credo sarebbe questo.

Quali consigli daresti ad un tuo collega che vuole distinguersi nel tuo lavoro?

Questa è una domanda difficile. Sinceramente non credo esistano tante società con team interamente dedicati a sviluppare integrazioni fra il servizio “core” e i sistemi terzi in modo così aperto come succede nel mio caso. Per questo è fondamentale essere parte della community della piattaforma specifica, essere al corrente dei trend, degli eventi, in generale di ciò che succede. Non è necessario (secondo me) prenderne sempre parte in prima persona, però sicuramente non si può mai smettere di fare attenzione. Non posso mai sapere se verrò chiamato a creare un’integrazione fra il nostro servizio ed un framework appena nato, oppure se dovrò modificare parti delle integrazioni già esistenti per essere più moderne grazie alle ultime tecnologie. Per questo mi impegno costantemente per integrare gli ultimi standard e lavorare sempre a regola d’arte, in modo di fornire alla community sempre uno strumento di alta qualità e il più possibile innovativo.

Un altro fattore assolutamente fondamentale riguarda la parte di testing. Io lavoro seguendo la filosofia “se del codice non è coperto dai test, il codice è potenzialmente fonte di bug”, a prescindere da quanto semplice o banale possa essere. Quando ho iniziato questo lavoro e ho ereditato del codice dallo sviluppatore precedente, la percentuale di copertura del codice era attorno al 90/95%. Sembrerebbe buona, ma indovina cosa si nascondeva in quel 5/10% rimanente? Dei bug. Per questo uno sviluppatore come si deve dovrebbe sempre cercare di raggiungere il 100% di codice coperto da test. Ovviamente questo non è sempre possibile, e altrettanto ovviamente la copertura al 100% non significa che il codice sia la sicuro dai bug, ma personalmente preferisco nettamente uno sviluppatore che lavora con metodologie come TDD e cerca sempre di scrivere test adeguati.

Come pensi che il tuo ruolo evolverà in futuro? Quali strumenti ritieni essere indispensabili per mantenerti “aggiornato”?

Essendo questo un ruolo particolare, diverso dal solito sviluppatore di agenzia, capire come si possa evolvere è abbastanza difficile. Una cosa che mi piacerebbe è acquisire un ruolo sempre più vicino al cliente, fornire supporto a livello architetturale, e aiutare a definire le best practices. Spesso i nostri clienti cercano di modernizzare le proprie infrastrutture, rimuovendo vecchie architetture monolitiche e cercando di rimpiazzarle con parti più piccole, più facilmente gestibili e testabili. Dato il mio ruolo di sviluppatore di software di integrazione, credo di avere una prospettiva unica sul come funziona il core product della mia società, e quali sono le esigenze degli sviluppatori che lavorano sulla piattaforma PHP, per questo vedo nel mio futuro un’integrazione maggiore nei vari stadi di sviluppo, sia interno che esterno.

Per restare aggiornato (e rilevante, come ho affermato nella risposta precedente) ci sono diversi strumenti: blog, newsletter, conferenze… La cosa più difficile è probabilmente riuscire a distinguere chi e cosa vale la pena di seguire. Purtroppo PHP ha una reputazione non eccelsa, in quanto per anni è stato visto come linguaggio “giocattolo” e pieno di problemi. Questo si vede ancora oggi ad esempio nei problemi ricorrenti di sicurezza di WordPress, che si ostina a non voler modernizzare la propria architettura, e mantiene il supporto per versioni di PHP assolutamente vecchie e abbandonate (supporta PHP 5.2, che non riceve aggiornamenti di sicurezza da più di sette anni). Per questo bisogna fare un po’ di fatica e distinguere chi vale la pena di seguire da chi continua ad usare PHP con i metodi antiquati di dieci anni fa. In generale, all’interno dell’ecosistema PHP, ci sono delle community dietro al alcuni progetti che mi sento di raccomandare, fra i quali il PHP-FIG, the PHP League, PHP The Right Way, PHPUnit, Symfony, Zend Framework, e Laravel (seppur quest’ultimo con qualche personale riserva). Le community dietro a tutti questi progetti forniscono continuamente spunti interessanti, per cui seguo buona parte di queste persone su Twitter, dove spesso trovo spunti e link che rimandano ad altri luoghi come forum, mailing list, blog, etc. In generale, credo che sia più importante seguire le persone, più che i progetti stessi, perché spesso i progetti interessanti nascono dalla collaborazione di più persone sveglie e brillanti.