Latest / We The People, in Tech or Not: O Debate / Não recomendado não é proibido. Mas documente.

Transcript

Não recomendado não é proibido. Mas documente. · We The People, in Tech or Not: O Debate

• 0:00
  WeThePeople In Tech or Not, o debate. Bem-vindo ao WeThePeople In Tech or Not, o debate. Imagine, hã, que você acorda em uma terça-feira, sabe? Os sistemas principais da sua empresa estão completamente fora do ar.
• 0:15
  Nossa, o clássico pesadelo de TI. Pois é, e todo o banco de dados tá simplesmente corrompido. E o motivo?
• 0:21
  Alguém, anos atrás, decidiu que era uma boa ideia alterar o fuso horário padrão de um servidor, só pra economizar tipo algumas horas de desenvolvimento. E claro, ninguém anotou isso em lugar nenhum.
• 0:33
  Absolutamente ninguém documentou o porquê dessa decisão.
• 0:36
  Então, antes de mergulharmos no nosso debate de hoje sobre essas armadilhas invisíveis da tecnologia, um aviso importante: este é um programa gerado por inteligência artificial, baseado em um post da newsletter WeThePeople In Tech or Not, de Alex Rosa.
• 0:50
  O nosso objetivo aqui é ajudar os ouvintes a aprender novas formas de explicar temas técnicos, do nível de quem é iniciante e não trabalha com tecnologia, até o nível de especialista.
• 1:01
  É, e é exatamente sobre isso que nós vamos debater hoje, né, pegar essas complexidades, hã, da infraestrutura de sistemas e traduzir pra realidade nua e crua dos negócios, como que isso afeta o dia a dia. Perfeito.
• 1:13
  O nosso dilema central hoje é muito familiar pra qualquer pessoa que já trabalhou com sistemas.
• 1:18
  O que você deve fazer quando escolhe um caminho técnico ou, hã, uma configuração que o próprio fabricante do software não recomenda como padrão?
• 1:26
  Eu vou defender a premissa fundamental de que documentar detalhadamente cada desvio do padrão, o famoso default, é, na verdade, o único caminho seguro pra sobrevivência a longo prazo do seu sistema e da sua sanidade mental também.
• 1:38
  Certo, mas eu, por outro lado, vou ancorar a nossa discussão na realidade pragmática, a realidade de quem gerencia equipes, orçamentos apertados.
• 1:48
  A minha posição é que, tipo, essa exigência de uma documentação hiperdetalhada pra qualquer desvio é muitas vezes um preciosismo acadêmico, sabe? Você acha irrealista. Totalmente.
• 1:58
  Porque no mundo real, a, a agilidade e a necessidade de entregar valor imediato precisam atropelar essa burocracia idealizada. Se eu tenho um problema agora, eu resolvo agora. Entendo.
• 2:09
  É uma tensão clássica, né, entre a engenharia pura e as necessidades urgentes do negócio. Mas veja bem, pra estruturar o meu argumento, a gente precisa primeiro olhar pra origem dessas recomendações.
• 2:20
  Quando gigantes da tecnologia, como a Microsoft, por exemplo, definem um padrão pra um servidor ou um banco de dados, não é um chute no escuro. Uhum. Eles têm dados. Exato.
• 2:29
  Eles possuem telemetria de milhões de instâncias ao redor do planeta. Então eles já viram aquele sistema falhar de formas que, francamente, um cliente individual jamais conseguiria imaginar na vida. É, com certeza.
• 2:40
  A base de dados deles pra tomar uma decisão arquitetônica é infinitamente superior à de uma equipe isolada. Isso é fato.
• 2:48
  Que bom que concordamos nisso, porque quando você questiona o fabricante sobre alterar um padrão, a resposta deles geralmente se enquadra em três categorias. Certo.
• 2:56
  A primeira é o bloqueio total, tipo, é um requisito obrigatório, não faça, ou o sistema simplesmente quebra. A segunda é quando existe uma recomendação já documentada pra um caminho alternativo que é seguro.
• 3:08
  E a terceira, que pra mim é a mais perigosa, é quando o caminho está aberto. Aberto, como assim? Liberado geral?
• 3:16
  É quando a engenharia do fabricante olha e diz algo como: "Olha, não vemos impeditivos técnicos imediatos, você pode fazer."
• 3:22
  A minha defesa, então, é que se você entra nesse terceiro cenário e opta por uma configuração que não é o padrão, você tem a obrigação moral e técnica de criar um registro formal dessa decisão, um decision record.
