4 erros que cometi como programador, mas tive que me tornar um CTO para vê-los

51

Trabalhei como programador por mais de cinco anos. Não é impressionante, já que alguns de vocês provavelmente têm três vezes mais experiência de trabalho, mas eu gostava de pensar em mim como um desenvolvedor sênior. Isso soa sério e importante, não é?

Um dia, recebi uma proposta para trabalhar como Chief Technology Officer (CTO) na startup de tecnologia med. Depois de algum tempo neste novo trabalho, posso olhar para trás e dizer, eu não era um desenvolvedor sênior. Não me faça mal – eu ainda acredito que tenho excelente conhecimento sobre programação, especialmente desenvolvimento web – mas, se esse é o caso, por que eu disse que não era um veterano?

Por causa dessas quatro coisas que tenho na minha cabeça agora.

1. O usuário é um

Não, não estão.

Sim, os usuários usam o aplicativo de uma maneira inesperada, muitas vezes estranha.

Sim, os usuários podem fazer perguntas que parecem muito estúpidas.

Sim, às vezes os usuários exigem recursos que parecem inúteis.

Sim, os usuários têm dificuldades com funções que parecem ser autoexplicativas.

O usuário não é um especialista. Meu médico não exige que eu saiba a diferença entre lipoproteínas de baixa densidade e alta densidade. Então, por que eu costumava assumir que os usuários deveriam saber que tipo de navegador eles usam? É óbvio para mim e para você, mas minha mãe acha que o Google e a internet são sinônimos. Ela diria que não usa nenhum navegador porque usa o Google.

Às vezes, para fazer o usuário feliz, eu tinha que substituir partes de estrutura para alterar seus comportamentos padrão. Às vezes eu tinha que adicionar suporte para navegadores que eu não queria (saudações para usuários do Safari ). É bobagem quando estou falando sobre isso hoje, mas naqueles dias eu realmente pensei que era culpa do cliente quando eu tinha que fazer algumas soluções alternativas no meu código apenas por causa de suas exigências personalizadas.

2. Meu código é uma arte e tem que ser perfeito

Código limpo, testes unitários, ótima documentação — são coisas sem dúvida importantes. Como programador, eu sempre quis escrever código limpo usando padrões modernos, e eu frequentemente verificava se todas as dependências de um projeto estavam atualizadas, etc. Eu queria ser o Bom Programador.

Quando meu gerente de produto me pediu para largar os testes da unidade para aumentar a velocidade de desenvolvimento, fiquei com raiva — ele não percebeu a importância dos testes unitários? Não tínhamos outros testes automáticos, então os UTs eram nossa única esperança de tornar o produto estável e livre de regressão.

Esta decisão parecia ser míope para mim. Além disso, ele sugeriu que parássemos de escrever documentação e converter código para arquitetura menos complexa (poderíamos fazer isso já que estávamos no início do projeto).

Ok, eu concordo que isso vai acelerar o desenvolvimento por um tempo, mas teremos um monte de problemas no futuro. Vamos perder muito tempo consertando bugs de regressão, e a nova arquitetura será muito simples quando o projeto crescer! E como vamos introduzir novos programadores ao projeto sem uma boa leitura?

Publicações Relacionadas

Passamos horas discutindo o quão ruim é essa decisão – e quanto ela vai nos custar no futuro.

O projeto falhou alguns meses depois porque excedeu drasticamente o orçamento.

Anos depois, tenho que admitir a verdade: nossa equipe cometeu um grande erro. Pensamos no futuro e esquecemos do presente. Ignoramos completamente as circunstâncias – um orçamento pequeno e a necessidade de criar um MVP em pouco tempo.

É ótimo fazer código que você pode mostrar aos outros e se orgulhar. Mas é ainda melhor terminar projetos com sucesso. Afinal, programação não é arte.

3. Eu vou usar “X” para este projeto porque eu sei que

