Techleder Skyeng Kirill Rogovoy () fai unha presentación en conferencias nas que fala das habilidades que todo bo desenvolvedor debe desenvolver para converterse no mellor. Pedinlle que compartise esta historia cos lectores de Habra, cedo a palabra a Kirill.
O mito sobre un bo desenvolvedor é que:
- Escribe código limpo
- Coñece moitas tecnoloxías
- Tarefas de codificación máis rápido
- Coñece unha morea de algoritmos e patróns de deseño
- Pode refactorizar calquera código usando Clean Code
- Non perde o tempo en tarefas que non sexan de programación
- 100% mestre da túa tecnoloxía favorita
Así é como RH ve aos candidatos ideais e as vacantes, en consecuencia, tamén se ven así.
Pero a miña experiencia di que isto non é moi certo.
En primeiro lugar, dúas importantes exencións de responsabilidade:
1) a miña experiencia son equipos de produtos, é dicir. empresas con produto propio, non subcontratación; na subcontratación todo pode ser moi diferente;
2) se es un junior, entón non todos os consellos serán aplicables, e se eu fose ti, concentraríame na programación por agora.
Bo desenvolvedor: realidade
1: Código mellor que a media
Un bo desenvolvedor sabe como crear unha arquitectura xenial, escribir código xenial e non facer demasiados erros; En xeral, fai mellor que a media, pero non está no primeiro 1% dos especialistas. A maioría dos desenvolvedores máis xeniais que coñezo non son tan grandes programadores: son xeniais no que fan, pero non poden facer nada extraordinario.
2: Resolve problemas en lugar de crealos
Imaxinemos que necesitamos integrar no proxecto un servizo externo. Recibimos as especificacións técnicas, miramos a documentación, vemos que algo está desactualizado alí, entendemos que hai que pasar parámetros adicionais, facer algúns axustes, tentar implementalo todo dalgún xeito e facer que algún método torto funcione correctamente, finalmente, despois dun par de días entendemos que non podemos seguir así. O comportamento estándar dun programador nesta situación é volver ao negocio e dicir: “Fixen isto e aquilo, este non funciona así, e ese non funciona para nada, así que infórmao ti mesmo. ” Unha empresa ten un problema: cómpre afondar no que pasou, comunicarse con alguén e tratar de resolvelo dalgún xeito. O teléfono roto comeza: "dille que lle enviarei un texto, mira o que contestaron".
Un bo desenvolvedor, ante tal situación, atopará contactos el mesmo, contactará con el por teléfono, discutirá o problema e, se nada funciona, reunirá ás persoas adecuadas, explicará todo e ofrecerá alternativas (o máis probable é que haxa outra). servizo externo con mellor apoio). Tal desenvolvedor ve un problema empresarial e resolve-lo. A súa tarefa péchase cando resolve un problema empresarial, e non cando se atopa con algo.
3: Intenta gastar o mínimo esforzo para obter os máximos resultados, aínda que iso signifique escribir muletas
O desenvolvemento de software nas empresas de produtos é case sempre o maior gasto: os desenvolvedores son caros. E un bo desenvolvedor entende que unha empresa quere obter a máxima cantidade de diñeiro gastando o mínimo. Para axudalo, un bo desenvolvedor quere gastar a cantidade mínima do seu tempo caro para obter o máximo beneficio para o empresario.
Aquí hai dous extremos. Unha delas é que en xeral podes resolver todos os problemas cunha muleta, sen molestarte coa arquitectura, sen refactorizar, etc. Todos sabemos como acaba isto normalmente: nada funciona, reescribimos o proxecto dende cero. Outra é cando unha persoa intenta crear unha arquitectura ideal para cada botón, dedicando unha hora á tarefa e catro á refactorización. O resultado deste traballo parece estupendo, pero o problema é que no lado empresarial leva dez horas completar un botón, tanto no primeiro como no segundo caso, simplemente por diferentes motivos.
Un bo programador sabe equilibrar estes extremos. Entende o contexto e toma a decisión óptima: neste problema vou cortar unha muleta, porque este é un código que se toca unha vez cada seis meses. Pero neste, voume molestar e facer todo o máis correctamente posible, porque cen novas funcións que aínda non se desenvolverán dependerán do que teña éxito.
4. Conta cun sistema de xestión empresarial propio e é capaz de traballar en proxectos de calquera complexidade nel.
Traballando os principios - cando anotas todas as túas tarefas nalgún tipo de sistema de texto, non esquezas ningún acordo, empurras a todos, apareces a tempo en todas partes, sabes o que é importante e o que non o é no momento, nunca perdes tarefas. A característica xeral destas persoas é que cando estás de acordo en algo con elas, nunca te preocupas de que se esquezan; e tamén sabes que o anotan todo e que logo non farán mil preguntas, cuxas respostas xa foron comentadas.
5. Pregunta e aclara calquera condición e introdución
Aquí tamén hai dous extremos. Por unha banda, pode ser escéptico con toda a información introdutoria. A xente antes que ti inventou algunhas solucións, pero pensas que podes facelo mellor e comezar a volver a falar de todo o que che precedeu: deseño, solucións empresariais, arquitectura, etc. Isto fai perder moito tempo tanto para o desarrollador como para os que o rodean, e ten un impacto negativo na confianza dentro da empresa: outras persoas non queren tomar decisións porque saben que ese tipo volverá e romperá todo. O outro extremo é cando un desenvolvedor percibe calquera introdución, especificacións técnicas e desexos comerciais como algo tallado na pedra, e só cando se enfronta a un problema irresoluble comeza a pensar se está a facer o que está a facer. Un bo desenvolvedor tamén atopa aquí un punto medio: intenta comprender as decisións tomadas antes ou sen el, antes de que a tarefa entre en desenvolvemento. Que quere o negocio? Estamos resolvendo os seus problemas? O deseñador do produto presentou unha solución, pero entendo por que a solución funcionará? Por que o líder do equipo tivo esta arquitectura en particular? Se algo non está claro, entón tes que ir preguntar. No proceso desta aclaración, un bo desenvolvedor pode ver unha solución alternativa que simplemente non se lle ocorrera a ninguén antes.
6. Mellora os procesos e as persoas que te rodean
Hai moitos procesos ao noso redor: reunións diarias, reunións, scrums, revisións técnicas, revisións de código, etc. Un bo programador levantarase e dirá: mira, xuntámonos e discutimos o mesmo todas as semanas, non entendo por que, tamén podemos pasar esta hora en Contra. Ou: para a terceira tarefa consecutiva non podo entrar no código, nada está claro, a arquitectura está chea de buratos; Quizais o noso código de revisión sexa malo e necesitemos refactorizar, imos refactorizar a reunión cada dúas semanas. Ou durante unha revisión do código, unha persoa ve que un dos seus compañeiros non está a usar unha determinada ferramenta con suficiente eficacia, o que significa que ten que aparecer máis tarde e dar algúns consellos. Un bo desenvolvedor ten este instinto; fai tales cousas automaticamente.
7. Excelente para xestionar outros, aínda que non sexa un xestor
Esta habilidade enlázase ben co tema de "resolver en lugar de crear problemas". Moitas veces, no texto da praza á que nos presentamos, non se escribe nada sobre xestión, pero despois, ante un problema alleo á túa vontade, aínda tes que xestionar os demais dun xeito ou doutro, conseguir algo deles, se esqueceu - empurra, asegúrate de que o entenderon todo. Un bo desenvolvedor sabe quen está interesado en que, pode convocar unha reunión con estas persoas, anotar acordos, envialos á folga, lembralos o día adecuado, asegurarse de que todo estea listo, aínda que non sexa persoalmente responsable directamente esta tarefa, pero o seu resultado depende da súa implementación.
8. Non percibe o seu coñecemento como dogma, está constantemente aberto á crítica
Todo o mundo pode lembrar a un colega dun traballo anterior que non pode comprometer a súa tecnoloxía e grita que todos arderán no inferno por algunhas mutacións equivocadas. Un bo desenvolvedor, se traballa durante 5, 10 ou 20 anos na industria, entende que a metade dos seus coñecementos está podre, e na metade restante non sabe dez veces máis do que sabe. E cada vez que alguén non está de acordo con el e ofrece unha alternativa, non é un ataque ao seu ego, senón unha oportunidade para aprender algo. Isto permítelle crecer moito máis rápido que os que o rodean.
Comparemos a miña idea dun desenvolvedor ideal coa xeralmente aceptada:
Esta imaxe mostra cantos dos puntos descritos anteriormente están relacionados co código e cantos non. O desenvolvemento nunha empresa de produtos é só un terzo de programación, os 2/3 restantes teñen pouco que ver co código. E aínda que escribimos moito código, a nosa eficacia depende moito destes dous terzos "irrelevantes".
Especialización, xeneralismo e regra do 80-20
Cando unha persoa aprende a resolver algúns problemas estreitos, estuda moito e duro, pero despois resolve-los de forma sinxela e sinxela, pero non ten coñecementos en campos relacionados, esta é a especialización. O xeneralismo é cando a metade do tempo de formación se inviste na área de competencia propia e outra metade en áreas relacionadas. En consecuencia, no primeiro caso, unha cousa fago perfectamente e o resto mal, e no segundo, todo o fago máis ou menos ben.
A regra do 80-20 dinos que o 80% do resultado provén do 20% do esforzo. O 80% dos ingresos procede do 20% dos clientes, o 80% dos beneficios procede do 20% dos empregados, etc. Na docencia, isto significa que o 80% dos coñecementos adquirimos no primeiro 20% do tempo dedicado.
Hai unha idea: os programadores só deben codificar, os deseñadores só deben deseñar, os analistas deben analizar e os xestores só deben xestionar. Na miña opinión, esta idea é tóxica e non funciona moi ben. Non se trata de que todos teñan que ser un soldado universal, trátase de aforrar recursos. Se un desenvolvedor entende polo menos un pouco sobre xestión, deseño e análise, poderá resolver moitos problemas sen involucrar a outras persoas. Se precisa crear algún tipo de función e, a continuación, comprobar como traballan os usuarios con ela nun contexto determinado, o que requirirá dúas consultas SQL, é xenial non distraer ao analista con isto. Se necesitas incorporar un botón por analoxía cos existentes e entendes os principios xerais, podes facelo sen involucrar a un deseñador e a empresa agradecerao.
Total: podes pasar o 100% do teu tempo estudando unha habilidade ata o límite, ou podes pasar o mesmo tempo en cinco áreas, nivelando ata o 80% en cada unha. Seguindo esta matemática inxenua, podemos gañar catro veces máis habilidades no mesmo tempo. Isto é unha esaxeración, pero ilustra a idea.
As habilidades relacionadas pódense adestrar non nun 80%, senón nun 30-50%. Despois de pasar de 10 a 20 horas, mellorará notablemente en áreas relacionadas, entenderá moito os procesos que ocorren nelas e volveráse moito máis autónomo.
No ecosistema de TI actual, é mellor ter tantas habilidades como sexa posible e non ser un experto en ningunha delas. Porque, en primeiro lugar, todas estas habilidades desaparecen rapidamente, especialmente no que se refire á programación, e, en segundo lugar, porque o 99% das veces usamos non só as habilidades básicas, pero certamente non as máis sofisticadas, e isto é suficiente incluso na codificación, mesmo en empresas xeniais.
E por último, a formación é un investimento, e a diversificación é importante nos investimentos.
Que ensinar
Entón, que ensinar e como? Un desenvolvedor típico dunha empresa forte usa habitualmente:
- comunicación
- autoorganización
- planificación
- deseño (normalmente código)
- e ás veces xestión, liderado, análise de datos, redacción, contratación, mentoring e moitas outras habilidades
E practicamente ningunha destas habilidades se cruza de ningún xeito co propio código. Cómpre ensinarse e actualizarse por separado, e se non se fai, manteranse nun nivel moi baixo, o que non permite un uso eficaz.
En que áreas merece a pena desenvolverse?
-
As habilidades blandas son todo o que non se refire a premer botóns no editor. Así escribimos mensaxes, como nos comportamos nas reunións, como nos comunicamos cos compañeiros. Todas estas cousas parecen ser obvias, pero moitas veces son subestimadas.
-
Sistema de autoorganización. Para min persoalmente, isto converteuse nun tema moi importante durante o ano pasado. Entre todos os traballadores de TI que coñezo, esta é unha das habilidades máis desenvolvidas: están superorganizados, sempre fan o que din, saben exactamente o que van facer mañá, nunha semana, nun mes. É necesario construír un sistema ao seu redor no que se rexistren todos os asuntos e todas as preguntas; isto facilita moito o traballo en si e axuda moito a interactuar con outras persoas. Sinto que durante o ano pasado, o desenvolvemento nesta dirección melloroume moito máis que mellorar as miñas habilidades técnicas; comecei a facer moito máis traballo por unidade de tempo.
-
Proactivo, de mente aberta e de planificación. Os temas son moi xerais e vitais, non exclusivos das TI, e todos deberían desenvolvelos. Proactividade significa non esperar un sinal para actuar. Vostede é a fonte dos acontecementos, non as reaccións a eles. A mente aberta é a capacidade de tratar calquera información nova de forma obxectiva, para avaliar a situación illadando a propia visión do mundo e os vellos hábitos. A planificación é unha visión clara de como a tarefa de hoxe resolve o problema para a semana, o mes, o ano. Se ves o futuro máis aló dunha tarefa específica, é moito máis doado facer o que necesitas e non ter medo despois de dar conta de que se desperdiciou. Esta habilidade é especialmente importante para unha carreira: podes conseguir resultados durante anos, pero no lugar equivocado, e eventualmente perder toda a equipaxe acumulada cando queda claro que estabas movendo na dirección equivocada.
-
Todas as áreas relacionadas co nivel básico. Todo o mundo ten as súas propias áreas específicas, pero é importante entender que dedicando 10 a 20 horas de tempo a mellorar algunha habilidade "estranxeira", pode descubrir moitas oportunidades e puntos de contacto novos no seu traballo diario, e estas horas poden ser suficiente ata o final da carreira.
Que ler
Hai moitos libros sobre a autoorganización; é toda unha industria onde algúns rapaces estraños escriben coleccións de consellos e recollen formacións. Ao mesmo tempo, non está claro o que eles mesmos lograron na vida. Por iso, é importante poñer filtros aos autores, mirar quen son e que teñen detrás. O meu desenvolvemento e perspectiva víronse máis influenciados por catro libros, todos eles dun xeito ou outro relacionados coa mellora das habilidades descritas anteriormente.
1. Dale Carnegie "Como gañar amigos e influír na xente". Un libro de culto sobre habilidades suaves, se non sabes por onde comezar, escollelo é unha opción gaña-gaña. Está construído sobre exemplos, é fácil de ler, non require moito esforzo para comprender o que le e as habilidades adquiridas pódense aplicar inmediatamente. En xeral, o libro trata o tema da comunicación coa xente.
2. Stephen R. Covey "7 hábitos de persoas altamente eficaces". Unha mestura de habilidades diferentes, desde a proactividade ata as habilidades blandas, con énfase na consecución de sinerxías cando necesitas converter un pequeno equipo nunha forza enorme. Tamén é fácil de ler.
3. "Principios" de Ray Dalio. Revela temas de apertura e proactividade, baseados na historia da empresa que construíu o autor, que dirixiu durante 40 anos. Moitos exemplos da vida conseguidos arduamente mostran como pode ser unha persoa prexudicada e dependente, e como se librar del.
4. David Allen, "Getting Things Done". Lectura obrigatoria para aprender a autoorganización. Non é tan fácil de ler, pero ofrece un conxunto completo de ferramentas para organizar a vida e os asuntos, examina todos os aspectos en detalle e axúdache a decidir o que precisas exactamente. Coa súa axuda, construín o meu propio sistema que me permite facer sempre as cousas máis importantes sen esquecerme do resto.
Debes entender que non basta con ler. Podes tragar polo menos un libro á semana, pero o efecto durará varios días e despois todo volverá ao seu lugar. Os libros deben utilizarse como fonte de consellos que se pon a proba inmediatamente na práctica. Se non o fas, entón o único que darán é un pouco de ampliación dos teus horizontes.
Fonte: www.habr.com