Book Review: The Presentation Secrets of Steve Jobs

I give a lot of presentations. As a college instructor, I present at least once every week, and usually multiple times. I’ve also presented in business contexts and to general audiences. The Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any Audience by Carmine Gallo caused me to rethink how I’m delivering my content. I had seen every Steve Jobs video available online, including all of his keynotes, before reading the book. But it took Gallo’s insights to distill what made Jobs’s presentations so great in a digestible form that I could use.

Gallo’s book is based on the premise that Steve Jobs’s presentations were excellent. If you don’t agree with that and you didn’t like his style, then don’t pick up this book. You can watch any of Jobs’s presentations on YouTube. And if you haven’t, I highly recommend watching some of the most famous ones (introduction of the iPhone for example) before picking up the book. They will give you context because Gallo refers to specific presentations in just about every chapter. In fact, if you haven’t seen them, you may want to watch them as they’re introduced in the book, although it will add many hours to your reading experience.

Most of Jobs’s presentations featured slides. Therefore a significant amount of the advice in the book relates to making slides. If your presentations don’t involve slides, you will find about one third of the book’s content not applicable to you. Jobs’s slides were very different from most of the slides we see in business and academia. They had almost no text. Gallo clearly explains how Jobs made this work

Much of the non-slide advice is common sense: practice, vary your use of voice, be passionate when presenting, use demos, break up your presentation, etc. Yet the combination of all of it into a single volume and the way that Gallo elucidates these points make the book a one stop shop for improving your slides. I never got bored reading this common sense because I love Steve Jobs and even though I already knew almost all of the anecdotes in this book, they really made the advice come alive. If you don’t know much about Steve Jobs then you might not find the book quite as exciting.

The Presentation Secrets of Steve Jobs is a great book to improve your presenting skills, especially if you make presentations with slides. Its advice about making slides is unconventional and will make you rethink how you do them. Its other advice is mostly common sense but is really well illustrated. If you’re not familiar with Steve Jobs or you have not watched his keynotes you should watch some of them either prior to reading the book or simultaneously with when they are presented in each chapter. If you don’t like Steve Jobs/Apple then this is not a book you will enjoy.

Book Review: Edison by Edmund Morris

Thomas Alva Edison is almost inarguably the greatest inventor of all time. The first device for recording and playing back sound, the first large scale power distribution system, the first practical light bulb, and the first commercially successful video recording and playback device were just a few of his numerous inventions. His inventions span the gamut from mining, to electricity, to chemistry, to telecommunications, to optics, to mechanics, and even to botany. Edmund Morris’s Edison is an excellent book by a very experienced biographer that takes you through every one of Edison’s major inventions with enough context to help you understand how and why they came about. But Morris made a very strange structural decision that, while interesting, takes away from the book’s enjoyment.

Morris’s biography dispels two myths that I had heard about Edison (having only previously read a dime store biography of him and a book about his movie production company). The first is that Edison doesn’t deserve credit for his inventions because it was his workers who really came up with most of them. It’s clear from this meticulously sourced biography that Edison was not only the visionary behind his inventions, but that he also had a thorough scientific knowledge that allowed him to work hand-in-hand with his workers, directing them at every step. This is all the more amazing since he had no formal education and was thoroughly a self-made person. Edison was incredibly studious and consumed volumes and volumes of both scientific and non-scientific literature. Most of his major inventions really were his ideas. Some of them were improvements on the work of other inventors, and some of them were co-invented with his workforce, but he was the indispensable figure who created the first industrial research laboratory, making this all possible and directing it meticulously from his own mind.

The second myth I had heard about Edison is that he was a good scientist but a terrible businessman. It depends what you mean by “businessman.” Morris makes it clear that Edison was poor at managing his finances. But what is also clear from Morris’s account is that Edison was an amazing entrepreneur. He was able to see what inventions had practical commercial potential. He turned ideas into money. Did he then subsequently run those businesses well? Not generally. He was a great entrepreneur, but not a great manager.

Beyond invention, Edison’s life was filled with serendipity, interesting personal stories, and meetings with the greatest figures of his generation. Morris spends about three fourths of the biography on Edison’s inventions and business pursuits, and the remainder on the rest. He was perhaps the most famous person alive during his lifetime, and for good reason—his inventions utterly changed the every day lives of the masses. Reading the biography, you will get a sense of this, but it’s not delved into in any great detail. The majority of the pages are spent on the inventions.

