Ho appena iniziato la mia carriera come sviluppatore web per un'azienda di medie dimensioni. Appena ho avuto il compito di espandere un'applicazione esistente (mal codificata, sviluppata da più programmatori nel corso degli anni, gestisce le stesse attività in modi diversi, struttura zero).

Quindi, dopo aver esteso con successo questa applicazione con la funzionalità richiesta, mi hanno dato il compito di mantenere completamente l'applicazione. Questo ovviamente non era un problema, o almeno così pensavo. Ma poi ho saputo che non mi era permesso di migliorare il codice esistente e di concentrarmi solo su correzioni di bug quando veniva segnalato un bug.

Da allora ho avuto altri tre progetti, proprio come sopra, che ora devo anche mantenere. E ho ottenuto quattro progetti in cui mi è stato permesso di creare l'applicazione da zero, e devo mantenere anche quelli.

In questo momento sto iniziando leggermente a impazzire dalle e-mail quotidiane degli utenti (leggi i gestori) per ogni applicazione che devo mantenere. Si aspettano che gestisca queste mail direttamente lavorando anche su altri due nuovi progetti (e ci sono già altri cinque progetti in fila dopo quelli). La cosa triste è che devo ancora ricevere una segnalazione di bug su tutto ciò che ho codificato da solo. Per questo ho ricevuto solo occasionali richieste di modifica di 180 cose diverse.

Comunque, è normale? Secondo me sto facendo il lavoro equivalente di un intero team di sviluppatori.

Ero un idiota quando inizialmente mi aspettavo che le cose fossero diverse?

Immagino che questo post si sia trasformato in un grande rant, ma per favore dimmi che non è lo stesso per tutti gli sviluppatori.

PS Il mio stipendio è quasi uguale se non inferiore a quello di un cassiere in un supermercato.

Durante uno dei miei stage ho scoperto di aver trascorso molto tempo a correggere errori. Devi capire che come impiegato entry level non otterrai il lavoro più sexy, otterrai il lavoro grugnito che nessun altro vuole. È sfortunato, ma è così per ogni lavoro.

Inoltre, devi rendertene conto che per un'azienda avere codice che funziona è più importante che avere un codice pulito. Dal punto di vista della tua azienda, cambiare la struttura esistente è denaro sprecato nel rifare qualcosa che è già stato fatto e introdurre potenzialmente ancora più errori. Di solito questi tipi di società non sono società di computer / software, quindi nessun manager sufficientemente alto ha il background tecnico per sapere che a volte è necessario effettuare queste revisioni importanti. Detto questo, se la tua azienda è gestita da persone tecnicamente competenti e capiscono il valore di un buon codice, potresti ottenere più margine di manovra, anche se a volte devi scegliere le tue battaglie (lo scopo principale di un'azienda è ancora quello di fare soldi, dopo tutto ).

Detto questo, non sei irragionevole nel voler essere in grado di lasciare il segno sul software e nel voler un lavoro più significativo. È anche un peccato che tu abbia a che fare con così tanti progetti contemporaneamente mentre inoltri richieste da così tanti manager diversi.

Come programmatore, è un dato di fatto che passerai più tempo a mantenere e modificare il codice di altre persone che a scrivere da zero. Se questo è un problema per te, forse dovresti continuare a sviluppare come hobby e perseguire una carriera diversa. Se sei d'accordo con il mantenimento del codice, ma ritieni di non essere utilizzato in modo efficace o di essere sopraffatto, allora è una questione che devi discutere con il tuo manager. Se i tuoi problemi sono più gravi di così o se ritieni che i tuoi manager non sappiano come gestire in modo efficace il tuo set di competenze, sarebbe una buona idea considerare di trovare una posizione in un'altra azienda. Dato il tuo basso salario dichiarato, questo è probabilmente il miglior modo di agire.

Sembra che la gestione abbia un problema nella gestione del carico di lavoro e nella definizione delle priorità delle attività. Dovresti parlare con il tuo manager e fargli capire che sei sovraccarico e non puoi fare un lavoro efficace se tutti continuano a bombardarti con richieste che vogliono soddisfare immediatamente.

Ciò ti fa saltare da un compito all'altro e proiettarti su un altro, sprecando molto tempo a cambiare marcia nella tua mente. Per un efficace lavoro di sviluppo software, si dovrebbe essere in grado di immergersi in un'attività e concentrarsi completamente su di essa. Più interruzioni si ottengono, più tempo viene sprecato dal cambio di contesto. La ricerca mostra che ci vogliono circa 15 minuti per immergersi e arrivare allo stato di flusso in cui la nostra mente lavora nel modo più efficiente. Se ricevi interruzioni ogni 15 minuti, non riesci mai a fluire, il che è un enorme spreco per te e per l'azienda.

Quindi dovresti provare a negoziare una modalità di lavoro più sensata con il tuo manager . Ciò dovrebbe includere la priorità delle richieste in arrivo e la pianificazione in anticipo in una certa misura . Tutte le richieste degli utenti devono essere gestite in un elenco, ordinato per priorità. E le priorità non dovrebbero essere decise dal richiedente (poiché naturalmente tutti pensano che la sua richiesta sia la più importante sulla terra), né da parte tua, ma da qualcuno con sufficiente conoscenza commerciale e panoramica dell'intera gamma di prodotti che stai mantenendo ( il proprietario del prodotto ).

Idealmente, tutte le richieste in arrivo dovrebbero essere inserite in un tracker di problemi come JIRA o Mantis . O almeno inviato al proprietario del prodotto, non a te. E lui / lei dovrebbe occuparsi anche di tutti i reclami degli utenti per "perché la mia richiesta non è ancora pronta ?!", permettendoti di concentrarti sul lavoro di sviluppo. Se ciò è irraggiungibile, dovresti almeno negoziare alcune finestre temporali quando guardi le richieste in arrivo e le gestisci, riservando una parte ininterrotta del tuo tempo esclusivamente allo sviluppo.

Se ciò è possibile, il prossimo passo potrebbe essere pianificare in una certa misura il futuro. Vale a dire, stimare il tempo necessario per implementare le richieste con la massima priorità, quindi pianificare il proprio tempo in sprint , che può essere una o più settimane ciascuno, e allocare abbastanza attività allo sprint successivo per coprire il proprio tempo.

Probabilmente vuoi mantenere una parte del tuo tempo per le richieste di emergenza in arrivo, ma il resto può essere pianificato in anticipo. E potresti anche preferire organizzare il lavoro su diversi progetti in "strisce" separate, vale a dire lavorare sul progetto A di lunedì, il progetto B di martedì-mercoledì, il progetto C di giovedì mattina e D di pomeriggio, ecc., Per approfondire ridurre il cambio di contesto.

In questo modo hai una vaga idea di cosa devi fare nelle prossime o poche settimane. Inoltre, questo fornisce una tabella di marcia anche ai tuoi clienti: possono vedere quando ottengono quale richiesta implementata. Puoi o non vuoi menzionare la parola "agile" al tuo manager qui - questo è fondamentalmente uno sviluppo agile , ma alcune persone si oppongono all'agile senza realmente sapere di cosa si tratta :-)

