How I became a first-time author and wrote a book

My first book has just come out, so here's what it took and why I did it

I’ve been writing or blogging for years on and off, so I’ve been naturally curious about the idea of writing an actual book. Then again, I could easily spend a whole weekend or two researching and writing a lengthy post like this one on consciousness, so I knew it wouldn’t be easy.

My other point of reference was my master’s thesis. It was all fun and games initially, an exciting new project. By the time I finished, it felt more like a nightmare I was glad I survived.

Well, six months and all my weekends later, I’m now a published author. Here’s my book, why I wrote it, and how.

This is my book.

Why I decided to write my first book

With this context, sometime in 2021, I was approached on LinkedIn by Packt, a publisher of technical books mostly targeting developers. Their proposal was for me to write a book on how to build a Robo-advisor.

Initially, I just brushed it off completely and to my shame didn’t even reply. They were very persistent though, checking in every few months. I just thought to myself that Robo-advisors are a pretty niche area, and frankly just didn’t have the capacity to take on such a project.

Then last summer they approached my co-founder Ned Phillips at Bambu about doing it. I thought to myself that Ned’s Python coding skills probably aren’t up to the task, so who else is going to do it? Maybe they were asking our competitors, too. Here someone is chasing me for months to write a book on a topic where I’m uniquely positioned as an expert. That seemed like a pretty unique opportunity to pass up. That thought ultimately led me to talk to Packt and take on the project.

I got into Robo-advisors in the first place back in 2016 with the purpose of helping more people save and invest, which I see as a net win for society. I believe financial freedom is a goal everyone should aspire to reach at some point in their life. So maybe doing this book could be a part of my small contribution to this industry.

My Robo-advisor startup Bambu has had success globally in working with traditional financial institutions like banks, but the next level of adoption remains around the corner. We’ve seen tremendous interest from startups and tech companies in integrating Robo-advisor features and journeys into their Fintech apps and solutions, but overall adoption has been very slow.

I knew from other more mature Fintech use cases like payments that it would take time for API models to take off, but the adoption within wealth management has been even slower than I had anticipated. So, this book might help one developer at one company start their own Robo-advisor project and nudge the industry forward one API at a time. I’d count that as a win. If they happen to need some Bambu APIs to do it, even better.

How I wrote my first book

So how does one actually write such a technical book? Well, compared to my blogs, it’s certainly more organized and formulaic, which can be positive or negative, depending on why you enjoy writing in the first place.

Since Packt focuses on technical books, they tend to be hands-on guides into specific technologies. So I was given a pretty comprehensive style guide on how to structure the book and various aspects of chapter contents and a PDF copy of a good example book they had published previously.

The outline

With all that in hand, the first job was to write an outline based on a word template. I had to basically fill in a very long form that determined who the book is for, why it was worth reading (and writing), and so on. That was the easy part. The hard part was to split the book into three or more parts, and at least 15 chapters. Given I’ve worked on Robo-advisors for 7 years, I thought it would be easy. But you have to remember this isn’t just a slide deck or a blog post. This is a 250+ page technical book with code that is supposed to teach the reader how to build a Robo-advisor.

I had to more or less just guesstimate what would make sense without knowing exactly how it would all fit together. Especially weird was trying to estimate how many pages each chapter would be, and what the 3-5 chapter headings would be. Overall, I’m actually pretty happy with how little I had to change things during the process. I definitely underestimated and overestimated several chapters by 5-10 pages either way, but overall it landed close to the sweet spot of 250 pages.

One of the first major hurdles was switching from Google Docs to Microsoft Office. I tried fighting it initially, but in reality, despite years of effort on compatibility, the styles from the Microsoft Word template just didn’t show up on Google Docs. In a technical book those styles are crucial, to highlight things like keywords, references to other chapters, URLs, and of course various styles for code blocks.

What the Microsoft Word online UI looks like incl. the extensive Packt style menu.

Despite my bad memories of old Sharepoint and the Mac versions of Microsoft office, I have to admit that Office 365 is pretty slick. It works inside your browser just like Google Docs and admittedly has more features. The only downside I could think of is that Grammarly, which I have lovingly used for years, didn’t work for me on Microsoft Word, although Microsoft’s own spell check and editor features seemed to catch most of my glaring mistakes.

The first chapter

It probably goes without saying that the first chapter was the hardest. Once I got past fiddling around between Google Docs and Microsoft 365, it was mostly the process of writing like a Packt book, instead of a blog post. For example, to aid in reading comprehension and consistency, there are instructions on how to write an introduction and summary, how to open headlines and provide signposts between sections, etc.

You also have to start to think about how you’re going to fill the page count, which was never a concern with my blogs. I would just write until I had said what I wanted. Here, if I said everything I had to say it would take years and a thousand pages and would be of no interest to nobody. Then again, it couldn’t just be an overview, it had to contribute knowledge at a specific level of detail and abstraction.

