<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Diogo Sampaio Jorge</title>
    <description>The latest articles on DEV Community by Diogo Sampaio Jorge (@diogojorge).</description>
    <link>https://dev.to/diogojorge</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F958331%2Ffe420bad-1759-4816-8144-b64878acb993.jpg</url>
      <title>DEV Community: Diogo Sampaio Jorge</title>
      <link>https://dev.to/diogojorge</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/diogojorge"/>
    <language>en</language>
    <item>
      <title>Chaos, Order, and Code: The Cycle That Drives Software (and Our Careers)</title>
      <dc:creator>Diogo Sampaio Jorge</dc:creator>
      <pubDate>Thu, 24 Sep 2026 18:22:39 +0000</pubDate>
      <link>https://dev.to/diogojorge/chaos-order-and-code-the-cycle-that-drives-software-and-our-careers-2gif</link>
      <guid>https://dev.to/diogojorge/chaos-order-and-code-the-cycle-that-drives-software-and-our-careers-2gif</guid>
      <description>&lt;p&gt;The first discussion I came across about this duality between chaos and order as it applies to software development came from &lt;a href="https://elemarjr.com/" rel="noopener noreferrer"&gt;Elemar Junior’s&lt;/a&gt; reflections. It was while listening to what he had to say that I began to see the birth of software from this perspective, and, wanting to better understand the subject, I ended up finding &lt;a href="https://www.jordanbpeterson.com/" rel="noopener noreferrer"&gt;Jordan Peterson’s&lt;/a&gt; books, which cover this eternal clash in the human experience. In our daily lives in technology, this isn’t just philosophical talk from a book—it’s pure reality. Almost all software is born out of chaos: a company comes to us in desperation because its processes have collapsed, spreadsheets can no longer keep up, and the operation urgently needs control. The system is then created as an attempt to save the team from chaos.&lt;/p&gt;

&lt;p&gt;But right from the start, we usually slip into the infamous trap of over-engineering. Because we're afraid of the future or trying to chase technical perfection that isn't necessary at the moment, we end up creating massive architectures, choosing tools that are too complex, and wasting weeks debating patterns that don't solve the current problem. This over-engineering delays delivery, slows down the time to launch, and ultimately freezes the software’s growth. Instead of getting the functionality live quickly and learning from real-world use, the team gets stuck in a project that was already too heavy from the start.&lt;/p&gt;

&lt;p&gt;True growth only happens when the team manages to establish a healthy level of order. That’s when the architecture becomes stable, basic tests cover what matters, and the delivery flow runs smoothly. But it’s a mistake to think the story ends there, because we enter an endless cycle where both sides need to coexist. Too much order turns into bureaucracy and blocks innovation; too much chaos leads to accumulated technical debt, inefficiency, and burnout for the entire team.&lt;/p&gt;

&lt;p&gt;The secret lies in knowing how to navigate between these two worlds with fluidity. We need to accept creative chaos in the early stages, letting new ideas emerge freely, but then quickly establish the order needed to structure, refactor, and scale safely. It’s a constant process of literally opening and closing the scope.&lt;/p&gt;

&lt;p&gt;At the end of the day, this dance between chaos and order applies to our careers as developers as well. Technology is constantly changing, and to stay relevant, we need to reinvent ourselves. This requires facing the discomfort of diving into the chaos of learning something new from scratch, so that we can later transform all that learning into professional maturity. Growing, in code or in our careers, means learning to suffer through the chaos to build the order of tomorrow.&lt;/p&gt;

</description>
      <category>programming</category>
      <category>discuss</category>
      <category>career</category>
    </item>
    <item>
      <title>Caos, ordem e código: o ciclo que move o software (e a nossa carreira)</title>
      <dc:creator>Diogo Sampaio Jorge</dc:creator>
      <pubDate>Thu, 24 Sep 2026 14:48:29 +0000</pubDate>
      <link>https://dev.to/diogojorge/caos-ordem-e-codigo-o-ciclo-que-move-o-software-e-a-nossa-carreira-1h4n</link>
      <guid>https://dev.to/diogojorge/caos-ordem-e-codigo-o-ciclo-que-move-o-software-e-a-nossa-carreira-1h4n</guid>
      <description>&lt;p&gt;O primeiro papo sobre essa dualidade entre caos e ordem aplicado ao desenvolvimento de software chegou até mim pelas reflexões do &lt;a href="https://elemarjr.com/" rel="noopener noreferrer"&gt;Elemar Junior&lt;/a&gt;. Foi ouvindo o que ele dizia que comecei a enxergar o nascimento do software por esse ângulo e, querendo entender melhor o assunto, acabei esbarrando nas obras do &lt;a href="https://www.jordanbpeterson.com/" rel="noopener noreferrer"&gt;Jordan Peterson&lt;/a&gt;, que fala bastante sobre esse eterno embate na experiência humana. No nosso dia a dia de tecnologia, isso não é papo filosófico de livro, é a realidade pura. Quase todo software nasce no meio da bagunça: a empresa chega desesperada porque os processos estão travados, as planilhas já não dão conta e a operação precisa de controle urgentemente. O sistema nasce, então, como uma tentativa de salvar o time do caos.&lt;/p&gt;

&lt;p&gt;Só que, bem na largada, a gente costuma escorregar na famosa armadilha do over-engineering. Com medo do futuro ou querendo buscar uma perfeição técnica que não cabe no momento, acabamos criando arquiteturas gigantescas, escolhendo ferramentas complexas demais e perdendo semanas discutindo padrões que não resolvem o problema atual. Esse excesso de engenharia atrasa a entrega, posterga a chegada da ordem e acaba travando o crescimento do software. Em vez de colocar a funcionalidade no ar rápido e aprender com o uso real, o time fica travado num projeto que já nasceu pesado.&lt;/p&gt;

&lt;p&gt;O crescimento de verdade só acontece quando a equipe consegue estabelecer um nível saudável de ordem. É quando a arquitetura se acalma, os testes básicos cobrem o que importa e o fluxo de entrega roda redondo. Só que o erro é achar que a história acaba aí, porque a gente entra num ciclo infinito onde os dois lados precisam coexistir. Muita ordem vira burocracia e trava a inovação; muito caos gera dívida técnica acumulada, ineficiência e esgotamento da equipe inteira.&lt;/p&gt;

&lt;p&gt;O segredo está em saber caminhar entre esses dois mundos com naturalidade. A gente precisa abraçar o caos criativo nas primeiras fases, deixando as novidades surgirem sem amarras, mas logo depois aplicar a ordem necessária para estruturar, refatorar e escalar com segurança. É um movimento constante de abrir e fechar o escopo literalmente.&lt;/p&gt;

&lt;p&gt;No fim do dia, essa dança entre caos e ordem vale também para a nossa carreira de desenvolvedor. A tecnologia muda o tempo todo e, para continuar relevante, a gente precisa se reinventar. Isso exige topar o desconforto de entrar no caos de aprender algo novo do zero para, depois, transformar todo esse estudo em maturidade profissional. Crescer, seja no código ou na carreira, é aprender a sofrer no caos para construir a ordem de amanhã.&lt;/p&gt;

</description>
      <category>programming</category>
      <category>career</category>
      <category>discuss</category>
      <category>braziliandevs</category>
    </item>
  </channel>
</rss>
