Em que momento você abandonaria alguns de seus princípios de desenvolvimento de software em troca de mais dinheiro?

Eu gostaria de lançar essa questão para ver de maneira interessante onde está o meio.

Vou admitir que, nos meus últimos 12 meses, peguei TDD e muitos dos valores Agile no desenvolvimento de software. Fiquei tão impressionado com o quão melhor meu desenvolvimento de software se tornou que nunca os abandonaria por princípio. Até ... me ofereceram uma função de contratação que dobrou meu salário para levar para casa durante o ano.

A empresa em que ingressei não seguia nenhuma metodologia específica, a equipe não tinha ouvido nada sobre cheiros de código, SOLID, etc., e eu certamente não iria me dar bem em passar tempo fazendo TDD se a equipe nunca tivesse sequer visto testes unitários na prática. Eu estou esgotado? Não, não completamente ... O código sempre será escrito "de maneira limpa" (conforme os ensinamentos do tio Bob) e os princípios do SOLID sempre serão aplicados ao código que eu escrevo conforme necessário. Os testes foram descartados para mim, porém, a empresa não podia se dar ao luxo de entregar uma equipe tão desconhecida que, francamente, até eu criei estruturas de teste, elas nunca usariam / manteriam a estrutura de teste corretamente.

Usando isso como exemplo, que ponto você diria que um desenvolvedor nunca deve abandonar seus princípios de artesanato por causa de dinheiro / outros benefícios para ele pessoalmente? Entendo que essa pode ser uma opinião muito pessoal sobre a preocupação com as próprias necessidades, as necessidades dos negócios e o artesanato, etc. Mas pode-se considerar que, por exemplo, os testes podem ser descartados se a empresa decidir que prefere ter um equipe de teste, em vez de entender o teste de unidade na programação, isso seria algo pelo qual você poderia se perdoar, como eu fiz? Portanto, dado que há algo que você deixaria de lado, normalmente deveria haver um custo igual nos negócios que compensasse o que você deixou de lado - esperançosamente, a menos que, claro, você esteja muito disposto a gastar seus próprios bolsos e não a colaborar com a comunidade / social; )

Dobrar seu dinheiro, voltar para a RAD? Ou siga em frente, procure alguém que faça Agile e nunca olhe para trás ...

Desde que me viciei em testes de unidade há mais de 10 anos, na maioria dos meus locais de trabalho, fui o primeiro a saber disso. No entanto, eu continuava escrevendo meus pequenos testes de unidade sempre que podia e calculando o custo dos testes de unidade em minhas tarefas. Sempre que alguém perguntava sobre meus hábitos de codificação, eu dizia o que estava fazendo e por que funcionava para mim. Normalmente, pelo menos algumas das pessoas estavam interessadas, e, eventualmente, pude fazer apresentações sobre o tópico e orientar as pessoas a escrever seus primeiros testes de unidade.

Você não precisa convencer as pessoas sobre a maneira ágil no primeiro dia em seu novo local de trabalho. Basta seguir os princípios em seu próprio trabalho, tanto quanto você puder. Se você fizer isso bem, fornecerá um código melhor. Se seus colegas de trabalho e / ou gerência perceberem, eles perguntarão como você o faz. Então você pode contar a eles.

Atualizar

A maioria dos desenvolvedores (e gerentes) experientes viu tendências e modismos surgirem e desaparecerem, para que não fiquem empolgados com as últimas novidades. No entanto, se você puder demonstrar que uma certa abordagem (ferramenta, modo de pensar) realmente funciona na prática, no projeto real , aqueles que se preocupam com seu ofício quase certamente se sentam e escutam. Mas se você não tem pessoas dessa equipe, talvez seja hora de procurar um lugar melhor ...

É aqui que acho que todos os desenvolvedores também devem conhecer um pouco do gerenciamento de projetos. Tudo é uma troca entre tempo, dinheiro e recursos. Considere-se o recurso.

Nos meus 12 anos de programação, acho que nunca concluí um projeto e pensei nele como concluído, ou completo em minha mente. Sempre havia algo que eu gostaria de ter feito melhor ou mais limpo. Levei muito tempo para perceber que isso se deve a essas compensações.

Então, se você está pensando em mudar de emprego apenas porque as metodologias não existem, eu pensaria novamente se fosse você. Essas compensações são constantes e se aplicam a todos os desenvolvedores de software. Até os desenvolvedores de jogos mais dedicados desejam poder fazer algumas coisas novamente ou praticar uma metodologia diferente novamente, se tiverem uma chance.

Eu diria que você deve examinar suas práticas de desenvolvimento ágil e perceber que você pode fazer isso mesmo em um nível micro. Certifique-se de que seus colegas de equipe possam estar fora do país fazendo o que quiserem, mas sua satisfação pessoal será maior e você certamente criará um código melhor do que eles a longo prazo. Então, quando o gerente vier e perguntar por que seu código é muito melhor, você terá a chance de converter a equipe :)

Mas se você não gosta das pessoas ou do trabalho, acho que já sabe a resposta. Mas duvido que alguém entre na sala e diga para você não usar os princípios de desenvolvimento ágil ao codificar ... se o fizerem ... gritam.

Nunca deixe cair algo que o deixará infeliz a longo prazo. É claro que você pode começar em terra de ninguém e tentar fazer a equipe se mover em sua direção. Se você estiver disposto a se esforçar e o trabalho valer a pena, isso pode até ser um desafio interessante.

