Bikingman Brasil 2021 – Treino 1

O Bikingman Brasil 2021 acontecerá entre 16 e 21 de maio de 2021. É uma corrida de 1005km de extensão, passando por terrenos indo do asfalto à lama e com subidas totalizando aproximadamente 18000m.

Em 19 de fevereiro de 2021 eu comecei meu primeiro treino no percurso da corrida, largando onde a prova vai largar, no mesmo horário da prova, porém em um dia da semana diferente.

Neste texto começo compartilhando dicas gerais para quem vai participar ou acompanhar a corrida. Em seguida escrevo sobre minhas expectativas, aprendizados, causos e resultados do treino.

Como chegar e onde ficar para a largada

Taubaté fica a 2 horas e meia de ônibus de São Paulo, com saídas a cada hora. Mesmo do Rio de Janeiro há ônibus de 2 em 2 horas, e duração da viagem de 5 a 6 horas.

A largada vai ser ao lado do Gran Continental Hotel, parceiro da prova. Eu fiquei no Íbis Taubaté, também a 30 ou 50 metros da largada. Não confundir com o Íbis Styles Taubaté (é claro que eu fiz isso, o atendimento foi gentil e eles trocaram a reserva sem problema).

A largada fica a 15 minutos de bicicleta da rodoviária, ou 7 se você já quiser entrar no espírito do Bikingman. Terreno de asfalto.

O Íbis tem a opção de um café da manhã servido antes do horário normal, acredito que custou R$12,50.

Outros lugares para anotar

Lugares para dormir

Em todo o trajeto que percorri, de Taubaté a Ubatuba, estamos relativamente próximos de cidades ou vilas. O trecho entre Salesópolis e Ubatuba é mais esparso e parece não ter pousadas, ao mesmo tempo com o refúgios o suficiente para aqueles que vão dormir onde for possível.

Penso que os lugares onde dormi nas primeiras duas noites podem se aplicar aos participantes que têm a intenção de completar a prova em 5 dias.

Primeira noite

Na primeira noite dormi na cidade do ciclista desequilibrado: Piracaia. A pousada se chama Requinte da Mantiqueira (Rua Mem de Sá, 100, telefone (11) 99574-3057), e todos na cidade conhecem como “pousada do carioca”. Ótima pousada, ótimo atendimento.

Segunda noite

Na segunda noite fiquei em Salesópolis, no Salesópolis Hostel (Rua Expedicionário Paulo Fatigatti — endereço mais apropriado, impossível —, telefone (11) 4696-1412).

O hostel é ótimo, atendimento muito atencioso e grande experiência em receber ciclistas, já que ali mesmo é largada e chegada de eventos do Randonneurs Mogi. Os donos são amigos do Vinicius Martins, diretor de prova, que foi quem me deu essa dica — obrigado Vinicius!

Terceira noite

Dormi em Ubatuba, na pousada Urbano Suítes (Rua Conceição, 1061, telefone (12) 3833-9029). Também super tranquila, limpa, atendimento muito cordial. Delivery de um bom açaí disponível, mas peça com antecedência porque dava para ter pedalado uns 30km na subida até eles entregarem.

Quarta noite

Não houve quarta noite para mim desta vez, mas compartilho uma dica de Paraty: o ciclista Diogo da Vinha tem uma pousada e uma pizzaria por lá (telefone (21) 99840 8431). Ouvi dizer que há chances de o Diogo participar da prova conosco, ele devendo ser penalizado em 30 horas caso durma na casa dele sem convidar também os outros 74 ciclistas.

Lugares para comer e beber

Alimentação

Entre Taubaté e Ubatuba não notei dificuldade para encontrar restaurantes, mercados, bares e vendas. Talvez no pedaço entre Salesópolis e a primeira vila da estrada de terra para Ubatuba seja mais difícil encontrar alguma coisa sem sair do percurso.

Não pedalei muito à noite, então fico devendo algum comentário sobre a logística da madrugada.

Hidratação

Foi possível encontrar fontes e bicas de água sem nenhum problema, bem como onde comprar.

O Treino

Dia 1

https://www.strava.com/activities/4814550633

Taubaté — Piracaia
222km
4467m de altimetria
16:21 tempo total

Cheguei no hotel em Taubaté às 11 da noite. Havia pego trânsito na saída do Rio e atrasamos quase 2 horas. Como eu acordei às 4 da manhã, acabei dormindo só umas 4 horas. Não me senti quebrado por isso, mas certamente não rendi tanto quanto teria rendido com 8 horas de sono.

A saída de Taubaté é tranquila, alternando asfalto com bloquetes. São 60km passando por Tremembé e Santo Antônio do Pinhal, com 1000m de altimetria e bonitas vistas das cercanias de Campos do Jordão, até o primeiro trecho de terra.

Caminho lindo — mas esse era errado, dei meia volta logo depois
Um checkpoint espiritual do Bikingman Brasil

O começo da estrada de terra é também o começo da subida mais exigente dos primeiros 300km pelo menos. Não são percentuais tão altos, mas a subida é longa e o terreno não é dos mais suaves.

Em Sapucaí-Mirim, no lado direito da estrada, você vai encontrar o Bar do Trevo, ponto conhecido entre os ciclistas de São Paulo. Ali comprei uns risoles e outros lanches pequenos para carregar comigo e ir me alimentando.

Se você vir esta placa, parabéns: você completou a subida mais longa dos primeiros 650km.

A descida após a segunda subida é técnica, convém ter cuidado. Havia poucos carros na estrada, o que só aumentava a necessidade de atenção quando passava algum no sentido oposto.

