Quando a primeira edição russa do conhecido livro "How to Graze Cats" foi publicada, dedicada ao difícil tópico de gerenciar profissionais desajeitados e não muito desenvolvedores de software, meu colega mais experiente, o gerente de projeto observou: "Seria mais correto chamá-lo de" Como pastar gado "" . A frase foi lembrada e, como mostra a experiência acumulada desde então na interação com os programadores - um colega estava certo.
Como os programadores da Nena veem seus colegas
Em Habré, há uma quantidade razoável de artigos dedicados a metodologias de desenvolvimento de software, comunicação e interação na equipe do projeto, seleção e contratação de programadores. Sem exageros, cada um desses artigos coleta muitos comentários irados dos programadores, nos quais eles culpam “piemas”, testadores, funcionários do departamento de pessoal, analistas, clientes - por quem simplesmente não se ama por falhas em uma metodologia específica ou por falhas em projetos. Nos artigos e nos comentários, a opinião predominante é que o desenvolvedor está sempre certo. A prevalência dessa opinião se deve, entre outras coisas, ao fato de que os programadores compõem a maior parte do público em Habr. Ao mesmo tempo, especialistas que não são programadores estão trabalhando em organizações e equipes de projeto. Este artigo expressa em particular o ponto de vista de um lado ou de outro formado do outro lado das “barricadas”.
Hoje, meu jovem amigo, descreverei o mundo através dos olhos de seus colegas e contarei como você, o desenvolvedor de software, o grande e sempre certo programador, aparece para eles neste mundo. Você tem certeza de que é o Centro do Universo, como seu gato, e que todos lhe devem um
caixão antes do final do projeto. Essa sua opinião é apoiada, entre outras coisas, pela superioridade quantitativa de sua coorte na equipe do projeto, mas na verdade, em boa parte dos projetos em que você, um jovem ou já está acinzentado, mas ainda não obtendo o suficiente amigo mental, o resto da equipe fica quieta odeia sua onisciência e excesso de auto-presunção. Seu esnobismo é bloqueado apenas pelo esnobado exorbitante e excessivamente inflado do arquiteto, mas as conversas sobre essa
casta ocorrerão em outro momento.
Um analista de negócios odeia você pelas partes mais demoradas das especificações que supostamente não foram realizadas devido à supervisão.
Os testadores odeiam você por realizar a montagem final com correções 5 minutos antes do final do dia útil e voltar calmamente para casa, e eles ainda precisam passar várias horas extras à noite verificando cinquenta correções e testes de regressão antes da liberação de amanhã.
O gerente de projeto o odeia por cuspir nele da torre sineira mais alta, porque seu futuro e seu salário na empresa não dependem de sua opinião e feedback, mas dependem apenas de seu chefe imediato, que quase sempre encontrará uma maneira para protegê-lo por qualquer falha sua. Bem, é claro, ele odeia você ainda mais que os testadores, porque depois que eles terminam os testes e dão o aval para o lançamento da versão final, ele, às 11 horas da noite, ainda terá que concluir a criação dos relatórios de versão final para equipes de implantação e manutenção para o cliente.
O serviço de suporte o odeia pelo código "auto-documentado" e pela evasão constante de respostas às perguntas deles, mesmo que as horas para suporte ao código alienado sejam alocadas especialmente em sua programação no novo projeto ao qual você está designado.
No entanto, as primeiras coisas primeiro.
Trajetória de vida de um programador comum
De alguma forma, depois de um projeto
bem -
sucedido , eu, com o consentimento do chefe do departamento de desenvolvimento, preparei uma apresentação para o grupo de programação, que, entre outras coisas, incluiu um "gráfico" que descreve a trajetória de vida do programador, desde o início, codificando no bloco de notas em idade escolar através do desenvolvimento de ambientes de desenvolvimento integrado (20 anos), gerenciamento de defeitos (25 anos) e interação com outros grupos de especialistas e contratados externos (30 anos), antes de aplicar a prática de integração contínua e desenvolvimento automático lançamentos yvaniya atingido o
aparecimento de cabelos grisalhos 35 anos (marcos de idade, é claro, condicional, e só servem para ilustrar o modo de vida em média). Um programador, como ninguém mais no mundo moderno, é forçado a aprender e melhorar constantemente técnica e profissionalmente, e muitos têm sucesso nisso. Ao mesmo tempo, a maioria dos que escrevem seu primeiro programa de denúncia
de fraudes “Hello, World” e publicam um currículo no site hh.ru / monster.com imediatamente começam a se espalhar nas entrevistas e se orgulham de ser “um verdadeiro profissional”, - estes não são de fato.
Nesse projeto, um desenvolvedor conseguiu esquecer de colocar o código atualizado em um repositório comum e dois de seus colegas meio dia no modo extremo tentaram determinar por que a função não funciona como indicado? Outro desenvolvedor cometeu um erro no script de implantação e, se não fosse percebido pelo gerente do projeto (!), A implementação dos resultados da colaboração da equipe para toda a iteração seria adiada até o próximo ciclo de lançamento do código no ambiente do produto, ou seja, por 2 semanas.
Ambos os especialistas tinham mais de um ano de trabalho, eram profissionais em desenvolvimento de software, ou seja, Receberam compensação monetária por seu trabalho, mas não codificaram "por si mesmos" ou em um projeto de código aberto gratuito. No entanto, eles cometeram erros "infantis", não importa para o que olhem. É uma coisa bem conhecida, todo mundo experimenta falhas; somente quem não faz nada não corta. Mas é por isso que eu queria fazer essa apresentação para os desenvolvedores mostrarem, com base em minha experiência em aconselhar várias equipes de projeto, quais áreas problemáticas quase qualquer programador possui e o que elas não residem no campo de conhecimento de uma tecnologia de programação específica, mas em áreas relacionadas, onde você é amado por você, , designers e destruidores, e as habilidades começam a trabalhar com requisitos, ferramentas, defeitos, planejamento etc. Portanto, se em algum lugar ao ler um artigo em qualquer um dos exemplos acima, você se reconhecer acidentalmente, e depois de lê-lo tirar conclusões apropriadas e conseguir “crescer acima de si mesmo” - outros o verão por direito como um profissional em seu campo e se alegram com isso. que trabalham com você no mesmo projeto e equipe.
Interação com não programadores
Diga a você, meu amigo hábil, que outros especialistas com quem você trabalha lado a lado na equipe do projeto, como testadores, analistas, escritores técnicos, designers e outros, não são menos responsáveis pelo sucesso do projeto do que você
. milagre do universo . E todos esses não-humanos desempenham um papel não menos importante e, em alguns projetos ainda maiores que o seu papel como codificador, a interação competente e benevolente com eles é parte integrante e essencial do seu trabalho, pelo qual você recebe muito dinheiro de um caixa eletrônico duas vezes por mês (para em uma palavra - o dinheiro é
muito maior do que todas essas pessoas tiram do mesmo caixa eletrônico). Você costuma olhar para eles e suas necessidades de design de cima ou por entre os dedos, sem a atenção que eles exigem corretamente. E eles têm necessidades e expectativas profissionais, e diversas, dependendo de seus papéis.
O analista, por exemplo, espera que você não apenas brinque sobre e sem cada letra nas especificações, mas também as traduza conscientemente em código de programa. E que você não usa óculos de proteção quando perguntado durante o teste por que você não implementou a função principal que foi incluída na liberação de amanhã e estabelecida nos requisitos antes de ser nomeado para a equipe do projeto há um ano, sempre havia e desde então nunca mudou uma única letra.
O testador tem o direito de esperar de você um resultado de qualidade sem erros do seu trabalho. Quando ela foi contratada, foi prometida e, portanto, espera que ela não faça parte da metodologia de desenvolvimento do TDD, segundo a qual você, MUD, “joga” o produto inacabado em testes e, de acordo com seus resultados, termina as peças ausentes de funcionalidade e corrige defeitos óbvios. E o testador certamente espera que você não espalhe a podridão pelo fato de que ela não sabe testar o produto de maneira diferente da manual, ou que suas habilidades em trabalhar com a linguagem de consulta do banco de dados são muito inferiores às suas. No final, não esqueça que eles pagam a ela muitas vezes menos pelos testes manuais do que pela programação e que, se ela conhecia o SQL tão bem quanto você, ela se sentava na sua cadeira em frente ao monitor e não você, porque com qualificações iguais entre si, ela preferiria deixá-la na equipe e na organização, porque ela, diferentemente de você, tendo seguido o caminho difícil do testador, nunca espalhará podridão nos colegas da oficina da maneira que você faz.
Conhecimento de engenharia de tecnologia
Você já terminou o instituto do
jardim de infância e, nas entrevistas, explica com sucesso como o designer difere do destruidor? Vou lhe contar um segredo que o mundo profissional da criação de software não se limita a esse conhecimento e, se você continuar pensando que o código escrito e de alguma forma executável é resultado suficiente do seu trabalho para
não fazer com que as
pessoas do gerente / cliente do projeto recebam sn duas vezes por mês, você está em sua futura carreira, você enfrentará muitos outros problemas por conta própria e, o mais importante, será uma fonte de dor de cabeça persistente para todos que não tiverem a sorte de trabalhar ao seu lado.
"Controle de versão? Comentando o código? Aderir aos padrões de codificação e nomeação? Não, eu não ouvi! Diga seus colegas aqui e aqui em várias equipes e organizações de projetos. Jovem amigo, você está se queixando de tudo que não está diretamente relacionado ao “jabbing de código”: sobre a necessidade de adicionar comentários, cubra o código com testes de bloco de acordo com os padrões estabelecidos na empresa ou departamento, mesclando ramificações do repositório ... O que podemos dizer sobre coisas mais complexas que exigem avançado ou verdadeiramente altamente qualificado: automação de teste, implementação e suporte para integração contínua, configuração de pacotes Bamboo-Pepino-Maven-Puppet, muitas horas de busca nos logs do sistema na pesquisa x evidência de erros de software - tudo isso é para você tédio e resíduos que não permitem melhorar diretamente suas habilidades de codificação e que você acha que menospreza suas perguntas frequentes. Além disso, ao recusar o uso de determinado hardware, você, um desenvolvedor de software profissional, geralmente simplesmente oculta sua incapacidade de usá-los. Lembro-me da reação e do rosto de um programador que, como tentativa de detectar um defeito "flutuante" difícil de encontrar, sugeriu o uso do criador de perfil incorporado ao IDE: disseram-me que esse não era o trabalho do gerente de projetos orientar as ferramentas que o programador deveria usar em seu trabalho.
Habilidades da ferramenta
Quão automatizado é o seu trabalho na sua estação de trabalho? Você desenvolveu suas habilidades no trabalho com expressões regulares, criando e executando arquivos em lote? A pedido de um colega, testador, analista ou cliente, você pode analisar algumas centenas de milhares de linhas de logs em um servidor remoto em 3 minutos, encontrar a entrada necessária do parâmetro chave, compactar a saída, encaminhá-la para o endereço especificado e retornar à tarefa interrompida? Com que rapidez, MUD, você sabe executar operações de rotina que exigem repetição repetida durante o dia de trabalho?
Como você sabe, é possível iniciar a compilação em ambientes modernos de desenvolvimento pressionando F5 (ou F6? Ou F13? .. No final, por que eu, gerente de projeto, preciso saber essas coisas? Você não sabe, MUD, com que rapidez, em alguns minutos descarregue o Jira, formate-o corretamente no Excel e envie um e-mail ao cliente sobre o relatório de defeitos com gráficos e tendências de
blackjet e prostitutas , mas você nunca deixará de fixar seu "piem" na sala de fumantes entre seus colegas que não é estúpido sabe como o destruidor difere do construtor). Mas, durante uma carreira bastante longa, não conheci tantos programadores que usam atalhos de teclado para invocar certas ações padrão - a maioria usa o manipulador de mouse mais lento para isso. Condicional "Guia - 1000 - Guia - 1 - Guia - 0 - Guia - Backspace - 2 - Ctrl + S - Ctrl-F6 - Enter, Alt-Tab, F5" em 6 segundos permite que um profissional real faça o que, movendo e cutucando o mouse com os dedos indicadores do teclado, o lento demora cinco longos minutos. E quando essas operações são executadas centenas de vezes por dia, no contexto de um prazo próximo, outro gerente de projetos às vezes quer
tirar e ...... afastar um "profissional" do teclado e fazer alterações / compilar / definir o código executável e dar aprovação ao grupo de teste A nova versão está finalmente pronta.
Portanto, MUD, não seja preguiçoso e gaste tempo dominando a impressão cega com dez dedos e os métodos de trabalho eficaz com ferramentas e acredite em pessoas mais experientes, mesmo que algumas delas não sejam tão amadas pelos seus gerentes de projeto - esse tempo será recompensador. Enquanto isso, você, jovem desajeitado, não alcançou a perfeição nisso - Vá, enterre-se no monitor e Escreva o Código, Bl ..!
Avaliação do trabalho
Você não aguenta quando o gerente de projetos intervém no processo sagrado de "escrever código". Mas, ao mesmo tempo, você nunca se negará o prazer de deixar um comentário cáustico sobre prazos "irreais", requisitos "vazamentos", solicitações prematuras de mudanças, gerentes de projetos incompetentes. Quando, dentro da estrutura de uma metodologia específica, eles recorrem a você para obter uma opinião especializada sobre a avaliação dos custos de mão-de-obra para a próxima iteração ou para todo o projeto, você faz uma cara de surpresa e começa a "desculpar-se" sobre especificações incompreensíveis ou incompletas, tecnologias desconhecidas e que isso não é o seu objetivo. para planejar, você não tem tempo para "besteiras" e é melhor fazer a coisa real - escrever código. “Estimativa de custos de mão-de-obra pelo método de pontos funcionais? Por analogia, com base em resultados anteriores? Com base no número de formulários de tela e solicitações de E / S do banco de dados? Não, eu não ouvi!
Portanto, um jovem amigo, fique quieto quando não é da sua conta planejar o trabalho no projeto ou aprimore suas próprias habilidades na emissão de avaliações verdadeiramente especializadas, e não com o dedo no céu. E até você dominar o último -
IPKB !!!
Código Hindu
Um de seus passatempos favoritos é criticar o código de software criado por desenvolvedores indianos. Não alimente seu pão, mas deixe-nos tirar sarro do estilo de programação "massas". Mais do que discutir o código "hindu", você gosta de conversar sobre tecnologia (veja abaixo). E tudo isso, apesar de você mesmo chamar métodos de nome orgulhoso kolbasa (), copia inesquecivelmente trechos de código em diferentes locais do programa e cria classes do tamanho de uma dúzia ou duas telas.
Pela insignificância de sua própria experiência profissional, MUD, você não está ciente de que a
merda do código que você mesmo escreve muitas vezes não é melhor, e às vezes pior, do que o código que seus colegas do sul criam. Programadores lamentáveis estão presentes em qualquer país, "não julgue, não sejamos julgados", e verdadeiros profissionais, vou lhe contar um segredo, MJD, não se submetem à censura de seus colegas em uma base nacional e, lentamente, melhoram suas próprias qualificações e tempo, alocados para a criação de um produto de software, eles gastam diretamente na programação, e não na busca de
canudos aos olhos dos outros, com uma falha no código de outra pessoa.
Discussão sobre tecnologia sem fim
Você discute incessantemente com outros programadores o que o Java ++ é superior ao C ## ou qual versão número cento e vinte e nove fração quinze de qualquer biblioteca Javascript é melhor que a versão cento e vinte e nove fração treze. Você nunca se arrepende de tais discussões, mesmo nos dias em que restam 2 a 3 dias ou semanas antes do final de uma iteração ou projeto de vários meses e o número de defeitos graves não corrigidos atribuídos a você excede cinquenta.
Você faz isso sem uma pontada de consciência durante o horário de trabalho, e não nas noites de sexta-feira ou nos fins de semana para tomar um copo de cerveja. Você está envolvido em tal conversa, apesar do fato de a questão de escolher e usar uma ou outra tecnologia em um produto estar fora do escopo de sua competência (porque o tamanho de sua competência, MJD, simplesmente ainda não cresceu), mas você ainda passa um tempo com seu empregador e projeto sobre trepot improdutivo.
Queixando-se de comícios "desnecessários"
Portanto, quando, depois de você
passar o tempo conversando, conversei por duas horas na cozinha / sala de fumantes com meia dúzia dos mesmos codificadores de
merda sobre a mais recente estrutura / conferência de imprensa Google-Microsoft-Apple-Linus Torvalds ontem, do que roubou algumas pessoas- Nos dias de desenvolvimento, repentinamente, na análise da iteração concluída, declara que são realizadas muitas reuniões desnecessárias no projeto e é necessário reduzi-las - em resposta a isso, você deseja gritar apenas uma coisa: cale a boca e
IPKB !!!
Russo alfabetizado
Bem, no final, como se costuma dizer, o último, mas longe do mais sem importância. , , , C## — - ( - , XXI ). , , , -
— , ..! ,
_ — , .
tsya.ru , «» — , "
" «» — , «
», ..!!111
Epílogo
, , , , , . ! , , , - ,
.
: ? , , , .
, , , . , - 10 . 3 , , , , , “” 3 .
: 1 3 3 1. , . , “
” ( “”). , , , , , .
“
” , , , “”, , . , , , , “, , , , , XYZ , , ( / / )!”.
, “”, “
”, , : , , , , ( ), “”.
.