Tieni presente che anche se la tua posizione attuale sembra poco apprezzata dalla tua azienda, maggiore è il numero di progetti che mantieni, maggiore è il potere di negoziazione che hai .

Trovare e formare un nuovo assunto per mantenere tutti questi progetti richiede molto tempo (= denaro) per l'azienda. E puoi giustamente sottolineare che il tuo codice è molto meglio delle parti legacy di queste applicazioni, quindi non è un dato di fatto che possano facilmente trovare un candidato con capacità simili per la stessa quantità di denaro. Per non parlare del fatto che se non migliorano le condizioni di lavoro, faranno stufare il prossimo ragazzo e si licenzieranno altrettanto velocemente come te ... Cerca di far loro capire che è nel loro miglior interesse mantenerti, e per farti felice dove ti trovi :-) Questo potrebbe darti il ​​potere di negoziare le condizioni di cui sopra e / o richiedere un aumento di stipendio.

Quanto potere di negoziazione hai - questa è una grande domanda. La tua direzione può o meno essere aperta a queste idee e può o meno rispettarti abbastanza per prendere sul serio i tuoi motivi. Ma se giochi bene le tue carte, hai una possibilità. E se rifiutano ... puoi sempre cercare un posto di lavoro migliore. Questa situazione non è la stessa per tutti i principianti, sebbene (purtroppo) le tue esperienze siano abbastanza tipiche. Ma ci sono davvero posti di lavoro migliori là fuori . La qualità del posto di lavoro è solo vagamente correlata alla posizione geografica, ma la mia sensazione è che nel Nord Europa ci siano possibilità superiori alla media. Quindi, se non riesci a migliorare notevolmente le tue condizioni attuali, dovresti iniziare a cercare immediatamente , prima di essere completamente stufo e bruciato.

È immensamente meglio cercare un lavoro mentre ne hai ancora uno, quindi non è necessario accettare la prima offerta solo perché hai bisogno di soldi immediatamente. Alla fine troverai un posto migliore :-)

PS Il mio stipendio è quasi uguale se non inferiore a quello di un cassiere in un supermercato.

Volevo scrivere qualcosa su come negoziare fino a quando non l'ho letto. Ora tutto ciò che posso dire è andarsene! Supponendo che sia la metà di quello che guadagna di solito uno sviluppatore con una laurea. E supponendo che le cose migliorino e che ti diano immediatamente un aumento del 10%, puoi capire quanto tempo ci vuole per arrivarci. Sembra anche che tu non impari nulla sul posto di lavoro e non sembri essere circondato da ingegneri brillanti lì, quindi è una perdita di tempo.

Anch'io mi trovavo in una situazione simile e posso dirti che se rimani su quella pista non finisce mai. La direzione continuerà a spalancarti addosso, perché ... possono.

Ci sono alcuni pensieri aggiuntivi che ho su questo argomento.

1. Fai quello che ti piace. Se non lo ami, preparati a fare il tentativo di trovare ciò che potresti amare.

2. Comunicazione. Comunica chiaramente le tue incapacità di soddisfare aspettative non realistiche. Nella mia esperienza simile l'architetto (che ha fatto il più spalare) ha detto, "devi gestire le aspettative degli altri su di te".

3. Bruciato. Se non hai sperimentato il burnout, non tentare il destino. Ti succhia la vita e l'anima dalla mente. Nonostante il tuo massimo sforzo, il tuo scopo lavorativo diventa grigio, triste e insignificante. Do questo consiglio perché devi, a tutti i costi, evitare il burnout.

4. Formazione. Ecco il rivestimento d'argento. La tua formazione ed esperienza, sebbene frustrante e forse sottopagata, è in effetti molto preziosa per la tua carriera. Questa è la tua grazia salvifica per rendertene conto perché puoi assorbire il più possibile l'apprendimento e ritardare qualsiasi inevitabile soffitto di vetro.

Concentrati su quali talenti e abilità stai sviluppando ... Questi ti porteranno attraverso le prossime opportunità della tua carriera.

Qui hai a che fare con più problemi ... Cominciamo con l'ovvio ...

È normale?

Diavolo, no. Ma ... è comune? Sfortunatamente sì.

Riguardo alla frustrazione per la correzione di bug

Anche se questo non scusa il resto del caos che devi affrontare e i molteplici progetti con cui ti sovraccaricano, voglio solo fare una breve nota che l'approccio "bug-fix" si avvicina, mentre è frustrante per te come sviluppatore , può essere un approccio perfettamente sensato per l'azienda e il suo management.

Superficie per più bug e costi

Più codice tocchi, più è probabile che tu introduca dei bug, anche se il tuo intento è di migliorarlo. Ciò significa tempo di sviluppo, tempo di test e costi prolungati. E se passa a una versione di servizio con un difetto medio-alto, è un gran casino per loro.

Rumore / Nebbia nei tuoi registri

Dal punto di vista SCM, ha anche un senso se lavori direttamente dal ramo di una versione del servizio, poiché desideri avere una visione chiara delle modifiche relative alla correzione di bug. Se ci sono 15 commit con migliaia di modifiche che circondano un bugfix che in realtà ha richiesto forse una modifica del codice di 1 riga, è un po 'fastidioso.

Quindi, essendo un nuovo assunto, è ancora più sensato chiederti di astenersi dal refactoring e / o dal potenziamento del software, e nel mio senso è abbastanza OK essere il più "chirurgico" possibile con le tue correzioni. Tiene a bada il mal di testa.

Puoi farci qualcosa?

Ora, ciò NON significa che ci sarebbero modi per raggiungere sia la sanità mentale del codice sia la sanità mentale delle menti delle persone coinvolte. Essendo junior, dovrebbero chiedere a qualcuno di rivedere le modifiche, in particolare correzioni di bug, e assicurarsi che siano approvate prima di apportare alle build di rilascio del servizio. Ciò impedirebbe o limiterebbe i cambiamenti radicali e sarebbe più sicuro.

Il progetto dall'inferno

Codice di schifezza, branco di programmatori, duplicazione, architettura di schifezze

Ancora una volta, il difensore del diavolo qui, ma sta solo dimostrando che la tua richiesta iniziale contiene alcuni bit non consequenziali.

Il mio punto è questo: davvero molto raramente ho acquisito una base di codice che non era in questo stato. E per caso, ho recentemente avviato progetti o prototipi avviati da programmatori piuttosto stellari. Ma la stragrande maggioranza di loro sembrava una merda, e un numero spaventoso di questi era una vera merda. Anche quelli avviati da programmatori bravi o bravi possono finire per essere cazzate, scadenze e altri impegni che aiutano ...

Benvenuti nell'ingegneria del software industriale nella vita reale!

E sai cos'è divertente? Spesso è molto peggio nel mondo dello sviluppo web. Godere! :)

Troppi progetti e richieste, non abbastanza mani e tempo

Il problema risiede probabilmente qui:

• la tua direzione (forse inconsciamente) abusandoti ,
• i tuoi colleghi (forse inconsciamente) ti abusano ,
• il tuo (forse inconsapevolmente) non ti copre il culo e combatti abbastanza le tue battaglie .