Na minha empresa anterior, criamos todos os projetos com a mesma pilha de tecnologia: Symfony e Angular. por que? Symfony é a melhor estrutura de backend? não. Talvez angular é a única maneira de criar um frontend moderno? não. Sempre escolhemos esse conjunto de tecnologias porque não consuíamos os outros tão bem quanto estes. Essa era a nossa zona de conforto, mas é errado selecionar tecnologias conhecidas para novos projetos? Isso depende.

Em muitos casos, seu próximo projeto é mais ou menos semelhante aos anteriores. Não faria sentido gastar muito tempo aprendendo novas tecnologias, já que você já tem soluções comprovadas. Mas às vezes, pode ser a decisão errada a tomar.

Lembro-me do projeto onde um WebSocket bem trabalhado era o requisito mais importante. O que escolhemos para criar nosso backend? Symfony, claro. Talvez hoje seja mais fácil criar WS em PHP, mas naqueles dias foi um pesadelo. Passamos muito tempo fazendo dar certo. Quero dizer, muito. Estávamos cientes de quanto tempo (e dinheiro) custaria para construir O WS com base no PHP, mas jogamos fora a ideia de usar o Node. por que? Eu realmente não sei. Em Node, construiríamos API 10x mais rápido, mas essa não era a pilha de tecnologia da nossa equipe.

Estou muito feliz que os programadores da minha equipe atual são mais de mente aberta do que eu era. Na semana passada decidimos mudar completamente a tecnologia usada para construir parte do nosso sistema. Tenho certeza que essa decisão nos poupará muito tempo, mesmo que signifique aprender algumas coisas do zero.

4. Meu proprietário/gerente de produto está errado, eu faria melhor

Quando eu trabalhava como programador, minha relação com o gerente de produto era… durão. Sempre que ele me contava sobre novas mudanças no escopo da tarefa, eu dizia:

Por que você não pode apenas fazer o seu trabalho e definir o escopo antes de eu começar a trabalhar?! É tão difícil decidir com antecedência como esse recurso deve funcionar?

Isso foi tão ingênuo, mas eu realmente pensei que era fácil. Agora entendo perfeitamente como pode ser desafiador planejar cada detalhe do projeto. Você tem que levar em consideração as limitações da tecnologia e do orçamento (que são a mesma coisa na verdade), você tem que pensar nos usuários que vão usar o seu produto, você não pode esquecer os requisitos de negócios e marketing. Às vezes, alguns dos requisitos não são conhecidos no início; às vezes, as circunstâncias dos negócios mudam, e às vezes você tem que construir algo primeiro para descobrir que pode ser feito melhor.

Outra coisa : os gerentes de produtos podem cometer erros. Isto é simples assim. Programadores fazem bugs, PMs também. É tão óbvio quando penso nisso agora. Eu seria melhor programador se percebesse isso antes. Em vez de tentar mostrar o quão errados eles estão, eu deveria me concentrar em encontrar soluções.

É irônico e triste, mas em algum momento, esqueci que eu e os gestores temos o mesmo objetivo — fazer um ótimo produto. Eles tinham um conhecimento muito mais amplo do que eu sobre orçamento, circunstâncias de negócios, requisitos do lado do cliente, prazos e prioridades. É por isso que eu não entendi algumas de suas decisões.

resumo

Para alguns de vocês, essas quatro coisas podem ser óbvias. Se você está trabalhando em uma grande equipe ágil organizada com um bom líder, e você tem em mente as regras básicas do UX – Estou muito feliz. Presumo que possa ser um programador muito melhor do que eu. Porque “ser um bom programador” não é apenas sobre habilidades técnicas. É ainda mais importante entender qual é o valor que você pode trazer para a empresa e como fazê-lo.

Um desenvolvedor sênior não é alguém que conhece todos os aspectos da tecnologia. É uma pessoa que vai ajudar nossa empresa a construir um grande produto, mesmo que isso exija que eles cruzem uma fronteira de sua zona de conforto. Soluções sobre problemas.

você pode gostar também