The explanations of the inventions are clear enough that you do not need a scientific background to understand the gist of their purpose. You won’t understand them at a fundamental level, but you will understand why they were important and how they connected to the rest of the Gilded Age world. There’s not room, even in eight hundred pages, to go into all of Edison’s inventions, nor all of his personal life. His journey was just that amazing. But you get a sense that Morris chose the important highlights well.

So, Edison is a well-written and balanced biography about one of the most interesting figures of all time. What is not to like? The structure. Morris chose to bizarrely present Edison’s life in reverse chronological order. Each chapter covers a decade of his life. And the book starts with his last decade, and ends with his first. As we all know, lifetimes progress linearly. We’re used to hearing stories in order. It’s hard to keep track of characters, when we are abruptly and repeatedly thrown back ten years in their lives. The result is that it’s very hard to keep straight the lives of Edison’s associates and family members as you read Edison. It’s interesting in the last two chapters, knowing what you know about his life, to hear about how it started. It’s interesting, but I don’t think the trade off was worth making the rest of the book harder to read and keep track of. Morris died about five months before Edison was published. I wonder if he had lived longer, if he would have rethought the structure upon further reflection. Some reviewers have suggested reading the book backwards. I don’t think it would hurt you much to do this.

Thomas Edison was an amazing, interesting, and world-changing figure who deserves a thoroughly researched extensive biography by a great writer. In Edison, we have that. Its bizarre structure notwithstanding, if you are at all interested in technology, business, or even just history, you should give Edison a read.

Book Review - No Rules Rules: Netflix and the Culture of Reinvention

No Rules Rules: Netflix and the Culture of Reinvention is not a history of Netflix. It’s an extended account of the corporate values that have resulted in Netflix’s success as told by its cofounder/CEO Reed Hastings and accomplished business writer & academic Erin Meyer. This well written and clearly explained book offers insight into managing a creative company using non-traditional management techniques that give employees greater freedom and responsibility. However, the techniques are likely not as widely applicable as the authors imply.

No Rules Rules follows a unique format, in which each author’s voice is clearly pointed out in their sections of each chapter, leading to a kind of dialogue between the two. This format creates balance. Each point is discussed from the insider/pragmatic perspective of Hastings and the more academic perspective of Meyer. Meyer will sometimes backup Hastings’s assertions with research outside of Netflix, or gently pushback against some of his more absolutist tendencies. Meyer appears to have had significant access to employees throughout Netflix while doing her research. However, there’s no section in which she completely disagrees with Hastings, and throughout most of the book the reader is simply getting the same point from multiple perspectives.

The book revolves around the benefits of a corporate culture that empowers individual contributors to make decisions without bureaucratic tape and draconian oversight. This is meant to increase efficiency, improve flexibility, and help employees feel more satisfied with their roles. A couple specific examples are employees deciding for themselves the appropriate amount of vacation to take each year (no vacation policy) and signing contracts without getting approval from their managers. To get to this place of what the book calls “freedom and responsibility” there are certain prerequisites defined by the authors. These include a culture of candid feedback and achieving a high “talent density.”

These corporate values have obviously served Netflix well, but they may not quite be the panacea they seem from reading the book. Unfortunately, despite Meyer’s involvement, the values are somewhat myopically presented within the confines of Netflix. Probably the most controversial point in the book is its assertion that “adequate” employees (sometimes interchangeably referred to as “good” employees) should be let go to make room for hiring “great” employees. This is presented rather uncritically, without the obvious introspection that it is easy for an industry leading organization like Netflix to have its pick of “great” employees waiting at the gates to get an opportunity to work for it when they let go of the “good” employees.

The authors only caveat is that safety or process oriented companies (think nuclear reactor or industrial manufacturing) cannot risk freedom and responsibility. Yet, there are many other creative types of companies that cannot fulfill the prerequisites outlined by No Rules Rules. For example, there are creative companies that due to the limited profits in their industry cannot pay top-dollar and cannot risk letting go of “good” employees because there will be no “great” employees waiting to take their place.

