Skip to content

Books

What It’s Like To Lead An Engineering Org: Thoughts On “CTO In The Loop”

I just read CTO In The Loop by Balki Kodarapu. It’s free on Kindle through July 20th, so if you want to give it a read, go do that now.

It’s a narrative arc following a developer, “Sam”, who starts as a software engineer at a startup, and ends up a fractional CTO after a career that includes engineering manager, director of engineering and VP of engineering at a company that IPOs. The book was a fun read, and does a good job describing what it’s like to build a company and a software business from the early days to a more mature organization.

The realities of Sam’s growth ring true: he starts out focused on features and clarity, and then moves up levels of abstraction. He loses touch with tasks and areas that used to matter, but gains higher level views and more ability to influence the organization. As a director, if you’re still reviewing PRs the way you used to, you’re basically breaking your organization

We also see the evolution of several other characters, including Priya the project manager, Mei the UX designer and Jack the senior developer. Some of these folks stay with Sam across companies, while others pop in and out, just like real world colleagues.

Some details felt a little forced; for example, locking down a GitHub repo and preventing merges to the main branch are treated as a major effort, when most software shops do that pretty early.

I especially liked the portrayal of the thorny moments of management that Sam encounters:

  • firing a team member
  • multiple rounds of layoffs (and subsequent hiring)
  • changing his understanding of the constraints and goals of the engineering org he is in

I also really enjoyed the emphasis on integrity, and how the protagonist was repeatedly challenged to hold onto it through different stages of business growth. I think integrity is an easy thing to write about and much harder to actually live. In the moment, you tell yourself that just this one tweak that you might feel uneasy about will move the business in a positive direction. But doing this repeatedly only works in the short term.

The benefit is immediate and the cost is deferred, and avoiding these kinds of decisions is a constant challenge as an organization grows.

The hard part is that it’s rarely obvious where the line is. Most people agree you shouldn’t commit fraud. But there are dark UX patterns that benefit the business. For example, you could make it much harder to unsubscribe from a service than it was to subscribe; every organizational incentive points that direction.

Another example is the integrity in making it easy for a customer to leave: making it easy for people to export their data and take it with them. That’s a frustrating tradeoff for whoever’s job it is to sell the product, but it’s a pretty clear-cut example of integrity. You want to earn people’s business, not hold their data hostage.

There are other places integrity shows up over the course of a career, but the author does a good job of showing how it is hard to maintain, especially when you are focused on the day to day of building a software business.

CTO In the Loop is a fun, easy read. I read it on the Kindle app in about 2 days while on a vacation. I’d highly recommend it to people early or mid-career in software who are curious what life looks like at a different level of the org chart. When I was younger, I assumed people at higher levels had a lot more control, agency, and power. That’s true, but they are also further from the customer, removed from knowledge of how technical systems actually work, and have a lot less clarity about the day to day. To say nothing of many competing demands that folks at the director or higher level have on them.

Writing code, or telling an AI how to write code, is one thing. Thinking about what the company looks like in one year or five, how to bring different teams together, how to manage investors and understand the market, and how to keep every department rowing in the same direction: that’s a tremendously difficult job. This book is an accessible narrative of those tensions, to which I don’t think new or even mid-career developers usually get exposure.

So go check it out. Did I mention it’s free on Kindle through July 20th?

Balki, thanks for writing this excellent, interesting fable of a software developer’s career.

What New Developers Need to Know About Working with AI

It’s been a few years since I wrote Letters to a New Developer, about what I wish I’d known when I was starting out. The industry has changed with the advent and acceleration of generative AI and the implications of these tools on coding and software creation.

So I wanted to write a quick update to give advice to developers who are entering this world with AI.

It’s important to understand what developers actually do.

They are not responsible for writing code. They are not responsible for liking technology.

Like other employees, developers are responsible for  taking their particular skill set and using it to solve problems that a business or organization needs solved. Whether that’s a one-person shop organizing their customers’ data or a large organization like Walmart, Amazon or the US military trying to improve their logistics, there are goals to achieve. For a developer building, maintaining and improving software is the main means to achieve those goals.

This does not change in the world of AI.

The role of a developer is still to understand technology, how it can be applied, where its limits are and to build it with the quality and appropriate flexibility for the business situation.

What do I mean by the last part? If you’re building a script to transfer data from one system to another one time, then a throwaway script that doesn’t have error checking, that doesn’t have proper variable names, that doesn’t have abstraction is appropriate. If, on the other hand, you’re creating foundational architectural components of a long-lived system, you need to think about all the things that make software more maintainable.

In either case as a developer your role is clear. It’s not to code the software. It’s to take the business requirements, understand the domain and build a solution that meets the business’s requirements for a given level of flexibility, complexity and completeness.

