Como eu parei de odiar e me apaixonei pelo desenvolvimento

O artigo Medo e ódio em TI me deixou triste. Não porque eu compartilho os sentimentos do autor, mas porque eles são compartilhados por muitos bons desenvolvedores, matando a si mesmos, seus projetos, a indústria e o progresso humano em geral. Aqui está, mahanul


Por mais entusiasmado que eu seja futurista e especialista em automação, este artigo é mais mundano do que um futuro melhor. Portanto, deixarei o destino da humanidade na próxima vez. Agora, finalmente, quero falar sobre os enormes volumes de negatividade, dor, medo e ódio que se escondem nas profundezas da comunidade de TI, cobertos por uma pequena camada quente de tecnologia exagerada e soluções legais de engenharia.

Isenção de responsabilidade

Pela minha própria experiência, sei como é difícil aplicar o que está sendo discutido na terceirização, especialmente em grandes projetos. Não quero que a maioria dos desenvolvedores pense "bem, agora" e feche o artigo, mas não sei como atrair, mas também não quero enganar. Por isso, pergunto: continue, nem tudo é tão ruim.

Complexidade excessiva

O autor do artigo original enfatizou o óbvio: o desenvolvedor não controla mais a operação de sua solução. Para muitos, era muito confortável, dando uma sensação de calma e controle. E esse conforto continua sendo o ponto de partida: até agora, apesar da transição da categoria de criadores para a categoria de artesãos, o programador ainda está tentando aproveitar o processo de criar algo do nada. Usando as criações de outras pessoas, esse prazer não pode ser alcançado; você sente, na melhor das hipóteses, um mosaico , pedras selecionadas com sucesso. (Mas o mosaico também é uma arte, o que há de errado aqui? Hmm ...).

Aceite o inevitável. Somente personagens selecionados de mitos poderiam criar planetas do nada. Usando os componentes apropriados, aplicando abordagens conhecidas e pensando com cuidado , você pode criar um sistema elegante e desfrutar comparável ao de uma criação "pura". E funcionará em qualquer nível: da nova enumeração ao design de um sistema de alta carga.

Tecnicamente, nem tudo é tão róseo. E duas coisas são as culpadas: tempo e colegas. Nossas decisões devem atender a dois critérios: os custos devem ser menores que os benefícios de médio prazo esperados e os custos de suporte menores que os de longo prazo. Portanto, com os volumes de desenvolvimento existentes, inevitavelmente tomamos decisões como “usar esse cliente em qualquer lugar”: é rápido e toda a equipe sabe como trabalhar com ele. E se o cliente for bastante popular, os futuros membros da equipe poderão. Procure um equilíbrio entre os extremos da criação exaltada e o transporte sem alma, aproveite para encontrá-lo!

Demasiado e Entrevistas

Escolher o componente perfeito para a solução atual é improvável. Mesmo que ele exista, ele é um em mil. Cada desenvolvedor / equipe / empresa escolhe algo para si, aprende a contornar as armadilhas ... e começa a exigir a mesma experiência dos outros. Isso é estúpido. Tão estúpido quanto agarrar-se ao controle perdido sobre sua criação.

Toda vez que leio outra história da dor da entrevista "eles querem saber a lista completa de mudanças no ES6", fico triste. Eles querem saber apenas uma coisa: você se adequará à sua equipe. E "eles" somos nós, apenas do outro lado da mesa. Nós não sabemos como perguntar e não sabemos como responder.

Quebre esse círculo vicioso de mal-entendidos! Pare de fazer entrevistas e comece a procurar um emprego para si mesmo. Diga o que você pensa. Aceite que sua equipe seja uma de vinte. Encontre-a.

Pare de procurar alguém que saiba a mesma coisa e comece a procurar alguém que lhe dê algo novo. Pergunte o que é importante para você. Aceite que, fazendo perguntas de conhecimento, você está simplesmente escrevendo um resumo detalhado. Encontre alguém que fale a mesma linguagem de engenharia com você, compartilhe seus princípios e abordagens de desenvolvimento.

Pessoas de TI