No Rules Rules is a good book for learning more about Netflix, how its corporate culture works, and how it has helped to make it successful. It’s sprinkled with enough interesting anecdotes and good writing to keep your attention. The unique format adds value and the non-traditional management techniques are interesting and surely have some merit. Yet, the book’s failure to acknowledge the unique circumstances of Netflix that make its unique culture possible, stop it from being a “great” book. It’s just a “good” book.

On Taking Criticism

I am what I would call a non-famous public person. What do I mean by that? I mean that I have jobs where people publicly review my work. As a college instructor, I receive student reviews. Some of them get read internally at our school, and some of them get posted publicy. And they’re attached to my name. They’re not some product where people might just know my company or my brand. They know me, and they’re reviewing me. As an author, my books get reviewed. Some of those reviews are by editors and official reviewers internal to the publisher. Some of those reviews are by email. But most of those reviews are posted online. As a software developer and hobbyist podcaster I also get public reviews.

To anyone in a personalized creative field who cares deeply about their work, bad reviews hurt. It’s not just about being sensitive (although I am sensitive and that doesn’t help). It’s that when you really pour your heart into something, as I do my teaching for example, then the product is an extension of you. Nobody would deny that the way a class or a book turns out is an extension of the personality, knowledge, and ability of the teacher/author. And when the product is criticized, it’s like you are being criticized.

My dad, who was also a college instructor, and the producer of nine books and nine instructional videos among many other public creative ventures, had a very thin skin. He couldn’t stand me reading him a bad review. That stuck with me. This very accomplished man, couldn’t stand even a little criticism. When I get too sensitive, I try to remember how his inability to accept criticism hurt some of his products. He was much more about getting things done than doing them perfectly. If he had a little bit more of a perfectionist streak in him, he would have done even better. But maybe he would have done less…

It doesn’t matter if I receive eighteen great reviews for a class. It’s the words of the two bad reviews that stick with me. And do you know why? Because almost always there’s a kernel of truth to those reviews. Does that mean we should listen to them? Well if I only listened to the bad reviews, I would never produce anything. I would just stay in bed. The fact is the people who are getting no bad reviews, are the people who are not taking the risk of putting themselves out there. So, we have to not let ourselves get so discouraged that we stop producing. And we have to remember that while we may not have served those two students well, we may have served those other eighteen students better than they would have been served in a world without us teaching them.

We can’t please every student or every customer. Nothing that gets watched/read by more than a few people is going to be liked by all of them. Even Mother Theresa would get a downvote on YouTube. So, if we’re serving the majority, we don’t want to let the critiques of a few steer us in the wrong direction.

On the other hand, being like my dad is dangerous too. No, the customer is not always right. But usually the customer has a point. We have to always be working to get better. Because we’re not perfect, and there’s always room for improvement. And we need to read those bad reviews to find those spaces for improvement. It doesn’t mean they’re right, but it does mean we need to think about them.

My dad accomplished an amazing amount. If he let those bad reviews slow him down too much, it’s very possible he would have not accomplished as much. But if he could have found a few tweaks, a few changes, to serve a few customers better, well then he could have grown through them. I want to grow, but I also don’t want to stop. So, I can’t let the reviews get me too down, but I have to read them.

Book Review: Let It Go by Stephanie Shirley

A child refugee builds the first wholly female software company, putting feminism into practice, and goes on to become one of the most noted philanthropists in her country. It’s a story fit for Hollywood. Stephanie Shirley tells it with gusto, raw honesty, and compelling writing in her autobiography, Let It Go.

As a half-Jewish child during the beginning of World War 2, Shirley was saved from the horrors of Nazism by escaping on a train as a child refugee. In England she would build a new life, and build a software consulting company. Freelance Programmers (later F International) employed female programmers who were under-appreciated and discriminated against by the business world at the time. Many of these women worked from home part-time or while raising children in a world that wouldn’t allow them to work otherwise. They would work on large technical projects for some of the largest companies in Britain. Let It Go is a strong feminist treatise drawn from reality, not abstractions.

Shirley was a pioneer in many ways. Creating a software company in and of itself was still a new idea in 1962 when she got started. Creating a company of freelancers decades before “the gig economy” was an innovation. Employing almost all women in a technology company (although women were many of the first programmers) was unheard of. In Let It Go Shirley takes you through the early struggles of building Freelance Programmers. The reader receives a strong understanding of how the company operated, how it acquired clients, and the challenges that it faced as it grew from her cottage into a multi-million dollar enterprise. While Shirley covers the early period in the right level of detail, the company’s later growth is not as well recounted in the book.