I tuoi manager dovrebbero essere consapevoli del fatto che stai lavorando a troppi progetti da gestire. Se non lo sono, assicurati che siano AL PIÙ PRESTO. Assicurati anche che sappiano che non è stato tutto un pick-nick nel parco e che ti sentivi sotto pressione, e che deve smettere.

Cerca di dare un'occhiata in giro e assicurati che i tuoi colleghi non devino più compiti e progetti su di te, direttamente (dicendo davvero "X sarà in grado di occuparsene") o indirettamente ("Non sono la persona giusta per questo, trova qualcun altro "-> finisce per essere te).

Aneddoto personale qui: ho fatto uno stage qualche anno fa, e proprio nel mio ultimo giorno, quando ho ottenuto la mia valutazione, il mio capo mi ha detto, nonostante fosse molto soddisfatto del mio lavoro in generale, che uno dei dirigenti avesse la sensazione che io avevano scaricato alcuni "compiti non così divertenti" su un altro stagista quando si sarebbero aspettati che li prendessi. Ero mortificato dal sentirli delusi , e all'idea che mi sembrasse di rilassarmi, quando il mio intento era esattamente l'opposto: stavo cercando di afferrare i compiti più difficili e fare in modo che l'altro stagista più giovane trattasse meno capelli problemi di elaborazione. Non mi ero reso conto che, se fossi stato nella sua posizione, sarei stato annoiato dalla mancanza di sfida e probabilmente mi sarei sentito così. Il punto è che devi comunicare per assicurarti che nessuno faccia false assunzioni su 3 cose ben distinte:

• cosa si può fare ,
• ciò che si vuole fare ,
• e cosa sei disposto a fare .

Quindi è anche in parte colpa tua per averlo lasciato diventare così. Ma è normale, è una lezione che tutti devono imparare. Si tiene in due lettere: N - O .

Di solito lo usi come prefisso per una risposta più lunga ma non molto più carica: No, non posso farlo. No, non so come farlo. No, non sono sicuro di essere la persona giusta per questo. No, non l'ho mai fatto.

All'inizio, è molto facile sentirsi come se potessi semplicemente dire "sì, lo farò (eventualmente)", e ammucchiare le cose e farle finire, magari dedicando qualche ora in più. È tutto sbagliato. Devi capire che il tuo tempo è, dopo le tue capacità, la risorsa più preziosa per te e per la tua azienda. Se viene utilizzato in modo improprio, influisce su progetti, scadenze e budget . Così semplice.

Inoltre, sembra un po 'preoccupante che tu abbia troppe persone a cui riferire. È OK avere più clienti con cui avere a che fare, e più proprietari di progetti o anche le principali parti interessate con cui comunicare. Ma, nel complesso, soprattutto perché sei un nuovo assunto, dovresti riferire principalmente a pochi manager (e molto probabilmente solo al tuo diretto manager, e possibilmente a uno sviluppatore principale o senior). Come è andata in questo modo? Non lo so. Può essere un problema organizzativo per la tua azienda o può essere il risultato del tuo favore e del fatto di essere contattato direttamente e di non dire "no". Oppure può essere che il tuo manager diretto abbia problemi con le attività di dispacciamento, per quello che ne so (sto davvero indovinando, ma il modello è riconoscibile e ben noto).

Ti consiglierei di fare piuttosto rapidamente: vai a parlare di persona con il tuo manager diretto, spiega che altri manager potrebbero essere un po 'invadenti o (probabilmente meno lamentosi) che hai troppe cose che si accumulano da troppe persone, e che hai bisogno del suo contributo (e forse anche del loro) per sapere a quali priorità assegnare.

Richieste di modifica a 180 gradi

Questi sono un altro grosso problema. Probabilmente non sono colpa tua, ma puoi provare ad aiutarli a risolverlo.

"Richieste di cambiamento a 180 gradi", come le chiamate in modo bello e preciso, sono un chiaro segnale che i requisiti sono confusi fin dall'inizio , e che nessuno si sforza abbastanza per farli scalpellare e chiarire nel tempo.

Di solito succede quando qualcuno ha bisogno di mettersi al telefono (o meglio, in piedi), afferrare le parti interessate per mano e dire loro chiaramente: "Ecco dove siamo, è dove vuoi che andiamo, confermi che siamo andando nella direzione giusta? ". Va bene non ottenere risposte chiare all'inizio, ma più passa il tempo, più devono diventare chiare o questo progetto è un disastro che attende di accadere.

Di solito direi di prendere tutti gli stakeholder a portata di mano, metterli in una stanza, guidarli attraverso questioni litigiose e cercare in modo incrementale di risolverli - e ottenere priorità mentre ci sei. Tuttavia, nel tuo caso, questa potrebbe non essere già la tua chiamata. Ma dici che ti hanno davvero dato la responsabilità dei progetti; quindi se è davvero così, allora prenditi la responsabilità e fallo. E NON rifuggire dal dire "NON POSSIAMO FARE" , o nemmeno "NON FACCIAMO" . È davvero importante limitare la portata di un progetto.

Se non c'è spazio, non ci sono requisiti precisi al termine della discussione.

Sovraccarico e-mail

Le persone tendono a comportarsi diversamente in base al mezzo di comunicazione che usano. Personalmente, anche se sono una persona piuttosto pacata (e ho lavorato principalmente in paesi stranieri, quindi finisco anche per non farmi piacere parlare troppo al telefono), preferirei in ordine di preferenza basato sulla produttività:

• parlare con le persone faccia a faccia ,
• parlare con le persone al telefono,
• parlare con le persone tramite messaggistica istantanea,
• parlare con le persone via e-mail.

Le e-mail sono utili per il monitoraggio, per ottenere conferme, per l'invio di note.

Per programmare, pianificare e discutere i punti problematici, sono quasi inutili. Bussa alla porta del ragazzo finché non lo apre e siediti con un blocco note e una copia della tua documentazione per chiarire le cose. Al termine, invia un'email e chiedi conferma. Se ritorna con una risposta negativa o un tentativo leggermente nascosto di intrufolare qualcos'altro nella busta, vai di nuovo a prendere d'assedio l'ufficio del tuo interlocutore.

Questa è ingegneria del software. Spesso è più produttivo quando non si digita su una tastiera e può effettivamente ridurre in anticipo le schifezze che dovrai affrontare.

Fare un lavoro di squadra

Stai facendo l'equivalente del lavoro di una squadra? Può essere.

Stai facendo l'equivalente del valore del tuo team di lavoro? Probabilmente no.

Quello che voglio dire è che il tuo team è probabilmente impegnato a lavorare e sei troppo oberato di lavoro. E questo è il problema: sei sovraccarico di cose che dovrebbero essere spinte fuori dalle tempistiche attuali del progetto o date a qualcuno con il tempo a disposizione.

Ero un idiota quando inizialmente mi aspettavo che le cose fossero diverse?

No; appena nuovo alla festa. È come un primo postumo o relazione. Ti passerà.

Immagino che questo post si sia trasformato in un grande rant, ma per favore dimmi che non è lo stesso per tutti gli sviluppatori.