• 3:34
  Tá, um documento formal. Sim, você precisa registrar o porquê, o quando e, crucialmente, quem tomou essa decisão. Olha, é aí que o meu lado cético acende um alerta vermelho enorme.
• 3:46
  Vamo focar justamente nesse terceiro cenário que você trouxe.
• 3:49
  Se o fabricante, com toda essa telemetria massiva que você bem descreveu, diz que o caminho tá aberto e não impõe barreiras, por que o cliente precisa assumir um fardo burocrático colossal internamente?
• 4:01
  Mas não é um fardo colossal, é um... Pera, pensa bem. Hum.
• 4:06
  Se a própria engenharia da Microsoft, por exemplo, deu passe livre, por que eu preciso parar a minha equipe de desenvolvimento pra redigir um documento interno superdetalhado justificando a escolha?
• 4:18
  Isso não é, no fim das contas, criar lentidão numa via que já é expressa? Não confunda a ausência de uma placa de "pare" com a garantia de que não há um penhasco ali na frente.
• 4:28
  O caminho aberto significa apenas que a plataforma permite a modificação, né? Não que ela seja imune a consequências no futuro. Deixa eu usar uma analogia do dia a dia pra gente visualizar. Manda.
• 4:39
  Imagina que você comprou um carro novo, e aí você decide modificar a suspensão original de fábrica pra rebaixar o veículo.
• 4:45
  A lei permite, e a fabricante do carro deixou os parafusos totalmente acessíveis pra você fazer isso na sua própria garagem. O caminho tá aberto, certo? Certo. E é uma modificação extremamente comum. Muita gente faz.
• 4:56
  Muito comum. Mas a geometria daquela suspensão original foi calculada pelos engenheiros pra um equilíbrio perfeito, seja em curvas ou em frenagens.
• 5:05
  Se você modifica isso e, hã, não anota em lugar nenhum quais peças usou, qual o novo ângulo, o porquê dessa mudança, o que acontece daqui a dois anos? Quando for consertar, vai dar problema. Exatamente.
• 5:16
  Você vende o carro, o próximo mecânico tenta alinhar as rodas usando as métricas originais da fábrica. O resultado é um desastre. Ele pode até causar um acidente, porque ele não tinha o contexto da sua modificação.
• 5:27
  Em sistemas corporativos, a lógica é idêntica.
• 5:30
  O fabricante permite a mudança, mas o próximo engenheiro que herdar o seu sistema, ele vai aplicar soluções padrão em uma infraestrutura que, bem, já não se comporta de forma padrão. Eu entendo o valor do contexto.
• 5:41
  E, de fato, a sua analogia do mecânico é bem válida pra ilustrar o risco lá na frente, o risco de longo prazo. Mas deixa eu trazer a minha própria analogia aqui pra ilustrar a dor do curto prazo, a dor do dia a dia.
• 5:53
  Vá em frente.
• 5:54
  Exigir um decision record formal e superdetalhado pra cada desviozinho do padrão é tipo pedir pra um bombeiro preencher um formulário de análise de risco, hã, em três vias, antes dele ser autorizado a ligar a mangueira de água.
• 6:07
  Nossa, mas aí é um extremo. Mas é como a gente se sente na gestão.
• 6:11
  Quando a casa tá pegando fogo, ou seja, quando o negócio tá perdendo dinheiro aos montes porque um sistema antigo não funciona na nuvem, você resolve o problema primeiro, se apaga o fogo.
• 6:21
  Tá, mas e se a água que o bombeiro tá usando, de repente reage com um produto químico que tá dentro da casa e causa uma explosão ainda maior? É um risco calculado, entende?
• 6:32
  Vamo trazer isso direto pro exemplo técnico prático que tamo debatendo do post. Migrar um banco de dados Azure SQL do fuso horário universal, que é o UTC, pra um fuso horário local, tipo o Central Standard Time, o CST.
• 6:46
  Ah, esse é um exemplo perfeito de um desvio de padrão que parece inofensivo, parece tranquilo, mas carrega um risco arquitetônico brutal.
• 6:55
  Veja bem, o padrão ouro na tecnologia é rodar servidores em UTC, porque o tempo universal é absoluto, ele nunca muda. Uhum. É a base.
• 7:03
  Quando você força o banco de dados a operar em um horário local como o CST, você cai direto na armadilha do horário de verão, o Daylight Saving Time. E aí pensa comigo: em novembro, os relógios atrasam uma hora lá.