Let It Go is also a deeply personal book. Shirley goes into detail about her relationships, her family life, and her struggles taking care of her child, Giles, who is affected by a severe form of autism. She weaves the personal stories well into the business narrative, making it a more “full picture” story than most business books. Her personal life affected her business and vice versa. That’s true of almost anybody, and to think otherwise is a folly. Yet many business memoirs almost completely exclude personal details.

One of the things I appreciate most about Let It Go is that Shirley held nothing back. Even embarrassing or difficult details were not left out. If she felt jealousy or betrayal over a colleague’s actions, she explained it. She covered her mental breakdown. She covered marriage difficulties. She covered her fraught relationship with her parents. It was real. It was raw. And it made for a more realistic, interesting, and insightful journey.

The latter half of the book deals primarily with three topics: Shirley’s transformation of her company into a partially employee-owned operation, her struggles to help her son with his condition, and her philanthropy. Shirley ended up being a leading figure in philanthropy in Britain, and in autism philanthropy in particular. She founded a school for children with autism, the country’s largest autism charity, and too many other philanthropic initiatives to mention here.

The theme of the book can be seen as “relinquishing control,” hence the title Let It Go. Shirley ultimately let go of her personal tragedies, her business, and many of her philanthropic ventures (to other managers). And she sees them as more successful as a result of it. It’s a powerful message that can only be fully understood by reading the book. If you have any interest in the early software consulting business, the evolution of autism care, women working in technology, or just want to read a great life story, Let It Go is worth your time.

Book Review: Blood, Sweat, and Pixels

Blood, Sweat, and Pixels: The Triumphant, Turbulent Stories Behind How Video Games Are Made by Jason Schreier is a compilation of vignettes about the development of ten different video games. Many of the games are RPGs, and most of them are produced by large studios. Despite the many different accounts, there is a real lack of diversity in the stories. Almost all of the stories deal with the same themes: crunch (working large amounts of overtime to ship a game), overcoming mismanagement from above, and reworking stories/gameplay that are found in development to be lackluster. The stories can therefore seem repetitive, despite being generally well written with a great degree of access to the original developers. The vignettes are too short to let the reader dive into the finer aspects of each game’s development, and it is hard to feel connected to the many introduced characters.

Although many of the ten stories feel repetitive, there are a few gems that stand out. The story of Eric Barone developing Stardew Valley by himself over five years was perhaps the most interesting, and is almost worth picking up the book for alone. It deserved more than just one chapter. Because it focused on just one person, it was able to better weave together the game and the personal story. Which really highlights the problem with the book as a whole: it tries to cover too many stories, and therefore ends up giving every story too little space. Schreier seems to have had excellent access to the developers, but this access was squandered by being so scattered.

Another strong chapter in the book is on the development of The Witcher 3. Schreier covered the interesting corporate history of developer CD Projekt, who’s unique foundation and Polish roots made for some less humdrum reading than many of the other large studio stories. The story of Yacht Club Games and Shovel Knight was the lone other indie chapter beyond Stardew Valley. Like Stardew Valley it was one of the more interesting chapters because it had fewer characters to keep track of. The book would have been better if it were ten chapters on five games, instead of ten chapters on ten games.

There is also a distinct lack of focus on overcoming technical hurdles and the software development/programming that goes into making games. The book focuses a lot more on game design and creative decisions, rather than technical work. Aspiring game programmers may come away disappointed. And by leaving this huge aspect of game development largely out of the book (there are some chapters that mention it, but without any level of detail), I feel the author did not fully represent the development process. On the other hand, not getting too technical probably made the book more appealing to a broad audience.

Blood, Sweat, and Pixels is an ambitious book that falls short of its lofty goal. It is probably best read piecemeal, picking and choosing the stories that interest you most. However, the author deserves credit for taking on such a challenging task, getting real access to the pertinent parties, and giving the reader an inside look at game development despite some poor editorial/structural decisions.

Announcing Classic Computer Science Problems in Java

I am pleased to announce the availability of my fourth book, Classic Computer Science Problems in Java. You can now purchase early access to the book from Manning. Use promo code ccspkopec for 40% off. This is the third book in the Classic Computer Science Problems series, following Classic Computer Science Problems in Swift and Classic Computer Science Problems in Python. You can find out more about the series at The manuscript is complete but it is being rolled out in chunks for reader feedback over the summer. Hopefully, the final version will be in print by the end of the year.