Questo è lo stesso per ogni sviluppatore di organizzazioni caotiche, siano esse startup o giganti affermati, e senza esperienza o fiducia per far muovere le cose un po 'per dare la possibilità di sopravvivere sul lato destro della scala.

PS Il mio stipendio è quasi uguale se non inferiore a quello di un cassiere in un supermercato.

Ho fatto salari decenti per lavori che sembrano scadenti. Non è il numero sull'assegno che conta, è il contesto. Cosa fai, la tua età, dove vivi e lavori, ecc ...

Detto questo, se sei gravemente sottopagato, lavori troppo, e non del tutto junior, vai a chiedere quel rialzo o trova un nuovo lavoro!

È semplice:

• se danno valore a ciò che fai, accetteranno volentieri un rilancio,
• se non lo fanno, il futuro in questa compagnia non sembra molto roseo (almeno per te, che è quello che conta), quindi non sentirti male di andartene.

Tieni presente che chiedere un rilancio è una buona cosa, anche se all'inizio non saresti costretto a pensarlo. Dimostra che tieni traccia di ciò che fai e suggerisce che tieni d'occhio un'altra opzione pur essendo disposto a rimanere a bordo. Ed è una buona cosa abituarsi a richiederli, in quanto sono come colloqui di lavoro o contrattazioni in generale: è qualcosa che richiede pratica e non cadono dal cielo se non li raggiungi da soli. Alcune aziende distribuiranno regolarmente aumenti senza che sia richiesto, ma questo è solo perché sono abbastanza intelligenti da sapere che ti rende mezzo felice e meno disposto a cambiare, e vogliono tagliare l'erba sotto il tuo piede (la maggior parte delle persone si sentirebbe un un po 'a disagio nel sollevare un'offerta di rilancio sono stati offerti direttamente).

Come procedere con questa richiesta è un po 'fuori dallo scopo di QUESTO progetto proprio qui, quindi non entrerò nei dettagli. Ma ti consiglio di preparare un registro dei tuoi ID commit SCM, dei tuoi bug corretti e dei risultati, e di preparare anche rapporti confrontandoli con lo sforzo complessivo del team. Per di qua:

• puoi misurare tu stesso se hai effettivamente fatto molto più dei tuoi coetanei o no,
• puoi resistere se affermano che la tua richiesta non è giustificata.

Oltre ai commenti degli altri:

1. Sì, è normale che a un dipendente entry level vengano assegnati i lavori che nessun altro desidera svolgere.

2. Dovresti vederlo come un elemento fondamentale per la tua futura carriera.

Quindi cosa dovresti fare? Per dimostrarti come sviluppatore professionista devi assicurarti che il tuo lavoro sia strutturato e pianificato, altrimenti potresti trovare difficoltà a basarti sulle cose buone che stai attualmente facendo, quindi dovresti provare a fare cose come le seguenti (se non lo sei già).

1. Registra il tuo lavoro con precisione, per ogni progetto. Quindi, se passi un'ora a correggere un bug sul progetto A, accedi questa volta. Questo sarà utile per mostrare al tuo manager se vuoi discutere di carichi di lavoro.

2. Scrivi unit test. Citi alcuni dei progetti che gestisci sono pieni di bug, quindi suppongo che ci siano pochi (se presenti) test unitari. Per ogni segnalazione di bug, scrivere un test unitario che replica il bug, quindi correggere il bug. Ciò contribuirà a garantire che non si verifichino regressioni, a migliorare la qualità del codice e a fungere da piattaforma su cui riformattare il codice se ti viene data la possibilità (ad esempio, potrebbe aiutarti a convincere le parti interessate che riscrivere alcune parti potrebbe migliorare qualità senza introdurre nuovi bug, grazie alla suite di test unitari).

3. Cerca un nuovo lavoro: lavori su molti progetti contemporaneamente, hai scritto codice da zero e probabilmente hai sperimentato l'intero ciclo di vita del progetto: queste sono tutte buone esperienze da applicare altrove.

La tua situazione è un po 'spigolosa, ma ancora normale. Ma il modo in cui lo gestisci è pessimo. Ecco cosa devi fare:

• Cerca di affrontare il tuo capo. Dovresti avere delle prove (numeri) di quanto tempo effettivamente costa la base di codici errati. Se non capisce cose come il debito tecnico, smetti di menzionarlo. Ti rovinerebbe la testa e potresti essere contrassegnato come un "cattivo atteggiamento". Non è compito tuo insegnare al tuo capo a fare il suo lavoro.

• Mantieni il tuo backlog (kanban). Quando arrivano nuove attività, mettilo alla fine e indica il tempo stimato di completamento.