That job doesn’t change whether you’re using:

  •  machine code assembly
  • a non-memory managed language like C
  • a memory managed language like Java or
  • spec-driven development.

As a dev, your job is to understand the technical trade-offs, use the right tools and meet the business or organization’s needs.

Now as a new developer, how do you learn to leverage genAI in a way that is going to help your career rather than hurt it? It’s tough out there to get your job as a new dev and ignoring AI is going to make it even tougher.

It’s important that you learn how to use this tool and use it well. But AI as a tool is much more like Google search results than it is like a compiler error. A compiler error is deterministic and will give you the same message each time you compile the code.

The output of an LLM is not deterministic, just as when you search for guidance for building software on Stack Overflow or your team. With these sources of knowledge, you as a developer need to learn judgment. You need to learn when to trust genAI and when not to trust it.

Do this by starting small, asking for links, and checking the output of an AI against other sources. These include other AIs and published documentation. You’re building your sense of judgment and intuition about the system you are improving. Use it to augment your understanding, not replace it.

When an AI hallucinates, don’t throw the baby out with the bathwater and never touch genAI again. Instead learn to sniff out when an AI is generating garbage and when it is generating helpful code that will accelerate things.

A good course of action is to use AI to generate easily verifiable code where errors are low impact. An example is writing tests with AI, especially unit tests, especially in a statically typed language. It’s very easy to tell if the tests that are written are working or not. Don’t forget to instruct the AI to fully flesh out the tests, you don’t want any “return true” nonsense.

Another example is read-only queries. If you have an understanding of the data you can verify whether or not the SQL the LLM creates gives you the correct answer. Write multiple queries because they are so low effort, and use them to double check answers. If you were looking for a count of a particular set of customers, ask it for multiple different ways, including a count of one particular kind of customer and a count of all customers grouped by type. This lets you see if things match up.

The goal is not trusting blindly but instead using the tool to accelerate delivery of solutions to the problems the business wants you to solve. But you want to do so in a way that is going to give you confidence that the solutions you deliver are real.

By the way, the value of such intuition and judgement is high for all developers.

I think that it’s even more valuable for newer developers.

If you would like to purchase my book, “Letters To a New Developer” for more of this kind of insight, there’s a sale going on right now through the end of the year. You can use this link to buy my book for just $24. (This is a better deal than I get with my author’s discount.)

 

When Are You Ready To Write A Technical Book?

This question came up on an HN thread.

My process for any book I’m thinking about writing is:

  • write out 10 titles for blog posts on the topic
  • write 1-2 blog posts (this lets you, in a low risk way, verify you have interest/expertise)
  • add an email list signup at the bottom of the posts
  • do a bit of research to see if someone else has written on the topic (some googling or reddit searching)
  • write the rest of the blog posts

If you can get 10 meaty blog posts, you have the basics of a book. Plus, you’ll know that you are interested in the topic and that you can write. As you wrote those blog posts, you probably had related ideas or areas you wanted to explore.

You’ll also be able to share these blog posts with friends, colleagues and online communities that you may be a part of. You can get feedback on the ideas and the overall topic here.

You can self-publish the book (done that) or use a publisher (done that). The latter will take more time and effort and will require you to fill out a book proposal.

To be honest, even if you are planning to self-publish, doing the hard work of completing a book proposal is useful. Even if you don’t submit it. It forces you to think about:

  • who is my audience
  • what are my core ideas
  • what else has been written on this topic
  • why is what I’m saying unique
  • why am I the right person to write this book

This can help you narrow in on what will make your book successful and can help with your marketing messaging.

What If you can’t write 10 blog posts about a topic? Then you are missing either:

  • interest in the topic
  • necessary knowledge

But it’s more likely the former. Because you’ll have time to do research to learn. I remember taking something like 4 hours to answer one question about how the Cordova CLI acted in one peculiar edge case. It turned into one sentence in my book.

Finally, if no one else has written anything about the topic (no books, no articles, no social media posts, no nothing) and/or none of your blog posts get any feedback (positive or negative), pick a different topic or expand your vision.

Here’s an exchange I had with Patrick McKenzie in 2013. I wrote:

I had a quick question. I was thinking about writing an ebook for a super niche topic (testing ETL transformations using Pentaho Kettle, an open source ETL tool).

I outlined the book, did some google searching and wrote up a series of blog posts with an email list signup at the bottom.

I got some nice retweets from folks in the Pentaho community and have about 8 people signed up to the list. That was a bit disheartening, but a friend suggested that the folks doing ETL work weren’t exactly developers (perhaps more DBAs or business analysts).

I am still tempted to write the ebook, given my interest in the subject–I think it is a pretty cool tool that I wish would replace lots of data munging scripts, and testing software written using Kettle makes development with it much more fun. On the other hand, I wouldn’t mind some income.

