Você deve escrever uma boa documentação e limpar o código para aumentar o “Fator Bus”?

Você deve se esforçar para tornar-se insubstituível não escrevendo código que ninguém mais entenda, mas reunindo mais experiência e conhecimento do que outros. A maneira antiga faz de você um desenvolvedor com o qual todos tentam evitar trabalhar, pois eles temerão e relutam em manter o código que você escreveu. Desta forma, você se torna um membro da equipe que os gerentes desejam ter em sua equipe.

Na minha experiência, escrever código limpo, bem documentado (e de preferência auto-documentado) sempre valeu a pena. Na verdade, aproveitei quase todas as oportunidades para ajudar e ensinar os outros (além de aprender com eles quando eles conheciam algo melhor), e quase nunca me senti em perigo de ser substituído por alguém menos capaz do que eu. Na verdade, isso geralmente ajudou toda a equipe a trabalhar melhor e a resolver problemas mais rapidamente, o que é o sonho de todo gerente - e um gerente sensato não quer substituir membros de uma boa equipe.

Se você for manipular as organizações ou as pessoas de forma tão transparente, é melhor que elas sejam estúpidas ou atoladas, o que não deixa outra escolha. Uma loja de desenvolvimento de software bem administrada examinaria seu código obscuro e a documentação que faltava e simplesmente o acionaria antes que você pudesse causar muitos danos. Se eles forem mal administrados ou não conseguirem que outros desenvolvedores trabalhem para eles, por que você gostaria de ter uma sinecure com eles?

PS Nem o Sr. Greene nem Maquiavel conseguiram muito além de escrever livros que tentavam lisonjear os possíveis "homens duros" da época. Siga seus conselhos com um grão de sal.

Se você é insubstituível, não pode ser promovido.

Você não quer ser insubstituível. Você não quer fazer as pessoas se sentirem dependentes de você, você quer que elas apreciem você. Geralmente, você quer ficar longe de pessoas que acreditam que até metade das leis de poder deve ser aplicada a relacionamentos (profissionais ou pessoais). Estas regras são um conjunto de instruções sobre como estabelecer com sucesso uma situação de ganhar-perder. O que você quer, é uma situação ganha-ganha .
Assim que as pessoas começarem a sentir, você está tentando empurrá-las para o lado perdedor de uma situação de ganhar e perder, elas vão reagir. As tentativas de estabelecer situações de ganhar e perder muitas vezes acabam perdendo, porque você está efetivamente desperdiçando recursos para colocar seu parceiro em uma posição de perda, em vez de investi-los no sucesso geral de sua parceria.

Se você fizer isso com seus empregadores, eles tentarão forçar medidas em você, para reduzir seu monopólio de conhecimento. Na maior parte, estas serão orientações ridículas sobre como você deve fazer o seu trabalho e, assim, transformar sua vida profissional em um inferno. Além disso, eles ligam para você às 3 horas da noite quando algo quebra, porque você é a única pessoa que pode consertá-lo. Tentar explorar essas situações como alavancagem provavelmente vai sair pela culatra e causar mais problemas.

The graveyards are full of indispensable men.
- Gaulle, Charles De

Então corte a porcaria e faça o seu trabalho corretamente. Se não para qualquer outra coisa, então para você, porque você provavelmente será a pobre alma, que tem que fazer algumas mudanças no código daqui a 2 anos.

Being replacable, isn't that against the interest of a developer?

Eu odeio dividir isso para você, mas todos é substituível. Claro, às vezes pode ser um pequeno desafio substituí-lo (se você for experiente e brilhante o suficiente), mas está a anos-luz do impossível.

A maneira de realmente ser uma mercadoria valiosa para o seu empregador (não apenas o empregador atual, mas qualquer empregador) é demonstrar a capacidade de escrever códigos fáceis de entender por qualquer pessoa que esteja lendo o código. aumentar o tempo para trabalhar com ele) e documentar o código (qualquer pessoa pode obter uma visão geral de alto nível de seus sistemas sem cavar código).

Na verdade, ser bom na documentação do código é uma qualidade difícil de ser obtida nos dias de hoje, e isso por si só ajudará a diferenciá-lo dos outros.