• Aumenta i tempi di risposta, controlla la tua email solo due volte al giorno. In genere prima di pranzo e poco prima di partire. (Il controllo dell'email non dovrebbe essere seguito dalla codifica, poiché potrebbe rovinarti la testa).

• Apporta piccoli miglioramenti al codice come parte di ogni attività. È semplicemente tuo compito migliorare il codice, le competenze e gli strumenti che stai utilizzando. Aumenterà anche la tua morale a lungo termine.

• Nessun cambio di progetto durante il giorno. Oggi stai semplicemente lavorando al progetto X e domani inizierai altre attività per Y.

• Assegna un'ora al giorno per il mantenimento del cancello. Significa piccoli compiti che sono banali da fare. Se questa attività richiede più di 10 minuti (non importa quale sia il motivo), va nel backlog e si comunica al gestore che sarà ritardato.

Ora arriva la parte difficile. Attualmente i manager non comunicano tra loro e presumono che finirai il loro progetto con la massima priorità. Questo porta molto stress in testa, perché sei nel mezzo di discussioni. Devi forzare i manager a iniziare a coordinare il tuo lavoro. Alla fine dovresti avere un backlog carino e semplice e i manager dovrebbero fare il prepotente a vicenda senza di te.

Facciamo un semplice gioco di ruolo. Esistono tre manager e progetti (Xavier con il progetto X, Yvonne con il progetto Y e Zed con il progetto Z). Hai un arretrato di due settimane, 5 giorni per X e 5 giorni per Y.

• Z ti chiede di svolgere alcune attività (1 giorno)
• Tu rispondi che sarà fatto in 11 giorni.
• Z risponde che è un compito semplice e non dovrebbe richiedere più di un giorno (notare che Z applica una leggera pressione).
• Hai risposto che al momento stai lavorando per X e quest'ultimo per Z. Dopo puoi fare il suo lavoro.
• Z risponde che dovresti svolgere immediatamente il suo compito (aumento della pressione, violazione diretta del territorio X e Y).
• Rispondete che svolgere il suo compito ritarderebbe il lavoro per X e Y. Dovrebbe prima chiedere loro. Hai anche CC X e Y.

Ora ci sono due estremità:

• I manager inizieranno ad abbaiare a vicenda, molte e-mail, probabilmente alcune riunioni ... Dovresti stare lontano e lasciare che il vincitore ti assegni un compito.

• Non succederà nulla, Z ti chiederà due giorni dopo dove si trova il suo compito. Hai risposto che stai lavorando per X attualmente, e non ha menzionato nulla sul progetto Z. Ancora una volta CC X.

Ora questo tipo di comportamento può farti licenziare. Ma la tua situazione è insostenibile e probabilmente abbandonerai presto comunque. Questa soluzione funziona solo se i manager sono in competizione l'uno con l'altro (molto normale). Dovresti anche tenere una documentazione del tuo lavoro (arretrato), nel caso qualcuno si lamenti, che stai rilassando.

Sette anni fa stavo facendo un po 'di manutenzione al 100% per un po' e ho scritto un articolo al riguardo: The Art of Maintenance Programming . Una parte che potresti trovare utile:

1. Mi piace

Come può qualcuno piacere programmare la manutenzione? Gli sviluppatori sognano di essere i principali architetti nei loro team e quando finiscono per mantenere il software esistente, sembra quasi una punizione. Non deve essere così: la programmazione della manutenzione ha le sue sfide e richiede molta creatività, adattabilità, pazienza, disciplina e buona comunicazione. Può essere positivo anche per la tua carriera: avere voci burrascose come "Applicazione enterprise 24 ore su 24, 7 giorni su 7" nel tuo curriculum sembra carino, ma i datori di lavoro apprezzano davvero le persone che risolvono i problemi; e la programmazione della manutenzione può essere una buona occasione per dimostrare le tue capacità di problem solving.

Il tuo problema suona come il sommething di cui ascolti più spesso. Sembra essere un lavoro che potrebbe facilmente adattarsi a The Daily WTF .

Molte organizzazioni si concentrano più sulle vendite o sulle funzionalità che sulla qualità. Quello che quelle aziende non riescono a vedere è che ci sono più delle qualità esterne di un software. Ward Cunningham ha coniato il termine debito tecnico .

Potresti anche voler leggere Steve McConnell sul debito tecnico . Ha alcuni punti interessanti. In un Google Tech Talk, Ken Swaber parla dello sviluppo di software agile . Una buona parte riguarda una storia simile alla tua. Parla di un progetto software diventato "braindead" dopo 10 anni di programmazione da vari programmatori senza mai effettuare alcun refactoring . Penso che se vedi questo video vedrai molte somiglianze con ciò che descrivi.

Qualsiasi sistema software peggiorerà in termini di qualità quando viene espanso. In effetti per sopravvivere dovrà. Le leggi di Lehman spiegano abbastanza bene questo principio. Alla fine si riduce alla seguente domanda: "Come posso convincere il tuo capo a fare refactoring?" .

Come ho affrontato un problema simile:

• Ho affrontato il mio capo e ho spiegato che la qualità del codice peggiora quando continuiamo a svilupparci ( Lehman Laws ).
• Ho cercato di spiegare al mio capo il concetto di debito tecnico . E che il modo in cui ti lascia lavorare è un modo che gli costerà denaro a lungo termine.
• Al fine di mostrargli quanto fosse grave il problema, ho (ai miei tempi) fatto un'analisi del codice statico. I boss non capiscono il software, ma capiscono i numeri. Sebbene le metriche del codice abbiano i loro difetti , è bene avere qualcosa di misurabile di cui puoi parlare. Prova a scoprire quali sono le letture normali per queste metriche e rimarrai sorpreso quando lo confronti con la tua base di codice.
• Se nulla aiuta e nulla cambia, l'unica cosa che puoi fare è spiegare che una certa nuova funzionalità richiederà una rielaborazione di altre parti della tua base di codice. Spiega che se hai un codice duplicato e vogliono cambiare qualcosa che anche i costi di una modifica duplicano.
• Una risposta comune al punto precedente sarà che nessuno ha chiesto e quindi non pagato per questa rielaborazione. Che "forse" questa rielaborazione è superflua. Dovrai spiegare che il software dovrà sempre cambiare. Come dicono le leggi di Lehman ; dovrà cambiare per rimanere in uso. Altrimenti, altri programmi che sono cambiati sopravvivranno sempre. Sono quelli che si aspettano il cambiamento e possono adattarsi al cambiamento che sopravviverà. Questo è lo sviluppo agile del software . ( Wikipedia )

Il mio capo oggi usa il concetto di debito tecnico per spiegare ai nostri clienti che a volte abbiamo bisogno di rielaborare parti del software che costruiamo. Solo per dimostrarlo: se hai un capo ragionevole, è possibile cambiare le cose in meglio.

La situazione che stai affrontando è quasi (se non del tutto) la stessa per molte matricole.

Questo succede nelle fasi iniziali di una carriera. Ecco il problema: dobbiamo superare questo problema e dimostrare il nostro valore per l'azienda (sia essa di medie dimensioni o MNC ). Dovremmo essere in grado di prendere decisioni su ciò che le circostanze ci richiedono di fare. Quindi non c'è nulla di male nel mettere gli sforzi nel lavoro, a patto che vieni notato per questo e rimani come un individuo per il tuo lavoro. Se vali, la compagnia noterà! Adios e buona fortuna.

A mio avviso, una società che vieta il refactoring non vale la pena lavorare. Refactoring è una capacità essenziale di sviluppo del software, e gli strumenti di controllo delle versioni rendono molto facile per sviluppare i cambiamenti in isolamento, senza danneggiare il 'tronco' (nel caso in cui un refactoring in realtà fa rompere qualcosa). Come dice lo zio Bob (parafrasato): "Non dovresti chiedere di essere un professionista e fare bene il tuo lavoro".

La programmazione della manutenzione non dovrebbe mai significare perpetuare un codice errato.

Ho ricevuto questa email cinque anni fa da un mio amico.

Email body:    

Un ingegnere apprendista appena iscritto chiede al suo capo "qual è il significato della valutazione?"

Capo: "Conosci il significato di dimissioni?"

Apprendista: "Sì, lo faccio"

Boss: "Quindi lascia che ti faccia capire cos'è una valutazione confrontandola con le dimissioni"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Apprendista: "Sì, capo abbastanza, ora ho capito il mio futuro. Per una valutazione dovrò dimettermi ... !!!"

Se fossi in te, passerei alcune ore tardi dopo il lavoro a ricostruire l'applicazione gratuitamente. Probabilmente sarebbe un compito divertente. Quando lo finisci, mostralo al tuo capo. Se funziona e stai facendo manutenzione, non dovrebbe avere nulla di cui preoccuparsi. Ciò renderà il tuo lavoro molto più semplice e aprirà gli occhi ai rialzi del tuo potenziale in azienda.

Sono uno studente universitario a tempo pieno che lavora per uno stage part-time per US $ 10 l'ora. Faccio cose di QA che sono noiose, ripetitive e facili. Mi considero estremamente fortunato, perché so che un giorno questo aprirà le porte a luoghi più grandi e migliori.

Sì, dovrai sempre conservare le domande, scritte sia da te che da altre persone. L'unica eccezione è se si scrive un programma che non ha mai bisogno di manutenzione. Quindi farai meglio ad essere in manutenzione.

Penso che ci sia un sottile suggerimento nella tua domanda di un difetto nel tuo approccio. Cioè, che la correzione di bug non comporta il miglioramento del codice.

Ma poi ho saputo che non mi era permesso di migliorare il codice esistente e di concentrarmi solo su correzioni di bug quando veniva segnalato un bug.

Non posso credere che qualcuno ti abbia detto "devi correggere i bug senza migliorare il codice". Questo è sia difficile che impossibile. Quello che non puoi fare è riscrivere l'applicazione solo perché non ti piace o trovi difficile comprendere l'approccio utilizzato nella base di codice esistente.

Il mio consiglio è di imparare a refactor. Ogni volta che correggi un bug, hai l'opportunità di migliorare almeno parte del codice. La quantità di codice che viene refactored dipende da quale sia il bug e da quanto sia buono o cattivo il codice. Ma se stai risolvendo bug e lasciando consapevolmente odori di codice in tutto il luogo, allora non stai facendo il tuo lavoro e stai accumulando debito tecnico .

Alcuni bug vengono corretti semplicemente mediante refactoring e talvolta è utile fare il refactoring per aiutarti a capire il codice . Questo perché il refactoring dovrebbe migliorare la manutenibilità e la coerenza del codice.

Quando stimerò una correzione di bug, di solito prenderò una decisione sul fatto che un importante refactor sia il modo migliore per farlo, e lo terrò in considerazione. Lo stesso con i test unitari. Entrambe queste cose dovrebbero far parte del modo in cui scrivi il codice, non qualcosa di facoltativo che comporta tempi supplementari.

Quindi non dovresti chiedere "posso migliorare il codice quando correggo il bug?" Perché dovresti esserlo comunque. Non dovresti chiedere "posso usare il refactoring per correggere il bug?" Perché se il codice che sta causando il bug dell'applicazione ha un disperato bisogno di refactoring, dovresti farlo comunque. Non dovresti chiedere "posso scrivere unit test quando correggo questo bug?" Perché dovresti scrivere un test di regressione prima ancora di iniziare a provare a correggere il bug.

NB: Sento che l'attribuzione per questa risposta dovrebbe andare a Jeff Atwood, visto che ho collegato 3 dei suoi articoli.

Questo riguarda i soldi. La mia ipotesi è che come antipasto, probabilmente sei troppo gentile per i clienti che hanno già ottenuto più di quanto hanno pagato.

Impara a quotare un prezzo per nuove richieste. Questo è tutt'altro che facile e spesso i clienti ti provano. Se puoi, richiedi l'aiuto di un project manager / product manager esperto.

Una volta che pensi in termini di denaro, comunicare con il management diventa molto più semplice. Se i tuoi attuali clienti forniscono denaro a tempo pieno, non dovresti raccogliere nuovi progetti. Ma capirai che la direzione proverà comunque a costringerti a farti del male.

Se sei davvero prezioso per l'azienda, otterrai potere contrattuale. Puoi chiedere loro di assumere più persone, ottenere meno nuovi progetti, aiutarti a ridurre il carico di manutenzione o aumentare il tuo stipendio.

Non dovrebbe essere la decisione del datore di lavoro di microgestire l'utente nella misura in cui è vietato migliorare il codice esistente. Usa il tuo giudizio professionale. Quando si sta valutando il lavoro, aggiungerei tempo aggiuntivo per consentire un certo refactoring, se aumenterà la produttività in futuro.

Ad ogni modo, sembra che tu non stia comunicando efficacemente con il tuo datore di lavoro.

1. Hai prove che il refactoring farà risparmiare denaro. Redigere una proposta per un progetto di refactoring e dimostrare quanto tempo e denaro l'azienda potrebbe risparmiare. Descrivi esattamente quali modifiche faresti al codice e quanto tempo impiegheresti.

2. Tieni un registro accurato per registrare quanto tempo dedichi a scrivere codice, riunioni e rispondere alle e-mail. Questo ti proteggerà in caso di ritardo.

3. Rallenta. Questo può sembrare un po 'intuitivo, ma il tuo tempo verrà abusato solo se fai tutto rapidamente. Le persone rispetteranno di più il tuo tempo se fai di meno. Ad esempio, vorrei controllare la posta elettronica solo una o due volte al giorno. Altrimenti, si rischia il burnout.

4. Considerando il tuo tasso di pagamento, non vale la pena avere mal di testa. Assicurati di partire in orario ogni giorno. Non dedicare ore extra senza compenso aggiuntivo. L'eccezione è se ci sono buone opzioni di avanzamento o se la reputazione dell'azienda aumenterà notevolmente il tuo curriculum, dovrai solo succhiarlo.

Senza saperne di più, suggerirei solo di provare ad essere più aperto con i tuoi manager. Forse iniziare ad aumentare le stime delle attività. Ricorda loro costantemente quanto è occupato il tuo carico di lavoro. Inoltre, dovresti incontrare il tuo capo e spiegare che vorresti un aumento di stipendio entro i prossimi sei mesi e chiedere come potresti migliorare le tue prestazioni al fine di ottenere questo aumento di stipendio.

In bocca al lupo.

Nella mia esperienza, il mondo accademico o i primi 6-12 mesi di una start-up tecnologica sono le uniche due aree affidabili in cui ti imbatterai in una vera tabula rasa. Entrambi comportano le proprie spese, ma se ti piace programmare e spesso sei inorridito dalla qualità del codice che scopri in natura, dovresti iniziare a orientare la tua carriera in una di queste direzioni.

Prova a parlare con i tuoi datori di lavoro e vedi se riesci a risolverlo. Sembra che tu sia sopra la testa per questo, e non ha nulla a che fare con l'essere un cattivo programmatore.

Le aziende Web più piccole tendono ad avere molti progetti in corso allo stesso tempo, il che in molti modi ti lascia in un posto. O cerca di sfruttare al meglio la tua situazione o cerca di trovare un nuovo lavoro se pensi di poterlo fare. Prometto che ci sono lavori di codifica migliori là fuori, quindi non lasciare che questo primo ti spaventi.

Buona fortuna e spero che sia tu che i tuoi collaboratori comprendiate la gravità o i vostri sforzi!

Esperienza personale

Come molti qui riconosco anche la tua situazione. Fondamentalmente ho ottenuto il mio primo lavoro di programmazione con un basso stipendio e ho dovuto mantenere un sacco di codice costruito con una struttura scadente. All'inizio ho trovato divertente imparare cose nuove, ma quando alla fine avevo molti progetti da mantenere, nuovi progetti da realizzare e una lavagna bianca che cresceva ogni giorno di più con punti su cui non avevo ancora finito, mi sono reso conto che non funzionava.

Dopo averlo sopportato per due anni, ho lasciato e ho trovato un altro lavoro di programmazione un paio di mesi dopo che mi si adatta perfettamente.

Ad ogni modo, molte volte non sono solo i tuoi progetti a costituire il problema. Mi trovo più a mio agio sul posto di lavoro quando ricevo il riconoscimento e il rispetto per il mio lavoro. Il problema con la situazione in cui ti trovi è che i tuoi datori di lavoro potrebbero notare solo i bug derivanti dai progetti creati e non il tempo impiegato per rimuovere tutti gli altri bug.

Stipendio

Se vuoi più soldi, puoi spesso ottenerli. Sono riuscito a negoziare il mio stipendio in meno di due anni con un aumento del 33%.

Fondamentalmente, pensa al valore del tuo lavoro e a quanto l'azienda ha bisogno di te. Se non possono permettersi di darti lo stipendio che hai guadagnato, allora l'azienda deve esaminare le loro spese o rendersi conto che la loro attività non funziona.

E come indicato da molti qui, e sono d'accordo, sei un pezzo molto prezioso del puzzle dell'azienda. Diavolo, probabilmente sei l'unico in grado di risolvere quel puzzle. :)

Dal momento che non posso ancora commentare perché sono in agguato in questo sito di scambio di stack, aggiungerò semplicemente alle informazioni qui.

1. Dal momento che hai appena iniziato, il tuo stipendio non sarà stellare a meno che tu non sia andato a lavorare per una grande azienda come Microsoft, Amazon o qualcosa di simile. Ma non dovrebbe essere quello di un impiegato della drogheria! Non tollerarlo a lungo, acquisisci esperienza facendo ciò che stai facendo e vai avanti quando si presenta un'opportunità migliore.

2. Per un concerto entry level questo è un po 'normale. Il carico di lavoro è troppo elevato, ma è previsto il tipo di lavoro. Per diventare uno sviluppatore migliore devi imparare dagli errori degli altri. Più vedi, meglio diventi. Ma questo implica che stai cercando cose da cui imparare, non imparare cattive abitudini ...

3. Il rapporto tra manutenzione e lavori di progetto dovrebbe cambiare nel tempo. In caso contrario, ciò significa che l'azienda per cui lavori non si rende conto di come mantenere un buon sviluppatore; hanno intenzione di farti fare la stessa cosa giorno dopo giorno. Fai un obiettivo annuale per te stesso su dove ti piacerebbe essere, stipendio e aspettative di lavoro sagge e spostati di conseguenza.

4) Se non sei felice, vattene! La vita è troppo breve per trattare con persone stupide.