Após um trecho bem curto de asfalto, paralelepípedo e bloquete, vem um segundo trecho de terra de 34km: é a terceira longa subida do dia. Ela é mais intensa e mais curta do que a segunda. Eu achei ela mais fácil. Ali eu vi uma família de antas cruzando a estrada, deviam ser uns 4 ou 5 adultos e uns 4 filhotes, incluindo um bem pequeno.

Descansando no topo da terceira grande subida dos primeiros 120km.

Descendo esse terceiro trecho, que também não é trivial, chegamos a um trecho de asfalto que vai até perto de Bragança Paulista. É um relativo descanso para a atenção e o corpo, com bom asfalto. Em Vargem atravessamos um morro com uma subida curta e bem dura, com mais de 20% de inclinação. Foi uma bela caminhada!

Eventualmente chegamos a um trecho de 9km de estrada de terra, muito mais tranquilo do que os anteriores tanto em elevação quanto em suavidade do terreno. Neste momento o sol estava se pondo.

O trecho final, que fiz quase todo no começo da noite, foi entre Bragança e Piracaia. É asfalto, em boa parte sem muito acostamento, ao mesmo tempo não tinha tráfego pesado. Foi a única vez em todo o treino que um caminhão passou mais perto de mim — ainda assim, nada comparável a outros “finos” que já me deram por aí.

Essa parte do percurso é relativamente tranquila, sobe e desce de morros baixos.

Cogitei seguir até Igaratá, mas parei para lanchar no Ditto Lanches em Piracaia (comi o carro-chefe do estabelecimento, um excelente X-Espetinho!) próximo das 8 da noite, e para analisar o percurso. Tinha um trecho longo de terra entre Piracaia e Igaratá, e eu poderia chegar lá próximo de meia-noite, talvez me dificultando a encontrar uma pousada.

Acabei dormindo em Piracaia, o que se mostrou uma boa decisão, mas isso já é assunto para o Dia 2.

O atendimento foi muito atencioso em todas as pousadas

Dia 2

https://www.strava.com/activities/4814550633

Piracaia — Salesópolis
190km
3258m de altimetria
15:05 tempo total

Saí de Piracaia às 4:40 da manhã ainda com uma meia-hora de escuro total. Entrando no trecho de terra, logo após a represa, uma bifurcação um pouco estranha: à direita o caminho principal parecia continuar, à esquerda uma porteira de fazenda, fechada. O GPS mandava ir pela esquerda, e por ali fui.

Pouco adiante, outra bifurcação e outra recomendação estranha do GPS: subir à direita de uma casa com 4 cachorros que não estavam entendendo a minha presença ali. O caminho já era bem coberto de mato, acidentado e muito inclinado. Novamente segui o GPS. Logo aceitei que estava subindo um morro, o caminho era não mais que uma trilha, e teria que botar a bike no ombro. Não sei ao certo quanto tempo subi dessa forma, talvez 20 minutos, talvez meia-hora. Era o caminho para uma plantação de eucaliptos, e passando o topo do morro vi pilhas de troncos cortados.

A descida foi bastante difícil também, muito íngreme e escorregadia. Após um tempo o morro acabou e dei numa estrada de terra mais normal, e por fim só pude pensar que esse trecho devia ser propriedade privada, já que estava demarcado também na saída.

Compartilhando videos e comentários sobre o trecho no grupo do Bikingman, o Vinicius, diretor da prova, conferiu e notou que esse trecho não era exatamente o planejado. O software que desenha o trajeto, RideWithGPS, tinha errado — algo que ele faz com alguma frequência. Eu havia feito um trajeto “custom” do Bikingman Brasil, e encorajo os mais aventureiros a tentar também no seu tempo livre.

Numa parada ainda naquele trecho, tirei os óculos e não sei se eles caíram do selim ali mesmo ou se pendurei na minha jersey e eles caíram mais tarde. O fato é que fiquei sem óculos. Meu colete de audax também ficou sem zíper e tive que amarrar com um elástico (um elástico de cabelo sempre salva alguma coisa em viagem).

Parei na próxima cidade, Igaratá, que poderia ter sido a minha primeira cidade de pouso. Considerando o trajeto errado, fiquei feliz por não ter tentado chegar a Igaratá na primeira noite. Mas agora sei que, em modo corrida, é possível passar por lá bem antes da meia-noite do primeiro dia.

Tomei 4 cafés com leite, comi 2 pães com ovo e um sonho, coloquei alguns sanduíches no bolso e segui viagem.

A parte seguinte tem uma intersecção grande com o trajeto de um brevet Randonneurs misto que fiz em dezembro de 2020, também criado pelo Vinicius. Só que desta vez passei no sentido inverso, o que foi muito bacana.

O prêmio maior é a chegada em Guararema: há uma rua que dá de cara com o rio Paraíba do Sul, e ali precisamos passar por um beco estreito e bem interessante. Saindo do beco, caímos na linha férrea da cidade, atravessamos a ponte ferroviária com uma linda vista, e chegamos na estação da cidade, que é bastante charmosa.

Saindo de Guararema há uma subida não muito longa mas exigente. Neste ponto, apesar de não estar exausto, eu já sentia algum acúmulo de cansaço. O sol estava a pino também.

Passei próximo a Mogi das Cruzes, já com um movimento urbano que estranhei depois de quase 400km no interior. Mas durou pouco e logo estava de volta a estradas mais vicinais.

Pão com ovo e mel — iguaria
Nascente do rio Tietê

