In uno dei commenti dici che questo è il tuo primo lavoro. I manager spesso non sono tecnici da nessuna parte tranne un negozio di software dedicato nella mia esperienza. Questo fa parte della vita, ci si abitua.
Piangi e piangi perché non c'è nessuno che possa apprezzare l'eleganza delle tue soluzioni. Il vero problema qui non è che non c'è nessuno ad apprezzare l'eleganza delle tue soluzioni, ma che non c'è nessuno che ti insegni che le tue soluzioni non sono così buone come pensi. Praticamente tutti i nuovi programmatori sopravvalutano le loro reali capacità. Senza un mentore, non c'è nessuno che ti aiuti a pratiche migliori. Se non c'è nessuno lì per guidarti, quindi unisciti ai gruppi di utenti locali, partecipa attivamente e ricevi qualcuno che ti aiuti. Ancora meglio, questo ti aiuterà a trovare un lavoro migliore alla fine.
Hai totalizzato uno zero nel test di Joel? Se sei l'unico programmatore (e suona da ciò che hai scritto che sei), perché non stai usando il controllo del codice sorgente? Cosa ti sta impedendo? Se non sei l'unico programmatore, perché non c'è nessuno che possa fare recensioni di codice? Tutti i nostri sviluppatori fanno una revisione del codice, non è una funzione di gestione soprattutto quando i manager non sono tecnici.
I requisiti cambiano praticamente in tutti i posti. Le esigenze aziendali cambiano continuamente e i non programmatori spesso non riescono a visualizzare ciò che il programma farà fino a quando non avranno qualcosa. Poi si rendono conto che non è ciò di cui hanno bisogno. Ecco perché Agile è nata proprio perché i vecchi metodi non gestivano bene quel cambiamento.
Imposta il bug tracking anche se la gestione non vuole inserire i dati stessi. Sii responsabile per l'inserimento di nuovi bug / funzionalità come qualcuno li menziona a te. Aiuta davvero essere in grado di dire al manager quando vuole una modifica che ti sono state assegnate altre 27 cose e qui c'è la lista, che vuoi spostare nella lista delle priorità per accogliere questo nuovo cambiamento. Aiuterà in fase di revisione perché sarà possibile contare il numero di correzioni di bug e funzionalità implementate. Se tutti non lo usano, almeno puoi farlo per il tuo lavoro. Se non ti consentono di installare alcun software, utilizza un foglio di calcolo Excel. Prendi qualche iniziativa. Una volta che puoi mostrare i risultati, gli altri saranno più interessati. Se pensi che ci sia troppo lavoro per una persona, il bug tracker ti aiuterà a dimostrarlo.
Non mostrare dimostrazioni lucide! Le demo dovrebbero apparire come se fossero scarabocchiate su una penna su un foglio di carta. Più l'interfaccia è levigata e più la persona non tecnica pensa che sia finita.
Anche se nessuno saprebbe se ad esempio non segui le best practice e il codice semi_hard, lo saprai e ti ritroverai in cattive abitudini. Questo non ti servirà bene nel tuo prossimo lavoro. Quindi fai le cose nel modo più vicino possibile alle circostanze. Assicurati di scrivere dei test (considera solo questo come parte del tempo di sviluppo e dedica il tempo necessario per farlo in qualsiasi stima tu dia la gestione anche se non dici specificamente che fa parte della stima) e usa quei test per assicurarti le modifiche successive non infrangono qualcos'altro.
Devi considerarlo un'opportunità inestimabile per crescere e migliorare. Hai più libertà nella codifica attuale di quella che molte persone hanno in quella fase della tua carriera. Considerate quindi questa un'opportunità per creare un portfolio di progetti implementati con successo. Quando andrai a cercare il prossimo lavoro, essere in grado di evidenziare tali traguardi come il controllo del codice istituita, il monitoraggio dei bug, il numero X di implementazioni di progetti di successo, ecc, ti farà emergere dal resto.
Hai anche una grande opportunità qui per imparare come gestire le aspettative verso l'alto. Questo è askill che ti tornerà utile per il resto della tua carriera. Non hai nulla da perdere nel provare a fare questo qui, le cose non sono già buone. Ma puoi imparare le abilità politiche che ti aiuteranno in posti migliori in seguito. Impara a fare un'analisi costi-benefici. Impara a capire il dominio aziendale in modo da essere convincente quando parli con loro. Impara a parlare in termini di benefici per l'azienda e profitto. Fai delle stime per ogni attività che ti viene assegnata e anche se non corrispondono alla gestione del waht ti dà, tieni traccia di ciò che hai stimato e di ciò che è effettivamente necessario per migliorare la tua capacità di stimare il lavoro. Una volta che puoi dimostrare che le tue stime sono state storicamente più accurate di quelle della gestione, saranno più propensi ad ascoltare quando dici che la stima è troppo bassa. Ma per prima cosa bisogna costruire un track record di entrambe le stime più accurate e, soprattutto, la capacità di fornire i progetti e farli funzionare. Ancora una volta questa è una buona abilità da avere mentre ti muovi nella tua carriera.
Soprattutto non essere passivi e aspettarsi che i miglioramenti arrivino dall'alto.