Também pessoas. As pessoas são diferentes, enquanto xenófobas; uma característica bastante útil em termos de seleção natural. Isso não ajuda no trabalho em equipe, e pouco pode ser feito sobre o assunto: será interessante para os damas jogarem seus brinquedos juntos, os engenheiros hardcore, criando algumas palavras, criarão coisas eternas juntos.

Aceite: as pessoas são diferentes. Se você precisar de pessoas, procure por "seu".

Provavelmente, a quantidade máxima de ódio está associada aos gerentes. E aqui estamos novamente em um círculo vicioso: o gerente não quer ou não pode fazer seu trabalho - e, portanto, nos afastamos dele e fazemos tudo sozinhos. Ele é inútil de qualquer maneira. Esta pergunta entra em

Negócios

Muitas cópias são quebradas no campo de batalha de Negócios com Tecnologia. Não tenho vontade de me repetir, por isso omitirei uma grande parte do contexto e vou direto ao ponto principal.

Somente o desenvolvedor é responsável por muletas nas soluções. Somente os negócios (representados por OP, PM, diretores etc.) são responsáveis ​​por falhas do projeto. E aqui você precisa de muita força. Aprenda a calcular o preço de soluções rápidas. Aprenda como provar que economizar um mês agora levará a dois meses de superação amanhã. Ou não vai. Aceite que um bom código não resolva problemas por conta própria, mas os negócios não querem se enterrar em dívidas técnicas!

Você pode se recusar a jogar bingo de merda. Chame uma pá de pá antes que eles cheguem até você e você os chamará de bonitos . Um desenvolvedor pode se dar ao luxo de ser honesto - ele não tem orçamento nem responsabilidade. É fácil para um desenvolvedor encontrar um novo emprego com um pouco menos de medo da honestidade. Dê sua opinião honesta e especialista sobre o problema e a solução e deixe que a empresa resolva isso. E diferencie a falta de vontade de decidir em encontrar uma solução. Acostumamos a empresa ao fato de que você pode fazer um hack rápido. Eles sabem que, se você pressionar um pouco, o resultado será cinco vezes mais rápido. Isso é uma rejeição da decisão, e não devemos nos entregar a esse comportamento. O gerente, em busca de uma solução, decomporá e priorizará, tentando mostrar o resultado no devido tempo. E somos obrigados a ajudar com isso.


O desenvolvedor deve entender o negócio apenas o suficiente para que o tempo para formular perguntas e entender as respostas seja comparável ao tempo para procurar uma solução técnica. Não podemos mais dizer “me dê um bolo e eu farei tudo”, esse bolo é quase a solução toda. Nosso trabalho não é mais para reorganizar bytes manualmente, agora temos muito mais tempo para analisar toda a imagem. Mas não devemos aceitar "há um monte de tarefas, resolva o que existe e como". Muitas vezes, os negócios economizam tempo para encontrar uma solução de negócios, e a tarefa do desenvolvedor é verificar que não há nada a ser desenvolvido e apontar isso para os negócios. Este é um trabalho árduo, e não para todos.

Sobre mim

Aos 20 anos, eu estava codificando por dias e com prazer fui trabalhar.
Aos 25 anos, vi como tudo estava ruim e sofria, esperando sexta-feira e um projeto de estimação em que tudo está bem.
Aos 30 anos, sou apaixonada pelo trabalho ... felizmente conhecendo sexta e o fim de semana.

Não sei o que acontecerá em mais cinco anos, mas espero não me decepcionar com as crenças atuais.
Nossa área nos dá muito - liberdade de expressão, desenvolvimento, conhecimento, experiência interessante e dinheiro decente. Nossa região é muito jovem, ainda é uma arte, e não temos uma dinastia de ancestrais artesãos. Ainda não sabemos como trabalhar nele. Portanto, estamos com raiva, sofrendo e esgotando-nos.

Minha decisão é a presunção de racionalidade. Já não chego a conclusões sobre uma pessoa por seu código, e-mails ou arrastar e soltar. Ainda mais, tento não pensar mal por causa do que ele diz ou faz. Afinal, enquanto trabalhamos em uma causa comum, e até que ele diga diretamente "Quero prejudicar o projeto", ele é meu aliado, e juntos podemos fazer mais do que individualmente.

Ninguém disse até agora, embora algumas vezes eu dirija alguns colegas para esse canto :)