That move was when my parents separated and I went to live with my mother. She is a psychologist, had paused her career for a few years to raise me and my brother, and in those years she went back to work. She came back taking courses, catching up, buying books on emotional intelligence. Hence the weight of the boxes.
But books had been part of the scenery at home long before that.
A Russian encyclopedia
My father subscribed to Folha de S.Paulo, and back then you collected the coupons from the paper, took them to the newsstand and traded them for things. On one of those trades we came home with a Russian encyclopedia. Don't ask me why. There was a Russian encyclopedia in the house.
A kid in the nineties, so there was also the dinosaur partwork you collected every week until it added up to a plastic dinosaur. Blame Jurassic Park. And my mother had the Disney collections, the fairy tales, all of that.
My father wrote a book, actually. In 1983, before I was born. He worked in finance and the book was about a program he had built, basically an Excel that ran on DOS. Years later I was searching for the title of that book on Google and up came some guy's résumé on Catho, listing knowledge of that program among his skills. From the same company I would end up working at a long time afterwards.
What's in your head
A friend of my parents had been through the Angolan war and used to tell us about a teacher there, in the seventies, who told her students that in a war you can lose everything except what's in your head.
I can't explain why a line like that crosses forty years and reaches me secondhand, but it did, and it stuck. To this day, when I buy a book, it never occurs to me to look at it as a cost.
The book that paid for itself on day one
There's a practical side too.
2004, university. We had just dethroned truco: poker became the official game of the break, and quite often the official game during class as well. That was in the wake of ESPN starting to broadcast the World Series of Poker, which changed a lot of people's habits at the same time. Texas Hold'em, always.
It wasn't the kind of gambling where you lose your house. A good Friday was worth about fifty reais, enough for beer and churrasco afterwards.
One day we were having lunch at Vila Lobos and I wandered into the Livraria Cultura inside the mall. I found a book on Omaha, which is a cousin of Hold'em: four cards in your hand and the pot split between the best and the worst hand. I bought it. Seventy-five reais. Devoured it over the weekend.
Monday I showed up with the pitch. Guys, today we play Omaha. I explained the rules, everybody was in, and on the first day I walked away with seventy-five reais.
The book paid for itself in one afternoon. I have never needed an argument for buying a book since.
A two, and then a zero point six
Poli, meanwhile, was the hardest thing I have ever been through. Anyone who went there knows what I'm talking about. There's a strange feeling in that place that the more you study, the worse you do.
Strength of Materials was my Waterloo. It was the subject I had decided to honour, real engineering, so I studied like a madman. First exam: a two. Out of ten. Fine, shock absorbed, moving on. I studied even harder for the second one and got a zero point six.
With a two and a zero point six there is no arithmetic that saves you. It didn't turn into a drama, I didn't go on failing the other engineering subjects, but that second exam was a reality check I still carry around.
The technical library
The relief came in the fourth year. The heavy, abstract part of engineering was behind us and the naval subjects started, which are the applied ones. They use everything from the fundamentals, but with a ship in front of you. That's when I saw some light at the end of the tunnel.
And in a Naval Structures class the professor said something that stuck. That we, as future engineers of this country, had to build our own technical library.
Technical library. He repeated it more than once, and it wasn't a reading tip. It was a professional obligation.
Manaus, with no credit card
I graduated and went to live in Amazonas. Small detail: I still didn't have a credit card, and with no card there was no Amazon. So my technical library, at the start, was torrents and PDFs.
The most important PDF I have ever read was one of those. Excel Power Programming with VBA, by John Walkenbach, some twenty years ago. That's where I understood you could turn Excel into a tool for writing software rather than a fancier spreadsheet. A few years later I left naval engineering because of that path.
When the card finally came through and Amazon started delivering to Manaus, that's when the real library began. Mooring systems, naval structures, and the university books I had only ever borrowed. I bought Strength of Materials. The same subject as the zero point six, which I ended up using plenty in real projects.
And it wasn't only engineering. Jack Welch, the Apple histories, leadership books. It's Your Ship was one of the ones that marked me most.
Two years later I moved back to São Paulo with three suitcases. One of clothes and two of books.
One book per industry
Since I changed careers several times, that turned into a method. Every new industry, I go find the book on that industry before trying to sound clever in a meeting.
Insurance: I bought Against the Gods, by Peter Bernstein. I recommend it even to people outside the trade. It tells the history of risk, how humanity slowly learned to measure what can't be predicted, and how that became a price.
Trucking: I went after the history of the American carriers and the origins of the sector. I worked at one and read the house book. There was the history of Expresso Jundiaí sitting there too.
And there was Adobe, one of the best stories I've read. Two mathematicians working at Xerox, where any project took five, seven years to get off the ground. They had created PostScript, which solved one of the nastier problems of the eighties: getting a computer to print your file on any printer at all.
And their business plan was to open a kiosk. A little shop where people would bring their files in and they would print them. That was the plan.
Their luck was running into a guy named Steve Jobs, who said he didn't want any kiosk, he wanted to license the software for Apple's printers, and put two million dollars on the table. That was Adobe's starting money. The two of them were very good: they built the whole font system, then came Illustrator, then they bought Photoshop.
The side effect of all this shows up in front of the client. When I sit down with a trucking company, I already know roughly how the business turns, what processes exist, where it usually hurts, what keeps the operation awake at night when the process doesn't talk to the technology. That doesn't make me an expert in their business. But it lets me ask a better question and connect a dot that would otherwise stay loose.
Studying before the problem shows up
Some people study when the problem arrives. I study because I enjoy it, and almost always what I study today turns out to be useful six months later.
One day I got it into my head that I wanted to learn Linux. There was no demand for it whatsoever. I bought books, took a course, and bought a Dell server to put at home. Back then I barely knew what cloud computing was, so the obvious solution was to buy a server. I still have it.
The course was with the Alura people, with Silveira. Very thorough, command by command, users, groups, permissions, file permissions, the utility tools. It gave me a solid base, and I did it out of curiosity, with no plan behind it.
Six months later I was promoted and landed on the analytics team. And suddenly I was SSHing into servers all day, running Hadoop and Hive jobs, later Spark. All of it on top of that base I had built for no reason at all half a year earlier.
Knowing it exists
There's a part of this I call indexing. You read, and you won't always use what you read. But it gets filed that the thing exists, and the day you need it you know where to go looking.
The best case of that in my career was with Zendesk. We worked with the tool a lot and I had done my homework: study everything it offers, read the whole documentation, including the parts that didn't matter at the time.
Then a client showed up needing marketplace integrations. Mercado Livre, Magalu, Shopee, that whole set. The natural answer would have been that you can't integrate that into Zendesk and each channel would carry on outside it.
Except I knew the Channel Integration Framework existed, which is there precisely to bring an outside channel into Zendesk. I was already a manager by then and had no time to get hands-on, but I had enough to give direction: this exists, the documentation is here, this is how it works, go.
That turned into a product. Channel integration, the agent answering marketplace tickets from inside the workspace itself, taking the actions right there, and it is still being sold today.
My technical contribution was knowing it existed. Anyone who didn't know would have walked right past it and solved it in a worse way. There are several companies that built marketplace integration in a clunkier way, and that's the only reason why.
The book that made me look in the mirror
Not every read is comfortable.
I once read a book on consulting that had an idea which got me right between the eyes. I had just lost a project because the client wasn't willing to pay what I thought the work was worth. And my reaction, which is anybody's reaction, was to decide the client hadn't understood the value.
The book said the opposite. If the client doesn't see the value, there is something in your process that isn't showing that value. The problem is yours.
It became a habit. Every time a proposal doesn't close, the first question is what I left on the table, not what the client failed to grasp. A book costs fifty, a hundred reais. A project runs into the tens and hundreds of thousands.
Three books in a year
The part of all this I like most isn't my own shelf.
I have a habit of giving books to the people who work with me. Read this one, when you finish I'll give you the next. I've done it with several interns.
There was one who arrived halfway through university, a bit lost, and I started passing along what I had read. Go study Python, go learn to write tests in Python. In the time they spent with me we went through about three books.
Some time later we bumped into each other. No longer an intern, hired as a developer at the bank where they worked. They thanked me for the push and said something I wasn't expecting: that they were, by a distance, the person who had read the most in their university class.
Three books in a year. Three. And that was already enough to be the biggest reader among their classmates.
They have a lot of autonomy today, and that's no coincidence. Knowing how to read gives you the ability to learn what nobody taught you. It's the skill of coping with the unknown, with the challenge you don't even know is coming.
The money comes later
These days, when a new challenge turns up, my first reaction is to look for whoever has been through it and written about it. Chatbots, for instance: we're going to build chatbots, so let's buy the chatbot books. It's cheaper to learn from other people's mistakes than from your own. Bismarck said as much.
And when it comes to fundamentals, the list is short and doesn't move much. Uncle Bob, The Pragmatic Programmer, Kent Beck, Martin Fowler, the people who signed the Agile Manifesto. Those ideas aren't tied to any language, which is why they stay standing while the stack underneath changes its name every three years. I've already listed nine of them here.
There's something I say that sounds naive: studying in order to make money never worked for me. I always studied what I liked, and the money showed up afterwards, when somebody found value in what I knew.
It isn't financial advice. It's just what happened.