The first code

The next great hurdle was writing code, which in my case only kicks off in Chapter 5. First of all, it was pre-determined by Packt that this should be done in Python. When I first heard that, I thought that makes no sense, you can’t build a Robo-advisor in a scripting language. But then I thought it through and realized that Python was exactly the right choice.

This book is a hands-on guide, it’s not a production-ready system you can copy/paste and expect to run a Robo-advisor. When I was in uni learning the fundamentals of Computer Science, we called this pseudocode. It’s code that is used to convey concepts, not run programs. Then it made sense to me, especially given that there’s also a code block size limit of one page. In reality, it’s hard to fit anything meaningful in 25 lines of code beyond toy examples. So I would focus only on the core algorithms that power Robo-advisors, instead of building a complete platform.

The other thing I really really wanted to avoid was messing around with Python virtual environments and the inevitable sea of errors of running all the necessary modules locally. I was relieved that Packt was okay for me to use Google Colab, which is an online Python runtime that works a treat. This was a lifesaver in so many ways. Generally, things just work.

My gigantic Jupyter notebook in Google Colab with sections for all code chapters.

If you’re used to using Jupyter or Spyder, then you’ll feel right at home. I only set up a local instance at the end once I had to set up the book’s GitHub repo. Much like with Colab, you can use the wonderful Visual Studio Code with Jupyter notebooks and very little hassle. The only real pain for me was that I had to separate my giant online notebook into separate notebooks for each chapter. Further, that meant copying any required code from earlier chapters to ensure the code for each chapter actually ran without error. In retrospect, I probably would have preferred to do it this way from the start, but using Colab in my view makes the book and code more approachable to newbies, where you can start coding in Colab in seconds with no messing around.

The wonderfully minimalist VS Code UI with integrations for Jupyter Notebooks and GitHub repos.

Due to the limitations in code block sizes, I took the approach of maximizing the usage of 3rd party Python modules. For example, it would be a real struggle to generate and visualize the Efficient Frontier beautifully in 25 lines of code. I’m sure some leet code would do the job, but it would defeat the purpose of the book. This of course is one of the very best aspects of choosing Python because there’s a module for everything! I was delighted to find many great open-source projects such as yfinance (market data), PyPortfolioOpt (portfolio optimization), PyHanko (digital signatures), PassportEye (OCR for KYC), and Smarty (address verification) to name a few.

Grinding out the remaining 200 pages

So, then I just had to write the rest of the book! I generally struggle with very long monotonous projects. Even though it greatly increased the overall effort, at least the code kept it challenging and engaging. Writing a text-only book on Robo-advisors would probably have been too much for me.

Thankfully, I didn’t need to do much research at all given my familiarity with the topic. That’s one piece of advice I would give to hopeful (technical) authors. If you know the subject inside out, you can do it for sure. If not, I’m not sure it's worth the gigantic effort, honestly.

The general process I settled into through the chapters was to write the code first. That way I knew that it would work, and all I had to do was add some color commentary, the occasional theory, and sprinkle a few formulas around the code blocks. That worked for me, at least. The hassle of copying and formatting code is so disruptive to the process of writing code, that in my view it’s best to separate those processes entirely.

So I basically spent a good chunk of the project just writing code for the majority of the chapters before actually writing anything. Packt didn’t give me too much trouble about how I went about it, as long as I would deliver draft chapters occasionally. Luckily they do have a nice web portal with timelines for the various milestones per chapter.

The review and editing process

I’ve heard about the horrors of editing books from established authors, so I had some dread about what that might involve. Overall, it was actually relatively painless. The first round was a Packt editor making sure I was following the structure and style guides for the book. It was harder for the first chapters, but when I started to internalize what was desired, the rest of the chapters went much smoother.

The second part was technical review, where two subject matter experts actually had to check that I wasn’t full of it. They had to check the code ran as expected without errors, and that generally, the theory checked out. I didn’t have to do too much of a rewrite apart from some finagling with the occasional broken Python module (I see you, Yahoo Finance API) and a few mental mistakes that are inevitable in such a long project.

Publishing my book on Amazon

The real reward here is probably just seeing my name on Amazon. It would be hard to imagine the financial compensation directly from book sales would yield even an acceptable wage given the hours required. I did it to cement my position as a Fintech thought leader, but mainly because it seemed crazy to decline a book offer. If I did this book, maybe other opportunities will come later.

A proud moment to see my name and face on Amazon.com.

For a long time, I’ve thought I should do something with my career that creates some lasting memory of myself. The digital equivalent of “I was here” carved in stone. I used to think a Wikipedia page would be a good sign, but actually, it just hit me today that I now have created a piece of content that will live on. There will be physical copies, albeit probably not many. Given the state of the internet today and progress in A.I. it’s not inconceivable that the record of this book could persist for a very long time. That might be the only kind of immortality available to this generation, so I’ll take it.

I was here.