• 7:16
  O seu banco de dados vai registrar transações às duas da manhã e uma hora depois vai registrar transações às duas da manhã de novo. É, ocorre uma duplicação. Você duplica o tempo.
• 7:26
  E pior, em março os relógios adiantam e você simplesmente perde uma hora inteira de registros. Fica um buraco.
• 7:32
  Olha, eu não discordo que puramente do ponto de vista da engenharia de software, a rodar em UTC é o único caminho lógico pra evitar essas sobreposições de dados. Isso é inegável. E não é só sobreposição.
• 7:45
  O risco vai muito além, vai até a quebra da integridade da exportação do banco de dados. Se você tentar fazer uma exportação bacpac, por exemplo. Que é o pacote completo.
• 7:54
  Sim, o empacotamento completo do banco de dados e de toda a sua estrutura. Essa variação de fuso horário pode causar falhas severas de consistência transacional.
• 8:03
  Imagina que a exportação bacpac é tipo, hã, encaixotar a sua casa inteira pra uma mudança internacional. Tá. Ok. A transportadora global opera em UTC.
• 8:12
  Ela precisa saber exatamente a ordem cronológica em que as caixas foram fechadas. Só assim ela consegue desempacotar no destino sem quebrar as dependências das coisas.
• 8:21
  Agora, se você etiqueta as caixas usando o relógio da parede da sua cozinha, que adianta e atrasa sozinho por causa do horário de verão, a transportadora simplesmente perde a referência de tempo.
• 8:30
  A mudança inteira fica estruturalmente corrompida. Certo, você cita esse risco de falha na exportação bacpac, mas vamos ser absolutamente pragmáticos e técnicos aqui.
• 8:41
  Quem, em uma arquitetura de nuvem moderna e de grande porte, realmente depende de uma exportação bacpac completa pra garantir a segurança dos dados no dia a dia?
• 8:50
  Bom, existem cenários de- Porque olha, nós usamos restores automatizados baseados em ponto no tempo, usamos réplicas geográficas, failovers instantâneos.
• 9:00
  O bacpac é uma ferramenta até útil pra certas migrações pontuais, mas usar ele como o grande bicho-papão pra proibir um desvio de configuração, isso é apontar pra um edge case, sabe?
• 9:11
  Uma exceção extrema só pra justificar a imposição de uma burocracia diária na equipe. Não é um bicho-papão inventado, é um sintoma claro de um sistema que perdeu a sua coerência estrutural.
• 9:21
  E francamente, migrações acontecem, mudanças de plataforma acontecem de verdade. A questão aqui é que você tá mascarando a gravidade técnica em nome de uma conveniência de gestão.
• 9:32
  Mas eu não tô mascarando nada, eu tô equilibrando a equação comercial, que é o meu papel. Pensa no cenário real, de mercado.
• 9:39
  A empresa pegou uma aplicação antiga, legada, com dezenas de relatórios gerenciais que são vitais pra diretoria e moveu tudo pra nuvem. Certo. Todo o código antigo desses relatórios se esperava rodar no horário local.
• 9:51
  Ao fazer o tal do jeitinho de mudar o banco pra CST, tudo continua funcionando instantaneamente. Não foi preciso alterar, tipo, uma única linha de código da aplicação.
• 10:01
  Cê tem noção de quantos milhares de reais em horas de desenvolvimento sênior foram economizados nesse dia? Eu imagino que muito. Exatamente. Pra um gestor, isso é eficiência pura.
• 10:13
  O risco hipotético de uma exportação bacpac falhar daqui a, sei lá, dois anos, simplesmente não justifica o custo massivo e a paralisação da equipe inteira hoje pra reescrever dezenas de relatórios antigos.
• 10:26
  É inegável que essa decisão salvou dinheiro no curto prazo. Eu concordo com você nisso. E esse é justamente o cerne do meu argumento.
• 10:33
  É exatamente porque desviar do padrão pode ser tão comercialmente tentador, que a documentação é inegociável. Você assumiu uma dívida técnica gigante e assumiu de forma consciente. Uhum.
• 10:43
  Então se você documenta isso em um decision record, o próximo engenheiro que chegar sabe que os relatórios rodam em CST, e ele pode planejar rotinas de manutenção pra que não caiam nas madrugadas de mudança de horário de verão.
