Em primeiro lugar, que me chamei de "engenheiro de software"
Do tradutor:
Nós, que cortamos meras pedras, devemos estar sempre imaginando catedrais. Nós, que cortamos pedras simples, devemos sempre ver catedrais atrás delas. Todos nós nos lembramos desta maravilhosa citação do livro de Andrew Hunt “The Pragmatist Programmer. O caminho do aprendiz ao mestre. " O post abaixo, na minha opinião, é sobre isso. Seu autor - líder técnico e arquiteto Dave Taubler, fala sobre como se desenvolveu sua carreira e suas visões sobre o seu trabalho em geral: da decepção com o marketing ao que ele veio hoje, muitos anos depois. O autor compartilha algumas recomendações que considera úteis para o desenvolvimento de sua carreira e, conforme está escrito no título, fala sobre o que mudaria em sua própria carreira, se pudesse.
Minha carreira começou não no desenvolvimento de software, mas no marketing. Eu sou uma pessoa criativa e pensei que a arte de slogans e harmonias me serviria. Mas o mundo do marketing acabou sendo mais mecânico do que eu imaginava. Surpreendentemente (ou talvez não surpreendentemente), percebi que a programação - até então um hobby - me deu a energia criativa que eu ansiava. Depois de alguns empregos em marketing, encontrei um emprego em desenvolvimento web. Esse trabalho foi o início da minha carreira como engenheiro de software, desde então não voltei mais para o marketing.
A profissão era ótima. Ela pagou bem, é claro, e eu mantive meu emprego durante a crise econômica. O desenvolvimento web me permitiu trabalhar com diferentes empresas e conhecer pessoas maravilhosas. E vamos encarar, codificar é divertido, então não me arrependo. Mas ainda há algo de que lamento. Nomeadamente:
Não gostaria de me ver como um "engenheiro de software".
Não estou falando sobre chamar a si mesmo de "programador" ou "arquiteto de software" ou qualquer outra coisa; especificamente essas duas palavras não me incomodam muito. Quer dizer, sinto muito por ter definido todo o meu propósito profissional na vida para projetar software e escrever código. Porque? Na verdade, existem várias razões.
Eu me via como um obstáculo a ser removido
Eu costumava pensar em mim como um interruptor [aprox. trad. - claro que facilitador é "uma pessoa ou coisa que torna algo possível": uma pessoa ou coisa que torna algo possível. Mas, neste caso, o autor lamentavelmente fala de si mesmo como um elemento de uma cadeia, o que significa que este tipo de literalismo é apropriado aqui, pois reflete claramente o humor e a intenção do que foi dito], um elo necessário na cadeia de desenvolvimento do produto que traduz conceitos em realidade. Isso é tão importante para os negócios quanto a água para a vida. Mas ultimamente não tenho mais tanta certeza dessa autodeterminação.
Pense em como funciona o desenvolvimento de produtos. Alguém teve uma ótima ideia. Por exemplo, forneça financiamento para pessoas que não podem obter um empréstimo ou ajude artesãos a vender seu trabalho online. Mas, para transformar uma ideia em realidade, o autor da ideia precisa de alguém que tenha a experiência e as habilidades para torná-la realidade. É aqui que eu entro como engenheiro de software. Apenas me pague e eu contribuirei com sua ideia. Direita? sim. Exceto pelo que me ocorreu: não sou realmente um assistente. Eu sou um obstáculo. Eu sou o que realmente fica entre a ideia e sua incorporação. O que precisa ser removido. Em outras palavras: você acha que eles queremas pessoas contratam outra pessoa para implementar ideias? Se eles pudessem, digamos, apenas pressionar um botão ... eles não escolheriam um botão?
Claro, esse botão não existe. Ainda não. Mas a indústria está caminhando lentamente nessa direção. Há muito tempo, para fazer um site simples, era preciso contratar alguém como eu. E agora, com ferramentas como o Wix, quase qualquer pessoa pode arrastar e soltar até um site bastante avançado ... Nenhum programador necessário! As plataformas de desenvolvimento de baixo código também reduzem a necessidade de engenheiros de software.
Mesmo as próprias linguagens de programação estão gradualmente (embora lentamente) sendo simplificadas; escrever se torna mais fácil. Afinal, qual é o objetivo de uma linguagem de programação senão preencher a lacuna entre as instruções humanas e como o computador executa as instruções? Não me entenda mal. Não acho que a demanda por engenheiros de software irá desaparecer em breve. Mas ... dotar-se de habilidades que estão gradualmente perdendo seu valor? Essa carreira começou a parecer pouco confiável para mim. E isso me levou ao meu segundo problema:
Eu desenvolvi um cinismo injustificado
Quando comecei, Java era um novo produto quente. Então eu mergulhei de cabeça. E eu me lembro de alguns programadores C e C ++ obstinados que odiavam Java. Claro que eles tinham motivos. Mas me pareceu que essas razões, em muitos casos, estavam simplesmente mascarando a ameaça existencial que os programadores sentiam. A capacidade de programar veio com grande dificuldade. Então veio o Java, que abstraiu muitas das dificuldades de C e C ++. De repente, descobriu-se que todo um fluxo de novos programadores poderia fazer seu trabalho.
Alguns anos depois, comecei a sentir que estava no lugar desses programadores. Reflexivamente, encontrei e acentuei falhas em qualquer linguagem ou tecnologia que eram supostamente mais simples do que o que eu conhecia. Claro, eu tinha e minhas razões para fazer isso. Mas muitas vezes eram mais como racionalizações criadas posteriormente. Então o que aconteceu comigo? Já faz muito tempo que criei meu conjunto favorito de ferramentas de programação e não queria desistir. Meu objetivo não era aplicar tecnologia para resolver problemas, mas aplicar habilidades específicas de desenvolvimento de software que já havia aprimorado. “Se essas habilidades se tornarem desnecessárias, meus objetivos também não serão necessários”, pensei. E então eu construí uma parede defensiva de cinismo. O mesmo sobre o qual em outros programadores, muitos anos atrás, eu me perguntei.
A questão é que manter esse cinismo em você mesmo pode ser exasperante e exaustivo. Na verdade, percebi um círculo vicioso: quanto mais me defendo de minhas próprias habilidades, menos quero aprender coisas novas.
Limitei meus horizontes profissionais
Trabalhei em muitos setores ao longo da minha carreira. Redes sociais, streaming de música, tecnologia financeira (fintech) e até edição de fotos. Embora eu tenha experiência em muitos setores, nem sempre sou bem versado em uma área específica. Ao mesmo tempo, percebi que alguns de meus colegas engenheiros permaneceram no mesmo setor ao longo de suas carreiras. Um colega, por exemplo, era apaixonado por fotografia, então se especializou em softwares de edição de fotos. Outros colegas dedicaram toda a sua carreira à tecnologia financeira.
O fato é que, em primeiro lugar, eles se interessaram por seus setores. Programar era simplesmente um meio pelo qual meus colegas participavam de seus setores e ganhavam a vida.
No começo, pareceu um pouco estranho para mim. Se você escreve código, pensei, não deveria se definir como engenheiro de software? Claro, eu faria um esforço para estudar qualquer área em que minha empresa atual atue. Mas muitas vezes eu pensei que era um mal necessário e que deveria prestar mais atenção para aprimorar minhas habilidades técnicas. Então por que isso importa? É claro que muitos engenheiros tiveram carreiras de sucesso com foco quase exclusivamente em software e tecnologia, não é?
Crescimento profissional
Em retrospecto, percebi que parte do problema era como eu pensava. Quando pensei sobre meu papel no trabalho como programador, tendia a apenas concordar. Outras pessoas conhecem o negócio , eu defini por mim mesmo, e por isso podem priorizar o trabalho da minha equipe . Eu estava na empresa apenas para fazer meu trabalho. Enquanto me concentrava no desenvolvimento de software, raramente me ocorria que tinha aspirações maiores.
Mas, para ir além da função de um engenheiro sênior, precisamos entender o negócio. Independentemente de estarmos percorrendo a rota do Gerente / Diretor ou Engenheiro-Chefe / Arquiteto, começaremos a tomar decisões de alto nível em nome da empresa. Compreensivelmente, quando assumi uma posição de liderança pela primeira vez, não me senti à vontade em focar em questões de negócios. Mas quando me acostumei a pensar em nome do negócio, me senti livre. Foi como descobrir um novo conjunto de habilidades. Se você almeja ainda mais alto, o foco está ainda mais no negócio. A experiência dos engenheiros da indústria está se tornando vital. E aqueles meus colegas de que te falei? Muitos deles deixaram totalmente o mundo da engenharia e foram promovidos no mundo dos negócios. Posteriormente, alguns partiram para fundar suas startups em tecnologia financeira.
Felicidade na carreira
Por mais que eu goste de programar, acho difícil manter a paixão por escrever código dia após dia. Para ser realmente feliz em sua carreira, é importante saber, é importante ter uma visão geral de como meu trabalho está mudando o mundo para melhor.
Além disso, gostaria de fazer o que alguns de meus colegas fizeram, que é dar um passo para trás e entender o que realmente valorizo neste mundo. Muita coisa é importante para mim: música, educação, mudança climática, etc. Se eu pudesse voltar atrás e mudar algo em minha carreira, isso é o que eu mudaria: eu decidiria quais são meus valores e quais problemas eu quero resolver neste mundo. E então eu aplicaria todas as minhas habilidades, técnicas e não técnicas, para resolver esses problemas.
Como ir além da engenharia de software
Esta história pode não agradar a todos que escrevem software para ganhar a vida. Existem muitos leitores que amam seu setor mais do que sua linguagem de programação. Quem se sente confortável o suficiente para saltar de C # para JavaScript e daí para ir. Quem sem problemas abre mão do que já aprendeu quando a solução parece mais fácil. Mas se essa história ressoa em você, continue lendo. Com o tempo, mudei minha atitude em relação à minha carreira e não há razão para que você não possa fazer o mesmo. Abaixo estão algumas dicas que considero úteis.
Mergulhe em outras tecnologias
O que vai curar nossa relutância em abandonar a tecnologia com a qual estamos acostumados e confiamos? Imersão em outras tecnologias. A maneira mais fácil de fazer este mergulho é em um projeto paralelo: o software que criamos nós mesmos quando o horário de trabalho acaba. O principal é mergulhar fundo em uma linguagem que não nos é familiar. Estou falando sobre duas coisas:
- Escolher um idioma completamente diferente fora de nossa zona de conforto. Por exemplo, se você está familiarizado com Java, não mude apenas para Kotlin; tente Go, Python, Rust ou NodeJS.
- Na definição do complexo no sentido de completar o projeto Não trabalhe apenas com o tutorial. Estabeleça uma meta elevada para si mesmo, que o fará realmente aprender o idioma para alcançá-la.
De fato, tenha como objetivo aprender um novo idioma tão bem que possa conseguir um emprego com esse idioma por dinheiro. Eu fiz isso há muitos anos. Eu era um arquiteto de software focado no back-end Java. Mas como um projeto paralelo, ajudei um amigo a construir um aplicativo iOS e um aplicativo de desktop Mac. Isso me deu as habilidades para mais tarde ingressar em uma conhecida empresa de streaming de música para ajudá-los a criar um aplicativo iOS.
Você precisa de mais do que apenas diferentes linguagens de programação: você precisa mergulhar em ferramentas que sejam independentes de linguagem. Por exemplo, sujou as mãos o máximo possível no Docker e no Kubernetes. À medida que eu ficava cada vez melhor no desdobramento e orquestração de imagens, tornava-me menos preocupado com o que havia nessas imagens.
Ou vamos pegar as tecnologias de nuvem. No passado, eu minimizava o papel das tecnologias sem servidor porque não tinha experiência com elas. Mas, pela última vez, também os abracei. Por exemplo, em um trabalho recente, tentei implementar AWS Lambda em nossa arquitetura de microsserviços. E trabalhou em um projeto paralelo em que o GCP Cloud Functions é amplamente usado.
Quanto mais me imergia nas novas tecnologias, mais livre me sentia. Já não me sentia obrigado a determinadas competências, mas sentia mais flexibilidade e preparação para resolver problemas utilizando as ferramentas mais adequadas disponíveis.
Concentre-se na visão geral do design
Como muitos engenheiros de software, comecei a prestar menos atenção à programação prática e mais focado em problemas gerais. Gerenciar outros engenheiros e focar na arquitetura me ajudou a me livrar do meu tempo pessoal investindo em algumas das tecnologias que a equipe estava usando. Além disso, essa abordagem permite focar em outras áreas do negócio. Recentemente, fiz parte de uma equipe multifuncional que liderou uma nova iniciativa de produto. Dito isso, passei mais tempo trabalhando com gerentes de produto e designers envolvidos no desenvolvimento de produtos do que trabalhando com código.
Uma pequena advertência. Como chefe do departamento de engenharia, é sempre importante para mim não perder de vista as tecnologias que a equipe utiliza, estar pelo menos um pouco atento. Claro, nossa equipe pode querer usar linguagens e ferramentas que vão além de suas habilidades pessoais. Não é ruim; pelo contrário, é uma grande oportunidade de aprender com a equipe. E acredite em mim, a equipe vai adorar se dermos a eles a oportunidade de nos ensinar algo.
Torne-se um Homem de Idéias
Anteriormente, apresentei uma visão simplificada de como os produtos nascem. Alguém tem uma ideia e outra pessoa a implementa. Então pensei: o que ser desenvolvedor, por que não se tornar autor de uma ideia?
Projetos paralelos
Até agora, o objetivo de meus projetos paralelos tem sido manter minhas habilidades de engenharia existentes ou aprender novas tecnologias. Em essência, esses projetos constituíram os exercícios glorificados do Hello World.
Agora começo com a própria ideia. Eu proponho algo que acho que será útil, mas idealmente será algo novo. Às vezes é uma ideia que pode se transformar em um produto. Em outros casos, essa ideia só é útil para mim. A questão é que me concentro principalmente na ideia.
Então, eu me desafio a encontrar a melhor maneira de dar vida a essa ideia. Talvez a implementação esteja relacionada à escrita de um aplicativo monolítico em Java. Ou talvez seja um front-end JavaScript / React, suportado principalmente por serviços em nuvem e vinculado a um pouco de código Go. Talvez estejamos falando sobre tarefas que não estão relacionadas à programação de forma alguma.
No trabalho
Também comecei a exercitar esse bom senso no trabalho. Era uma vez, eu estava procurando projetos nos quais pudesse usar minhas habilidades específicas de programação. Afinal, fui contratado para essas habilidades especiais, certo? Mas aos poucos fui percebendo que fui contratado principalmente para resolver os problemas da organização. Comecei então a procurar os problemas que mais precisavam de solução e descobri como resolvê-los. Em muitos casos, a solução está relacionada ao software. Mas comecei a aproveitar os momentos em que a decisão não era relacionada a software, porque naquela época eu estava expandindo meu escopo e cruzando fronteiras, focando mais no lado comercial das coisas.
É mais fácil falar do que fazer? Talvez. Claro, isso depende da disposição de nosso empregador em desistir da programação em um ritmo muito rápido. Mas descobri que muitas empresas ficam mais do que satisfeitas quando os engenheiros desejam tomar a iniciativa de resolver problemas que vão além da esfera de escrever software. E se nossa empresa não apoiar a iniciativa? Então lembre-se de que somos engenheiros de software ... Podemos ser um pouco exigentes sobre para quem trabalhamos.
Se você quiser mergulhar em outras tecnologias, como o autor do post aconselha, nós, de nossa parte, estamos prontos para ajudar com nosso conhecimento, mentores experientes e suporte. Vai ser difícil, mas interessante. E não se esqueça do sempre ativo código promocional HABR - que vai agregar 10% ao desconto no banner.
Outras profissões e cursos
