Executando verificação de segurança...
11

Programar é Muito Mais do que Codar: Veja o Diagrama Científico que Mostra uma Verdade

Programar não é só escrever código num editor de texto — é um processo bagunçado e dinâmico, onde codificar é só uma pequena parte. Um estudo de 2017, publicado no ACM/IEEE International Symposium on Empirical Software Engineering and Measurement chamado Characterizing Developer Behavior in Cloud Based IDEs chegou a um resultado visual impressionante.

Spoiler: é muito mais leitura, pesquisa e caos — e claro tudo o que você faz online está sendo rastreado.

O destaque do trabalho é um diagrama de transição (Figura 3 do artigo), um mapa visual que mostra como os programadores pulam de uma tarefa pra outra. Imagine uma teia de nós — cada um é uma atividade como “Codificar”, “Pesquisar” ou “Depurar” — conectados por setas que mostram a chance de ir de uma pra outra. Olha só:

fig3

  • Codificar? Só uma Parte: Apenas cerca de 25% das atividades. Os programadores passam muito mais tempo em outras coisas.

  • Leitura Domina: Um total de 15,79% do tempo é gasto pesquisando e lendo online.

  • Ciclo de Tentativa e Erro: Setas como “Codificar → Executar” → “Depurar → Pesquisar” mostram o loop constante de escrever, testar, aprender e corrigir.

  • Pausas e Deslizes: Os programadores ficam ociosos mais de 10,00% do tempo (pensando ou travados), e 2,55% são puro “Acidentes” — troca de abas aleatória ou confusão.

Como Eles Chgeraram Nisso

Aí meu caro, tem que ler o artigo.

Mas de forma mais concisa possível o estudo usou o JazzHub, uma IDE na nuvem. Além disso eles gravaram telas, capturaram tráfego HTTP com proxies e construiram um modelo Markov que mapeia transições probabilísticas entre atividades.

Tem limitações, claro, um monte: pra começar, é uma IDE que roda no navegador, o ambiente era supercontrolado, poucos participantes, e exercícios de programação, tipo entrevista, nada a ver com o mundo real.

Ainda assim, é uma evidência empírica de algo que todo programador experiente já sabe na pele: programar não se trata só de codar. O diagrama é uma foto bonita, só isso, não a verdade.

O Lado Sombrio da Nuvem: Tudo é Rastreado

Usar uma IDE na nuvem significa que tudo é rastreado. Cada pesquisa, cada pausa, cada erro — tudo registrado. Isso é ótimo pra pesquisas ou pra criar ferramentas de produtividade, mas é um baita risco pra privacidade

  • Sem Escapatória: Seus hábitos, suas dificuldades, até os trechos que você copiou do StackOverflow ficam salvos em servidores remotos.

Da próxima vez que você programar online, lembre-se: não é só sobre o que você cria, mas sobre quem está te observando.

Foque no que Realmente Importa

Programar é menos sobre codificar e mais sobre garimpar recursos, testar ideias e lutar com problemas.. Pra se tornar um programador melhor, ESPECIALMENTE EM ÉPOCA DE VIBECODING o segredo não está só em CODAR melhor/mais rápido, mas em dominar outras habilidades cruciais. Aprenda a encontrar recursos úteis rapidamente, Invista em testes e depuração, os loops “Codificar → Executar” e “Depurar → Executar” mostram que testar e corrigir são o coração do processo.

Um abraço e bons estudos.

Carregando publicação patrocinada...
2

Atualmente na minha empresa estamos trabalhando na refatoração da featire de pix, ela foi feita as pressas logo no início, e agora pra escalar precisamos praticamente refazer do 0, e o que mais fazemos é definir coisas, a gente passa mais tempo estudando soluções, validando idéias, testando arquiteturas e oitras coisas do que codando o projeto, e acredito quae codar vai ser a coisa mais simples da refatoração quando já tiver tudo definido, visto que a IA automatiza a escrita de código, e o código fica bom desde que você saiba guiar ela para o que você quer de código (Não é só pedir pra ela fazer a feature, é pedir pra ela fazer de acordo com tudo o que você definiu e ajustar caso ela não consiga)

2

Que publicação enxuta e precisa!

Eu gostei bastante do exemplo aqui apresentado, porque nunca foi uma questão de programar, mas como você disse de investigar de forma profunda um determinado problema, ou conjundo de informações e transformar elas em conhecimento.