Mas se você precisar deixar exatamente as coisas que mantêm o prazer de codificar (ou qualquer outro trabalho), minha experiência é que você se afastará mais cedo ou mais tarde. Aprendi que a frustração nunca deve ser subestimada ...

As pessoas em seu último trabalho já sabiam sobre TDD, SOLID, etc. Isso é ótimo. Tenho certeza que você gostou de trabalhar lá e aprendeu muito. Agora você tem a oportunidade de ensinar esses conceitos (enquanto ganha muito dinheiro ao mesmo tempo). Na minha experiência, ter de ensinar a alguém um conceito sempre me ajudou a aprendê-lo com ainda mais detalhes. Apenas seja paciente com eles, e continue promovendo seus conceitos, um de cada vez. Quando ficar frustrado, vá para casa e conte seu dinheiro. Ou procure suporte no SE.

Devo admitir que sou demais nesse aspecto. Como freelancer, qualquer que seja o cliente que considere a metodologia certa para o projeto, está bem comigo. Isso não significa que o dinheiro é a única coisa com a qual me preocupo, mas a decisão sobre o que fazer e o que deixar de fora depende do cliente. Porém, eu não aceitaria más condições de trabalho (barulhento, longas horas etc.).

Quero citar um ex-colega meu. Ele disse que, sempre que procura um emprego ou um projeto de meio período, há três critérios que o projeto deve atender:

• Deve ser divertido trabalhar com
• Deve ser benéfico para o desenvolvimento de sua competência (não tenho certeza de que este é o caminho certo para expressá-lo)
• Deve pagar bem

Enquanto leio sua pergunta, este projeto atende apenas aos últimos critérios.

Como você gosta de TDD (assim como eu), acho que você circula diariamente e deseja que todos os seus colegas de trabalho tenham alcançado o mesmo insight que você. Portanto, o primeiro critério provavelmente não seria atendido.

Em segundo lugar, se você deseja buscar projetos de TDD e, talvez, obter mais experiência na criação de equipes ágeis, trabalhar nesse projeto não ajudará a fortalecer essas habilidades. Portanto, o segundo provavelmente também não será atendido.

Então, pessoalmente, se eu estivesse na sua posição e não estivesse em posição de ajudar a introduzir o TDD na empresa, eu procuraria em outro lugar.

Nunca.

A vida é muito curta (especialmente à medida que você envelhece) para fazer coisas que você vai odiar.

Obviamente, dificulta a troca de emprego e há menos lugares para trabalhar.

Mas pelo menos apenas o código legado cheira mal. (E eu tenho autonomia, para que possamos fazer coisas sensatas, como passar uma semana eliminando avisos do compilador da base de código herdada ...)

Em resumo, a metodologia de desenvolvimento não faz parte de você. Não é uma religião e não é quem você é. É uma ferramenta. Faça o que lhe foi dito, como lhe foi dito e ganhe dinheiro extra. Milhares de sistemas foram desenvolvidos e estão funcionando hoje sem TDD, Code Smell, etc. Em poucos anos, ninguém saberá o que esses termos significam porque as metodologias vêm e vão mais frequentemente do que um ônibus da cidade. Trabalhe duro como lhe disseram e pegue o dinheiro que é apreciado a qualquer momento e o tempo todo :)

Apenas certifique-se de que trabalhar com a nova equipe seja um bom investimento do seu tempo.

Talvez eles funcionem de maneira mais eficiente do que você encontrou até agora? Nesse caso, trabalhar com eles será uma ótima experiência de aprendizado para você (portanto, um bom investimento).

Por outro lado, as metodologias da nova equipe podem ter pouco valor para você (muita "codificação de cowboy" etc.). Nesse caso, o dinheiro adicional provavelmente não vale a pena (a menos que seja uma inicialização pré-IPO ou algo extraordinário). Você provavelmente não aprenderá muito ... e corre o risco de se queimar.

Eu não iria trabalhar em algum lugar que não me permitisse trabalhar do jeito que eu queria. Com isso, quero dizer que não quero ser microgerenciado.

Trabalho sob a suposição de que sou bom no que faço e, se você me der algumas tarefas, eu as realizarei com eficiência e eficácia. A forma como eu os implemento, desde que não quebre suas diretrizes e padrões de código, depende de mim. Essa é a parte divertida do meu trabalho.

Se eu quisesse fazer o teste de unidade em todas as aulas que escrevo, isso pode ser um problema, mas escrever testes de unidade geralmente é bom, desde que eu ainda cumpra os prazos. Espero que um proponente do TDD argumente que escrever testes de unidade realmente aumenta a produtividade (mais tarde, etc). Se eu estivesse no seu lugar, escreveria alguns testes de unidade que me poupariam um pouco de tempo (presumivelmente menos bugs, correções mais fáceis). Se você reinvestir o tempo economizado em mais testes, ele aumentará ainda mais o tempo economizado e, eventualmente, você poderá relaxar com um grande sorriso quando tiver um conjunto incrível de testes e verificar facilmente as alterações de código quando houver uma nova 11ª hora requisito entra.

Se eu não pudesse fazer isso, não sei se gostaria de trabalhar lá.

O que estou dizendo é que acho que deve haver algo a dar e receber nesses assuntos - um pouco de negociação. Quanto mais eles me pagam, menos gentilezas não monetárias eu espero. Mas eu sempre preciso de um nível de autonomia e respeito próprio, especialmente quando não há necessidade de recusar. Abandonarei qualquer outro princípio enquanto tiver esse pouco de autonomia. Afinal, o que pode parecer uma metodologia maluca por trás pode ser a melhor coisa que você já fez!