Is this too niche a topic? I’ve been a generalist for most of my career, and if I don’t write this now, in 6 months I probably won’t have the desire or knowledge to do it again (though I might find another software niche to write about by then).

His answer was:

I regret that I have absolutely no knowledge of anything you just said. In general, I might suggest something slightly less niche (you can reasonably suspect to sell 2 copies to 8 people, so unless it is going for $10,000 a copy, might want more volume). You’d still learn a lot publishing it but for the same amount of work why not write on a subject big enough to support 100 or 200 people interested in it?

I could have expanded this topic in several directions:

  • focus on more general ETL testing
  • expand beyond ETL and look at patterns for testing data manipulation
  • focus more on the tool and write a guide to pentaho development, including testing

Or, treat the exploration as an end in itself and not write a book. That’s always a valid outcome of this process of experimentation.

Read “meaty” books

Every so often I read a book that I can’t describe with any other adjective than “meaty”. They’re large, complex and tough to get through. I read them 5-10 pages at a time. They are slow reads (and sometimes I don’t finish them) but they either change my perspective in multiple ways or introduce me to an entirely new perspective.

Some of these books:

  • Capital in the 21st Century by Thomas Piketty, which changed my thinking on how capital accumulates and what that means for societies.
  • These Truths by Jill Lepore was a re-examination of the history of the USA from perspectives I hadn’t considered.
  • The Case for Mars by Robert Zubrin is a book examining the real world possibilities for space colonization.
  • Refactoring by Martin Fowler exploded my ideas about how to modify software and gave me a new vocabulary too.

The latest book that I’ve read in this category is The Comanche Empire by Pekka Hämäläinen. This book has totally reworked my understanding of native tribes, political economy of the southwest in the 1700s-1800s, US western expansion, the wealth of Texas, social organization and more.

While it is fun to read books that don’t challenge my thinking, it is also good to read these “meaty” books periodically as well.

Book Review: The Cuckoo’s Egg

I recently finished “The Cuckoo’s Egg”, by Clifford Stoll. It was a fascinating non-fiction book exploring the foundations of computer security in a personable format.

The setting is the mid 1980s. The author discovers something weird on his academic computer system. There’s an unexplained charge of 75 cents. He digs deeper, discovers that someone who’s left the university is logging in.

After further investigation, he discovers that the user who is logging in is an intruder. After discussing the situation with his boss, he gets three weeks to find out who they are. He figures that’s plenty of time.

The investigation ends up taking a year.

It also extends far beyond his academic systems, both in scope and effort. Stoll talks to numerous government agencies and private organizations, letting them know they’ve been attacked and getting their assistance tracing the hacker. He sleeps under his desk. He rigs up a pager so that he can know which accounts the hacker is using. Stoll sets up printers so that every word the hacker types is recorded, unbeknownst to him.

It’s quite the tale. As someone who has worked with software for years, I really appreciated the historical nature of it. When I became aware of the internet, in my youth, some of the groups and communities he mentions were still around; I remember reading and posting to usenet. But many of the systems were before my time. I’ve never touched a computer running VMS, for instance.

But, for all the history, the people problems were the same: users not changing passwords, system managers not locking their software down, bureaucrats happy to take information but not willing to share. Let’s just say, mistakes were made.

I also enjoyed the author’s interspersal of lived experiences. We don’t simply follow one computer nerd tracking another. We also learn about milkshakes, parties in San Francisco, curry nights and his first experience with the microwave. While some phrases and analogies are repeated (“should we thank someone who goes to a little town and robs people to illustrate they should lock their doors” pops up at least twice), in general the book is pretty readable. Stoll’s personal stories and musings help that readability immensely.

All in all, a great book if you are interested in the history of computing or modern security practices. If you’re interested in learning more, you can check out a paper he wrote based on the same experience for ACM.

Book Review: Algorithms to live by

I finished Algorithms to Live By, by Brian Christian and Tom Griffiths. I enjoyed it immensely.

The premise of the book is that computer programs make decisions with algorithms all the time. There’s math behind how they do so, including tradeoffs and time considerations. Human beings face some of the same decisions and there’s no reason we can’t use this knowledge to live better lives.

Yes, this is kind of a self help book—“you can live a better life by thinking like a computer”. But it’s math, folks.

I actually recommended it to my SO because I feel like she’d understand me better after reading it. I’m always talking about how much of the stress in our life is due to resource contention.

The book covers a wide swathe of decision making. Here are some examples of the broad categories and some specific references:

  • when to decide to stop looking for a house or a partner
  • when to explore new knowledge vs exploit current knowledge in the context of clinical trials
  • how randomness can lead to better outcomes
  • how caches can help you determine what of your wardrobe to keep
  • how overfitting warps sports like fencing