A tarde estava começando a cair, talvez fossem 4 horas, e uma placa: Salesópolis a 20km. Esse era o caminho pela autoestrada: na corrida vamos pela terra, dando a volta na represa, com mais do que o dobro da distância. Mais uma vez era o caminho que eu tinha feito em dezembro, apenas ao contrário. É um caminho bastante bonito, em particular quando beiramos ou atravessamos a represa. O cascalho ali em alguns trechos é bem solto, e tem subidas que te obrigam a empurrar a bike, mas não por grande distância. Fiz uma boa parte seguindo dois bons mountain bikers que faziam ótimas linhas no cascalho. Mesmo provavelmente mais cansado do que eles, consegui acompanhar, mais graças à bicicleta do que às minhas pernas.

Anoiteceu nessa estrada, com um misto de sol e leve chuva. A temperatura estava bem suave e a lua no alto. Cheguei no começo da noite em Salesópolis. Havia sido avisado que não teria tantas opções de pouso logo após Salesópolis, então fiquei por ali e ainda pude tomar banho e sair para comer uma pizza antes de dormir.

Dia 3

https://www.strava.com/activities/4827699210 – o Strava e o Wahoo pararam de registrar antes de Ubatuba

Salesópolis — Ubatuba
~150km
~2550m de altimetria
13h tempo total


A saída de Salesópolis é o primeiro refresco de toda a prova: asfalto, acostamento largo e muito mais descidas do que subidas. O dia amanheceu ali, e a cada duzentos metros um falcão reinava sobre a pista. Ao me ver eles levantavam vôo, e várias vezes fomos voando juntos.

A paisagem é muito bonita, e só foi melhorando ao longo do dia.

Após umas poucas horas, cheguei na rodovia Tamoios, que desce de São José dos Campos para Caraguatatuba. O acostamento dela é mais largo que muita rua por aí, mas havia um trecho em obras que precisou de um pouco de atenção e generosidade dos carros.

Pouco depois do pedágio, a saída da Tamoios leva à estrada de terra que vai até próximo à descida para Ubatuba. Durante 20 ou 30 quilômetros é chão de terra bem batida e com menos subidas. Dá para desenvolver muito melhor do que nas estradas de terra dos primeiros 2 dias.

Passamos por vilarejos bem pequenos. O maior deles talvez seja Pouso Alto, ainda no começo, que foi onde os diretores de prova Vinicius e Axel dormiram em cima de uma padaria no reconhecimento que eles fizeram. Eu realmente não vi pousadas nessa estrada, mas há água e comida durante o dia.

Saindo de Pouso Alto a estrada gradualmente começou a mudar, e foi se transformando numa estrada de terra como as típicas do sudeste do Brasil: terra vermelha e alguma erosão. Nada muito sério aparentemente, mas pela primeira vez encarei bastante barro.

A minha bicicleta já tinha acumulado terra entre o quadro e o pneu traseiro nos primeiros dias, e não tinha chegado a atrapalhar. Aqui, rapidamente o barro bloqueou o pneu que, quando girava, ficava pincelado de lama e muito escorregadio.

Limpei essa lama algumas vezes, inclusive tirando a roda do eixo para ajudar, mas logo o barro acumulava. Isso em um trecho de talvez menos de 1km.

Escorreguei na lama e caí para a esquerda. Eu estava devagar, então nada aconteceu. Levantei, pedalei talvez mais uns 100 metros e caí para a direita. Também não estava rápido e nada aconteceu comigo, mas quando levantei e tentei pedalar, nada. O câmbio traseiro estava solto: a peça que liga o câmbio ao quadro, a famosa gancheira, havia quebrado.

Pensei que talvez uma oficina não muito distante tivesse outra gancheira, então preferi não mexer na bicicleta e empurrar até entender melhor. Acabei andando 12km (subindo na bike quando havia descidas) até chegar a Vargem Grande, um pequeno vilarejo.

Ali recebi a ajuda do seu Ramiro. Seu Ramiro trabalhou com bicicletas há mais de 20 anos e, ao me ver, exclamou toda a sua repulsa a câmbios de bicicletas. Logo ficou claro que não haveria gancheiras por ali. A alternativa foi desmontar a corrente da bike e fixá-la como em uma bicicleta sem marchas: escolhemos uma relação de marcha um pouco mais leve, retiramos os câmbios e rezei um pouco. Testei e funcionou, não sem antes a corrente escolher o peão dela e ficar extremamente esticada. Mas dava para pedalar, restando apenas saber por quanto tempo.

Segui pela estrada de terra, ainda encarando algumas subidas de respeito, mesmo sem a marcha ideal para isso. Depois de mais uns 11 ou 12km, cheguei no asfalto. Começou a chover, e segui no ritmo possível para o estado da bicicleta rumo à descida da serra para Ubatuba.

Cheguei na descida depois das 4 da tarde. Chovia, havia uma neblina considerável e, por ser domingo, a estrava estada movimentada. Felizmente a maior parte do movimento era no sentido contrário.

Foi o trecho mais tenso da viagem para mim. A descida é longa e íngreme, o asfalto estava escorregadio e eu não podia contar com a tração da bicicleta caso fosse necessário. Depois do perrengue da gancheira e do desgaste natural dos 3 dias, eu sabia que mentalmente não estava 100%. No comecinho da descida, um senhor com uma bicicleta de trabalho, daquelas com um espaço grande para engradados na frente do guidom, “pegou minha roda”. Acho que ele simplesmente não queria descer a serra sozinho.

A descida tem 8km. A cada quilômetro tem um recuo no asfalto para emergência. Optei por parar duas vez em um desses recuos, apenas para dar uma zerada mental dos carros que tinham me ultrapassado. Vale lembrar que, na corrida, os participantes vão passar por essa descida em um dia de meio de semana, portanto provavelmente muito mais tranquilo do que o que eu vi.