The books are aimed at intermediate programmers who want to delve deeper into the covered problem solving techniques, brush up on core algorithms, or learn more Swift/Python/Java using problems familiar to them from other languages. They are suitable for professionals looking to deepen their understanding of the covered topics, students with some programming background looking to expand their computer science knowledge, and anyone preparing for coding interviews.

What is a “Classic Computer Science Problem?” It is a problem one typically finds in an undergraduate computer science curriculum. The topics covered in the books span the gamut from core computer science algorithms you would find in a data structures & algorithms class to artificial intelligence and its sub-discipline machine learning. There are both practical and whimsical problems. They include classic search problems, constraint satisfaction problems, graph algorithms, genetic algorithms, k-means clustering, simple neural networks, and more!

They’re meant to be approachable broad books, not deep books. They’re not textbooks. They’re hands on code-centric tutorials to pique your interest in the many topics covered.

All of the code in the most recent book is available on GitHub. The book takes advantage of features up to version 11 of the Java language. The code only uses the Java standard library throughout, so there’s no wrestling with third-party libraries. You will learn how to solve all of the problems in the book “from scratch” so that you gain a deeper understanding of how each problem solving technique works under-the-hood.

To learn more, checkout the Classic Computer Science Problems in Java page on Manning’s website where you will find a full table of contents and temporary free access to small portions of the book.

We decided to bring the book to Java (a language close to my heart because I first learned it as a teenager over 20 years ago and have worked professionally in it), because the Python version has been a huge success. It has sold many thousands of copies and has been translated into eight human languages in addition to the original English. The Swift version did only moderately well, so we are excited to bring the book to another mainstream language audience. We try to be careful to make sure each version uses best practices in its respective language, but I would love to hear your feedback about the Java version during the early access period for any ways we can improve on our use of the Java language.

Remember that you are purchasing a pre-release version of the book, so you will be joining me on the journey to its final release in the fall. You will be receiving rough drafts of chapters before they have been fully vetted. I encourage you to send me your feedback, but keep-in mind that these are early days and everything is not yet perfect. You will receive the final version of the book upon publication.

Updating the Declaration of Independence

The Declaration of Independence is considered to be one of the most important documents in human history. Not only was it the seminal document in the political formation of the United States, it also was arguably the first time that a nation was expressly formulated with an understanding of the essential nature of human rights, despite not living up to it. It inspired many more rebellions against tyranny around the world in places as far removed as Vietnam and Haiti, and continues to inform our understanding of the relationship between a people and their government.

However, while its syntax is beautiful, it also no longer rings true to everyone who reads it. This is both because of our updated understanding of who political rights should be applied to (all human beings), and because not every reader is familiar with the assumptions and meanings inherent in the eighteenth century English of its writers. I don’t think we should literally update a historical document, but I do think it’s important to be clear about what the Declaration means to us today.

Here is the language in the Declaration’s most famous section:

We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.–That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed, –That whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness. Prudence, indeed, will dictate that Governments long established should not be changed for light and transient causes; and accordingly all experience hath shewn, that mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed. But when a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to reduce them under absolute Despotism, it is their right, it is their duty, to throw off such Government, and to provide new Guards for their future security.

Here is my interpretation of the Declaration’s most famous section in the simplest language that can represent what it means to me in today’s context, and no simpler:

We believe that all people should be treated equally under the law. There are universal human rights including, but not limited to, the rights to life, liberty, and the pursuit of happiness. Government exists to ensure these rights. Government’s only legitimate power comes from the people it governs. Governments that infringe on human rights or derive their power from a source other than the people, are illegitimate. It is the right and duty of people to replace such governments.

This is my personal interpretation of the Declaration. This is what it means to me today. And it’s how I will parse it for my children. Maybe I have some details wrong and I’ve changed some of its intent. But I think the spirit is right and I think the language will be very easy for them to understand and contextualize for the modern world.

Building a Local Newsletter

One year ago, I launched BTV Daily, a daily email newsletter that delivers news, events, top social media posts, and other items of local interest to subscribers in the Burlington, Vermont area. The newsletter is largely automated, although I write a short daily blurb in a section called “Dave’s Corner.” BTV Daily is a hobby, but one that I take quite seriously because it provides real value to its subscribers. I know this because for the one-year launch anniversary this week, I put out a subscriber survey, and I was impressed to find how many people really appreciate the newsletter.