Ti auguro il meglio.

Inizi a utilizzare un tracker di problemi per tenere traccia dell'elenco delle cose da fare.

Questo non solo ti aiuterà a tenere traccia di ciò che è critico, ma aiuterà gli utenti e il tuo capo a vedere qual è il tuo carico di lavoro attuale.

Inoltre, se dovessero mai assumere un secondo sviluppatore (o se esci e il tuo sostituto ora occupa il tuo carico di lavoro) questo ti aiuterà a gestire il carico di lavoro e sarai in grado di evitare di calpestare le dita dei piedi.

L'unico modo per spezzare questa catena è sviluppare nuove infrastrutture progettate per la flessibilità e testate per unità completa + integrazione.

Se riesci a venderlo alla direzione (firma altri sviluppatori e gestori al concetto in riunioni 1: 1), puoi lentamente raggiungere uno stato, in cui la maggior parte del codice delle applicazioni è nell'infrastruttura ed è facile espandere e mantenere, mentre le applicazioni attuali sono leggere e possono essere scritte abbastanza rapidamente.

Lo sviluppo dell'infrastruttura può consentire inizialmente di sostituire parti di applicazioni esistenti e dopo un po '(potrebbe richiedere alcuni anni) sostituire intere applicazioni.

A lungo termine può ridurre drasticamente i tempi di sviluppo di nuove applicazioni e i tempi di manutenzione di future applicazioni esistenti.

