Eu tinha um contrato de 12 meses (moro num país onde isso não é comum para novos desenvolvedores) até duas semanas atrás, quando a gerência da minha empresa me fez uma oferta e um aumento para me tornar um funcionário permanente para eles. Eu gosto de manter meu currículo sempre atualizado (especialmente com o COVID), então eu pesquisei no Google sobre a inclusão do mesmo no meu currículo.
O conselho que encontrei foi que eu geralmente deveria listar o feito que motivou a contratação. É justo.
O problema é que a realização estava sempre a cumprir os prazos apertados dos clientes e, francamente, fi-lo ao decidir que a engenharia poderia ser menos do que estelar em casos específicos (que a gerência concordou).
I'sou um devoto relativamente júnior numa equipa de 6 programadores. No entanto, eu me tornei rapidamente um dos desenvolvedores que mais confia na gestão do devs quando eu digo que vou entregá-lo e mantê-los informados sobre os trade-offs relativos para chegar lá. No meu reconhecidamente curto tempo aqui, eu sempre fui capaz de enviar algo quando eu disse que podia enviá-lo.
Já tive alguns casos como este, mas este foi o que fiz mesmo antes de me oferecerem o emprego permanente. Um dos nossos produtos é um API em lote que é chamado uma vez por dia por um único cliente. Ele não precisa devolver nada, exceto um CSV de entradas falhadas via e-mail. Eles queriam um novo recurso adicionado e o vendedor concordou contratualmente em tê-lo para eles até o final do mês. Por várias razões, esse pedido de recurso não'não nos chegou até segunda-feira da última semana do mês.
O desenvolvedor sênior disse ao gerente que o desenvolvimento não poderia't ser feito corretamente e para dizer ao cliente que ele não poderia't ser feito. Eu não't contradigo os desenvolvimentos sénior nas reuniões de planeamento de sprint, mas talvez fosse óbvio que eu não concordava com o tipo sénior. Tipo, não discordava, mas existia uma opção com certas trocas. Os outros devs também são bastante passivos, então ninguém mais o contradisse também. O gerente não ficou feliz com isso, pois o cliente já está com raiva de nós por não entregarmos quando prometemos fazer isso. O gerente então me chamou ao seu escritório após a reunião para perguntar se eu via uma alternativa. Eu disse a ele que eu poderia conseguir algo para trabalhar, mas provavelmente dobraria o tempo de processamento da API (que adicionaria 4 minutos) já que eu não tenho nenhuma habilidade SQL especializada. O gerente concordou e aparentemente o cliente não'nem notou.
Não sei quais teriam sido as consequências de faltar o prazo, mas foram suficientemente íngremes para que o CEO da nossa empresa de 1000 pessoas me enviasse um e-mail de agradecimento por tê-lo entregue.
Outro caso não atraiu tanta atenção, mas havia um processo que precisávamos executar em uma base de dados. A forma correcta de o fazer teria sido escrever um processo batch adequado no sistema mega Java que utilizamos, enviá-lo através de todos os processos regulares de GQ, e deixá-lo sair no final duas semanas depois. Eu ofereci ao gerente um script Python que precisaria ser executado manualmente e seria horrivelmente ineficiente (teria que executá-lo durante a noite), mas se acionado uma vez por mês, manteria o problema à distância até que uma correção permanente chegasse. Este era um problema de produção, então ele concordou com isso como uma medida provisória. Isto era basicamente apenas um loop barato que verificava as linhas para um certo tipo de dados errados e os re-formatava.
Existe uma maneira de listar este tipo de coisas no meu currículo que não'não me faz parecer um programador de hackers que minam os devs seniores? Admito que as minhas soluções não são tecnicamente sólidas, mas eram sólidas para as necessidades do negócio na altura e a ineficiência foi em grande parte irrelevante na maioria dos casos.
Você encontrou várias maneiras eficazes (não eficientes) de resolver problemas sem super-engenharia e "Done é melhor que perfect"
Encontrar uma solução que seja suficientemente boa é uma habilidade importante para um engenheiro, pois de outra forma você gastaria muito tempo otimizando algo que não vale a pena ser otimizado. Se algo não é usado com frequência, muitas vezes's não vale a pena otimizá-lo. Existe um bom XKCD-Comic com uma tabela que lhe diz quanto tempo você deve investir em algo.
Uma solução só vale alguma coisa se for (ou puder ser) usada, por isso com um hack você habilitou o cliente a continuar trabalhando até que você tenha uma solução.
Não há razão para dizer a ninguém que não concordou com o seu supervisor. Basta ir para algo como "Capaz de produzir soluções eficazes sob pressão de tempo".
admito que as minhas soluções não são tecnicamente sólidas, mas foram sólido para as necessidades do negócio na altura e para o comércio ineficiente off foi em grande parte irrelevante na maioria dos casos.
Você tinha um trabalho: " encontre uma solução que funcione dentro dos limites de tempo que resolvam o trabalho". E foi exatamente isso que você fez.
Tenho a sensação de que só a gerência tem dado respostas aqui, porque não houve nada mais do que elogios no cumprimento de prazos irrazoáveis.
Há aqui outro ponto de vista. Não se deve subestimar os distúrbios sociais que se inflama dentro da equipa de desenvolvimento quando a gerência corta os cantos e ignora as opiniões dos programadores seniores. Há um ditado que se aplica mais ou menos assim:
Enquanto houver alguém que esteja constantemente a extinguir o fogo, a gerência não deixará de brincar com fósforos.
Uma coisa é se uma vez/duas vezes se for obrigado a fazê-lo, mas uma coisa completamente diferente se estiver a obter a norma. E pela sua descrição, parece-me que a gestão se tornou bastante confortável com a prática de o utilizar para cortar os cantos. Deveria considerar seriamente levantar esta questão à sua gerência e aos seus superiores, a fim de manter um ambiente de trabalho saudável. Uma empresa é um equilíbrio entre o dev e a direcção e não simplesmente uma estrutura de cima para baixo. Há uma razão pela qual a palavra "não" existe e deve praticar a sua utilização.
No entanto, esta é ainda mais uma questão de gestão do que a sua. Por conseguinte, não há razão para de alguma forma mencionar isto no seu currículo. Por isso, eu concordaria com isso:
capaz de cumprir prazos
Como diz o ditado "Perfeito é inimigo do bem" - fazer compromissos técnicos para satisfazer as necessidades do negócio é praticamente de rigueur. Os bons devs/programadores/engenheiros são aqueles que podem identificar os acceptable trade-offs que podem ser feitos.
No seu exemplo de API o cliente estava claramente mais disposto a aceitar um atraso de 4 minutos no processamento de algo que funcionava e era entregue a tempo.
Idealmente você deveria estar procurando minimizar o débito técnico ao fazer esses compromissos - mas isso'é tudo parte e parcela de experiência e saber onde você pode barbear o tempo e quando você precisa garantir que algo seja feito "certo" a fim de economizar mais tempo a longo prazo.
A minha pergunta fundamental é: existe uma maneira de listar este tipo de coisas no meu currículo que não'não me faz parecer um programador de hackers que minam os devs seniores?
Quando chegar ao topo do seu currículo lá's não precisa de entrar nas especificidades da sua solução - pode simplesmente dizer que tem um bom historial de cumprimento de prazos em projectos sensíveis ao tempo e mencionar os exemplos sem detalhes da implementação real.
O que você faz NÃO é " hacking", é " encontrar soluções".
Eu trabalho como desenvolvedor e consultor há 20 anos, e esta habilidade é o que os empregadores buscam: Don'não deixe isso fora do seu currículo, mas enfatize exatamente isso: Você tenta encontrar soluções, mesmo que isso signifique ir "incomum" caminhos.
Don'não escreva que você faz isso nas costas dos desenvolvedores seniores, mas que você faz isso sempre que lhe pedem soluções, mesmo que os caras mais experientes discordem / digam que não é possível.
Há uma grande citação que se diz ter vindo de Albert Einstein que descreve exactamente a sua situação:
Todos sabiam que era impossível, até que um idiota que não sabia'não sabia e o fez.
Eu trabalhei com muitos desenvolvedores e conheço todas as facetas disso:
Eu trabalhei com um desenvolvedor que está entre os 1% melhores especialistas em JavaScript no stackoverflow. Ele é um gênio e eu realmente admiro cada linha de código que ele escreve. Mas muitas vezes ele não terminou seus projetos: Ele'prefere não terminar algo do que terminá-lo quando não estava satisfeito com a beleza do código.
E trabalhei com desenvolvedores que foram extremamente eficientes, mas por isso tomei muitos atalhos que tornaram as soluções quase insustentáveis (caminhos codificados, números mágicos, etc.).
E eu sempre preferi "done" over "beautiful" e no final, os meus clientes também o fizeram: Eles'preferem "algo" quando o prazo está lá do que "nada mais será bonito em mais algum tempo X"
Apenas uma coisa: soluções alternativas / atalhos / "hacks" precisam ser compreensíveis, documentadas e de fácil manutenção, então não há nada contra soluções como você
Assim, criou algum software que levou quatro minutos a correr (porque o seu código não era muito bom). Se demoro 12 horas a fazer o trabalho à mão, o vosso software poupa-me 11 horas e 56 minutos. Se escreveu um código melhor que funcione em 1 segundo, poupa-me 11 horas, 59 minutos, 59 segundos. Se o código melhor foi entregue uma semana mais tarde, então tive de fazer o trabalho manualmente cinco vezes, os 3 minutos 59 segundos adicionais nunca irão compensar o tempo que perdi.
Ou torná-lo mais extremo. O software precisa de funcionar em 24 horas. O seu código é mau, por isso precisamos de um computador de 5.000 dólares para o executar em 24 horas. Com um código melhor, um computador de $2.000 poderia executá-lo em 24 horas. Uma poupança de $3.000 dólares. Se demorar duas semanas a tornar o código mais rápido, é uma perda global.
Ser capaz de o entregar quando é necessário é uma coisa muito, muito boa. Além disso, um programador muito bom pode escrever mau código de uma forma que possa ser melhorado mais tarde com facilidade. Os maus programadores escrevem mau código que é uma dor para refactor numa boa forma, os bons programadores sob pressão de tempo escrevem mau código que é fácil de melhorar.