• 10:54
  Agora, se você não documenta, a economia genial de hoje virá a falência sistêmica de amanhã, quando o banco de dados corromper silenciosamente e a equipe não fizer a menor ideia de que o relógio do servidor tá em conflito com o relógio da nuvem.
• 11:06
  Tudo bem, tudo bem. Eu concedo que registrar o fuso horário específico faz sentido pra evitar esse choque.
• 11:13
  Mas o ponto de maior atrito aqui, e o que mais me incomoda na rigidez desse modelo de documentação, é a exigência do "quem".
• 11:21
  A recomendação superestrita do autor de que o documento deve conter os nomes completos das pessoas que tomaram a decisão, tanto do lado da equipe interna quanto do lado do fabricante.
• 11:31
  Sim, o rastreamento autoral da decisão técnica. Exato.
• 11:35
  E cara, do ponto de vista da política corporativa no mundo real, exigir o nome do indivíduo em um documento de desvio de padrão cria imediatamente uma cultura de caça às bruxas, um apontamento de dedo, sabe?
• 11:48
  Você acha que inibe as pessoas. Totalmente.
• 11:51
  Se eu sou um desenvolvedor e eu sei que o meu nome vai ficar gravado na pedra como o cara que tirou o banco de dados do padrão de segurança e assumiu o risco do horário de verão, eu nunca vou inovar.
• 12:02
  Eu vou ser empurrado pra aquela mediocridade do tipo: "Vamo fazer só o que a Microsoft diz. E se o negócio perder dinheiro, hum, a culpa não é minha."
• 12:10
  Isso paralisa completamente o dinamismo de qualquer equipe técnica ágil Eu compreendo perfeitamente esse receio, mas eu acho que a sua leitura do quem tá um pouco invertida.
• 12:20
  O objetivo não é culpar as pessoas, é iluminar as decisões. Na filosofia, tem um conceito maravilhoso chamado "A cerca de Chesterton".
• 12:29
  O princípio diz que, hã, você nunca deve derrubar uma cerca que tá no meio de um campo até você entender completamente o motivo pelo qual ela foi construída lá no passado.
• 12:39
  Ah, a regra de não mexer no que você não entende. Isso.
• 12:43
  Se você simplesmente vai lá e tira a cerca sem saber o porquê, você pode descobrir da pior forma possível que ela tava lá justamente pra impedir que lobos atacassem as ovelhas. É um belo conceito, de verdade.
• 12:55
  Mas como que isso muda o medo real do desenvolvedor de assinar um documento de risco? Porque o nome dele no documento não é um alvo colado nas costas, é a assinatura do arquiteto da cerca.
• 13:07
  Se eu entro na empresa hoje e vejo uma configuração bizarra, a minha primeira vontade de engenheira é apagar e voltar pro padrão limpo.
• 13:14
  Mas se eu tenho o nome da pessoa que configurou aquilo, eu posso ir até a mesa dela e perguntar: "Escuta, por que essa cerca tá aqui?"
• 13:22
  E ela vai me responder: "Olha, porque se você mudar isso pra UTC agora, 30 relatórios financeiros vão quebrar na mesma hora e o faturamento da empresa para." O registro do quem preserva o raciocínio.
• 13:33
  Essa é uma visão muito romântica da convivência em TI, né? Nem sempre as conversas são assim tão tranquilas. Não é romantismo, é proteção legal e profissional, de verdade. Pensa no pior cenário possível.
• 13:44
  Daqui a três anos, o sistema cai justamente por causa daquela bendita mudança de fuso horário. Um novo diretor de TI assume, tá furioso e exige saber quem foi o irresponsável que autorizou aquilo.
• 13:55
  É, isso acontece com frequência. Acontece. E se não há um documento, o desenvolvedor que fez o jeitinho é simplesmente demitido por descuido ou incompetência.
• 14:05
  Mas se existe um decision record assinado, aquele papel se torna um escudo. O desenvolvedor levanta o documento e diz: "Não foi irresponsabilidade minha.
• 14:13
  Foi um risco de engenharia calculado, validado pelos líderes na época, tudo pra salvar cinquenta mil reais do orçamento do mês. Todos concordaram."
• 14:21
  O documento transforma o que seria visto como um erro primário em uma decisão estratégica auditável. Certo, eu tenho que admitir.
• 14:30
  O argumento de que o documento serve como um escudo contra diretorias futuras é bem persuasivo.
