Recentemente, fui contratado para trabalhar para uma pequena empresa como desenvolvedor freelance C ++ / Racket. Eles são especializados em serviços médicos para clínicas e médicos. Como eles são uma equipe muito pequena (acho que cerca de 6 a 10 pessoas juntas), a maioria deles são formados em biologia / medicina com apenas muito pouca experiência em programação. Seu último programador desistiu porque eles eram pequenos demais para ele, ou pelo menos é o que diziam.
Na semana passada, tive meu primeiro pequeno projeto trabalhando para eles. Nada importante, apenas uma função lenta de exportação de CSV que precisava de conserto, já que aparentemente a exportação travou a máquina do cliente – ele tentou exportar um grande banco de dados de pacientes clínicos, cerca de 10.000. Portanto, aqui estão algumas coisas que aprendi enquanto resolvia o problema.
1. Ler código não comentado é horrível
Eu ouvi sobre aqueles programadores misteriosos que nunca comentavam muito seu código durante meu tempo na universidade, mas nunca encontraram nenhum deles até agora. Os únicos comentários no código que encontrei eram, a julgar pelo conteúdo, de outro programador, desesperado enquanto tentava entender as linhas místicas que estavam diante deles. Exemplo:
// Constructor for a new list that recieves an item and has an int-Value
// Frankly, I've no idea what this is good for, but it must have seemed a rather nice idea at this timeEntão, sim, pense nas pessoas pobres que em algum momento no futuro terão que ler seu código e comentá-lo. Tive a sorte de o código em si não ter sido escrito de forma tão horrível, mas estremeço ao pensar no que teria feito se estivesse.
2. Os não programadores subestimam sua carga de trabalho
Devo escrever um breve relatório sobre o tempo que considero necessário para concluir qualquer projeto antes de começar oficialmente o trabalho. Por causa do código horrível e não comentado, não pude estimar totalmente o que teria que fazer para corrigir o problema – apenas otimizar a exportação CSV, reescrevê-la ou talvez até mesmo armazenar os dados do programa em dados completamente diferentes estrutura mais eficiente. Todas eram possibilidades válidas após cerca de uma hora de leitura do código. Portanto, estimei cuidadosamente 10 horas, ou cerca de dois dias úteis para a tarefa. Ao receber o relatório, os superiores disseram que eu poderia começar meu trabalho, mas minha carga de trabalho estimada era um pouco alta. A resposta que lhes escrevi leva-me ao meu terceiro e último ponto …
3. Usar uma ferramenta de controle de tempo é inevitável
… se você for freelance e for pago por hora. Não pesquisei muito sobre ferramentas de controle de tempo, basicamente apenas uma rápida pesquisa no Google, mas acabei ficando com o Klok . Respondi que estava usando uma ferramenta de controle de tempo, que também seria capaz de imprimir um relatório de tempo total de trabalho, se necessário. Eu refletiria o tempo real na conta final, então se eu precisasse de apenas 5 horas, eu cobraria apenas 5. Se acabasse precisando de 15 horas, teria o software ao meu lado, “provando” meu tempo – provando entre aspas porque é claro que alguém poderia simplesmente deixar o software rodando enquanto assiste TV, mas vamos supor que somos todos pessoas honestas aqui.
Então, sim, isso é basicamente o que aprendi na minha primeira semana de trabalho como desenvolvedor freelance. Basicamente, acabei percebendo que teria que reescrever completamente a exportação CSV, com a qual eu estava quase na metade quando recebi um e-mail informando que o cliente aparentemente não recebeu mais nenhum erro .. meu contato na empresa se desculpou pesadamente e garantiu Eu, seus clientes não eram normalmente assim e que eu obviamente seria pago pelas horas que trabalhei até agora, mas ainda assim, um final meio engraçado, ou assim eu acho.