No fim deu tudo certo e cheguei a Ubatuba ainda com a luz do dia. Encontrei alguns personagens raros logo na entrada da cidade.

No trajeto eu já tinha trocado mensagens com amigos do Bikingman que procuraram me ajudar com contatos de mecânicos e lojas locais. Eu ainda pensava em seguir naquele dia mesmo até Paraty. Conforme ficou claro que não haveria atendimento naquele dia, busquei uma pousada bem próxima à loja de ciclismo considerada a melhor de Ubatuba, a Trilha Norte.

Jantei um açaí gigantesco, lavei minhas roupas e dormi.

No dia seguinte, já que teria que esperar a loja abrir, aproveitei o café da manhã da pousada, que foi espetacular depois dos dias comendo em movimento.

Arrumei tudo, montei a bike e toquei para a Trilha Norte. Em minutos entendi que não seria fácil encontrar a gancheira. A Trilha Norte é representante da marca Specialized, minha bicicleta é Cannondale e Ubatuba até tem representante Cannondale, mas ela também não tinha a minha gancheira.

Rodei 12 bicicletarias, fui até uma serralheria, mas a gancheira é bem específica e não houve solução. Como eu tinha apenas aquele dia e mais um, pesei tudo e optei por voltar de ônibus para o Rio, poupando um dia de folga para outra oportunidade. Foi uma volta bem tranquila e no fim da tarde eu já estava em casa.

Aprendizados

  1. Em provas com trechos de terra, levar gancheira reserva.
  2. Saber instalar a gancheira — depois instalei uma nova e é muito fácil
  3. Numa prova com terra e 5 dias, considerar pneus para terreno molhado, ou no mínimo misto. Pneu para terreno seco vai ser ótimo enquanto estiver seco, mas em 5 dias a chance de chover é enorme e uma queda boba pode pôr tudo a perder
  4. Durante o dia, não parece necessário levar 4 ou 6 sanduíches de reserva. Dois está mais que bom — há lugares para comprar e, sendo ágil nos botecos, parar a cada 4 horas refresca a mente.
  5. Testar bolsa de quadro além das bolsas de selim e guidom. Não faltou espaço na bike, mas a ênfase na bolsa de selim exigiu tirar muitas coisas para alcançar outras. A bolsa ficou bem desequilibrada também, e no primeiro dia me incomodou batendo na minha perna ao pedalar. Perdi um tempo até achar uma solução: amarrar uma tira de câmara no selim e com ela puxar a bolsa pra cima.
  6. Podendo, comprar um Garmin 1030 Plus. A tela maior deve ajudar na navegação. O fato de ser colorida deve facilitar a visualização rápida. A bateria dura muito, então menos um item para se preocupar em carregar todos os dias.
  7. O “cockpit” se torna muito importante: posição do ciclocomputador (para carregá-lo pedalando, o cabo encaixa sem problemas? É fácil ler a tela mesmo numa estrada muito esburacada, na descida?), o que colocar na bolsa de guidom, e como organizar, farol não atrapalhar ou ser atrapalhado pelos outros itens.
  8. O setup de bikepacking é mil vezes mais legal que os alforjes laterais. Se você estiver dando a volta ao mundo e acampando, ok: alforje. Para uma viagem de 1 a 10 dias, sem camping, as bolsas de bikepacking resolvem perfeitamente e a bicicleta fica muito mais equilibrada.
  9. Provavelmente dá para não levar nenhuma roupa de dia-a-dia na corrida, apenas jersey, bretelle e agasalhos de pedal.
  10. Cortar o cabo da escova de dente não vale a pena. A dignidade de escovar os dentes direito, uma vez por dia que seja, compensa os 10 gramas a mais que vamos levar.
  11. Viajar de bicicleta é transcendentalmente maravilhoso. Isso eu já sabia mas a gente sempre renova esse aprendizado.
  12. Quem não se comunica se trumbica: eu havia compartilhado um video com meu “kit” de viagem e nele pedi orientação aos atletas mais experientes. Eles me ofereceram ajuda não apenas quanto ao kit como também as mais variadas dicas e encorajamento. E estou falando de caras com provas muito cabulosas no currículo. Foi de grande valor, agradeço muito!

My Year in: Tech

I started out 2020 taking my first relatively prolonged vacations of the last 15 years or so: 3 weeks. Coming out of the first year of my twin children, the break was welcome.

To recap, I was working at Toptal’s core and had just finished recruiting a new team, having hired 3 new front-end engineers. I put myself in contention for a promotion to Engineering Manager. At Toptal this was a rarefied position. The company was about 600 or 700 people and only 4 EMs existed. They were opening 4 new spots. I was looking for a step forward, not necessarily associated with a title.

Almost parallel to that, a former colleague tweeted that his company, Circuit, was looking for people. I really love this guy, Filipe Alvarenga, so any company he’s working for must have virtues. I met Jack Underwood, one of Circuit’s founders and its CEO. I felt good about him and the company. It helped that Jack publishes monthly letters to the public about how the company is doing, and they seemed very candid.

Circuit provides technological infrastructure for last-mile deliveries. Think managing your daily routes if you are an individual driver, and also doing that in a team of dozens of drivers.

I was hired at the Team Lead level, same as I had been at Toptal. The idea was to expand the front-end headcount at Circuit and create a React team. When I joined, in the second half of March, the world had just been turned upside down by Covid. All plans at the company changed very quickly: despite the immense negatives of the pandemic, Circuit was in a position to help things and grow significantly, as deliveries exploded everywhere.

I operated as an engineer for the rest of the year. In my first 2 or 3 weeks I wrote an application where recipients of deliveries could track their shipments. It was relatively simple, and got shipped quite smoothly. That was the first application written in React at Circuit.