• 14:36
  Um bom gestor realmente prefere ter um papel assinado atestando um risco corporativo do que assumir a culpa por uma gambiarra silenciosa que alguém fez no passado. Exatamente. Traz segurança pros dois lados.
• 14:49
  No entanto, se nós aceitarmos que documentar o quem e o porquê é tão essencial assim, nós esbarramos no verdadeiro pesadelo operacional: auditar o que já existe hoje.
• 15:01
  Ah, você quer dizer fazer o inventário das cercas que já foram construídas. Precisamente.
• 15:06
  Se eu assumo uma infraestrutura hoje com centenas de bancos de dados rodando há 10 anos, como que eu encontro esses desvios sem paralisar a minha equipe, que devia tá produzindo?
• 15:15
  É muito fácil falar de documentar o futuro a partir de amanhã. Mas e o legado? A famosa frase: "Estava assim quando eu cheguei".
• 15:24
  É, esse é o desafio real de 90% das empresas, mas a tecnologia nos dá ferramentas incríveis pra auditar a si mesma.
• 15:31
  No caso específico que estamos debatendo, hã, o ecossistema do Azure SQL e do SQL Server 2017 em diante possuem um recurso chamado Database Scoped Configurations, ou configurações no escopo do banco de dados. Certo.
• 15:46
  E você pode interrogar o sistema inteiro com uma consulta supersimples. Você literalmente pede ao sistema: liste tudo na tabela sys.database_scoped_configurations, onde o valor is_value_default seja igual a zero.
• 16:01
  Ou seja, me mostra em uma lista apenas o que foi alterado em relação ao que veio de fábrica.
• 16:06
  Legal, mas antes da gente entrar no resultado prático dessa consulta, a gente precisa deixar muito claro o impacto dessa configuração no escopo, porque, hã, alterar algo no escopo do banco de dados é diferente de alterar o servidor inteiro.
• 16:21
  É um excelente ponto pra quem tá acompanhando a gente. Pensa no seu servidor de banco de dados como um carro que é compartilhado por vários motoristas de uma mesma família, tá?
• 16:30
  Cada motorista tem a sua própria viagem, que representa um banco de dados diferente rodando naquela mesma máquina. Uhum, faz sentido.
• 16:37
  Uma configuração a nível de servidor global seria o equivalente a trocar o motor do carro. Afeta todos os motoristas instantaneamente e o risco de uma falha sistêmica que pare tudo é altíssimo.
• 16:48
  Já uma configuração no escopo do banco de dados é como ajustar o ângulo dos espelhos retrovisores e a altura do banco apenas quando você entra no carro com a sua chave.
• 16:58
  Afeta exclusivamente o seu ambiente isolado, sem quebrar o carro pros outros motoristas. É um ambiente de contenção muito mais seguro.
• 17:05
  E essa é a beleza e ao mesmo tempo a maldição da coisa, porque como é mais seguro mexer, as pessoas alteram sem pensar duas vezes. E aí nós voltamos ao ponto do pragmatismo puro.
• 17:16
  Digamos que eu rode essa consulta mágica que você mencionou no meu legado. Certo. Eu descubro que existem tipo 50 configurações com is_value_default igual a zero. O sistema roda há cinco anos assim.
• 17:29
  Ninguém da equipe atual sabe o porquê daquilo tá lá e os autores originais da mudança já saíram da empresa há muito tempo. O clássico mistério corporativo. Pois é.
• 17:39
  Na tecnologia, existe uma regra de ouro de sobrevivência, muito respeitada por qualquer veterano que se preze: se está funcionando, não mexa.
• 17:48
  O perigo de investigar essas 50 configurações e, pior, tentar revertê-las pro padrão apenas pra ter um sistema certinho e limpo, não seria esse o verdadeiro risco inaceitável pro negócio?
• 17:59
  Olha, operar com base em superstição não é engenharia de sistemas. Essa frase de "se está funcionando, não mexa" é justamente o que cria aqueles monstros inatualizáveis que um dia paralisam as empresas.
• 18:12
  Mas eu vou ceder um ponto bem prático ao seu argumento de gestão. Qual? Nem toda configuração alterada merece, de fato, uma investigação forense de alto custo. A chave é focar estritamente no que traz efeitos colaterais.
• 18:24
  Se a alteração lá do legado não degrada a performance nem ameaça a integridade dos dados, ela é só um ruído.
