Ser programador pode ser interessante e divertido, mas ser desenvolvedor de software é um inferno. Os computadores são lógicos, as pessoas não. Infelizmente, na indústria moderna de software, eles não pagam pela programação. Eles pagam pelo desenvolvimento de software, e isso implica concluir tarefas em equipe - junto com outras pessoas. Os comandos são compostos de pessoas rebeldes, não de classes e métodos Java.
O sucesso de um projeto de software depende de engenheiros inteligentes, que geralmente são preguiçosos, ignorantes, egoístas, irritáveis e simplesmente infelizes. O sucesso depende de pessoas que geralmente não sabem se comunicar, compartilhar conhecimentos, liderar e obedecer e seguir as instruções. Depende da nossa capacidade de formar equipes e participar de suas atividades. E também de nossas habilidades sociais - às vezes em uma extensão muito maior do que de habilidades técnicas.
Drama Eu concordo Esse drama se aplica a cada um de nossos irmãos da profissão; portanto, se você quiser sobreviver nessa profissão, leia este livro.
Egor Bugaenko .
Hoje, o desenvolvimento de software envolve mais do que escrever código. Não se trata de algoritmos, fórmulas, bytes, arquivos ou protocolos. E não sobre instruções, operadores, testes de unidade, interfaces de usuário ou cenários de implantação. E nem mesmo sobre desempenho, escalabilidade, tolerância a falhas ou confiabilidade. Todos esses componentes são importantes, mas eles não tornam um programador mais eficaz que outro, ou alguma equipe de desenvolvedores é mais bem-sucedida que a dos concorrentes. Um papel decisivo no mundo moderno de software e hardware é desempenhado por outra coisa: não são computadores, mas pessoas.
O sucesso de um projeto de software depende de pessoas que geralmente são preguiçosas, ignorantes, egoístas, irritadas e simplesmente infelizes. Depende de pessoas que geralmente não sabem como se comunicar, compartilhar conhecimentos, gerenciar e obedecer e seguir instruções. Depende da nossa capacidade de formar equipes e participar de suas atividades. E também de nossas habilidades sociais - às vezes em uma extensão muito maior do que de habilidades técnicas.
Neste livro, você encontrará um pequeno grupo de programadores, arquitetos e executivos que são pagos para criar software. Nas próximas mais de duzentas páginas, eles resolverão problemas, contornarão situações de conflito e discutirão os recursos do trabalho em equipe. Espero que seus diálogos e monólogos ajudem você a entender a importância do aspecto social do desenvolvimento de software e, como resultado, se tornar um desenvolvedor ou líder ainda melhor.
Capítulo 1
Adrian
Ser programador pode ser interessante e divertido, mas ser desenvolvedor de software é um inferno. Os computadores são lógicos, as pessoas não. Infelizmente, na indústria moderna de software, eles não pagam pela programação. Eles pagam pelo desenvolvimento de software, e isso implica concluir tarefas em equipe - junto com outras pessoas. Os comandos são compostos de pessoas irracionais, não classes e métodos Java. Vou conseguir um emprego em uma dessas equipes e sobreviver nela. Eu posso escrever em Java, mas isso não é suficiente para o sucesso. Outras habilidades serão necessárias lá. E alguns deles ainda não foram desenvolvidos.
Mineiros e mineiros
Eu disse à secretária:
- Eu tenho uma reunião com Chris, ele está me esperando.
Algum dia terei minha secretária, meu escritório, meus programadores, minha startup com investidores e a grande missão que seguiremos. E eu serei famoso e bem sucedido. Enquanto isso, não preciso pagar pela moradia. Parece que esses caras são ricos o suficiente para lidar comigo nos próximos meses, e parece que gostaram do meu currículo. Agora tenho que convencê-los de que sonho em ficar com eles para sempre.
Como qualquer arquitetura de software é um produto das atividades das pessoas, para melhorar um produto, é necessário primeiro melhorar as pessoas.
"Na verdade, é ela", respondeu a secretária secamente.
Chris apareceu um minuto depois. Vamos para a sala de reuniões, ela oferece café, mas peço um copo de água. Ela sai e eu automaticamente pego meu telefone e verifico o Facebook. Chris volta com um copo de água e acompanhado por um cara de camiseta escura com o logotipo do GitHub. Ela diz que está muito feliz em conhecê-lo e vai embora. O nome do cara é Adrian, ele é desenvolvedor. Estamos começando uma conversa. Com suas perguntas, ele dá a impressão de uma pessoa bastante experiente. Sinto-me bastante à vontade - é óbvio que sou tecnologicamente superior a ele, portanto não há claramente nada com que se preocupar.
"Precisamos de alguém para consertar nossa arquitetura", resume Adrian depois de meia hora.
"Em vez disso, você precisa de alguém para corrigi-lo antes que possa fazer algo com a arquitetura", pensei, mas disse em voz alta:
- Ficarei feliz em ajudar. Parece-me que seu projeto é interessante tanto tecnologicamente quanto do ponto de vista dos processos de negócios. Eu realmente não gosto de trabalhar em projetos chatos, não importa quanto eles paguem por isso. Eu prefiro ser apaixonado pelo meu negócio, então quero fazer algo interessante e moderno.
Adrian sorri melancólico. Talvez ele tenha ouvido isso de cada segunda pessoa sentada nesta sala ...
Ele me faz uma pergunta difícil:
"Quando você está pronto para começar?" Quanto tempo você precisa para concluir seus projetos em andamento? Estamos à procura de uma pessoa em tempo integral.
Ele parece muito orgulhoso do que foi dito. Aparentemente, eles acham que um emprego em período integral será um bem absoluto para mim. Eu já percebi que teria de me sentar neste escritório das nove às cinco, calculando meu salário. Embora eu não tenha minha própria startup, aparentemente será. Esta semana é a terceira empresa em que estou sendo entrevistada. Os dois anteriores ainda não me responderam, embora parecesse que eu era adequado para eles. Esse cara parece muito mais desesperado. Suspeito que seus servidores falhem quase a cada duas noites e isso se tornará meu problema assim que eu assinar o contrato. Eu preciso tomar cuidado.
"Talvez uma semana seja suficiente para concluir todo o trabalho."
Eu digo o que tenho a dizer, embora agora não tenha projeto, emprego ou renda. Eu não posso lhe dizer a verdade - você deve seguir as regras do jogo. Eu tenho que parecer popular e muito ocupado. Mas, por outro lado, a promessa de concluir todas as coisas em uma semana parece lógica? Em que tipo de projeto estou trabalhando agora que posso concluí-lo em apenas uma semana? Claro, nós dois entendemos que isso é uma mentira ... mas também entendemos que não podemos fazer nada sobre isso.
Uma pessoa que promete ser leal a uma empresa imediatamente deixa de ser leal a outra.
- Há quanto tempo você trabalha nesta empresa? Peço que ele mude de assunto.
"Dois anos", Adrian responde.
- Você criou a maioria dos projetos da empresa?
- Sim, sou o primeiro desenvolvedor aqui. Há dois anos, conheci Tony, nosso cofundador e diretor técnico. Você o verá na próxima entrevista.
Eu vejo o quão respeitosamente Adrian fala dele. Tony paga-lhe dinheiro.
- Ficarei feliz em conhecê-lo! Eu respondi e terminamos a conversa.
Chris me escreveu três horas depois. Tony quer me ver amanhã de manhã. Ela diz que Adrian falou positivamente de mim. Aparentemente, eles estão interessados. As duas empresas anteriores ainda estão em silêncio, para que eu possa trabalhar para Tony. Embora eu nem saiba quanto eles estão dispostos a pagar, o anúncio diz que o pagamento é "decente".
Eu nem quero me imaginar trabalhando para outra pessoa. Posso me sentir bem à vontade no escritório deles, fingindo ser interessante para mim, rindo das piadas de Tony e perguntando a Adrian como estão seus filhos. Mas não quero escrever código para eles ou, pior, ser responsável por suas falhas técnicas. E é isso que eles tentarão fazer: colocar o máximo de coisas possível nos meus ombros.
Eu não sou uma pessoa preguiçosa. Adoro escrever código, mas fazê-lo para que a outra pessoa se torne milionária - não, obrigado. Minha vida vale mais do que o salário que eles podem oferecer.
"Quanto um empregador pode pagar?" - A pergunta certa que um especialista deve se fazer.
Sinceramente, acho que foi justamente essa minha atitude que foi a verdadeira causa dos problemas que encontrei no meu trabalho anterior (e em vários trabalhos anteriores). Todo mundo queria que eu fosse um bom funcionário, e eu queria fazer o que eu gosto: traduzir minhas próprias idéias escrevendo código em Java. Já fui demitido quatro vezes, mas tenho apenas 29 anos. Até agora, não é uma carreira muito impressionante. O que estou fazendo de errado?
Já ouvi muitas vezes de pessoas diferentes: quando o empregador o entrevista, você também deve entrevistá-lo. Essa abordagem parece correta para mim, mas não porque você precisa ser exigente ao escolher uma empresa da qual queremos fazer parte - elas são todas iguais no estágio inicial, apenas nomes, mercados e orçamentos diferentes. Devemos "entrevistá-los da nossa parte" para demonstrar que estamos especialmente interessados neles. É como conhecer uma garota2: você precisa fazer perguntas e fingir que está interessado na alma dela, e não apenas no corpo dela.
A princípio, toda nova empresa, equipe ou projeto é um mistério. Não importa quantas perguntas você faça sobre os processos de DevOps, os princípios de gerenciamento e a análise estática, porque qualquer resposta pode ser uma mentira, sua invenção ou tudo pode não funcionar como imaginam. Eu nunca ouço o que eles dizem nas primeiras entrevistas. Aqui está o que presto atenção: 1) o dinheiro que eles estão dispostos a me pagar; 2) o tamanho da equipe; 3) a posição que me será oferecida.
A questão do dinheiro é óbvia: quanto maior o salário, melhor. Não apenas por ser ganancioso e preferir a Mercedes-Benz ao invés da Chevrolet, mas também porque um bom financiamento significa que o projeto é valioso e interessante. Considere isso da perspectiva do mercado: se eles podem pagar mais do que outros, eles têm dinheiro de algum lugar.
O salário é o principal indicador explícito da importância de sua contribuição para o mercado.
Talvez eles tenham conseguido atrair grandes investidores (o que significa que eles acreditavam em suas idéias); talvez eles já estejam obtendo uma renda decente (daí resulta que o consumidor os valoriza mais que seus concorrentes). Ou talvez o fundador tenha herdado alguns milhões e investido em uma startup louca (o que significa que, em vez de serem desperdiçados em Las Vegas, esses dólares aquecem o mercado através dos negócios em que sou convidado a participar).
De qualquer forma, o dinheiro é um indicador da importância desse negócio em particular no mercado. Quanto mais dinheiro, maior a demanda do mercado por esse projeto. Quando o projeto em que você está trabalhando fica sem dinheiro, é hora de mudar para outro, mais importante para o mercado. Essa abordagem pode parecer desleal, mas ainda é verdade se você se preocupa com seus clientes, e não com os chefes que cortam seus salários a cada duas semanas.
Escolher um projeto que pague menos e que "pareça mais interessante" é injusto e ilógico. Não cabe aos programadores decidir o quanto isso é interessante e valioso. Tais decisões devem ser tomadas pelo mercado, representado por clientes ou investidores em solventes. E eles nos transmitem as decisões tomadas com a ajuda de nossos salários. Quando o salário aumenta, o mercado fica satisfeito com o que fazemos por ele. Quando o salário diminui - é hora de fazer a pergunta: por que você ainda está fazendo esse trabalho para o mercado, se o mercado não o aprecia mais?
O segundo indicador importante para mim é o tamanho da empresa. Muito pequeno e muito grande não são bons. Quando a empresa é muito pequena, os especialistas técnicos são forçados a combinar muitas responsabilidades, realizando um trabalho diversificado: escrever código, configurar servidores, preparar apresentações para investidores e até organizar móveis e consertar uma máquina de café. Do ponto de vista da carreira, isso é degradação e o risco de perder tempo. Como resultado, você terá que fazer muito trabalho que não esteja relacionado à posição imediata, apenas para ajudar a equipe a sobreviver.
As grandes empresas são muito políticas, as pequenas são muito caóticas.
E as chances de sobrevivência de pequenas empresas são bastante pequenas (como dizem as estatísticas). Prefiro ficar longe de projetos que empregam menos de 20 técnicos.
Por outro lado, todas as grandes empresas têm um tipo diferente de problema: política. As pessoas não trabalham lá - elas brigam entre si. Eu sobreviverei no nível mais baixo da hierarquia corporativa, detendo o título de "desenvolvedor sênior" e recebendo uma caneca uma vez por ano no meu aniversário, ou me tornarei um mestre da intriga em um grupo específico de cretinos. Nenhuma das opções me atrai. Então, eu não gostaria de ir para uma empresa que emprega mais de mil pessoas.
O terceiro fator em que presto atenção é a posição oferecida a mim. Estou me referindo à posição real na hierarquia. Todas as empresas são caracterizadas por uma hierarquia de funcionários, independentemente do que dizem os adeptos da holacracia. Sempre há um superior, e há pessoas que o obedecem (até o nível mais baixo). Ficar no nível mais baixo eu sempre tento evitar. Não apenas porque tenho auto-estima, mas também porque sou preguiçosa. Quanto mais baixo você estiver na hierarquia, mais trabalho precisará fazer e menos dinheiro terá. A divisão do trabalho em ação (e não apenas no campo do software).
Portanto, quanto menor a posição proposta e mais técnica, maiores serão as dificuldades: terei que trabalhar para alguém, não para mim. É exatamente isso que eu odeio fazer. Estou pronto para trabalhar duro quando sei que o resultado será meu. Porém, nas equipes de desenvolvimento com uma camada gerencial espessa, os níveis mais baixos criam uma renda consumida por níveis mais altos. Então, qual é o sentido de ficar abaixado?
Você já ouviu falar do experimento que Didier Desor e seus colegas realizaram na Universidade de Nancy? 2 Eles pegaram dez células idênticas, cada uma com cinco ou seis ratos machos. Para conseguir comida, os roedores precisavam passar por um pequeno buraco, nadar através do aquário até a calha, pegar um pouco de comida e nadar de volta para comê-la (era impossível comer diretamente da calha). Ao final do experimento, em todas as gaiolas, os ratos foram divididos em dois grupos - presa e não presa. Os mineiros nadavam por comida, e os mineiros roubavam essa comida deles.
O que essa história nos ensina? Que você trabalha ou rouba. Os ratos não sabiam dos dez mandamentos. Eles não tinham idéia de que roubo era um pecado. Parece que a natureza não tem nada contra o roubo (para ela, essa é a distribuição natural de papéis). Da mesma forma, para algumas pessoas, o trabalho é a atividade preferida. Para outros, o roubo é mais comum.
É claro que não somos ratos, e nosso comportamento é muito mais complicado, mas o princípio geral é o mesmo: trabalhamos ou atribuímos o resultado do trabalho de outros. As hierarquias de controle foram inventadas para controlar esse processo e evitar batalhas constantes (como entre ratos em gaiolas). Não lutamos mais com nossos chefes, apenas damos a eles os benefícios que produzimos, acreditando na justiça. Obviamente, eles mesmos também produzem algo, mas os benefícios que eles trazem são claramente menores e o salário é mais alto.
Quanto mais alto você estiver na hierarquia, menos precisará fazer especificamente e mais outros serão creditados a você.
Com base nisso, a posição mais conveniente para mim no sistema moderno de “mineradores e mineradores” é parecer um mineiro, mas receber pagamento como mineiro. Em outras palavras, parecer um engenheiro de software trabalhador, na realidade, praticamente não fazendo nada.
A grande maioria das equipes no campo de desenvolvimento de software não consegue que os programadores dêem o melhor de si. O manual, especialmente nos níveis mais altos, não entende a diferença entre Java e JavaScript. Por outro lado, em um nível inferior, é mais difícil enganar o chefe, fingindo estar escrevendo código, mas realmente postando uma nova postagem no Facebook naquele momento. Por isso, quanto maior minha posição, melhor. Ninguém vai entender o que estou fazendo, para poder fazer o que quero. Participo de projetos pelos quais sou pago, mas prefiro fazê-lo quando quiser e quando for realmente necessário. Não às nove da manhã.
»Mais informações sobre o livro podem ser encontradas no
site do editor»
Conteúdo»
TrechoPara Khabrozhiteley desconto de 25% no cupom -
Nosso código