Il mio manager, un programmatore entusiasta, è pieno di energia per programmare. Ma lui ha ... l'abitudine di essere negligente nelle riunioni se non riesce a capire il problema o la discussione. Di conseguenza, rovina un paio di cose.
Ad esempio:
Quando stavamo parlando del processo di progettazione per i servizi web REST, ho suggerito di scrivere prima le specifiche dei servizi web REST e poi avviare l'implementazione.
Ha insistito sul fatto che, se avessimo potuto utilizzare JAX-RS per implementare il componente riutilizzabile, la documentazione per le specifiche non sarebbe stata una priorità. Ho detto che i componenti riutilizzabili sarebbero un problema se avessimo cambiato le specifiche del servizio web REST e provato ad aggiornare i sistemi che usano questi componenti. Non capiva o non importava di cosa stavo parlando.
Dopo che l'API JAX-RS è stata rilasciata e utilizzata in altri progetti, si è reso conto che qualcosa non andava nella progettazione delle classi Java. Voleva modificare l'interfaccia Java dell'API client (annotata con JAX-RS) ma non sapeva come aggiornare i sistemi che l'utilizzavano, così ha deciso di scrivere un'intera nuova API. La nuova API è stata un disastro a causa della mancanza di documentazione e della costruzione con la sua intuizione. Infine, l'API del servizio web REST che ha terminato non corrispondeva alle specifiche del servizio web REST sul server.
Abbiamo modificato i nostri progetti per utilizzare la nuova API. I nostri progetti sono falliti, abbiamo trovato i problemi e li ha risolti; fine della storia.
Questo potrebbe essere un problema di comunicazione (sempre di comunicazione), ma a lui non interessano le cose tecniche a cui non ha familiarità - eppure era solito scrivere codice in modo intuitivo.
Devo continuare a convincerlo delle migliori pratiche con cui ho esperienza o semplicemente faccio il mio lavoro? Questo non è un incidente isolato.