Atualmente, eu utilizo IA porque percebi os benefícios ao longo da jornada até mesmo de trabalho, e lendo muito sobre, percebo que utilizar esta lupa pode beneficiar coisas como deixar de dar atenção a processos mecânicos que na sua grande maioria das vezes, pode atrapalhar, mesmo quando você treina esta parte também.

Então, buscar entender como o ferramental funciona, você consegue navegar de um ponto a outro e economizar o seu tempo em uma parte do processo como o digitar, e criar coisas repetitivas, que antes só eram possíveis com geradores de código, que nunca foram tão bons porque nenhum cliente quer ver material repetido ou partes do sistema iguais a de um concorrente e focar em questionar, produzir artefatos que fazem o projeto ser mais compreensivo para um par que vai contribuir com ele.

Além do mais, se você entregar "exatamente" o que foi pedido dentro de um orçamento bacana, sendo contratado ou trabalhando em uma jornada "própria" você vai ganhar muitos pontos, seja para assumir projetos com maior valor ou ser indicado para um novo projeto, e entender antes de codificar algo, evita que você construa uma ferramenta que pode prejudicar um conjunto de pessoas de algum modo, só pelo dinheiro.

Ética é importante neste caso, porque a evolução na carreira de um engenheiro pode ser alguma outra área, como a de segurança que necessita muito mais de você ao passo que entra mais capital, é desta forma que penso e isso não esta gravado em pedra. É necessário pensar de forma estratégica sempre, ou o trabalho não será bem feito, e continuaremos como simplesmente amadores.

Cada um tem uma história e quando conseguimos contar ela bem, tudo fica mais proveitoso, porque pode aprender com outras pessoas, como nesta experiência que trocamos, parabéns de verdade.

Forte Abraço!

1

Excelente post, clacerda!
Faz total sentido o que você escreveu.

A sua análise sobre programar ser muito mais do que apenas "codar" bate perfeitamente com a minha própria experiência, e acho que a de muitos outros desenvolvedores.

Eu mesmo já passei por isso muitas vezes, principalmente em projetos pessoais. No passado, eu ficava semanas preso no desenvolvimento. A minha ânsia era codificar tudo o mais rápido possível, pensando que estava ganhando tempo, otimizando a entrega. Mas aí, quando me dava conta, estava gastando um tempo enorme adaptando funcionalidades, corrigindo bugs inesperados e lidando com coisas que nem tinham passado pela minha cabeça no início, que surgiram totalmente fora do escopo original. Tudo isso por causa daquela ânsia de "codar rápido".

E, como você bem mencionou sobre a época de "vibecoding", percebo como o uso descuidado de IA, apenas para gerar código mais rápido, poderia até piorar essa situação se não houver planejamento.

Até que resolvi dar um basta nisso e mudei completamente minha abordagem, inspirado justamente por essa percepção que seu texto ilustra tão bem. Hoje, ao invés de sair programando de cara, eu invisto um tempo considerável na fase de planejamento e análise, usando a IA como uma ferramenta antes de escrever código:

- Valido hipóteses: Uso a IA para discutir a ideia central, possíveis problemas e cenários.
- Analiso a stack: Peço para a IA comparar tecnologias, listar prós e contras de usar X ou Y para aquele contexto específico.
- Refino a arquitetura: Discuto a arquitetura que imaginei, questiono as decisões ("por que seguir o caminho X e não Y?"), e peço sugestões de padrões ou abordagens alternativas.
- Só depois de passar por essa fase de validação e planejamento é que eu realmente coloco a mão no código.

O resultado? Sim, eu demoro mais para começar a codar. A fase inicial se estendeu. No entanto, depois que começo, o desenvolvimento flui de forma muito mais suave. Aquele ciclo interminável de "coda > testa > arruma > quebra outra coisa > arruma de novo" diminuiu demais. Estou levando mais tempo para dar o pontapé inicial, mas estou salvando um tempo precioso de depuração, refatoração e retrabalho lá na frente.

Seu post e o diagrama do estudo capturam essa realidade perfeitamente: focar apenas na velocidade de escrita do código é uma ilusão.

O verdadeiro ganho de produtividade vem de entender o problema, pesquisar, planejar e validar antes – exatamente as atividades que o estudo mostrou serem tão significativas.

Ótima reflexão! Um abraço.

1

Eu não diria wue rastrear é algo sombrio, afinal, pra você drbugsr precisar ssber o que está acontecendo e pra isso voce rastreia os dados. So que se faz com os dados após a resolução é que de fato deve se preocupar.