As illustrated above, this is not a book about theory, but is actually hands on. I don’t recall seeing a single equation, though there are graphs. And the authors do mention plenty of researcher names, provide footnotes and have a twenty page bibliography. So if you want to learn more about the formal proofs, the info is there.

It’s hard to choose just one takeaway from this book, but if I had to pick one, it’d be the fact that game theory shows that you need external forces to avoid the tragedy of the commons, and that emotions may play a role in providing that.

Here’s an excerpt if you want a deeper look.

If you spend any time thinking about how you can make decisions better, Algorithms to Live By is worth reading.

Book Review: A Memory Called Empire

I was at a bookstore the other day and was rummaging around for an escape book. I had picked up one book based on staff recommendation, but came across another that had won the Nebula. A Memory Called Empire appeared to be an award winning space opera novel.

I thought, why not, and picked it up. I was not disappointed.

There are two main cultures of different power and viewpoints. The action follows an new, unprepared ambassador from one culture to the other. The cultures are coherent and yet alien. Alien to each other and to me. Competitive poetry, internal reflection, and constant political intrigue define one culture. We get drips and drabs of the other, less powerful civilization, but you learn enough to be appreciative of their scrappyness and reverence for the collective.

The cultures are never described to the detriment of the action. The ambassador is dropped into a political mess and acts and reacts to help save her nation and herself. Whether she is trying to meet powerful people to negotiate for her people, reading correspondence, or escape danger, there’s no downtime. The entire book happens in span of about two weeks.

I also enjoyed the character development. Many of the characters pop in and out of the storyline, but you follow a few main characters for a while. You get to understand and appreciate the way they interact with each other. It doesn’t feel forced at all. At the same time, the “otherness” of the ambassador provides a constant tension which is understandable to anyone who has been dropped into an uncomfortable situation.

The plot revolves around a mystery. But even when it is unveiled, there’s still plenty of excitement, as a confluence of outside, political events ensnare the protagonists.

Some books are so good they keep you reading late into the night. This was one of them.

Book Review: Am I Being Too Subtle?

I recently finished “Am I Being Too Subtle”, which is a business book by Sam Zell. He is an American businessman and real estate tycoon.

I quite enjoyed the book. We learn a bit about his parents and upbringing, and then he plunges right into the deals. Some of the details are great (he was able to complete a transaction once because he found out the owner of the property had buried a favorite dog in the backyard, and added a clause to the contract allowing the pet to be exhumed). He addresses his successes (helping professionalize the REIT market, selling the equity group, the loyalty of his employees) and his failures (the bankruptcy of the Tribune company in 2008).

The single biggest lesson that I took away was that to succeed you need to be looking in places that others aren’t and that eventually what worked for you will stop working and you’ll need to change. There are other pieces of wisdom in the book, and it’s less than 250 pages. A great fun read if you enjoy learning about business and deals.

The Case For Space

Sunrise over a planetI recently read “The Case For Space“, by Robert Zubrin. It was great. Now, I have a degree in physics, but it’s been a long time since I did any math more complicated than algebra. So I can’t speak to the nuances of his calculations–I didn’t verify them. (A google search for reviews where people work through the math doesn’t turn up anything either.)

But I thoroughly enjoyed this overview. This book is in two parts.

The first covers where we are in space exploration now, and where the physics can let us be. He spends a lot of time on what we could do right now. But he also write a number of chapters on where we can be if there are scientific advances in energy generation (namely fusion). The author starts with low earth orbit (LEO) and then heads to the moon, Mars, the asteroid belt, the gas giants and beyond.

This section is a lot of fun. Zubrin covers areas that I never considered to be related to space (the power of transorbital flight to make the earth even smaller than it is today for travelers). He also talks about the economics of space flight and colonization. What exactly will the moon settlers or Martians have that they can sell? There’s a reference to a three way trade between Earth, Mars and the asteroid belt. I really enjoyed the details he dove into. For example:

“In the almost Earth normal atmosphere of Titan, you would not need a pressure suit, just a dry suit to keep out the cold. On your back, you could carry a tank of liquid oxygen, which would need no refrigeration in Titan’s environment…and could supply your breathing needs for a weeklong trip…”

The second part is supposed to be more inspirational, as if getting to space wasn’t inspirational enough. He covers various reasons (freedom, security, survival) that we should be getting off Earth. I found this section less exciting, but I can understand why he included this–if you aren’t excited about space travel for the adventure, Zubrin might convince you in this section.

There were parts of this book that dragged on a bit, but for the most part the prose is accessible and the math skippable. The real world plans that he outlines, especially at the beginning of the book focused on reusable spacecraft technology, LEO, the moon and Mars, are fascinating for their audacity and specificity. Recommended.