• 18:31
  Mas aceitar como resposta padrão a frase "já estava assim quando eu cheguei e nós não sabemos o que faz", isso é uma bandeira vermelha gigante Um sistema que funciona por puro acidente não está funcionando de verdade.
• 18:42
  Ele está apenas aguardando a combinação climática ideal pra desmoronar em cima de você. É, eu compreendo a sua preocupação.
• 18:50
  A ignorância sobre os próprios mecanismos de produção da empresa é uma dívida que hora ou outra sempre cobra juros, e juros altos.
• 18:58
  E eu acho que é justamente nesse ponto que as nossas visões convergem de forma muito orgânica pra gente concluir o debate de hoje. Com certeza.
• 19:05
  Eu acho que pra resumir a defesa da arquitetura mais formal que eu trouxe hoje, ter clareza conceitual e exigir um decision record pra configurações que fogem do padrão não é
• 19:17
  um ataque à agilidade da equipe técnica, é, na verdade, a criação de um escudo.
• 19:22
  Registrar as decisões protege os desenvolvedores contra as mudanças da gestão, preserva todo o-o contexto de negócio que justificou aquela escolha e garante que o próximo profissional saiba exatamente onde os riscos tão enterrados.
• 19:35
  E saber como auditar isso, né, separando o que é impacto isolado do que é impacto global, é o mínimo que a gente espera de uma governança madura. É uma ótima visão.
• 19:44
  E do lado de cada mesa, na cadeira gerencial, eu reforço que entender profundamente o próprio sistema é, sem dúvida nenhuma, vital.
• 19:53
  Nenhuma liderança quer sentar em cima de uma caixa preta que é instável, mas o pragmatismo exige equilíbrio, sabe?
• 20:00
  O discernimento do gestor tá em saber balancear aquele esforço enorme de escavar os fantasmas técnicos do passado com a necessidade implacável de entregar os resultados e as metas do presente.
• 20:10
  Aceitar um desvio de padrão, dar aquele jeitinho bem calculado, muitas vezes é o oxigênio que o negócio precisa pra não sufocar hoje.
• 20:19
  A documentação é excelente, desde que, claro, não se torne uma burocracia cega, que impeça o bombeiro de apagar o incêndio na hora que importa.
• 20:27
  Eu diria que é uma conclusão bem justa, onde a teoria técnica e a prática gerencial precisam, no fim do dia, apertar as mãos.
• 20:35
  E pra você, nosso ouvinte, nós deixamos um desafio muito claro hoje, que é inclusive o mesmo dever de casa proposto pelo nosso material base. Sim.
• 20:43
  Quer você seja aquele arquiteto purista, que gosta de tudo no padrão, ou o gestor que passa o dia apagando incêndios, faça esse exercício bem simples.
• 20:53
  Nessa semana, escolha apenas uma configuração do seu sistema principal que você sabe que não é o padrão de fábrica, apenas uma.
• 21:01
  E tente responder ou escrever em três linhas rápidas quem alterou isso, quando foi alterado e qual foi o motivo técnico ou de negócio pra essa mudança.
• 21:11
  É, e se você e a sua equipe não conseguirem responder a essas três perguntas básicas sobre uma configuração fundamental, olha, encare isso como um sinal claríssimo de que vocês precisam ter uma conversa bem séria sobre a dívida técnica que tá pendente aí.
• 21:24
  É um teste de sanidade rápido, que expõe o quanto do nosso conhecimento interno está, na verdade, baseado em pura tradição oral, de passar de um pro outro sem anotar nada.
• 21:35
  E pra quem achou esse debate instigante e quer mergulhar mais fundo nas ideias do autor. E nós convidamos todos vocês a lerem o post original completo.
• 21:43
  O acesso é totalmente gratuito e você pode encontrá-lo em intactornot.com. Deixando bem claro pra você poder anotar aí: intactornot.com.
• 21:54
  Apenas um pequeno aviso de que o texto lá no site original está escrito em inglês, mas a leitura é indispensável pra quem deseja refinar a forma como lida com essas decisões e com dívidas arquitetônicas no dia a dia.
• 22:06
  É isso aí. E nunca se esqueçam, hein? Antes de rebaixar a suspensão do carro de produção da sua empresa, certifiquem-se de anotar onde vocês guardaram as molas originais. O próximo mecânico agradece demais.
• 22:17
  Um excelente conselho pra fechar. Muito obrigada por nos acompanhar em mais um debate do We The People, In Tech or Not. Até o nosso próximo encontro.