O hábito é uma força terrível. Faz você resistir à mudança, impede o desenvolvimento. Mas em TI, adoramos estar na vanguarda da tecnologia, amamos desafios, adoramos implementar o que se espalhará para outras áreas em apenas alguns anos.
Estamos prontos para o novo e não podemos esperar até o futuro chegar, e teremos que nos adaptar a ele. Podemos seguir em frente, saber apenas em que direção.
Egor Bugaenko sabe o que precisa ser feito agora para continuar sendo um programador procurado em 5 a 10 anos. Suas idéias, como sempre, podem parecer controversas. Você não precisa concordar incondicionalmente com eles, mas pensar, por exemplo, no projeto do animal de estimação não será prejudicial novamente. E o fato de o programador precisar de inglês, dificilmente pode haver opiniões diferentes. Mas nos pontos restantes, será interessante conhecer a opinião da comunidade nos comentários.
A seguir, está a versão em texto do relatório de Egor sobre o
AppsConf , mas ele se refere não apenas e não tanto ao desenvolvimento móvel, mas ao setor como um todo. Egor Bugaenko, fundador da Zerocracy, desenvolvedor de Cactoos, Takes Framework, JCabi e outros projetos de código aberto. Ele escreveu uma série de livros chamados "Objetos elegantes", mantém um
blog provocativo e apresenta relatórios instigantes como este.
Começarei com uma história sobre há pouco tempo que decidi começar a desenvolver software para dispositivos móveis e colidi rapidamente que não sabia como fazê-lo. Portanto, decidi pedir ajuda a alguém que me dissesse como criar um aplicativo em um formulário totalmente compactado. Ou seja, crie um aplicativo que estará disponível na Apple Store.
Eu queria saber como montar o aplicativo em um pacote, ou seja, não apenas desenhar alguns botões na tela, mas fazer um
aplicativo inteiro . Obviamente, o código, por exemplo, no Swift e o produto no celular, são duas coisas completamente diferentes: a primeira é muito pequena e a segunda é muito grande e inclui essas perguntas:
- Testes unitários
- análise estática;
- Integração Contínua
- gerenciamento de dependências;
- Entrega Contínua;
- Ambiente de preparação;
- Processo de aprovação de aplicativos na Apple Store
- processo de montagem de defeitos de produção, etc.
Como organizar os botões na tela é fácil de ler na Internet. Eu precisava de um especialista, um especialista que me ajudasse a montar o pipeline inteiro. Para mim, como programador, isso é mais importante do que organizar os botões na tela.
Encontrei um especialista, mas ele me disse: “Por que você está pensando sobre isso? Desenhe o aplicativo primeiro. O que é integração contínua? Aguarde até com testes de unidade - faça funcionar. O que é um pipeline de entrega? Por que TestFlight - use um simulador ".
Certamente, ele é um bom programador, mas, na minha opinião,
tudo está de cabeça para baixo . Ele acha que o código é importante e o restante da embalagem é secundário. Na minha opinião, este é um grande problema, e eu quero falar sobre isso.
Por alguma razão, muitos desenvolvedores acreditam que
o código em si é importante, e montagem é o que o engenheiro do DevOps ou outra pessoa faz. Normalmente, quando você chega a uma equipe, isso já está pronto e configurado. Você se encontra em um projeto em que escreve código, sem saber como tudo acaba em produção. Acredito que o fato de os programadores não verem o ciclo completo de montagem, não saberem como ele funciona, é um problema.
Primeiro implante e depois codifique
Escrevo livros sobre programação e sei por mim mesmo que um
livro funcionará bem se você o projetar lindamente primeiro . Ou seja, eu crio o livro antes de escrever. Primeiro, faço um makefile, que diretamente da linha de comando coleta o livro inteiro dos arquivos do LaTeX, prepara textos, fotos, arte de capa. Passo muito tempo e faço isso com um único comando para coletar o livro inteiro em um arquivo PDF. Presto muita atenção à aparência, onde estão os recuos, quais blocos de texto e a distância entre eles, como as páginas serão numeradas. Quando gosto de tudo isso, vejo que tudo está maravilhosamente montado e tudo neste produto está completo, mesmo que apenas uma página tenha sido escrita até agora, só então começo a escrever um livro e só então me dá prazer.
Na maioria das vezes, os programadores fazem o oposto: escrevem, executam no simulador, verificam o trabalho. Acredito que é mais correto
implantar primeiro e depois codificar .
Vou dar mais um exemplo. Um desenvolvedor iniciante se ofereceu para fazer um projeto de código aberto conosco. Ele escolheu Flutter, fez a primeira iteração, iniciou, disse que tudo estava legal e ofereceu aparência. Perguntamos: “Como tentar alguma coisa? Aqui está o iPhone - para onde empurrar? O que ele começou a explicar, para onde ir, o que baixar, foi um processo longo.
Isso nos pareceu desconfortável e, no final, ele concordou que o aplicativo realmente precisa ser carregado no TestFlight. Depois de algum tempo, ele mostrou o aplicativo no TestFlight. Apertei os botões e notei alguns defeitos. Eu não trabalhei com Flutter e realmente não queria, mas queria consertar rapidamente o que percebi. Perguntei como fazer isso, onde e como enviar uma solicitação de recebimento. Eu abro o repositório, arquivo leia-me: "Esta é uma aplicação interessante ... clique em baixar ...".
As instruções eram complicadas e incompreensíveis, perguntei novamente como implantar tudo isso no meu computador. Eu só queria modificar o código de outra pessoa com um simples clique de alguns botões no meu computador, iniciar o simulador e enviar uma solicitação de recebimento. Aquele cara foi descrever tudo e nunca mais voltou.
Essa situação ilustra que suas qualidades como programador são boas - ele foi capaz de executar o aplicativo. Mas suas qualidades, como uma pessoa que vê todo o projeto, deixam muito a desejar. Como resultado, o projeto me perdeu não só como colaborador, mas também muitos outros. Este programador não recebeu retornos de outros, ele trabalhou como um solitário.
Na minha opinião,
estar sozinho está errado agora. O mercado está se movendo em direção a equipes populosas maiores: haverá mais pessoas nelas, elas entrarão e sairão com mais frequência.
A dinâmica dos recursos humanos está se movendo em direção a uma rotatividade mais alta, de modo que todas as pessoas que vêm ao projeto novamente devem vê-lo na íntegra - não apenas no código executado nos simuladores.
Um novato deve entrar em um ambiente que seja amigável para ele do ponto de vista da montagem - ele precisa abrir um arquivo leia-me e entender em alguns minutos como fazer tudo começar no simulador. O que clicar para verificar se tudo foi criado a partir da linha de comando - e não de IDEs complexos que precisam ser configurados por mais algumas horas. Deve ser possível escrever make / build / etc na linha de comando. Depois disso, tudo é coletado e imprime uma linha verde - tudo está pronto - e depois solicita a solicitação. Este é o primeiro pensamento que quero compartilhar hoje.
Obviamente, você dirá que não está trabalhando sozinho, não como o único fundador de projetos, nem como CTO. Você trabalha em equipe e não pode simplesmente dizer que agora vai lidar com a implantação, TestFlight, e precisa entender com urgência o IC. Esta não é sua tarefa, você não terá tempo para isso, etc.
Portanto, recomendo que você faça seus próprios projetos de estimação - projetos que você faz para seu próprio prazer - para entender tudo na sua totalidade.
Apenas 20 a 30% dos programadores têm seu próprio aplicativo publicado, e todos deveriam tê-lo. Se você se considera um programador muito procurado, recomendo que você faça seu aplicativo móvel e passe por todo o ciclo de sua entrada no mercado: verificações na Apple Store, CI, embalagens e tudo mais. Crie código aberto para que as pessoas possam contribuir e mostrar como elas falham.
Veja como você trabalha com o mercado, tente entender que tipo de programador você é. Eu acho que um programador que não tem projetos para animais de estimação é ruim.
Ele não está interessado em sua profissão ou não se importa, ou não pode, ou está com medo. É um medo ver todo o ciclo. Temos medo de ver o projeto como um produto pronto para o cliente. E o cliente para nós, em muitos casos, é outro desenvolvedor, como no meu exemplo eu era desenvolvedor de clientes no Flutter.
O segundo medo, na minha opinião, é dinheiro.
Quanto código você escreverá por US $ 100?
Eu trabalho com muitos programadores na plataforma Zerocracy e notei que eles geralmente têm medo de dinheiro. Eles estão acostumados a pagar no final do mês e são bastante dolorosos quando avaliados em dinheiro. Muitos não podem responder à pergunta simples: "Você sabe quanto pode gerar código por US $ 100?"
Certamente você sabe quanto deseja ganhar por mês. Imagine quanto custa um mês inteiro de sua vida: um apartamento, um carro, pagamentos regulares, o nível usual de conforto e entretenimento.
Os desenvolvedores de tempo integral e remuneração fixa estão ficando sem tempo.
Acho que trabalharemos cada vez mais em equipes temporariamente reunidas, onde as pessoas vêm enquanto são necessárias e vão mais longe depois disso. A era dos desenvolvedores que estão em um só lugar está saindo porque a empresa os contratou há muitos anos, eles simplesmente amam essa empresa e, portanto, estão com ela - não importa qual tecnologia a empresa use.
Conheço exemplos desses projetos que foram escritos em C ++ por muitos anos e depois percebi que eles precisavam escrever em Java. E as mesmas pessoas, no mesmo escritório, pela mesma troca de dinheiro para investidores, treinam novamente por meio ano e começam a tremer e rolar em Java. Esta é uma abordagem do passado. Na minha opinião, no futuro essas abordagens deixarão de existir, porque não farão sentido.
O mercado está se tornando global , o acesso remoto ao mercado de trabalho está se tornando cada vez mais fácil. Uma empresa sediada em Moscou será desinteressante e não lucrativa para treinar pessoas, por exemplo, do iOS para o Android ou do C ++ para Java. É mais fácil contratar novos especialistas que virão como freelancers, concluirão a tarefa e partirão.
Eu acho que esse formato de projetos será popular: projetos temporários, onde os freelancers se encontram, realizam suas tarefas - um especialista nisso, outro especialista nisso e sair.
Para os programadores, esse novo tempo espera:
- A capacidade de entender quanto você vale. Ou seja, forneça uma estimativa de quanto vale sua hora de trabalho, quanto valor você criará para ela.
- Capacidade de trabalhar em condições temporárias.
- Habilidades para vender a si mesmo, adequadamente presentes. Um desenvolvedor freelancer no mercado global deve ter uma "vantagem comercial" e preço.
Muitas pessoas têm medo de criar currículos, medo de vender a si mesmas. Como eu disse, acho que o resumo definitivamente deve incluir o item do projeto de estimação.
Projetos próprios serão o primeiro indicador de valor no mercado , e não no local em que você desenvolve o software que herdou por 5 anos seguidos. Você cria um projeto Pet do zero e não importa do que se trata, quão complicado é ou quantos downloads ele tem na Apple Store. Deixe 0 curtidas e 2 downloads, mas este é um projeto integral que você mesmo criou.
Para mim, como empregador, essas pessoas são mais valiosas do que aquelas que estão no escritório há muitos anos e têm um currículo com um ou dois empregadores. É difícil para mim entender o que fazer com essa pessoa, como avaliá-la. Eu sei que ele quer que eu o leve durante todo o mês e seja amigo dele, independentemente do resultado. Para mim, esse formato agora é inaceitável; para um grande número de empregadores no futuro também será desconfortável.
Portanto, a recomendação é
contar dinheiro, tentar trabalhar em contratos . Talvez isso não seja o ideal para seus empregadores, mas tente, trabalhando em período integral e sentado no escritório, ao mesmo tempo procurando alguns micro-projetos para um emprego de meio período. Não por uma questão de dinheiro, mas para entender se o mercado precisa de você como freelancer ou não, se você precisa dele como especialista ou não. Ou você só precisa do seu chefe, que tem medo de perdê-lo, porque só você sabe como o código do projeto funciona.
Procure alternativas, veja, tente, venda . No começo você não será comprado, haverá problemas - muitos problemas! Mas, resolvendo esses problemas, você se tornará um programador mais procurado em um nível superior.
Infelizmente, não apenas os próprios programadores não podem determinar o preço do trabalho, mas também os clientes. Às vezes, eles sugerem que eu execute certas tarefas como especialista. E muitas vezes o cliente que me oferece um emprego não entende como me avaliar. Na maioria das vezes, as pessoas querem apenas mais barato, como US $ 50, e não US $ 100, por hora. Entendo que uma pessoa com essa abordagem ainda não entende o quanto vou escrever em tempo real durante esta hora. Então concordo e apenas multiplico o número de horas por 2. Como resultado, recebo o quanto queria originalmente.
Eu sei o meu valor e velocidade reais. Os clientes não estão prontos para montantes de US $ 100 a 500 por hora; para eles, 20 já é muito, porque estão acostumados ao formato de emprego em período integral ao longo do tempo. Ou seja, quando uma pessoa recebe dinheiro pelo tempo que supostamente gasta em desenvolvimento.
Não conheço você, mas não consigo ficar oito horas escrevendo código. Tenho certeza de que cada um de vocês confirmará que, em oito horas úteis no escritório ou no computador, você realmente escreve muito menos código. E eles pagam por essas 8 horas, e o cliente pensa que são 8 horas de trabalho. Este é um sistema de duplo engano: eles estão contentes de serem enganados, e nós os estamos enganando. Portanto, eu uso o fator de multiplicação. Trabalharei por pelo menos 20, mas depois farei 3 semanas o que realmente posso fazer em 2 horas.
Ensine seus clientes e aprenda a contar você mesmo.
Bons programadores escrevem código, os melhores - tickets
Clientes e programadores estão acostumados à comunicação informal.
A comunicação informal na forma de bate-papos, telefonemas, comícios e e-mail é uma forma de comunicação que destrói o projeto e só piora o cliente e o programador.
A comunicação informal permanece no ar, não é registrada na documentação, não é monitorada, é difícil retornar a ela e dificulta a manutenção do projeto. Quando uma equipe muda, e como eu disse antes, a equipe deve mudar e mudará mais intensamente, torna-se muito importante o quão compreensível as comunicações passadas no projeto.
Se eu for a um projeto em desenvolvimento, quero entender o que foi feito no ano passado, não apenas na forma de código, mas também para ter algum tipo de explicação para esse código: por que uma estrutura ou algoritmo foi escolhido, que já expressou sua opinião sobre esse algoritmo e eu não concordo. Quero ver tudo isso, e não procurar no escritório ou conversar por alguém que me explique tudo. Preciso da oportunidade de ler isso diretamente no sistema de repositório ou ticket.
Infelizmente, na maioria das vezes os programadores seguem a liderança dos clientes. Obviamente, é do interesse do cliente ter a oportunidade de comunicação informal com o desenvolvedor. E nos encontramos fracos o suficiente e seguimos a liderança deles, ouvimos ao telefone o que deve ser feito, atendemos, ouvimos, atendemos ... e depois fazemos o que fazemos.
Depois, decorrem 2-3 semanas, e não nos lembramos mais do que combinamos. O cliente diz que não queria isso, estamos tentando provar que foi o que ele solicitou, estamos procurando alguma menção no bate-papo - a captura de pulgas começa.
Eu acho que o motivo é o medo dos sistemas de tickets. Muitos programadores com quem trabalhamos (com certeza, isso também lhe interessa) não sabem como, não gostam, não querem formular tarefas na forma de um ticket - claro e conciso.
É mais fácil para as pessoas dizerem: "Vamos conversar!" Realizaremos um comício, sentaremos juntos e decidiremos tudo. Em três horas, nos entenderemos e depois codificarei. Vou me lembrar do que combinamos e programarei tudo. ” Não esqueça nada, encontre-se novamente. E assim, de alguma forma, esticaremos de rali para rali.
Isto está errado. Nós, como programadores, devemos converter qualquer comunicação informal em tickets. Conversamos com o cliente (cliente, proprietário do produto, outro programador), descobrimos o que precisa ser alterado - convertemos qualquer comunicação em um ticket limitado pela estrutura do nosso sistema (Jira, GitHub, etc.), onde anotamos: o que não funciona, como você precisa corrigi-lo, por que você precisa corrigi-lo, que motivação e, em seguida, trabalhamos nesse ticket.
A incapacidade de um programador estruturar o trabalho em tickets pode indicar suas baixas qualificações. Eu acredito que existem dois tipos de desenvolvimento:
- Desenvolvimento contínuo - programação das 9h às 17h: cheguei, liguei o computador, depois fiz alguma coisa, lá, almoço, também codifiquei, o fim do dia - bem, amanhã continuarei. Ou seja, programamos enquanto há energia, tempo e força.
- O desenvolvimento incremental é diferente: existe a tarefa número 13, farei isso até o fim e depois ver qual tarefa será a próxima. Neste formulário, a tarefa (ticket) sempre será concluída. Mas se não houver ticket, não houver tarefa documentada, o projeto não será movido - o código não será gravado e a solicitação pull não aparecerá.
Costumo me encontrar trabalhando no primeiro cenário. Eu gosto de programar, de manhã ligo o computador - e parti. Então eu paro, paro, vamos dividi-lo em tarefas, determinar para qual tarefa iremos passar.
Na segunda versão, cada ticket termina com uma solicitação pull: aqui está o problema, sua descrição, discussão no campo desse problema, uma alteração no código. Solicitação pull enviada, verificada, aceita - ticket fechado, você pode prosseguir para a próxima.
Geralmente as pessoas trabalham nos dois sentidos. -, , : .
, 2 , pull request' 5 . . — 0,5–2 , pull request 50-100 . — - (, ) .
, , .
, — , . , , , .
. , , , . . , , , , - , . , . , , . .
. . — , . .
, , .
? !
, — . , - , . IT- , , , . , , .
, . , , , , , ,
English only .
, , — , , Swift, , , . , . , 5-10-15 , .
, . Telegram-, , . — , . , , .
, . , .
, .
. , , .
. . , -, . , , , . — . . , , , .
. , , , . , .
—
. Twitter, , Telegram- . , . .
, , , , . , , , , , — .
5-10 . 2 , , .
, . — . , , .
GitHub —
, open source , 10–15 open source, (NASA ).
, .
open source . , — . : , pull requests , , GitHub, .
open source- . open source-, , , .
, , . — open source, ? , , , — .
, — , . , , . open source- . open source community: , -, , pulll request, .
open source-, : , , — - . 2 300 followers GitHub — , 6 .
— , . -, , . , .
, . , . , , , , . — , 25 , , community .
, . , . , full-time, . , .
— , . , 20 Twitter 2 GitHub, . open source-, , . .
— .
2000 , 2019. 2029 . , , followers, , .
, . DevOpsConf Russia , , QualityConf . Saint TeamLead Conf .
— . .