The company’s focus had shifted to really serving teams of drivers. It’s a natural progression from individual drivers, to teams, and eventually to enterprise.

Our back-end uses Firestore, a serverless product from Google, and there was work to do there after completing the recipient application. I shipped or helped ship several of these cloud functions, both for external and internal use. What was missing in our backend were tests. A colleague had just started writing unit tests in the repo. I spent weeks of off-time trying to learn how to properly test back-end functions in Firestore. The documentation is not helpful and I could not find good materials. So I pieced out the knowledge, tried things, and eventually got one version to work, then we all improved on it. I think this was our main achievement of the year, technically. Soon the tests spread out in the app, all colleagues were writing tests, and I believe we got a much more productive rest of the year with the benefits of serious test coverage.

After some work converting our internal admin panel to React, we took on the rewrite of SpeedyRoute.com, also in React. SpeedyRoute is an acquisition made by Circuit some time ago, originally written in CoffeeScript. We completely rewrote it in React, and now the UI looks a bit more contemporary too. Around then the decision was made to convert all our web applications to React, and to start the new ones in React as well, phasing out Ember.js.

At this point, we were in the last quarter of 2020 and we were ready to go back to the original plan for my joining Circuit. Jack invited me to lead the recruiting of 4 front-end engineers. It was great to be back doing interpersonal-focused work. The internal recommendations of engineers were very strong and this helped the process move quite quickly. We now have 3 hires and may close out the 4th soon.

The newcomers will start in the first few weeks of January, and we will spawn a team to rewrite our most important web client, Circuit for Teams.

The year was challenging, of course, but at work it did not feel proportional to a global pandemic. The culture at Circuit is driven but very balanced, the founders are sensible, very intelligent, and rational. They are always present, designing and coding along, so it feels they get a much more realistic sense of how things are progressing than if they were only doing management. And because they are working with everyone, it is just natural that we can talk frequently and issues get resolved quickly.

The company more than tripled its annual recurring revenue from US$3M to just over US$10M this year. There were next to no major bugs or incidents, and a lot got done during the year. Interactions with everyone were unfailingly pleasant and constructive.

I was the 8th person in the company when I joined, we are now 12 and, with the new team, will be at least 16 in the first quarter of 2021. It will be fun to help grow the company, help keep the good things that can be kept of the current structure, and also help add good things for it to scale nicely. We have reasons to be optimistic that Circuit will accomplish this.

TDD with Firestore functions emulator

Having spent time running tests inside and outside Firestore’s emulator, I learned that using the emulator is more than 50% faster.

Here is the latest flow we are using at Circuit. If you know of a simpler way, please let me know at gus [at] getcircuit [dot] com.

Basic version

firebase emulators:exec --only firestore 'jest'

You can replace jest with the runner of your choice.

Abstract the emulator call

Install scripty:

yarn add scripty

Add an entry to package.json:

{
  …
  "scripts": {
    …
    "test": "scripty"
  }
  …
}

Create a directory called scripts in the root of your project.

Create a file with path and name scripts/test:

#!/usr/bin/env sh

str="$*"
firebase emulators:exec --only firestore "yarn jest $str"

Allow computer to run this file:

chmod 644 scripts/test

Now you can run yarn test and add anything you would add to the command, like yarn test --watch, yarn test /path/to/test.file.

Enable connecting with a browser’s debugger

Add an entry to package.json:

{
  …
  "scripts": {
    …
    "debug": "scripty"
  }
  …
}

Create a file with path and name script/debug:

#!/usr/bin/env sh

str="$*"
firebase emulators:exec --only firestore "node --inspect node_modules/.bin/jest --watch --runInBand $str"

Allow computer to run this file:

chmod 644 scripts/debug

Add debugger to any line of your Firestore code.

Run yarn debug — you can also pass a filename to focus on it right away.

Open your browers’s developer tools.

Click on the green cube (Node’s logo):

This will open the debugger and you’re ready to step debug your code.

Simple tips for applying for a new development job

For several years, recruiting has been a part of my job in software. A few times I’ve been on the other side, looking for a job myself.

There are many low-hanging-fruit-type tips that can really make a difference when we look for a job. By making mistakes myself, seeing them made while recruiting, and by talking to colleagues, it’s now possible for me to list a few. Some may seem obvious to you — if you haven’t yet recruited, you’re in for a surprise over how common they are, and how much they affect the chances of someone getting a great job.

Learn about the company first

Before starting your application, spend no less than an hour attentively studying the company. Go to YouTube, try to watch videos involving top leadership. Read articles and learn about the people there.

Apply only to companies you care about

If you are in full application mode, apply to no more than 3 companies per day. Ideally 1 company.

If the company’s purpose doesn’t resonate with you, recognize the fact and move on.

Look at companies’ careers pages

Several companies, often the best ones, don’t advertise open jobs. They have their own careers pages and, relying on their reputations, will wait for applications.

For people who like to work remotely, Remotive’s company list has been helpful to a few people I know: https://remotive.io/remote-companies.

Don’t wait to apply

Once you’ve learned about a company and feel enthusiastic about it, apply immediately. In the global development market, good companies receive hundreds of applications on the first day or two after they post a job.

Apply to many jobs

While not applying to just any open job, do apply to as many of them as you truly like. Statistically, odds are low that you will be called for one given opportunity.

Start early

If I am suggesting you do not apply to too many positions each day, but to apply to many positions, by consequence I am suggesting you start early in your job search. Maybe practicing going through recruiting processes even before you need or want to do it can be ideal.

No spelling or grammar errors