Il nuovo sviluppo richiederà almeno l'80% di dedizione (preferibilmente di più) con un team composto da più di uno sviluppatore (alcune menti sono meglio di una). Tutti gli sviluppatori dovranno essere in grado di pensare in modo creativo e infrangere i preconcetti esistenti.

Prova a definire e progettare ad alto livello una nuova infrastruttura, quindi presenta la definizione ai tuoi colleghi e al management.

In base alle tue condizioni di lavoro, chiedi di guidare un nuovo team di infrastrutture che si occupi di questi problemi (in base alle tue definizioni e al tuo design) e di attirare nuovi sviluppatori per mantenere le vecchie cose mentre le assisti se necessario (fino al 10-20% di il tempo). Se la direzione accetta l'idea, puoi chiedere di rinegoziare i termini. Preparati a trovare un altro lavoro se si rifiutano. (Ricorda, il tuo lavoro richiede abilità, conoscenza ed esperienza, non sei facile da sostituire come ti stanno pagando per credere.)

Il tuo manager è a conoscenza di tutte queste richieste di modifica (richieste di manutenzione)? Si rende conto che il tuo tempo è passato a vagliare tali richieste che non hai l'autorità per sanzionare? O apporti modifiche ogni volta che un manager ti chiede?

Mi sembra che il tuo primo approdo sia quello di mettere tutto sulla scrivania del tuo manager. Nessuno dovrebbe venire da te direttamente. I problemi dovrebbero sorgere attraverso chiunque si occupi di questo, di solito un team di supporto. È normale supportare il codice per un breve periodo di consegna, di solito una settimana circa. Le modifiche dovrebbero essere costate e addebitate (trasferimento di addebito) in qualsiasi azienda che si classificherebbe come "media", e questo sembra essere ignorato (non c'è da meravigliarsi che ti stiano invadendo - sei come la troia al ballo).

Dovrebbe esserci una procedura di richiesta adeguata sia per sollevare problemi che per richieste di modifica. Il supporto / manutenzione riguarda la correzione di bug e problemi (che si adattano alle specifiche originali, ma falliscono a causa di un bug nel codice o di un evento esterno, come un sistema di spegnimento o corruzione a monte, ecc.).

Se la tua azienda non offre nulla di tutto ciò e si aspetta che tu faccia fronte e sia responsabile di questa miriade di richieste casuali, allora seriamente devi considerare di andare avanti. La retribuzione è sempre scarsa in fondo - nel mio primo lavoro di programmazione (quasi 25 anni fa) ho trascorso 8 anni per la stessa azienda e la mia retribuzione è aumentata poco (anche se era sempre molto più alta di una cassa!). Entro 2 anni dalla mia partenza l'avevo raddoppiato - e due anni dopo stavo portando a casa oltre dieci volte quello in cui avevo iniziato (ma allora ero un imprenditore indipendente). Come sempre, guadagna speroni, impara il tuo mestiere e salta la nave in un ambiente più caldo.

Forse sei in grado di andare da un manager e dire: "Guarda, sarò sincero con te. La mia paga è terribile, potrei ottenere N volte questo come programmatore entry level in X.

Sto facendo troppe cose con A, B e C. Non posso mantenerlo. Onestamente, e senza alcuna offesa, uscirò da questa stanza con questo o fisso o con la mia lettera di dimissioni lasciata con te. Ora che tutto è nell'aria, come possiamo lavorare insieme per farlo bene? "

La risposta è cercare di spiegarlo in termini comprensibili;

• È come il cambio dell'olio. Non sono urgenti .... ma devono essere fatti regolarmente comunque
• dipingi sulla ruggine e sembrerà grandioso. Fino a quando non sanguina
• costruire una nuova scrivania da tetto sul tetto senza rinforzi. Funzionerà per un po 'forse. Quindi crollerà e farà del male alle persone e sarai responsabile.
• a / c è fantastico. Un'unità finestra è ottima per una o due stanze. Cercando di mettere 146 condizionatori unità finestra in un condominio e avrai ... problemi.
• Insegnare 5 bambini va bene. 10 non è poi così male. Ma ci sono dei limiti. Prova a insegnare in modo informale a 75 bambini e vedrai questo.

Se questi non stanno risuonando. Lasciare - IL GIORNO CHE OTTIENI UN'OFFERTA SULLA SCRITTURA, non il giorno successivo! Una volta che AVETE un nuovo lavoro, andate via con ZERO preavviso. Letteralmente non venire in quel giorno. Ma assicurati di avere un collega o due che sanno cosa hai fatto. Questo aiuterà effettivamente l'azienda, se la società può essere aiutata, mostrando loro che la loro mancanza di rispetto e arroganza hanno un prezzo. L'ultima compagnia ero a TRE DEI QUATTRO TECNOLOGICI A SINISTRA ENTRO 6 MESI SENZA LAVORO. Almeno ha fatto una dichiarazione e ha dato alla persona che se ne andava una volta una buona occasione per dire: "Sì, bello bs che dici ogni giorno ma ne sei così pieno, non ti sto nemmeno dando la soddisfazione del mio avviso.

Infine, sappi che questa serie di affari era la NORM e lo standard 20 anni fa prima che agile, tdd, bdd e refactoring diventassero più che normali. Potresti parlare con persone anziane che rispondono immediatamente "bene, l'ho fatto anch'io e ha funzionato bene, blah, blah, blah". Bene, sicuramente cavalli e carrozze funzionarono bene 150 anni fa. Nelle aree tecnologiche, le tecniche di 20 anni fa sono obsolete quanto il trasporto di 150 anni fa. Se rifiutano questa multa. Sappi solo che non assumeranno mai sviluppatori di tecnologia decente che rimarranno. Avranno il peggio del peggio e danneggeranno terribilmente i loro affari. Se dipendono dalla tecnologia e non riescono ad adattarsi, falliranno e alla fine potrebbe essere la migliore ricompensa per te. E'

Sembra che la tua direzione fondamentalmente non ti rispetti né capisca il tuo carico di lavoro.

Non dovresti implementare tutte le richieste di funzionalità che arrivano. Il tuo manager dovrebbe fungere da buffer tra te e le richieste in arrivo (tranne forse le più semplici richieste di interruzione / correzione). Quindi lui o lei dovrebbe sedersi con te e determinare la fattibilità e la priorità per qualsiasi richiesta approvata.

Inoltre, dovresti probabilmente fare 2x (almeno) quello che ti stanno pagando.

Sembra che probabilmente abbiano davvero bisogno di almeno un altro sviluppatore per lavorare al tuo fianco, ma con quello che ti stanno pagando sembra abbastanza improbabile.

Se non sono disposti a pagarti adeguatamente o a aiutarti a gestire il tuo carico di lavoro, sarei alla ricerca di un nuovo lavoro. Vuoi lavorare in un posto in cui fai parte di un team e in cui la tua direzione lavora con te per completare i tuoi progetti. Scendi da quella nave che affonda non appena puoi.

Essere un eroe in una squadra ti brucerà.

Sono solo uno studente (ancora) ma è abbastanza normale (dalla mia esperienza di tirocinio). Questo è ciò che ottieni quando lavori in applicazioni di supporto e web.

Ti consiglierei di capire cosa vuole il cliente (gestore) prima di iniziare a scrivere codice. Potrebbe essere complicato perché a volte non lo sanno da soli, quindi lavora con loro fino a quando non saranno d'accordo su qualcosa. Assicurati di essere entrambi d'accordo sulla soluzione finale prima di codificarla.

Inoltre, se sei un manutentore puoi praticamente cambiare qualsiasi cosa nel codice - assicurati solo che non cambi il comportamento o introduca dei bug. Mi aspetto che i manager non ti "consentano" di cambiare nulla perché sono abituati e contenti di come sono adesso e non vogliono pagare per eventuali nuove modifiche.

Infine, non preoccuparti se non riesci a gestire qualcosa perché stai facendo qualcos'altro. Ti consiglierei di far sapere alle persone che sei sopraffatto dal lavoro e che la loro richiesta richiederà tempo. Se non lo fai i manager penserebbero solo che sei pigro. Fai loro sapere che hai già un lavoro e che potrebbero assumere più persone. Non c'è altro modo per loro di sapere che il lavoro è troppo per una sola persona.

Questo è un problema di gestione del progetto. Usa un qualche tipo di gestione del progetto per decidere quale sia la massima priorità su cui lavorare.

a) È necessario un backlog di elementi su cui lavorare. Metti il ​​tuo piano per migliorare il codice nel backlog.

