I pericoli di implicito

Questo articolo è una reazione alla "disimparare, programmatore Young" articolo che ho letto l'altro giorno.

Sarebbe meglio se si sarebbe voluto del tempo di leggerlo prima, ma per il tipo pigro (di quelli che ho sono una parte), ecco un breve curriculum. L'autore sembra essere uno sviluppatore di software esperto. Egli fa l'osservazione che quando lui altri compiti sviluppatori junior per fare alcune cose, i risultati spesso non sono quello che si aspettava. Al fine di illustrare il suo punto, prende l'esempio di dover appendere un quadro. Devo ammettere che gli esempi sono molto divertente e parla molto con me. Tuttavia, alla fine, la conclusione è che gli sviluppatori giovani devono fare domande, punto.

Assumersi la responsabilità

Come architetto gestione sviluppatori dalla mia torre d'avorio (leggi: non avere abbastanza tempo per istruire loro), succede che io non sono soddisfatto dei risultati. Non so se si tratta di un tratto proveniente da età, cultura, paese o quant'altro, ma la prima domanda che mi pongo è quello che non ha fornito il mio committente non lo avrebbe potuto raggiungere i risultati che volevo. Questo non è perché io sono modesto o non sicuro, ma perché c'è una regola che si può solo cambiare voi stessi , il resto spetta agli altri. Pertanto, non è allo sviluppatore farti domande (anche se sarebbe più comodo per la maggior parte di noi), ma a voi per dare loro il maggior numero informazioni utili relative al loro lavoro. Mettere la responsabilità sviluppatori è troppo comune un difetto nella gestione visto che dovremmo cercare di non farlo noi stessi.

Il pericolo di implicita

Il mio secondo pensiero è per il divario tra ciò che viene chiesto e ciò che è implicito, perché ci si trova il più grande problema. Come un esempio tratto dalla vita reale, sei mesi fa, ho avuto un incidente in moto in un paese straniero (con la polizia e l'ambulanza e l'intero spettacolo, ma non avevo ferite, anche se ero un po 'scosso). La mia moto è stata gravemente danneggiata in modo che doveva essere rimossa. Il camionista mi ha dato il suo biglietto, e ho assunto ha guidato la mia moto al suo garage, perché è così che funziona nel mio paese. Purtroppo, questo non era il caso: ho solo capito quando ho ricevuto la notifica che la mia moto è stata sequestrata ed è stata destinata ad essere distrutta per decreto, se non avessi fatto nulla.

Quante volte queste cose accadono nella vita (con conseguenze meno drammatiche)? Non appena si trovi di fronte ad un paese straniero cultura / che sembra simile in superficie, ci sono molte possibilità per implicito a insinuarsi attraverso. implicita è molto peggiore dell'ignoranza : quando non sai, non comporterà anyhting e la maggior parte di utilizzo sarà molta attenzione su di esso. Per lo sviluppo del software, questo significa che può essere meglio avere un Business Analyst che non ha conoscenza del dominio aziendale. Lui / lei probabilmente scavare in profondità in ogni angolo compaired ad un BA che ha una conoscenza di un dominio analoga, sia perché quest'ultimo farà ipotesi. Data la legge di Murphy, che probabilmente sarà presupposti falsi, portando così a conseguenze disastrose fase successiva del progetto.

Conclusione

Anche se posso essere d'accordo con gli esempi grafici molto l'articolo di riferimento, sono assolutamente d'accordo con la conclusione. Ingegneri del software senior dovrebbe essere il più esplicito possibile nel dare compiti a quelle più giovani. Anche se ho avuto la migliore esperienza di lavoro con i programmatori che si avvicinò con domande, non sono tutti così, nonostante noi di dover avere successo in ogni progetto.

Corso Java - Corsi Java - Corsi programmazione Java

 Corso programmazione Android - Certificazione Android