Este é um post mais voltado para quem programa. Se você tem uma veia mais técnica, te convido a ler até o fim.

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.

Como eu conheci Ruby

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.

Programador não é tradutor

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.

Felicidade de quem programa não é luxo

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 que isso muda para quem usa o Atenda

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.

O que custa

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ã.

Ferramentas que tratam a gente como gente

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.