Make it perfect in the language the company operates in. Pay someone, or a service, if needed. Great companies will quickly screen out applications that have language mistakes. By writing minimally well, expect to go to the top 10% of all applications.

Add a Github link to your CV

This is a huge differential. Prefer Gitlab or Bitbucket? Great, use your favorite. Don’t have public repos? Add repos of things you study, it’s perfectly fine. Make sure you add very good READMEs enabling visitors to run and test your repos.

Nothing like relationships

All the above may not be necessary if you have good relationships with former colleagues. You may be sought out before you need to look for a job. For this to happen, it is not enough to be very proficient at the technical part, people have to like spending time with you.

Git basics while typing less

Very short git commands

As computer programmers evolve in their craft, they increasingly identify repetitive tasks at all levels. One of the most basic levels is typing on the keyboard. Some programmers choose to invest effort and minimize typing. I am one of those people.

Git commands are among the ones I use the most, as listed in decreasing order with the number of times for each:

1241 gc
637 gco
583 v
419 git
373 cd
368 rm
316 mv
302 yarn
299 gb
247 gto
215 ga
213 c
191 gst
160
136 bundle
124 ©
115 mkdir
114 cp
106 npm
106 gt

If you’d like to see yours, you can run the following on the terminal: history | awk 'BEGIN {FS="[ \t]+|\|"} {print $3}' | sort | uniq -c | sort -nr | head -n 20

Please note that the number 20 at the end is the number of results to retrieve.

Back to my own history, you can see that:

  1. I use a lot of aliases
  2. Most of them are git-related, and that’s why they start with a g; gc is git commit, gco is git checkout and so on.

Recently I have taken this to the extreme, and so far the results have been excellent. Below are the commands I am able to run:

c (git commit or git commit -m, depending on the args passed)

p (git push)

a. (git add .)

b (git checkout -b)