This post contains details about how I built BTV Daily and how I’ve grown it from 0 subscribers to (a still fairly meager) 296 subscribers (as of today). Keep in mind that Burlington, Vermont is a city of just 40,000 people. Also, keep in mind that the newsletter is not (yet?) monetized. In fact, it costs me money. This is a passion project, not a business.

Generating Content

To see what a copy of the newsletter looks like, you can checkout the archive section of the BTV Daily website. The sections in the newsletter are Weather, This Day in Vermont History, News, Events, Top Twitter Posts, Dave’s Corner, Latest SeeClickFix Issues, and Quote of the Day.

Technical Setup

BTV Daily is generated by a Python script that runs via a cron job on a Raspberry Pi in my home. At 7:45 AM each day, the Pi connects to GitHub to pull my latest blurb for Dave’s Corner. At 8 AM each day, the main script executes. It calls various APIs to generate BTV Daily’s content, which is amalgamated into an HTML file that is passed to MailChimp to deliver to our subscribers. I use no images in the newsletter to decrease load time and avoid being marked as spam. I do make extensive use of emoji instead. Unfortunately, I still get erroneously marked as spam by gmail’s spam filter for some users despite the fact that this is a subscribe-only newsletter (I don’t manually add any users).


The day’s weather information is generated using the Dark Sky API. An avid reader asked me to include sunset time in it, and I think that was a very nice addition. Apple has purchased Dark Sky, but their API will keep working through the end of 2021.

This Day in Vermont History

I added this section about halfway through the year after receiving permission from the Vermont Division for Historic Preservation to use their database (which they sent me as a Word document). This was, of course, very nice of them. I wrote a script to reformat the database into a Python dictionary.


When I first started BTV Daily, I used the RSS feed of The Burlington Free Press to generate the news content. However, much of the content from them is paywalled, and users complained. So, I moved to the Bing News API, which Microsoft provides a Python library for accessing. I carefully calibrated the local sources to request stories from, the keywords to use to get Burlington specific stories, and other settings. I also added the NY Times as a source, so that when Burlington is in the national news, relevant stories will come up. This did lead to some Bernie Sanders political stories making their way into the newsletter even though they were not really about Burlington (sometimes stories about him will mention his hometown of Burlington in passing).


The newsletter links to Burlington area events from Seven Days, hopefully driving some traffic to this venerable publication.

Top Twitter Posts

I use the Twitter API to search for the top five tweets in the past 24 hours that have the most favorites that use hashtag #BTV or #BurlingtonVT. #BTV was unfortunately getting me tweets from non-Burlington sources, but I later discovered that the API has an option to limit searched tweets to a radius around a zip code. I use a 250 mile radius of Burlington and it works well.

Dave’s Corner

I write Dave’s Corner in a text file that is labeled by date in a format the script looks for. I can include HTML tags. I should probably put the work in to include markdown support. Occasionally, my wife will write a blurb and the section changes from Dave’s Corner to Rebecca’s Corner if the first line is “Rebecca.” My blurbs are usually observations about Burlington or my life.

SeeClickFix Issues

SeeClickFix is a tool for citizens to report local issues to municipal authorities. I have some concerns about the fact that people can be virtually anonymous on the site (they can act almost as a secret police). By exposing issues to the general populace through the newsletter, hopefully they are getting more scrupulous attention. I report the SeeClickFix issues of the last 24 hours via the SeeClickFix API. They are released under a non-commercial license. If I monetize the newsletter in the future, I suppose I may need to remove this section, or is it fair use?

Other APIs

I use the MailChimp API for actually sending the newsletter. I use the WikiQuotes API for generating a random local quote at the end of the newsletter. Unfortunately, the only non-political and non-controversial figures from Burlington on Wikiquotes are Ethan Allen and John Dewey. These quotes get pretty boring, pretty quickly.

Getting Subscribers

I got my first twenty subscribers through a Reddit post. I got another twenty or so subscribers by mentioning the newsletter on a Vermont email social network called Front Porch Forum. Several people in the one-year anniversary survey said I should post more about the newsletter on Front Porch Forum, but believe it or not the advertising rates on Front Porch Forum are exorbitant. And I don’t want to post regularly there without paying for advertising since that doesn’t feel right.

The rest of the ~300 subscribers have come through Bing ads, Facebook ads, Twitter ads, and word of mouth. I also tried a few physical advertisements on bulletin boards around the city. It ends up costing me about $1/subscriber when using Facebook/Twitter ads. I guess that’s my “customer acquisition cost.” Since this is a hobby project that I enjoy, I don’t mind that I’ve spent a few hundred dollars on it.

Keeping Subscribers

The vast majority of people who subscribe to BTV Daily stay subscribed. The numbers show that over the first year, about 80% of people who subscribe don’t unsubscribe. I try to be responsive to individual emails I get from subscribers. Several improvements to the newsletter have been a result of reader feedback. About 40–50% of subscribers open any given edition of the newsletter within 24 hours.

The vast majority of subscribers live in Burlington or one of the surrounding communities. Once in a while someone from out of state will accidentally subscribe and they will realize their mistake and unsubscribe. The most infuriating thing is when someone unsubscribes after being on the list for months and marks the reason to Mailchimp as “spam.” This happens rarely, but how can a newsletter that you personally signed up for and read for months be spam?

Looking Forward

I would like to add additional sections to BTV Daily. One section in particular that I am interested in adding is job postings in the Burlington area. I contacted Craigslist legal for permission two times, one year apart, and nobody got back to me. I applied to become an publisher almost a month ago and never heard back as well.

I would like to grow the newsletter to 1,000 subscribers (2.5% of the population of Burlington proper). I am thinking of showing a progress bar in the newsletter. Perhaps that would encourage subscribers to tell their friends. Or perhaps it would discourage them because they thought the newsletter had thousands of subscribers and it only has ~300.

If I reach the 1,000 subscriber goal, I may try to monetize the newsletter to at least cover its advertising costs by allowing people to place local ads. I would not be opposed to making a profit either! But it’s not my primary concern right now.

If you have questions or comments about the newsletter, feel free to reach out to me at newsletter at btvdaily dot com

Book Review: Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft

I enjoy books about tech history and business. I also enjoy biographies. So, Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft by G. Pascal Zachary was a perfect fit for me. It has a compelling software business narrative, backed up by significant author access to the major players, and features non-stop action throughout most of the book.

Showstopper, written in 1994, is a book about the building of Windows NT, one of the last still-in-use desktop operating systems to be developed from scratch (Windows NT remains the underpinnings of Windows 10). Zachary had incredible access. He was able to interview all of the major players involved in NT development, including David Cutler, the project’s lead, and Bill Gates, the CEO of Microsoft at the time. It provides real insight into the market landscape at the time, the challenges that Windows NT faced, and what is was like for regular software developers and management to laboriously crank out NT over many sleepless nights throughout a period of roughly four years.

Zachary does a good job balancing vignettes about management with vignettes covering lowly software developers, testers, and their families during development. He pays attention to the human story. What was the toll of the breakneck development schedule and the high pressure environment on families and worker mental health? He clearly did his research, took the time to interview everyone relevant that was involved, and weaved their respective narratives into a cohesive largely chronological whole.

Where Showstopper falls short is in Zachary’s understanding of the technology. While seemingly written for a mainstream audience, I imagine most readers today, like me, will be software developers. From the beginning it was clear to me that Zachary did not fully grasp all of the software development technology that a book like this inevitably needs to cover. Or if he did, he dumbed it down too much for my liking. He did his best, and I think if I were a mainstream reader, his explanations would actually be quite good: just enough to give me a basic understanding. But as a software developer, I was left wanting.

The parts of Showstopper I liked least were the first thirty pages, largely covering Cutler’s career at Digital, and the Afterword in the 2008 edition with Zachary pontificating about 2008 Microsoft. I think Showstopper was at its best when reporting on the week-by-week challenges and worker vignettes during NT development, and at its worst when trying to analyze the big picture. Another problem with the book is that it tries to cover too many characters. It was easy to lose track of who was who. You will be treated to many mini-biographies, which while interesting, are not enough to get you invested in each of the players.

Despite its flaws, Showstopper! is worth reading because it pulls back the covers of a Herculean software project in human terms. If you are interested in computer software history or the business history of Microsoft in the early 1990s, it’s a must read. Software developers with an appreciation of computer history will find it compelling and enthralling, if they make it past page thirty.

One Year of Classic Computer Science Problems in Python

Approximately one year ago today, my most recent book came out, Classic Computer Science Problems in Python. It is the second book in the Classic Computer Science Problems series. You can purchase it on Amazon or through the publisher’s website. It has been an amazing year for the book.

I had the good fortune to be on several podcasts to promote the book. I really appreciate all of the podcast hosts who gave me the honor of being on their show. It made a huge difference in sales. For example, my appearances on Talk Python to Me and Podcast Init alone accounted for approximately 1,000 sales according to the publisher. To see all of the podcasts I’ve been on, checkout the interviews section of

This has been the most successful book that I’ve written by an order of magnitude. It’s surpassed the sales of Dart for Absolute Beginners and Classic Computer Science Problems in Swift by a multiple of their combined sales. I appreciate all of the support from the community. I think Classic Computer Science Problems in Swift was a good book but the publisher was right in saying that it needed a larger language audience. Python not only has more users in absolute numbers, it also has more users in one of the major target demographics for the series, which is self-taught programmers who missed out on a computer science education.

I’ve done many things to promote the book, and I appreciate how my publisher, Manning, has advertised the book to their audience. However, more effective than anything have been the podcast episodes. I can’t tell you how many people have told me they learned about the book through a podcast episode. Podcast episodes have even led to translations. If I hadn’t appeared on the mostly Portuguese (but sometimes English) podcast Castalio, then perhaps the Portuguese edition would not have come out.

Amazingly, the book is now on target to be translated into seven languages, including: Russian, Polish, German, Traditional Chinese, Japanese, Korean, and Portuguese. Interestingly, the only translation publisher that has been in regular contact with me has been O’Reilly Japan. I think they did a really nice job on their edition, and I thank them for their attention to detail. It’s interesting to see how the book’s teaching style (informal in terms of theory/math, to the point, and code heavy) appeals to some cultures and not to others. Anecdotally, my worst review has been for the Russian edition, and some of my best reviews have been out of Germany for the English edition. Of course I can’t tell you if the Russian translation is good or not, since I don’t speak Russian.

By far the most controversial decision I made about the book was to use type hints/type annotations throughout. This decision alone led to some of the worst reviews of the book. Would I do it again? It’s impossible to say how many people bought the book because it was one of the first Python books to use type hints throughout. I do think the type hints add value in terms of readability once you get used to them, but I can definitely see how the effect of turning some people off, makes any benefits not worth it. And of course I agree that the way Python does type hints is still too verbose.

Looking forward, one nice thing about the Python book versus the Swift book is how much more stable a language Python is. I wrote both books according to the latest versions of their languages respectively. However, by the time the Swift book came out (it took 6 months to go from done to store shelves) it was already a little outdated due to the fast pace of change in the Swift language. Python on the other hand, has a much longer shelf life and greater backwards compatibility between versions.

Finally, I am currently writing the third book in the series, Classic Computer Science Problems in Java. I look forward to it being released later this year, so look out for it if you are a Java aficionado. To decide what language to do next, we did a poll of Manning readers that had 300 votes. Java practically tied with Go. The idea of going with Java is that this book did well in a large language community (Python) and only okay in an emerging language community (Swift). Writing a book in Java feels like going back to my roots since Java was one of the first “real” languages that I learned in the late ’90s. I have done some professional projects in Java as well, so rest assured that I’m competent to write it!

I’d like to thank all of the readers who have purchased the book. I’d like to thank anyone who’s shared their constructive feedback. And, I’d like to thank the team at Manning. If you are a reader and you like the book, please do leave a review on Amazon or your place of choice.

Also, it goes without saying, but please stay home during the coronavirus crisis if you can. Stay safe!

About Me

I teach Computer Science to college students, develop software, podcast, and write books about programming including the Classic Computer Science Problems series. I'm the publisher of the hyper local newsletter BTV Daily.

You can find me on Twitter and GitHub. Check out my podcasts Kopec Explains Software and Business Books & Co. You can subscribe to my very low volume newsletter to find out about my future book, media, or software projects.


©2012-2023 David Kopec. As an Amazon Associate I earn from qualifying purchases.

Based on tdSimple originally by Lasantha Bandara and released under the CC By 3.0.