Não se descreva só como 'developer'
Título vago barra conversa de salário e escopo.
Resposta direta
Título vago barra conversa de salário e escopo — o núcleo do material original é direto: Você se descreve como um desenvolvedor? Dê uma impressão certa à pessoa sobre quanto bem você é pagado e o fato de que você é um indivíduo profissional. Bem, você considerou que se descrever como um desenvolvedor afeta como você vê a si mesmo? E isso poderia, ao invés de te ajudar, pode limitar seu potencial, te segurar de se envolver em atividades fora de um papel de desenvolvimento típico. E neste vídeo, vou responder à pergunta de se é hora de parar de chamar-se de desenvolvedor.
O que o material mostra de fato
No material original, o ponto de partida não é teoria abstrata: é uma sequência concreta ligada a «Não se descreva só como 'developer'». Eu acho que os caras de operações que pareciam falar uma língua diferente. Mas porque eu estava na minha mentalidade de desenvolvedor, eu nunca realmente pensei em aprender de forma séria o que esses caras fizeram, entender a terminologia deles de servidores e balanços de carga e tráfego, entender o que tudo isso significava. Então, eu só fiquei dentro da minha caixa de formato de desenvolvedor e... De certa forma, isso me levou para trás, para progressar.
Detalhe do transcript que não pode virar genérico: E eu não sei que tipo de desenvolvimento de software você faz, mas há uma tendência, especialmente em empresas maiores, de querer contratar roles muito específicas, como pode ser um desenvolvedor de software de front-end e de back-end. Ou pode ser ainda mais específico do que isso, pode ser um desenvolvedor de back-end de API. um desenvolvedor de front-end de React. O problema com isso é que dá a impressão de que se tornar um especialista extremo é uma boa ideia. E, na minha experiência, isso é muito longe da verdade.
Contexto e motivação
O contexto importa porque a mesma ideia muda de preço conforme ferramenta, fase do produto ou disciplina pessoal. Agora, mais tarde na minha carreira, eu comecei a fazer algumas mudanças. E a primeira coisa que me promoveu... fazer isso e começar a se desmaiar da minha função de desenvolvimento, só vendo eu mesmo como um desenvolvedor, era trabalhar para uma cadeia de supermercados no Reino Unido chamada Waitrose, construindo sua loja de e-commerce online. E eu era um desenvolvedor e a equipe de DevOps estava basicamente na banca de desks ao meu lado.
Detalhe do transcript que não pode virar genérico: Eu vi grandes problemas com o servidor de integração contínua, o servidor que era responsável por deploiar nosso software para a produção. Havia problemas com isso e, porque a esse ponto eu tinha um certo nível de experiência, eu tinha visto como essas coisas podem funcionar muito bem e eu vi que o sistema que este time de DevOps tinha colocado não estava funcionando. E sabe o que? Eu vi um problema e pela primeira vez pensei... Não há razão para eu não poder resolver isso sozinho.
Como funciona na prática
Em vez de colecionar slogans, trate o conteúdo como checklist operacional: o que fazer nesta semana, o que medir, o que descartar. Porque se eu não conseguir, eu vou ficar preso nesse trabalho por quanto tempo eu vou trabalhar aqui. E eu vou ficar preso com esse foda-se de servidor de integração contínua que sempre está a quebrar e vai demorar, potencialmente, uma hora para para desbloquear nosso software quando isso poderia acontecer em 10 minutos e eu decidi começar a fixar isso.
Detalhe do transcript que não pode virar genérico: Eu comecei a conversar com o time da DevOps, eu comecei a me interessar pelo que eles estavam fazendo e isso meio que abriu um novo mundo de aprender sobre diferentes áreas que eu não considerava antes era desenvolvimento de software, olá, mas ainda é um pequeno garoto na parte de trás, áreas de desenvolvimento de software, mas eles são importantes para o desenvolvimento de software. E isso me abriu para o mundo da AWS. aprendendo como hostar software no cloud, em serviços web da Amazon, aprendendo sobre integração contínua com Jenkins e GitHub.
Erros comuns e armadilhas
Onde isso quebra na prática: quem tenta atalho sem o mecanismo descrito no transcript perde consistência rápido. Eu poderia listar todas as tecnologias, mas isso não é o importante. O importante é que quando você começa a, ao invés de apenas se ver como um desenvolvedor e que você escreve apenas código, você pode realmente se ver mais como um solucionista de problemas dentro da tecnologia. E quando você faz isso, você começa a crescer como, digamos, como um engenheiro, como um tecnologista. E as pessoas começam a notar isso e você ganha mais responsabilidade. As pessoas te veem como alguém que pode resolver maiores problemas.
Detalhe do transcript que não pode virar genérico: E na minha experiência, pelo menos, isso me levou a me tornar um líder de time e então um arquiteto técnico. basicamente me levou, no papel, pelo menos em um trabalho, a eu realmente poder escolher o que eu queria trabalhar e como eu queria trabalhar, porque eu era visto como um contribuinte valioso. Então, se você está em um trabalho, eu convido você a não confiar em si mesmo, apenas no papel de desenvolvedor. Olhar para problemas e tentar descobrir... o que você precisa aprender para resolver esses problemas.
Checklist de aplicação
Na prática, isso vira rotina: escolha um experimento curto, documente antes/depois e só então escale. E se você precisa aprender coisas que não estão estrictamente dentro da sua função de desenvolvimento, então... Então o que? Vá e faça isso. Isso pode ser divertido. Vai ser interessante. E vai resolver problemas assustadores que provavelmente ficarão sem resolver por anos se você não for e se aproximar. Agora, eu saí do meu trabalho de desenvolvimento há quatro anos para... para começar a trabalhar independentemente.
Detalhe do transcript que não pode virar genérico: E se você está pensando nas mesmas linhas como eu, ver você mesmo não apenas como um desenvolvedor é ainda mais importante se você for tomar a rota independente. E eu poderia falar sobre isso por horas, mas aqui são alguns exemplos rápidos. Se você quer aprender a construir sua própria software fora de um trabalho, Você vai ter que descobrir como, basicamente, marcar sua software para que, uma vez que você a construiu, você possa encontrar pessoas que gostariam de usar essa software.
Information gain
Ganho específico deste material (9688): preserve a especificidade de «Não se descreva só como 'developer'» — números, ferramentas e narrativa do source, sem genificar.
Próximo passo concreto
Feche o ciclo com um próximo passo observável — sem isso, o artigo vira entretenimento e some na timeline. Você vai ter que lidar com vendas, ou, em outras palavras, pedir dinheiro para as pessoas. E essas são todas atividades que você vai ter que, tipo, ficar incomodado e sair da sua mentalidade de desenvolvimento e aprender essas habilidades extras. E, na verdade, não apenas a construção de software, mas praticamente tudo que você quiser fazer. Eu vendi um curso através deste canal do YouTube e eu escrevi e vendi e-books também publicados através deste canal do YouTube.
Detalhe do transcript que não pode virar genérico: E agora, obviamente, eu estou fazendo algo que eu nunca teria pensado que eu faria se eu só pensasse em mim mesmo como desenvolvedor, que é vir para fora e gravar vídeos. falando sobre minha experiência, isso está tão longe de o que nós normalmente pensamos de desenvolvimento de sentar e escrever código em uma mesa. Eu nunca teria feito isso se eu tivesse pensado em mim mesmo como um desenvolvedor.