The c function works for the following cases:

  1. c (will open the text editor for a long commit message)
  2. c “Your commit message” (acts as an alias for git commit -m
  3. c Your commit message (the one I love as you just type c plus the message, and it works)

While p and a. are calls with no args, with b you must simply add a branch name.

These are extremely simple improvements to the flow, and together with many others that I created or that I use from libraries, they make the path from brain to computer shorter and more pleasant.

To see how these are implemented, please visit this gist: https://gist.github.com/gusaiani/70736c970c2b2d4020006eb7dd31bc40

The commands in the gist which are not defined in this file come from oh-my-zsh plugins.

My Year in: Tech

I started the year of 2019 as a front-end developer at Toptal’s core team. Just a few days later, I was invited to be Team Lead for a brand new team.

My emphasis turned, again, to working with people. That was a delight and I fully embraced the opportunity to help build a team. We had a few company veterans enlisted to start the new team, all of whom I had not worked with before, and we needed to hire two more front-end engineers.

The first recruitment process was for an excellent React engineer. It was done very deliberately and unhurriedly, to make sure we raised the overall level of the team on the React stack. It took us a little over 2 months until we found a great guy, who has contributed a lot this year.

The second engineer was a gift to us, as he was initially hired for another team. Happy to say he’s also doing tremendously well.

We quickly became a real team. It seems we did a few things that helped: communicating a lot, admitting mistakes and ignorance openly and quickly, and being real human beings.

One teammate brought along the Personal Questions call from his previous team. This call has a simple structure: one team member asks one or two questions, personal as the name says, to everyone on the team.

The questions are as simple as “What was the best trip you ever took?”, or “What is your favorite dish?”. It’s up to the team to let this call become just a little window on who they are, or a huge gateway to people’s souls. Yes, it’s possible to cry while listening to someone tell you about their favorite food once they tell you the story behind it. The bond I felt with the team was immense.

Dedicating at least one or two hours per week of each team member’s time to building rapport makes a big difference, particularly in new teams. Next year I will work to learn more ways of doing that.

I made my share of mistakes. The one that comes strongest to mind is about having patience before giving feedback to people you may like personally but don’t think are doing a good job — especially when they are not reporting to you. Convincing people to change is hard enough as it is, doing it without mutual trust and knowing their motivations is likely to backfire.

Another lesson I was reminded of by a mistake of mine is the “no surprises rule”. It’s often hard to know, in advance, how sensitive some task or decision may turn out to be. Next time something I do starts to deviate too much from what was agreed-upon, I should remember to share that early on, and avoid surprises, because the surprise itself may make people react negatively to something fundamentally desirable, or I may have the wrong assumptions or decisions and other points of view will help me see that.

I stayed with the team for a total of 9 months, we launched a good chunk of the new application we were developing, and then I was enlisted to start a new team from scratch: to recruit every single engineer, and help recruit designer and product manager.

It was painful to say goodbye to a team I loved so much.

Soon it was back to recruiting, this time a few weeks of full-time effort, and we are still at it. We seem to be close to hiring two people, and have one more front-end and one more QA person to bring onboard on the engineering side.

This recent team switch gave me time to study programming after a several-month hiatus. I am focusing on new React APIs, from Hooks to Context and Suspense, as well as testing, TypeScript and, soon, Apollo.

I did continue to study the Elixir language source, something I’ve done for maybe 3 years now. This year I did relatively little of it. I love Elixir just as much as always, and am thankful for having learned so much from its community.

I plan to go multi-team as soon as I have a chance, be it in an Engineering Manager or CTO role. Thus I dedicated more time than ever to reading about leadership, management and communication, often with a big emphasis on tech. Especially for people who are new to management, I recommend The Making of a Manager by Julie Zhou.

A personal take on interviewing programmers

A few months ago some members of the team I lead at Toptal’s core team started interviewing programmers.

The fundamental questions that popped up were simple and deep: What should I look for in the interviewee? How do I know I should pass or fail the person?

I really like the priorities my own former supervisor, Timo Roessner, advocates: to look for—in decreasing order of importance—a team player, a good communicator, and a technically excellent person.

The person should ideally be very good at all 3 requisites. The main point, however, is deemphasizing technical wizardry in favor of interpersonal skills.

How to assess team-playing chops in a 90-minute interview with a coding challenge

Team-playing chops and communication chops seem intermingled, and in fact I believe one potentializes the other, but they can be assessed quite separately in software engineers.

As you facilitate a coding challenge or nearly pair-program with the interviewee, try to make it as close to the interviewee’s normal workflow as you can. Don’t use CodePens, have the interviewee use the editor or IDE of her preference. Apart from the technical things you need to evaluate her on, encourage her to use her favorite tools and procedures.

What you need to evaluate the candidate on is up to the needs of your company or team, but in general I prefer to give the candidate a wide-open small project instead of some algorithmic or procedural task. The reason is you will get a chance to role-play being the customer or Product Manager, and you can talk to the interviewee as such and see if she is able to conduct a dialog like this.

Calibrate, as you go along and get a sense of the candidate, how high-level or low-level it’s better to be. That is, is this person more concerned about the coding nitty-gritty or about what the entire project should do? Both are fine and necessary programmer inclinations, but the quicker you spot the candidate’s preferences, the quicker you can develop a rapport.

As the coding challenge starts, pay attention to the questions and shared thoughts. It should be clear to you, given some experience, if the candidate has mileage or a willingness to openly express thoughts. If they don’t say anything at all, probably this person will behave the same way at work.

Avoid, or delay, “helping” the candidate. Generally, in a coding challenge lasting 1 hour, I may interfere 1 to 3 times. But when you do, try to make it very meaningful and make it so that the proposed change of course really takes things in a different direction.

For example you propose the programmer develop a simple game. She starts by crafting the algorithm that will define if the game is over. As the interview goes past half its allotted time, and if the candidate has shown a good direction regarding the solution, propose she create the UI (if she is a frontend developer), or suggest creating a way to store a leaderboard (if she is a backend developer).

The way the candidate reacts to such proposals can be telling of a team player.

Also, very often candidates will do or say things that you don’t know anything about. Tell them you don’t know anything about that and see how they react. Do they explain it to you? Are they surprised? Do they convey a sense that they respect you less for that? But don’t pretend you don’t know something you know—you don’t need any trickery to interview people well.

How to assess communication chops

Assessing communication skills is a bit easier than assessing team-player inclinations. Start with the basics: can you even understand what the interviewee is saying? Often that is not the case. If and when you don’t, tell them that in a gentle way. This happens particularly often in international interviewing when spoken languages are not native to you or the candidate.

The opposite can happen: the candidate does not understand you. You should, of course, try your best to communicate clearly, and if the candidate still has a hard time getting what you are saying or asking, notice if they have the energy to ask you to clarify. If so, that is a good sign.

Being able to listen deeply is what differentiates an ok communicator from a good or great one. Does the candidate flow from what you are saying? In other words, can you notice them using and reshaping pieces of your discourse? Repeating things back to you transformed? Those are good signs. If they just respond things that seem unrelated to what you have been saying, then clearly this is a minus. More often things fall around the middle, and with time you will develop a feel for how good the candidate seems to be, plus the courage to use your intuition when the decision is not clear-cut.

How to assess programming chops

This is the easiest part if you yourself are a programmer, but it’s still challenging sometimes. Granted, it’s easy to reach a conclusion in extreme cases: if the candidate did really poorly or just brilliantly in the coding part.

When things fall more in the middle, which is by far the most typical, your skill can make a huge difference in the decision to say Yes or No to a candidate.

I always like it when a candidate writes, in human language, something like a list of things that need to happen in the program. For example, if the proposed task is to build a search user interface: to jot down that the screen has an input and a submit button, the user will type a string in that input, then press the submit button, and so on. This helps the candidate “think like a computer”, it allows her to expose her thought process to the interviewer and, if her assumptions are off-base, to know early. The worst that can happen is to end up with a little algorithm of what to code.

TDD, or anything similar to that, is a huge positive differential. It is a kind of planning ahead.

I must say it’s very rare that anyone uses TDD in interviews I run, and I’ve run a few hundred of them at the very least. It has never ever happened that a candidate wrote down point by point what should happen in the application.

Finally, good code architecture early on is one of the strongest signs that the candidate is good. If they refactor continuously, improve variable names often, and order things in their codebase without losing their train of thought, you are looking at a hire. And that’s why giving people much harder tasks than they will face in their work is typically not a good idea: you need to see how they can make code understandable to fellow programmers.

So if they start one file and fill it up with disorganized, commented out code and huge blocks of attempts, unless you asked them to do something too hard, in general consider this as a potential flag. But don’t get stuck to this: it’s not uncommon for great developers to seem quite sloppy the first 15 minutes in, and 10 minutes before the hour, to start deleting code and apply a final layer of improvements that leaves the code looking quite wonderful.

If you give the candidate a project that is larger than the hour you have to interview, something I support you do—as long as you set the right expectations, otherwise you will have a frozen person in front of you—, and you enabled the candidate to own the code in her machine, the bonus point is them continuing the project on their own. Until recently I sometimes suggested they do it. Nowadays I don’t even suggest that. If they have a way to reach me, they can do it if they want. I certainly take it as the strongest sign of interest in the part of the candidate if, hours or even a couple of days later, they get in touch with the completed project.

Participating in Daily Standups



Purpose of Daily Standups


You should leave a daily standup:

  1. More energized than you entered it.
  2. Aligned to be in contact after the daily with anyone if your or their main task needs discussion.
  3. Remembering everyone’s update.

Things outside of Daily Standups that can ruin Daily Standups

  1. If team communicates 1-to-1 a lot and not on shared channels.
  2. If people are tackling too many things at the same time.
  3. All basic management deficiencies.

How to prepare for a Daily Standup

Half an hour before the Daily Standup, stop for 5 minutes and:

  1. Decide what is the one initiative you will mention.
  2. Write it down in your own words.
  3. Edit that down to 280 characters.
  4. Include expected time to finish task at the end.
  5. Say it aloud.
  6. Improve the wording or delivery until you have a clear and memorable update.

How to decide what to mention in a Daily Standup

By decreasing order:

  1. Task you are doing that is most problematic.
  2. Task you are doing that you know someone can help you with.
  3. Task that is going well.

How to listen well in Daily Standups

  1. Keep a log of Daily Standups and make notes of every update.
  2. Come back to that log half an hour after the daily and read it again.

Trusting the Scrum Master in Daily Standups

If each team member delivers their update clearly, nicely and concisely, the Scrum Master will have time to:

  1. Ask about important items that were not selected by the team.
  2. Raise questions.
  3. Ask about extraordinary additions to people’s update.
  4. Align people for pairing on issues raised.
  5. Use the extra time for having a bit of fun and enjoying the team before it gets back to work.

My Year in: Software Development

The year of 2018 has been a wild ride for me. It started at EmCasa.com, the startup I described a year ago. We were in the process of putting out a successful MVP, engaging clients, becoming accelerated by Harvard University and closing out an excellent seed round with important investors. All this in just a few months.

Very quickly my job morphed from do-it-all (think product and CTO duties, plus co-founder responsibilities) to team-building. This was a highlight as I was lucky to bring in great people like Gabriela Seabra, Nathan Queija and Rodrigo Nonose, each respectively owning mobile, web frontend and backend. On the design side, Plau.co did great work.

For the first time I felt fully ready to create a digital company in style. The Elixir-React stack worked beautifully, we rolled out features fast and the development team became a cohesive unit very quickly.

Towards the middle of the year, as the company reached 14 people, it had become clear to me that there wasn’t a good cultural fit among the founders. It was one of those very painful decisions but ultimately not difficult to make when visions don’t intersect well enough: we parted ways amicably at the end of July and I went looking for a new job.

That month was tense for me. I knew I had a deadline to basically stop getting paid, my wife was 6 months pregnant with twins and I had nothing lined up as far as work.

I am part of Toptal’s network of freelancers and that was one of the main ways I tried to find the next thing. I found something that really interested me: they had posted an opening to join their Core Team. I applied, passed, and joined the team as a freelancer in August. 

The first few weeks were hard in a sense: I and two other developers coming from Toptal’s talent network had a kind of secondary status, without access to many tools. Luckily our teammates were extremely helpful and welcoming. In a few weeks we became official team members and got access to what the other engineers see.

My team works on Toptal’s public pages, from home to skill pages, basically everything a logged out user can access in the website. 

It’s been a tremendous experience for me so far, as it’s the largest organization I’ve been a part of in technology. Toptal is in fact the largest fully distributed company in the world today. As such, I work with people from all over the world, and that’s the part I like best. To do it from home is the cherry on the cake as my children are very young and being close to the family is priceless at this moment.

At my team I’ve experienced the most well-developed set of processes I’ve ever come across. The firm has reached a level of maturity that allows for very well written task tickets, a proper retrospective at the end of each sprint, interesting strategic discussions among executives, and work that has large-scale, immediate impact. On the other hand, I am very far from top strategic decisions and information, and this feels weird to me having run my own company for so many years.

To a very large extent, this was the year when, for me, technical concerns became secondary to human concerns. Sure, if you’re starting a product alongside just one other person, what tech stack exactly to choose is of paramount importance. In a team of 200 that’s much less important, as each person can focus on a narrower part of the work, and the human interactions can catalyze or hinder progress.

Thus, I gave myself the chance of observing all the teams in the organization: dialogs, processes and rituals. Whatever was visible to me, I tried to learn from. It wasn’t long before I got the opportunity to onboard newcomers, help interview candidates, conduct daily standups and interface with other companies. That’s not to say I didn’t study programming this year: I continued my deep-dive into the Elixir codebase, studied GraphQL, some more Elm, algorithms, some Python and a little bit of Natural Language Processing.

It’s much easier to paste some code or links to a framework and illustrate what goes on as a programmer. Human interactions seem to me much harder to communicate. A book that does a great job of explaining management applied to software is The Manager’s Path, by Camille Fournier. I read it this year and it very neatly sums up many things we learn the hard way, plus many others I simply did not know.

So this year was one in which I started out as CTO and ended-up as an individual contributor. But each experience has taught me a lot about management and leadership, which will be my way forward in technology.

 

Naive Investor, Episode 400

Today Naive Investor has hit episode 400.

If anything, a good excuse to post about it here.

Initially I went for posting every single episode in this blog, but pretty quickly the blog would become just a mirror of the YouTube channel.

A lot of learning has indeed taken place. That was the main goal. Along the way, people have sent me corrections, suggestions and encouraging messages.

At year end I will publish the update to the little (but growing) investing partnership I’ve been running rather informally for now, and which incorporates the knowledge gathered from the Naive Investor videos.

If you don’t yet subscribe to the channel, please consider doing so: https://www.youtube.com/c/NaiveInvestor

And here’s the 400th episode: