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.

Carta da Parceria de Investimentos — 2019

Caros parceiros,

o retorno da nossa parceria em 2019 foi de 59,25%. A cota encerrou o ano a R$1,72409133324.

Nossa parceria superou o índice Bovespa, que subiu 31,58% no ano, em 26,67 pontos percentuais.

Ano Nosso Fundo Ibovespa
2017 29,44% 26,86%
2018 11,51% 15,03%
2019 59,25% 31,58%
Acumulado 129,86% 92,01%

Nossos ativos sob administração cresceram 183,40% no ano. Como vou lembrá-los a cada carta, toda a minha poupança vai para a parceria. O princípio é simples e o mesmo de sempre: objetivos compartilhados e a certeza de que estou cuidando da parceria com o mesmo zelo com que cuido do futuro da minha família.

Começamos o ano com 6 empresas no portfólio: Cyrela, Trisul, Hering, Metisa, Tarpon e Cielo. Na carta aos parceiros do ano passado eu compartilhei que a permanência da Tarpon em nossa carteira era uma dúvida. A própria empresa retirou suas ações da bolsa este ano.

Outra empresa que não está mais em nossa carteira é a Trisul, desta vez por bons motivos: suas ações mais do que quadruplicaram de preço em pouco mais de um ano. A empresa emitiu também novas ações em 2019. Com tudo isso, o preço da empresa, ao menos até onde consigo enxergar, deixou de ter uma margem de segurança suficiente para o futuro.

O setor imobiliário mudou de perspectiva com os juros em queda. Nossa alocação de quase 35% da carteira na Cyrela e na Trisul, quando começamos 2019, deu resultados muito bons e rápidos — a Cyrela quase dobrou de preço no ano, mais dividendos.

Ao longo do ano acrescentamos à nossa participação na Cielo, e hoje ela é um terço do nosso portfolio. Foi um ano marcado pela ida de concorrentes como a Stone Pagamentos ao mercado de capitais, esta com o glamour a mais de ter sido via Nasdaq. O mercado de meios de pagamentos deixou mesmo de ser um monopólio da Cielo e é agora um oligopólio. Nos últimos 4 anos a Cielo perdeu mais de 70% de seu valor de mercado, mesmo atendendo o país inteiro, tendo grandes clientes e muitos anos em atividade. Acredito que a Cielo passou boa parte do ano de 2019 custando menos do que vale.

A única empresa nova em nosso portfólio este ano foi a Metalúrgica Gerdau. A Gerdau que todos conhecemos é subsidiária da Metalúrgica Gerdau. Ambas têm um balanço saudável e bons fluxos de caixa a preços ainda hoje convidativos.

Em um ano de resultado tão bom para a parceria, é mais fácil lembrá-los de que um ano é muito pouco tempo para julgar uma iniciativa de investimento. Nosso portfólio é concentrado e pode oscilar bastante. Blocos de 5 anos são bons mínimos para avaliar. E um referencial exigente de comparação é o Índice Bovespa.

O retorno acumulado nos 3 anos de existência da nossa parceria, líquido de taxas de performance, foi de 101%, superando em 8,99 pontos percentuais os 92,01% acumulados pelo Ibovespa no mesmo período.

O ano de 2019, e isso é algo muito raro, não revelou nenhum grande erro. É claro que, quando uma empresa mais do que quadruplica de preço em tão pouco tempo como foi o caso da Trisul, desejamos ter alocado 100% da carteira nela e não 5 ou 10%. Não precisamos acertar tudo para ir bem, e é certo de que esta seção das cartas da parceria logo voltará a trazer meus erros e, com eles, mais aprendizados.

Desejo um 2020 maravilhoso para você e seus familiares.

Abraços,

Gustavo

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.

My Year in: Books

Any year in which you read Grande Sertão: Veredas is automatically excellent.

This year I read 32 books. I may have broken my record of rereads at 4. I continued reading in Italian, 2 books this year. Or should I start saying “consumed” books? Thirteen out of the 32 were audiobooks.

It may be hard for a non-Brazilian to understand what about Grande Sertão: Veredas makes it the best book of all time. It is probably as difficult as can be to translate. It is very hard to understand at first, even for solid, native readers. Suffice it to say that it is on par with the Iliad, the best Goethe or Shakespeare. Ranking works of art is nonsense. Still, Grande Sertão is number one for me.

If not for Grande Sertão, 2019 would have left a lot to be desired in terms of my reading. I am happy to put in a good word for Crucial Conversations, a book I listened to and immediately repeated. I seem to have reached that age when any meaningful personal growth is to do with interpersonal skills.

Crucial Conversations was one of several books I read around communication and management, the one big topic for me in 2019. It always feels like most of these books could have been fine as shorter blog posts, but you never know which ones should truly be books and I end up reading them whole. Also, a single good idea may easily be worth the dozen hours we spend on a given book, and that makes me think of The Culture Code, a serious candidate for a future reread as it may contain 2 or 3 really good ideas.

But then there is Grande Sertão: a book where every line, every phrase and word explodes with meaning, with angles on life, a love story to make Romeo and Juliet robotic and numb by comparison.

Maybe I’m ripe for some fiction after a long hiatus.

I log my reading, done or intended, on Goodreads. Please friend me there if you’d like and let’s find the next amazing book.

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.

Carta da Parceria de Investimentos – 2018


Caros parceiros,

o retorno da nossa parceria em 2018 foi de 11,51%. A cota encerrou o ano a R$1,08264.

Nossa parceria ficou aquém do índice Bovespa, que subiu 15,03% no ano, por 3,52 pontos percentuais.

Ano Nosso Fundo Ibovespa
2017 29,44% 26,86%
2018 11,51% 15,03%
Acumulado 44,34% 45,93%

Em 2018, descontando leituras de livros e artigos sobre investimentos, dediquei 144 horas à análise de empresas — um aumento de 27,43% em relação a 2017.

Um outro número de menor importância, porém digno de menção, foi o aumento de 49,18% nos ativos sob administração, ou seja, o total de reais no fundo. Vale lembrá-los de que toda a minha poupança vai para este fundo, e se isso porventura mudar algum dia, vocês serão informados com antecedência. O princípio é simples: objetivos compartilhados e a certeza de que estou cuidando da parceria com o mesmo zelo com que cuido do futuro da minha família.

Ao longo deste ano não vendemos nenhuma das ações que tínhamos no dia 1º de janeiro. Nosso portfólio consistia em 4 empresas: Cyrela, Hering, Metisa e Tarpon. A participação na Cyrela, que em janeiro era “nova e relativamente menor”, recebeu acréscimos e, junto com alguma apreciação, hoje representa um quarto do portfólio. O ano foi fértil em ideias de investimento, num total de duas: inauguramos participações, ambas também muito novas e relativamente menores, na Construtora Trisul e na Cielo, empresa de meio de pagamentos.

Os parceiros que prestaram atenção às atualizações trimestrais deste ano certamente observaram a grande volatilidade nas cotações do fundo, e em menor medida no mercado como um todo. É mesmo de se esperar que nosso fundo, que teve de 4 a 6 empresas ao longo de 2018, exiba variações muito mais amplas de cotação do que índices com dezenas de empresas. Desta forma, eu não me sentirei um investidor fracassado se em determinado trimestre, semestre ou ano formos pior do que determinado índice, e da mesma forma não me sentirei um gênio se o oposto acontecer. Ao longo de mais tempo, por exemplo blocos de 5 anos, o objetivo continua sendo superar consistentemente o índice Bovespa.

Uma pergunta que veio de parceiros este ano foi sobre expectativas quanto ao trimestre subsequente a cada atualização que envio, talvez uma espécie de “guidance”. A verdade é que admitir que não temos poderes de clarividência já é uma vantagem competitiva: muitas pessoas extrapolam precedentes ou apostam em repetições duvidosas de fatos para alocar capital, com consequências muitas vezes desastrosas para suas economias.

Felizmente, com um prazo maior podemos vislumbrar o futuro de modo bastante útil. É possível, por exemplo, dizer que a saúde financeira atual de algumas empresas brasileiras e a sua capacidade de ganhos, comparadas aos seus preços de hoje, nos dão grande confiança de retornos expressivos em um horizonte de 10 anos para investidores pacientes e cautelosos.

E já que estamos falando de cautela, é hora da parte mais importante das nossas cartas: os erros do ano. Em 2018 tivemos algo que tem toda a cara de erro e de qualquer modo nos custou bastante: a Tarpon Investimentos.

Comprei participação na Tarpon nos primeiros meses de 2017. Naquele momento muitas empresas brasileiras estavam à venda por preço equivalente a menos de 10 anos da média dos seus lucros recentes, mas o caso da Tarpon era mais extremo, girando em torno de 3 anos.

Não é de se esperar que empresa alguma chegue a este preço sem um gatilho negativo. Mais de 4 anos antes, a Tarpon havia tomado a arrojada decisão de, fugindo de seu histórico de investidores passivos, controlar e operar suas investidas. Não só isso: pouco tempo depois ela concentrou a maior parte de seu capital em uma só empresa: a BRF de Sadia e Perdigão.

A história é longa e até, para um livro, interessante. Hoje sabemos que ela culminou na Operação Carne Fraca e até mesmo na prisão preventiva de Pedro Faria (sócio da Tarpon que foi CEO da BRF) e no indiciamento dele, do então CEO Zeca Magalhães e de Abílio Diniz, presidente do conselho da BRF trazido ao cargo pela Tarpon.

A intersecção entre “histórias interessantes” e “bons investimentos no longo prazo” é bastante pequena, e acredito que seja mais útil compartilhar os aprendizados deste investimento para prevenir a repetição de erros:

  1. Aplicar o mesmo nível de exigência quanto a baixo nível de dívidas ao analisar as subsidiárias. A Tarpon em si não tinha dívida nenhuma, mas suas subsidiárias tinham níveis de dívidas que me fariam pensar mais de duas vezes antes de investir diretamente.
  2. Preferir muita clareza, transparência e facilidade de entender o negócio. Desvendar o portfolio da Tarpon demandou esforço. Hoje eu encaro isso como um sinal de perigo. Minhas tentativas de contato com a empresa para fazer perguntas nunca tiveram resposta. Na época eu racionalizei que, por ser um investidor pequeno, talvez não merecesse a atenção. Hoje eu racionalizaria que eles é que não merecem o nosso investimento.

O ano terminou com a notícia da intenção da Tarpon de fechar seu capital, horas após o último pregão de 2018. Mesmo ressaltando que até agora não foi divulgada nenhuma evidência de atuação criminosa por parte dos executivos da Tarpon, o fato de a empresa ter vendido ações no meio do ano a R$2,58 para cobrir folha de pagamento e, tão pouco tempo depois, anunciar a intenção de recomprar as mesmas ações por R$2,25 é um sinal muito forte, talvez até para os investidores mais pacientes, de que o melhor a fazer é agradecer ao milagre da diversificação e buscar outras ideias.

Entramos em 2019 com quase 35% do nosso portfolio em duas empresas de construção de imóveis: a Cyrela e a Trisul. São companhias de tamanhos muito diferentes, mas que têm em comum o fato de estarem passando pela grave crise no setor com as finanças equilibradas. Também aqui o fim do ano trouxe notícias que podem afetar, desta vez positivamente, nossos resultados: a mudança na Lei do Distrato. Até a semana passada, um comprador de imóvel na planta que desistisse da compra conseguiria 50% do seu dinheiro de volta. A boa intenção de proteger o consumidor acabou desencorajando as empresas de assumir o risco de oferecer novos imóveis. Com a mudança, esse percentual de restituição em caso de desistência tende a ser muito reduzido, e as empresas contarão também com um tempo de carência de 6 meses para entregar os imóveis sem sofrer multas.

Nosso investimento em Cyrela e Trisul não foi pautado em mudanças na legislação, e sim em acreditar que as administrações são competentes e que, o setor superando o momento de dificuldade, ambas estarão muito bem preparadas para dar ótimos resultados nos próximos anos.

Se já admiti que a Tarpon é dúvida em nossa carteira para o futuro, digo também que acredito que teremos longa parceria com nossas demais empresas. Acredito também que deveremos ter uma diversificação um pouco maior do que 5 ou 6 empresas, e trabalharei bastante para encontrar as próximas ideias de investimento para a parceria.

Na carta do ano passado mencionei a intenção de converter esta parceria ainda bastante informal em algo formalizado, permitindo que tenhamos valores mais significativos no portfolio. A intenção continua firme e forte. Não tenho um cronograma para isso, mas me comunicarei com cada um de vocês no momento oportuno.

Terei prazer em responder a quaisquer perguntas, em qualquer momento. Se eu não tiver deixado algo claro na carta, por gentileza não hesitem em me avisar para que eu possa esclarecer para todos.

Um ótimo 2019 para você, seus familiares e amigos!

My Year In: Books

In 2018 I read 28 books. The number means little but this is probably the lowest for me in many years.

I’ve noticed a trend this year of enthusiastic book readers becoming less so, and praising blogs and other media instead. That was not really the case for me: this year my family and I spent another two months in Italy, and again, why read books if you’re living inside one. More importantly, my wife had twins.

This year I continued to read in Italian, and I was able to read much more advanced texts like Diario Minimo by Umberto Eco, Mark Twain’s Following the Equator and Elisabeth Roudinesco’s biography of Jacques Lacan. Out of the 28 books, 5 were in Italian.

Last year I mentioned I had taken up audiobooks, and this year I continued to listen to them, 11 in total. I think I have gotten better as a listener of books, and the main thing I’ve been doing more often is re-listening to sections of books. This seems to compensate for the lower rate of absorption I seem to be capable of in audio form.

The book I liked reading the most this year was “Don’t Sleep, There Are Snakes”, by Daniel Everett. In it, Everett recounts his experiences living with the Piraha tribe in the Amazon jungle. His initial mission was to translate the Bible to their language as a Christian missionary. What he comes across, however, changes his own life. It’s a profound encounter of two cultures that could not be more different from one another, in the midst of another culture, that of Northern Brazil. On top of it all, Everett, also a linguist, discovers a language unlike any other in the world, and picks a fight with Noam Chomsky about what even constitutes human language. It’s all so amazing you wonder how much of it is really true. Incidentally, this one was in audio book format and it was great to hear the author reading it, warts, emotion and all.

This year I doubled down on a practice I had started, but not mentioned, last year: that of translating/transcribing books. In 2017 I went to Berlin while living in Italy and really loved it. It was my first time in Germany, and it made me want to learn some German. While in Rome I had learned of Goethe’s experience living there, and of a book recounting his life in Italy. So I started translating “Italienische Reise” from German to Portuguese, and that has been my introduction to German. One year and a half later, I’m still in page 20 of the book. I may go entire weeks without doing it, but I have fun when I translate a paragraph or two. And the links between the German language and the others I know are always deeply touching. Languages are among my favorite things in the world.

So by doubling down I meant I started doing something similar with another book. This time I am not translating but transcribing Security Analysis, by Benjamin Graham and David Dodd. It’s one of the most important books about investing of all time, I had read it before but it’s such a dense book that I thought I should do this to slow it down and spend more time with each paragraph. Almost every weekday I dedicate 10 minutes to it. At the current pace I will need several more years to complete the book. I have no idea if I want to do the whole thing, but I can say it’s been a great experience so far.

If you’d like to see all the books I’ve read in 2018, please take a look at my Goodreads year list and do friend me there if you wish.

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.