No primeiro Save Point, eu disse que tecnologia existe para servir às pessoas, e não o contrário. Aqui quero mostrar que essa ideia começa nas nossas próprias ferramentas.
Eu descobri Ruby por volta de 2009/2010. Na época, eu já conhecia XP e o Manifesto Ágil, mas estava insatisfeito com a minha carreira: o que eu lia era muito distante do que eu vivia no trabalho.
Eu consumia muito podcast e livro técnico, e acabei chegando ao trabalho de Dave Thomas, um dos signatários do Manifesto Ágil, e ao seu livro Programming Ruby: The Pragmatic Programmer’s Guide, o famoso “Pickaxe”. Não vou falar do livro aqui, porque ele renderia posts inteiros. Fica só a recomendação: é excelente.
Foi ali que eu vi isto:
3.times do
puts "hello"
end
Até hoje é uma das construções mais bonitas e expressivas que já vi em programação. Em Ruby, tudo é objeto, inclusive o número 3. Então 3.times é uma chamada de método comum, que recebe um bloco e o executa três vezes. Sem contador, sem for (int i = 0; i < 3; i++). O código se lê quase como uma frase: “três vezes, faça isso”.
A partir daquele momento, eu só sabia que precisava saber mais.
Já contei um pouco dos meus primeiros meses com Ruby no meu blog pessoal.
Antes de seguir, um esclarecimento: isto não é uma crítica a quem desenvolve software de outro jeito. Há empresas que trabalham bem assim. É só o relato do que a minha vivência me ensinou sobre o que eu quero e, principalmente, sobre o que eu não quero fazer no meu trabalho.
No meu trabalho daquela época, programação era vista como uma etapa de conversão. As especificações chegavam prontas, e o meu papel era transformá-las em algo que o computador entendesse. Não se esperava que eu colaborasse com as outras áreas para chegar a um resultado. Esperava-se que eu executasse a conversão com perfeição. A inteligência vinha antes, de outro lugar, e o programador era um tradutor: quanto menos mexesse no texto original, melhor.
Sobrava muito pouco espaço para criatividade. E, com o tempo, fui percebendo que esse modelo tinha um problema mais fundo.
Uma especificação escrita em linguagem natural é cheia de ambiguidades. Duas pessoas leem a mesma frase e entendem coisas diferentes, e as contradições só aparecem quando alguém tenta fazer aquilo funcionar. Normalmente, quem descobre é o programador. O código não tem esse luxo: ele não admite ambiguidade e faz exatamente o que diz, nem mais, nem menos. Por isso acredito que o código é a melhor especificação e a fonte da verdade de um sistema. Ele não é a tradução de um documento, é o lugar onde a solução finalmente fica clara. (Essa é mais uma premissa que a IA pode nos fazer rever, mas, de novo, fica para outro post.)
E se o código é a especificação, quem o escreve não está traduzindo, está desenhando a solução. Isso se faz conversando, entendendo o problema junto com quem o vive, e não recebendo um documento pronto por cima do muro.
Isso contrastava cada vez mais com o que eu aprendia sobre XP e agilidade, e eu me sentia um estranho no ninho naquele mundo corporativo. Ruby me mostrou que existia outro jeito: uma linguagem que se apresenta como “a melhor amiga de quem programa”, e um framework, o Rails, cujo primeiro princípio é otimizar para a felicidade de quem programa. Ferramentas que tratam o código como um texto para ser lido por pessoas, e quem programa como alguém que pensa.
Programar é uma atividade criativa. Linguagens de programação são uma forma de expressar essa criatividade, dando vida a soluções para problemas práticos. (Sim, eu sei que isso está mudando com o avanço da IA, mas esse é assunto para um post futuro.)
Matz, o criador do Ruby, disse certa vez que espera ver Ruby ajudar todo programador do mundo a ser produtivo, a gostar de programar e a ser feliz, e que esse é o propósito principal da linguagem. O que eu entendo disso é um ethos: a linguagem, e a tecnologia em geral, deve servir ao humano, e não o contrário.
Quando você obriga quem programa a escrever código boilerplate, está invertendo as prioridades: colocando as necessidades do compilador à frente das de quem programa. Não tome isso como um ataque a linguagens compiladas ou com tipagem estática (aliás, Ruby é fortemente tipada, só que dinâmica). Cada ferramenta tem o seu propósito.
Mas a ausência de boilerplate e a clareza do código Rails deixam óbvio que ele foi feito para ser lido por humanos. Veja um model real do Atenda:
class Affiliate < ApplicationRecord
belongs_to :user
has_many :referrals, dependent: :destroy
enum :commission_type, { percentage: 0, first_mrr: 1, fixed: 2 }
before_validation :generate_token, on: :create
validates :token, presence: true, uniqueness: true
validates :commission_rate, presence: true, numericality: { greater_than: 0 }
end
Mesmo quem nunca viu Rails consegue ler isso quase em voz alta. Um afiliado pertence a um usuário e tem várias indicações, que são apagadas junto com ele. A comissão pode ser um percentual, a primeira mensalidade ou um valor fixo. Ao ser criado, o afiliado ganha um token, que precisa existir e ser único. E a taxa de comissão é obrigatória e precisa ser maior que zero.
Sejamos francos: é muito mais satisfatório e produtivo quando você consegue, com pouco código, comunicar o que o seu programa faz. E mais ainda quando consegue ler o código do seu colega quase como se estivesse lendo em inglês.
O Atenda é uma empresa tocada por duas pessoas. E quando falo em empresa, falo de tudo: vendas, suporte, desenvolvimento de produto. É mais trabalho do que parece.
Isso não seria possível sem ferramentas de alta produtividade que colocam o humano em primeiro lugar. Por isso escolhemos o Rails, que o DHH, seu criador, chama de one person framework: um framework com o qual uma pessoa sozinha consegue construir e manter uma aplicação inteira.
É também por isso que usamos Hotwire em vez de dividir a aplicação em um SPA no front-end e uma API no back-end. Mantemos um sistema integrado, que entrega a solução completa para quem interessa: o cliente. E, de quebra, mantemos a sanidade: o debug é mais fácil, as convenções decidem por nós o que não precisa de decisão, e ninguém precisa trocar de contexto entre dois projetos.
Sim, eu sei: com IA, produzir código ficou muito mais rápido. Mas escrever código nunca foi o gargalo. O difícil sempre foi entender o problema e empacotar a solução de um jeito que caiba na nossa cabeça. No Atenda, não colocamos código em produção sem revisão e sem entender as consequências. E código que se lê como uma frase é muito mais fácil de revisar, venha ele de uma pessoa ou de uma IA. Se não formos capazes de sustentar a confiança que os clientes depositam em nós, viramos só um intermediário entre a IA e o cliente, e esse tipo de trabalho tende a ser automatizado.
Mas o mais importante não é só o que conseguimos produzir. De nada adiantariam os resultados se eu levasse uma existência miserável trabalhando com as minhas ferramentas. Quero não só entregar o melhor resultado, mas me divertir fazendo isso, e Ruby tem um peso enorme na nossa satisfação com o código do dia a dia.
Para quem usa o Atenda, isso tem efeito direto. Cada hora que a ferramenta nos poupa é uma hora que sobra para o que prometemos no primeiro Save Point: ler cada pedido e responder cada cliente pessoalmente. E gente que gosta do que faz atende melhor.
Nenhuma escolha é de graça, e seria desonesto falar só das vantagens.
Tipagem dinâmica cobra disciplina. Sem uma boa suíte de testes, os erros aparecem em tempo de execução, e não de compilação. A comunidade Ruby absorveu isso faz tempo: teste é parte da implementação, não uma preocupação para depois. Para quem veio do XP, isso nunca foi sacrifício.
Ruby não é a linguagem mais rápida. O desempenho já foi o espantalho preferido de quem critica Ruby, e por anos com alguma razão. Hoje, com o YJIT, a distância diminuiu bastante, e num produto como o Atenda o tempo de resposta depende muito mais de banco de dados, rede e APIs externas do que da linguagem. GitHub e Shopify rodam Ruby numa escala que a gente nem sonha. Se serve para eles, serve para nós.
Hotwire tem limites. Para interfaces muito ricas, com muita interação no navegador ou funcionamento offline, um SPA pode ser a melhor escolha. Não é o nosso caso. Se um dia for, preferimos pagar esse preço lá na frente a pagar desde o primeiro dia o custo de manter dois projetos.
O mercado é menor. Há menos gente programando em Ruby no Brasil do que em JavaScript, Java ou Python. Se um dia formos contratar, vamos sentir isso.
Pesando tudo, para uma empresa de duas pessoas a conta fecha com folga. O que perdemos em desempenho bruto e em tamanho de mercado, ganhamos em velocidade, em código que cabe na cabeça e em vontade de abrir o editor toda manhã.
Este texto começou com três linhas de código que me conquistaram há mais de quinze anos. Ainda hoje, é isso que procuro numa ferramenta: que ela respeite quem a usa.
Escolhemos ferramentas que nos tratam como gente pelo mesmo motivo que queremos que o Atenda trate os seus clientes como gente.
Se quiser saber como o Atenda pode ajudar o seu negócio, ou só conversar sobre programação, me chama em engineering@useatenda.com.
]]>Ninguém escalou essa pessoa para um plantão. Mas, na prática, ela está de plantão todos os dias.
Eu trabalho com software há anos e, convenhamos, a gente que constrói tecnologia tem parte da culpa nisso. Esse texto é sobre por que, mesmo assim, decidimos construir automação. E sobre o que ela precisa respeitar para valer a pena.
O digital tornou tudo mais fácil: encontrar uma empresa, fazer uma pergunta, marcar um horário. Uma mensagem sai de qualquer lugar, a qualquer hora.
Só que essa facilidade trouxe junto uma regra que ninguém escreveu: se dá para mandar uma mensagem agora, alguém deveria responder agora.
O horário comercial acaba, mas o canal continua aberto. Para o cliente, é só uma pergunta rápida. Para quem recebe dezenas delas, é um expediente que atravessa o dia e entra pela noite.
Poder ser encontrado a qualquer hora virou obrigação de responder a qualquer hora.
Responder uma mensagem leva trinta segundos. A interrupção dura muito mais.
Quem programa conhece bem esse custo: você está no meio de um raciocínio, alguém te chama, e voltar ao ponto onde estava leva bem mais tempo que a interrupção. Com o dono de um pequeno negócio é igual, só que o raciocínio interrompido pode ser um corte de cabelo, uma consulta ou o jantar com os filhos.
E o custo não para quando o celular fica em silêncio. A expectativa da próxima mensagem continua ali, ocupando espaço na cabeça. O sono piora, o foco se espalha, a ansiedade vira rotina.
Gostar dos clientes e levar o trabalho a sério não torna essa disponibilidade infinita. Descanso não é luxo, é parte do que mantém um negócio de pé.
Aqui aparece um dilema que parece inevitável. Ou você responde tudo pessoalmente e mostra que se importa, ou coloca uma máquina para responder e passa a parecer frio e distante.
Eu não acredito nessa escolha.
Cuidado não é repetir o horário de funcionamento pela décima vez no mesmo dia. E uma resposta automática, sozinha, também não garante atendimento bom. Todo mundo já ficou preso numa URA de banco apertando 9 para voltar ao menu anterior.
O cuidado está em outro lugar: numa resposta clara, no respeito ao contexto de quem pergunta e na chance de falar com uma pessoa quando isso faz diferença.
Boa parte das mensagens de um pequeno negócio segue um roteiro: qual o horário, quanto custa, tem vaga sábado, onde fica, o que eu preciso levar. São perguntas previsíveis, com respostas previsíveis.
Esse é o trabalho que uma máquina faz bem. Não se cansa, não esquece e não perde o jantar.
Quando a automação cuida do previsível, sobra atenção para o que precisa de gente: uma reclamação, um caso fora do combinado, uma dúvida que a pessoa ainda nem conseguiu formular direito, uma decisão que afeta a vida de alguém.
Mas a fronteira entre os dois nem sempre é óbvia. Uma pergunta simples pode esconder uma situação delicada. Uma conversa que começou no roteiro pode precisar sair dele no meio do caminho.
Por isso, a habilidade mais importante de uma automação é saber quando parar. Uma automação que não sabe passar a conversa para uma pessoa não é atendimento, é labirinto.
É com essa visão que estamos construindo o Atenda. Na prática, isso se resume a três regras que usamos para tomar decisões de produto:
Se eu tivesse que escolher um único critério para avaliar uma automação, seria este: o que acontece quando ela precisa sair da frente.
Esse compromisso não vale só para o produto. Vale para a gente também.
Quando você contrata o Atenda, ou simplesmente manda uma mensagem para a gente, não está falando com uma empresa sem rosto. Está falando com duas pessoas. Não nos escondemos atrás de cargos como CEO nem de um “time de sucesso do cliente”: somos dois nerds apaixonados por tecnologia, que constroem o produto e respondem a quem usa.
Cada pedido que chega é lido por mim e pelo meu sócio, e cada um recebe uma resposta individual, escrita por um de nós. Preferimos uma conversa franca, mesmo quando a resposta é “isso ainda não dá”, a uma promessa bonita que não se cumpre.
No fim das contas, é a mesma ideia do resto do texto: tecnologia existe para servir às pessoas, e não o contrário.
Essa ideia começa nas nossas próprias ferramentas. Não é por acaso que construímos o Atenda em Ruby. Yukihiro Matsumoto, o Matz, criou a linguagem com um propósito declarado: ajudar quem programa a ser produtivo, a gostar de programar e a ser feliz. O Rails, o framework que usamos, transformou isso no primeiro item da sua doutrina: otimizar para a felicidade de quem programa. Escolhemos ferramentas feitas para servir a gente pelo mesmo motivo que queremos que o Atenda sirva a você.
Se quiser trocar uma ideia sobre o Atenda, atendimento ou tecnologia, me chama em engineering@useatenda.com ou no meu GitHub.
Ninguém deveria precisar ficar disponível o tempo todo para manter um negócio funcionando.
Queremos que sobre tempo para descanso, família, concentração, trabalho bem-feito e para as decisões que realmente precisam de uma pessoa. E queremos que quem procura atendimento seja tratado com clareza e respeito.
Tecnologia não deveria pedir que a gente viva como máquina. Ela deveria assumir o trabalho mecânico para que as pessoas possam viver melhor.
Na próxima vez que você responder pela décima vez a mesma pergunta às onze da noite, lembre: isso não é dedicação, é um processo esperando para ser automatizado. Deixe a máquina fazer o trabalho de máquina, e guarde você para o que só você pode fazer.
]]>