b) Tutti i bug vanno nel backlog

c) Il backlog ha la priorità.

d) Fai tutto in ordine di priorità.

I bug possono benissimo essere una priorità più alta, ma se una volta risolti tutto ciò che hai, hai dei cicli da spendere in nuove funzionalità o nel design del refactoring.

È più semplice se si eseguono semplicemente i miglioramenti del refactoring in modo incrementale, poiché si passano sopra sezioni che presentano problemi / bug da correggere. Quindi puoi dire al management: "Ho dovuto riparare A, ma B era fondamentalmente rotto e ho dovuto fare la soluzione C per risolvere tutto in modo che D fosse più facile / economico in futuro" Dove A = Il bug, B = Il anti-pattern, C = Soluzione, D = Guadagni futuri

Se non riesci a giustificare il lavoro come investimento che vale la pena fare, gli uomini d'affari non lo accetteranno mai.

Questi sono affari come al solito. Sembrerà essere sfruttato finché continuerai a lavorare lì. È nell'interesse dell'azienda continuare a seguire questo modello piuttosto che farti sentire felice in quello che stai facendo. Quando si tratta di esso, a loro non importa davvero. Si tratta di creare un codice affidabile per loro e se sei una one-man-band, sicuramente ti stanno facendo banca. Perché dovrebbero cambiare?

La buona notizia in tutto questo è che sei un VIP per loro anche se non lo sanno. Quello che suggerisco di fare è allineare alcune altre opportunità prima di saltare la nave, quindi afferrarle per le palle e richiedere uno stipendio più alto. In caso contrario, passare a un'opportunità migliore. Secondo me, dovresti trovare presto un lavoro più eccitante. Punta più in alto che puoi. Una volta arrivato in un negozio per sviluppatori, sarai molto più felice come Google o qualche startup divertente in cui esiste una cultura collaborativa per sviluppatori in cui ti sentirai davvero felice.

Quello che ho fatto personalmente è stato quello di utilizzare un'organizzazione di appaltatori di cacciatori di teste e ho rapidamente ottenuto molte esperienze straordinarie, passando da una all'altra mantenendo comunque un impiego stabile dal mio appaltatore. Ti impedisce di annoiarti e ti sfida. Alla fine, nel mio tempo libero, ho creato alcune piccole imprese che sono sbocciate in affari reali, e poi ho saltato la nave dal lavoro a contratto.