RE: Medo e ódio em TI

Escrever respostas para artigos é fácil e divertido. Você não precisa se debruçar sobre a estrutura do artigo por horas, basta seguir o plano de outra pessoa e apenas articular claramente seus pensamentos no papel. No entanto, atrevo-me a sugerir que um olhar crítico “do outro lado” sobre as questões levantadas no artigo “ Medo e ódio na TI ” por respeitados eugene_crabs ainda será interessante. Hoje, sou o advogado do diabo, que defende o sistema desumano.



Ao contrário dele, não uso borlas de senador e tenho alguns anos a menos de experiência em desenvolvimento e não tenho formação especializada, para ser sincero. Mas não tive problemas com um interesse básico no trabalho, e parece-me que o motivo é uma percepção ligeiramente diferente da realidade.
Um artigo para uma ampla gama de leitores.

RE: Complexidade excessiva

Claro, é bom manipular sistemas simples. Entendo essa mágica quando você entende como ela funciona nos mínimos detalhes: quando você desce para o nível de montador e código de máquina e quando vai ainda mais fundo - até onde o processador é uma série de portas lógicas.

A situação atual é tal que os principais desenvolvimentos no software e no hardware dos processadores já estão muito longe de uma compreensão cristalina de como isso funciona por uma única pessoa: os processadores estão cheios de lógica gerada, cache de vários níveis e preditores de ramificação tanto que os bugs neles não são assim. eles não são notados, ou mesmo assumidos, por equipes inteiras de desenvolvimento, e florescem tão violentamente que surgem em seus efeitos no nível do usuário. Além disso, somos forçados a arrastar uma enorme bagagem de funções antigas, garantindo compatibilidade com versões anteriores; caso contrário, venceremos em velocidade e simplicidade, mas perderemos o trabalho para o qual esse hardware foi originalmente desenvolvido.

A situação é a mesma com o software: o entendimento, e mais ainda a escrita de instruções de montagem, permanece apenas em áreas estritamente especializadas, e estruturas e camadas de abstração reinam supremas no que vive e gira nas imediações do usuário.

Do ponto de vista de uma pessoa que deseja controlar seu código e máquina, isso é ruim. Do ponto de vista do usuário - bom, pois simplifica o entendimento, o trabalho e o caminho da ideia ao produto. O preço que pagamos por esse desejo dos usuários é que as crescentes capacidades do processador sejam imediatamente consumidas pela complexidade dos programas, o que, aparentemente, não é justificado por nada e não traz vantagens (fonte de alimentação, como disseram no local de trabalho anterior).

No entanto, se você se aprofundar, acontece que estamos alterando esses recursos para aumentar o público, simplificando a interação. Os terminais de passagens aéreas exigiam conhecimento de abreviações, entendendo como as companhias aéreas funcionam e a capacidade de trabalhar com um terminal de texto. Agora, qualquer usuário vai para a Aviasales condicional e pega uma passagem barata em uma rota difícil sem muitas hemorróidas.



Você não pode tornar a interface compreensível para a pessoa comum em um terminal de texto, porque a clareza da interface é a resolução do monitor, e belas imagens que não assustam o cérebro, fontes bonitas e dicas que aparecem quando você passa o mouse sobre o botão e a interface de toque.

E também, a capacidade de testar todos esses chips, com foco no comportamento do usuário. Ao trabalhar em cascata, você lança um release uma vez por ano, coletando comentários sobre a versão atual o ano todo. Até algum estágio da interface, você passa dez anos, dez lançamentos. Ao implementar pequenas correções e testá-las ali mesmo, você chegará ao mesmo estágio em um ano e meio. Mas esse trabalho exige um ritmo diferente, outras ferramentas e tecnologias e a rejeição de certas coisas. Na honestidade, desde a lambedura do código: tudo deve funcionar agora, porque requer um processo desse ritmo.

Em troca, essa corrida louca por novos recursos nos oferece uma base crescente de usuários: quanto mais simples os botões são pressionados, mais pessoas podem pressioná-los, e a crescente base de usuários gera dinheiro não apenas para seus salários, mas também para o desenvolvimento de novo hardware. Quanto mais pessoas puderem usar o smartphone de forma produtiva, mais o comprarão, melhor será o hardware na próxima versão. O fato de trocarmos imediatamente esse ferro não por vôos para Marte, mas por um público crescente ... bem, isso pode ser comparado a uma empresa que investe todos os seus ganhos em desenvolvimento, e não em dividendos e lucros no relatório anual. Só agora, por algum motivo, você justifica quando Musk e Bezos fazem isso, mas não pode justificar a indústria.

Para melhor ou pior, pode-se argumentar. Por um lado, a qualidade do software, por outro - progresso constante em hardware, público e altos salários no setor. Talvez eu escolha o segundo (embora prefira desacelerar), mas entendo as pessoas que escolhem o primeiro.
Mas uma coisa nos unirá - não podemos fazer nada com isso.

RE: Muitas coisas

O fato de haver muitas ferramentas é uma continuação lógica do parágrafo anterior. Quando há muita energia na região, isso permite que você gaste energia extra em hipóteses de teste, algumas das quais falharão, outras secarão, mas outras formarão a base dos novos padrões da indústria. As reclamações sobre o caos são semelhantes às reclamações sobre a ineficiência da evolução, que por algum motivo criou um monte de espécies, a grande maioria das quais desapareceu silenciosamente, e mesmo a maioria não é muito bem-sucedida e vive em uma faixa estreita. É realmente impossível criar imediatamente uma pessoa que possa sobreviver mesmo no Pólo Norte, mesmo no deserto, apesar de ele próprio ser bastante frágil - ele não corre rápido, não há garras, seus dentes são pequenos e sem brilho, o ângulo de visão é pequeno.

