Tenho codificado, dependendo de como você mede, há cerca de 10 anos. Ganhar dinheiro com isso por 6. Fazendo isso todos os dias por 17 meses. Mas meu projeto atual é o primeiro que posso realmente dizer que é “grande”.
Claro, outros projetos levaram meses – alguns levaram mais de um ano do início ao fim (incluindo todas as correções de bugs e mudanças do cliente e assim por diante) – mas poucos realmente se sentiram grandes no escopo do que resta a ser feito e é o impacto potencial.
Não posso dizer com precisão o que estamos fazendo ainda (poderia, mas meu chefe teria um ataque de merda), mas um resumo muito vago é “um processador MIMP distribuído, produzindo visualizações preparadas em enormes conjuntos de dados discretos”. Ah, e é em tempo real. E apenas transbordando com a frase “embaraçosamente paralelo”.
Então, agora que estamos há cerca de 3 meses e cerca de 6 semanas de lançar algo em forma aproximadamente “beta”, acho que é um bom momento para resumir meus sentimentos até agora:
Planeje primeiro, codifique depois : cada decisão errada leva o dobro do tempo para ser corrigida, porque você precisa desfazer todas as suposições feitas com base no código anterior.
Mas não tenha medo de refatorar : não importa o quanto você planeje, você deixará algumas ideias ruins escaparem. Só porque algo é difícil, não deixe que isso o impeça de reescrever grandes partes do programa. Quanto antes você trocar algo grande, mais barato ficará. Em um post anterior, escrevi sobre a mudança do Beanstalkd para o Redis para nossa fila de mensagens: embora o beanstalkd funcionasse, ele não forneceu alguns recursos importantes e a mudança levou a outras otimizações para processamento de dados.
Pense com pelo menos um mês de antecedência : embora tivéssemos planejado o produto principal antes de começarmos, a necessidade de alguns novos recursos tornou-se aparente; contanto que eles não sejam colocados na linha do tempo para o marco atual, geralmente não é um problema. No entanto, só porque algo não é importante agora , não significa que você não deva pensar nisso. Considere as implicações técnicas e de negócios dos recursos planejados quando precisar de algum tempo de inatividade; quanto antes você apresentar uma solução técnica, mais tempo terá para pensar por que errou.
Às vezes, você deve simplesmente ir para casa : muitas vezes há a tentação de passar a noite inteira codificando. Embora “o groove” seja definitivamente uma ferramenta poderosa, às vezes é fácil fingir que você está nele quando na verdade você passou os últimos 20 minutos alternando entre o mesmo arquivo e o Reddit. Voltar para casa não é admitir a derrota.
Um ambiente ruim é seu pior inimigo : trabalho em um escritório com vários outros desenvolvedores, alguns vendedores e alguns outros funcionários. É bastante natural que, com 20 pessoas em um espaço de aproximadamente 1.500 metros quadrados, fique muito alto com todas as conversas e telefones tocando … mas, por mais “normal” que seja, destrói absolutamente qualquer capacidade de entrar na zona. Ficar depois do trabalho costuma ser a melhor maneira de fazer as coisas – sem distrações além de alguns alto-falantes tocando música fácil, e 8 horas voam fazendo tanto trabalho quanto 20 quando todo mundo está por perto.
Todo mundo se importa menos do que você : muitas vezes me esqueço, depois de passar os últimos meses pensando quase nada além desse projeto, que outras pessoas estão envolvidas nele tanto quanto eu. Outras pessoas podem estar mais relaxadas, ou menos verbais sobre o que estão pensando, ou apenas trabalhando em algo com o qual você não está familiarizado (e, portanto, não consegue avaliar a complexidade), mas é definitivamente uma armadilha que sempre tenho que me desvencilhar from: são outras pessoas comprometidas com este projeto e estão se esforçando tanto quanto você.
Tenho certeza que nos próximos meses terei mais pensamentos aleatórios para compartilhar. sinta-se à vontade para comentar abaixo com palavras sábias de sabedoria sobre o que eu preciso cuidar!