C#

Considerando que mudar do .NET Framework para o .NET geralmente não é tão simples quanto mudar de alvo, é interessante que a maioria dos desenvolvedores esteja embarcando pelo menos no trem do .NET (Core). Ao mesmo tempo, é surpreendente que uma porcentagem significativa de desenvolvedores ainda mantenha projetos direcionados ao .NET Framework 4.6 e versões anteriores. Estou curioso para saber o que está impedindo esses projetos de avançar para a versão 4.8.

Acho bom que mais desenvolvedores estejam usando a versão mais recente do C#. Eu me pergunto se eles estão movendo mais aplicativos legados para a versão mais recente do .NET ou se estão apenas criando novos aplicativos e sistemas e deixando o antigo código legado para trás.

O C# continua sendo a linguagem de escolha indiscutível entre os desenvolvedores .NET. O VB.NET e o F# também são usados, mas o C# e as linguagens de front-end, como o JS e o TS são usadas com mais frequência.

Estou um pouco surpreso com quantos desenvolvedores C# estão (também) usando o macOS e o Linux. Para o Linux, seria interessante dividir isso em máquinas Linux (virtuais) regulares versus WSL.

Como ex-SDET, acho decepcionante a porcentagem de desenvolvedores C# que não escrevem testes de unidade. Eu esperava que agora houvesse um consenso sobre os benefícios dos testes de unidade em geral. Seria interessante descobrir o porquê disso. Será que os desenvolvedores não acreditam nos benefícios? É uma questão de falta de treinamento ou cultura de engenharia? A gerência está reduzindo os investimentos de curto prazo exigidos pelos testes de unidade?

Olhando para trás em meus 20 anos em campo e comparando minha experiência pessoal com os números aqui, tenho que chegar à conclusão de que a análise e a melhoria do desempenho são muitas vezes um ponto cego nos dias de hoje, embora na verdade não devessem ser. De muitas maneiras, fechamos o círculo. Considerando que antigamente os problemas eram a memória e os recursos de CPU limitados, hoje costumamos escrever código para rodar em dispositivos móveis em que a duração da bateria é um problema, bem como soluções em nuvem que precisam ser expandidas e em que o uso ineficiente de recursos de computação significa rapidamente gastos milhares de dólares a mais por mês do que o necessário.

Acho que o profiling regular segue a ideia de juros compostos. Como você sabe, como na aposentadoria, você deposita uma pequena quantia de dinheiro ao longo do tempo de maneira consistente, o que acaba levando ao ponto em que você tem algo significativo. A mesma coisa com o profiling: mesmo um pequeno segmento de tempo para observar o desempenho se converte em grandes melhorias em todos os aspectos, se você fizer isso de forma consistente e persistente ao longo do tempo. Portanto, não busco melhorias enormes e massivas de uma só vez. Elas são excelentes quando avançamos, iteração após iteração.