É bom olhar para o resultado da evolução de lado e se perguntar quanto tempo levou para criar uma vantagem completamente óbvia - um dedo flexível e um cérebro desenvolvido.

Mas, no início da jornada, o resultado não era tão claro: os dinossauros também reinaram supremos na Terra e, se houvesse analistas de troca em seu tempo, poucos colocariam ratos em alguns mamíferos contra esse favorito óbvio.

O desperdício na forma de ferramentas "erradas" é um companheiro constante do caminho que leva ao topo.

RE: Programador deve ser analista de negócios e entrevistas de emprego

Não, não deveria, é claro. Mas, nas condições da necessidade de um teste rápido de hipóteses, é muito mais produtivo fazer isso da mesma maneira que toma decisões sobre arquitetura, simplesmente porque há menos sobrecarga: você precisa deliberar por dois dias e pensar por uma hora. Você sabe como fazê-lo na área de assunto - bem feito, durma em um sofá amassado. Se você não sabe, eles estão esperando por você nas áreas em que a confiabilidade é mais importante que o progresso: espaço, medicina, militar, sistemas de comunicação de sinais. Essas áreas são e não são um frontend menos importante. É verdade que eles pagam menos. Tal viés no mercado, que eu gostaria de corrigir, mas isso é algo maior do que não apenas uma pessoa, mas a maioria das empresas.

A propósito, esse mesmo fator permite que você despreze o RH com perguntas complicadas, até "Eu não sei com o que estou preso, vamos conversar com o diretor técnico". Não quer ser analista, mas quer escrever código em um TK lambido pronto? Veja acima - outras áreas para você: bons programadores que não cometem erros e implementam o TK de forma eficiente e eficiente também são muito necessários.

RE: pessoal de TI

Desenvolvedores entediantes que só falam em trabalho? Estranho, parece chato para mim que quer cortar discretamente o código de acordo com o TK finalizado de 9 para 18. Nós dois estamos errados, mas estou falando de outra coisa: essa organização da mente, na qual a tarefa gira constantemente na cabeça, dá um impulso significativo à velocidade do desenvolvimento e teste de hipóteses. Um pouco acima do limite, e o desgaste se espalha por lá, mas isso é uma questão de controlar a saúde mental. O que não nega o fato de que algumas empresas (não apontaremos o dedo para quem paga táxi após 22 horas, incentivando-o a permanecer no trabalho) percebendo que um funcionário em chamas funciona melhor, fornece todas as condições para essa queima.

Projetos? Você simplesmente não sabe como cozinhá-los. Um projeto é uma ferramenta universal: por um lado, é necessário truques de mágica para programadores (um programador deixado por conta própria, muda para fazer coisas engraçadas para seu amado) e, por outro lado, arquitetos e líderes de equipe podem despejar a maior parte do trabalho organizacional sobre ele. organização de reuniões, manutenção da relevância do cronograma, relatórios sobre o trabalho realizado, comunicação de rotina com o cliente e assim por diante.

RE: Negócios

Aconteceu que um homem inventou dinheiro. Eles não fizeram isso na geração atual, nem mesmo cem anos atrás. O dinheiro provou ser uma excelente ferramenta para organizar uma sociedade heterogênea com diferentes conceitos de beleza e diferentes desejos das pessoas incluídas nela.

Você pode tentar inventar outra coisa, mas até agora não encontrou nada fundamentalmente melhor. É claro que existe motivação como apoio social e espírito de equipe, mas o primeiro é um derivado do dinheiro digerido pelo Estado, e o segundo é tempero, não o prato principal. Em uma pitada, sobremesa.

Você é pago pelo seu trabalho. Se o seu trabalho não gera dinheiro - desculpe, os negócios não precisam dele. Rude, eu sei. Vamos tentar mais suave.

Os negócios precisam de dinheiro. Uma empresa é uma organização que ganha dinheiro. Se você não receber dinheiro pelo que considera necessário, não demonstrou como isso trará ainda mais dinheiro aos negócios. Aprenda a justificar o desperdício de recursos, prove que é benéfico, mesmo a longo prazo, e haverá recursos. Os negócios e a tomada de decisões nos negócios a esse respeito são muito mais adequados do que as pessoas comuns: no entanto, quando uma pessoa tenta comprar uma passagem por meio ano por dez mil, porque é muito dinheiro, e prefere comprar uma passagem por dois mil por mês, apenas um está interessado nos negócios figura - lucro com dinheiro investido. Lucro de 16%? Pegue! Sem dinheiro, mas posso obter um empréstimo para esses gastos em 5%? Pegue!

Se uma empresa não pode justificar uma revisão de código porque seu código permanece por três meses, após o qual é substituído por um novo, e então sai daí, o que você está fazendo aí? Há um grande número de empresas para as quais a revisão e refatoração de código são componentes importantes do processo. E a primeira empresa está focada no teste de hipóteses, e não na codificação: isso também é normal e permite encontrar um novo nicho no qual você pode crescer, amadurecer, acumular gordura e começar a praticar a revisão e refatoração.

Não culpe o projetista que constrói uma casa de tijolos de brinquedo sem prendê-los com argamassa: viver em um hamster nesta casa, e a tarefa desta casa é testar a hipótese da aparência e não servir como casa. E mesmo que esse designer esteja pronto para pagar por ajudá-lo a construir sua casa de brinquedos, não cuspa nele com o fato de que você precisa de um poço de argamassa e fundação, mas se acomode em construtores normais.

RE: Saúde

Talvez este seja o único ponto ao qual não tenho nada para responder completamente. Além disso, no meu mundo, uma pessoa tem vontade e razão, e se acredita que não precisa levantar pesos, não os levantará.