Código limpo e bem documentado também merece ser colocado em um currículo (pelo menos, resultados tangíveis disso, ou seja, "fomos capazes de trazer n novos desenvolvedores com rampa mínima e assistência devido à minha documentação) , onde ser sorrateiro sobre se tornar "insubstituível" não é.

As respostas negativas não são muito surpreendentes, dado o número de programadores melhores do que a média que esse site atrai. Pessoas talentosas geralmente não precisam recorrer a esses tipos de táticas de segurança por ofuscação. Mas eu trabalhei em um fornecedor automotivo da Fortune 500 com alguns desenvolvedores não tão talentosos que tinham esculpido pequenos feudos para eles mesmos, que eles zelosamente guardaram criando copiosas quantidades de documentação para as interfaces horrendas que eles tinham projetado.

O trabalho completo de um cara era manter o código de um módulo que conectava dois subsistemas totalmente separados, permitindo que os módulos em cada sistema se comunicassem por meio de um UART. Basicamente, era a Serial Programming 101. Em vez de apenas criar uma interface geral que se parecesse com isso:

  int sendData(int targetModule, void *data, size_t byteCount);
  int recvData(int sourceModule, void *data, size_t maxBytes);

ele criou opcodes separados para cada mensagem que quaisquer dois módulos de comunicação podem querer enviar uns para os outros. O que significava que seu módulo precisava saber sobre cada mensagem e precisava ser atualizado sempre que uma mensagem fosse adicionada ou alterada. Fale sobre intimidade inapropriada!

O problema é que esse cara manteve um documento do Word ordenadamente listando todos os opcodes / mensagens e diligentemente o atualizou conforme necessário. Tornou-se o seu trabalho completo . Algumas vezes por semana, ele enviava uma nova revisão para todas as pessoas que tinham a infelicidade de tê-lo em seu caminho crítico. E isso era visto como 'profissional', já que o gerenciamento adorava ver a documentação. Meio que me faz chorar pela indústria automotiva.

Eu acho que meu ponto é: às vezes escrever documentação pode, de fato, proteger programadores medíocres. Os gerentes muitas vezes não conseguem distinguir entre um bom design e um mau, e muitos são forçados a tomar decisões técnicas com informações limitadas. É incrivelmente estressante para eles. Ver um documento do Word com dezenas de tabelas ordenadamente formatadas pode ser muito reconfortante - mesmo que o que ele descreve seja uma idéia fundamentalmente ruim.

Being replacable, isn't that against the interest of a developer?

Depende de quais são os interesses desse desenvolvedor. Se você é alguém que quer se destacar em um único emprego durante toda a sua carreira, seja completamente indispensável para uma empresa que recompensa a incompetência e faça um bom dinheiro, então sim, absolutamente.

Mas o que acontece quando a empresa cai, provavelmente porque eles contrataram muitas pessoas assim? Aonde você vai a seguir? O que quando perguntam por que você ficou no mesmo emprego por 15 anos? E assim por diante.

Agora, olhe de outra forma: quantos desenvolvedores perderam o emprego sendo alguém que escreve um código que qualquer pessoa pode ler?

A única probabilidade de isso acontecer é se a empresa está com problemas e tornando as pessoas redundantes. Se isso está acontecendo, é melhor você sair, e estará muito bem preparado para as próximas entrevistas. Além disso, sua consciência será completamente livre - você não estará deixando para trás o código inexplicável que escreveu para seu próprio benefício.

Eu não sei que tipo de pessoa você é, mas isso serve melhor aos meus interesses.

Being replacable, isn't that against the interest of a developer?

Você está certo, mas eu acho que você entendeu mal o significado de substituível. Eu pude encontrar 1000 desenvolvedores que escrevem código agitado, não documentado, que pode se transformar rapidamente em uma bagunça inamovível.

Um desenvolvedor que produz não apenas programas estáveis, mas também código limpo, documentação informativa e garante a continuidade do projeto, que não é apenas insubstituível, mas inestimável .

Eu vou abordar essa questão de uma perspectiva diferente, já que existem várias respostas excelentes.

Considere o que acontece quando você joga jogos insignificantes tentando tornar-se "insubstituível", evitando que outras pessoas aprendam como seu código funciona. Você fica no mesmo emprego mantendo suas próprias bagunças enquanto a empresa tolera você. E esse é o melhor cenário, o pior cenário é que outros engenheiros e gerentes mais talentosos e mais éticos em sua empresa vêem o obstáculo que suas práticas ruins impõem à empresa e decidem fazer algo a respeito: demitindo você e reescrevendo tudo do zero. Está feito. Na verdade, é algo bastante comum acontecer.

Agora, considere o que acontece quando você escreve um bom código e uma boa documentação. Você cria um componente ou um sistema que funciona bem, que depois de um tempo em funcionamento, trabalhando os bugs funciona sem problemas e dificilmente precisa ser olhado. É preciso pouco esforço para mantê-lo. Você pode então passar para projetos maiores e melhores, com uma sólida vitória em seu currículo. As pessoas reconhecerão você por ter feito um bom trabalho e começarão a respeitar sua opinião. Você terá a capacidade de subir na cadeia de alimentos e tomar decisões mais significativas, ou fazer um trabalho mais importante e impactante, ou gerenciar projetos em um nível mais alto. Sua carreira irá melhorar, você será promovido, ganhará mais dinheiro, ganhará reconhecimento e aprovação de seus colegas, e adicionará mais e mais sucessos de projetos cada vez mais importantes ao seu histórico.

Qual caminho você prefere?

Se você é o único ponto de falha, seu cliente (ou empregador) provavelmente tentará substituí-lo; Há sempre um ponto em que é menos caro substituir o software do que mantê-lo, por mais essencial que pareça. Há uma razão pela qual a TI é uma das profissões mais terceirizáveis.

Por outro lado, ser substituível oferece vários benefícios inestimáveis:

• ser capaz de tirar férias
• não estando em contato
• liberdade para sair e trabalhar em um projeto novo e em andamento

A excelente documentação acabará sendo obsoleta com refatoração / evolução, e mantê-la atualizada é realmente demorada.

Limpar código + teste de unidade > excelente documentação

Se você não gastar 5 minutos escrevendo alguma documentação rápida, gastará uma hora relendo e explicará às pessoas quando elas precisarem usar seu código.

Ainda pior seria passar dias procurando um novo emprego porque seu chefe descobriu que você não estava escrevendo código sustentável.

A resposta para sua pergunta é "sim". Sim, você deve escrever uma boa documentação e limpar o código. Fazer o contrário de maneira deliberada exibe uma falta de integridade, que, embora cada vez mais predominante no mundo dos negócios, não é, de certo modo, de repente, uma coisa "boa".

Ninguém é insubstituível. As pessoas que fabricam uma situação em que pensam que são tendem a descobrir da maneira mais difícil que não são. Fabricar uma co-dependência para você é contraproducente, pois também o limita, não apenas ao seu empregador.

One of the main goals of software development companies is to increase their Bus factor

Premissa falsa. Os principais objetivos de uma empresa de desenvolvimento de software (todos os que eu trabalhei, pelo menos) são produzir o melhor software possível e ganhar dinheiro, não necessariamente nessa ordem. Reduzir o "fator de ônibus" é apenas uma maneira de evitar perder dinheiro.

Law 11 Learn to keep people dependent on you.

O que isso significa para você?

Você quer que as pessoas dependam de você porque você as prejudicou de tal forma que elas só podem seguir em frente com sua ajuda? Ou você quer que as pessoas dependam de você porque você é inteligente e perspicaz, confiável, confiável e capaz de ajudar os outros a fazerem o seu trabalho melhor também? Você quer fazer seus colegas parecerem ruins sem sua ajuda, ou você quer que eles apreciem você por fazê-los parecerem bons?

É sua ligação.

(assumindo o código de produção)

Eu costumo ir um pouco mais longe. Eu escrevi sobre fazer programas "à prova de idiotas", mas eu nem sempre qualifico isso: eu escrevo um monte de código que outras pessoas não vão ver ou trabalhar (pelo menos, essa é a expectativa quando está escrito). Eu sou o idiota que estou tentando me defender nesse caso. É uma coisa boa quando seu programa detecta problemas para você, e o problema foi simplificado tanto que é óbvio que há um erro e sua origem. A verdade é que os detalhes da implementação são óbvios quando você escreve um programa (a menos que você esteja implementando-o prematuramente), mas eles devem ser abstraídos e resistentes a erros para os clientes (mesmo quando existe a localidade do módulo). A razão é que os programas se tornam muito complexos. Às vezes você pode separar problemas, mas não o tempo todo. Se você mantiver seus componentes muito rigorosos, simples, bem encapsulados e à prova de idiotices, eles tendem a escalar bem e a maioria dos defeitos é detectada antes de serem enviados. É mais fácil de reutilizar, e você tem mais confiança e um tempo mais fácil reutilizando os programas. Além disso, os programas complexos que você escreve só se tornam mais complexos (até para você) depois de algum tempo longe do programa. Quando você lê em 6 meses, pode demorar um tempo absurdo para entender e depurar em comparação com a versão à prova de idiotas. Se um componente introduzir uma alteração de quebra, ele poderá passar despercebido por um longo período de tempo. Programas são complexos; você não pode escapar dessa realidade, mas pode torná-la à prova de idiotas, o que tornará sua vida muito mais fácil quando algo der errado ou quando precisar ser reutilizado ou alterado. Portanto, a abordagem à prova de idiotas significa que seu software pode ser compreendido, reutilizado ou mantido por seus juniores ou pessoas mais novas na equipe também (não apenas alguém tão bom / experiente quanto você). A substituição é uma preocupação à parte: se as pessoas adoram trabalhar com seus programas, você está fazendo um bom trabalho - não se preocupe com a substituição. Claro, eu poderia criar cenários em que programas ininteligíveis pudessem salvar seu trabalho, mas escrever um bom programa que os outros possam usar e manter é claramente o mal menor (olhe para os resopios dos outros). Se eu me pegar escrevendo algo que não é uma prova idiota, eu tento consertar isso.