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.

Posted in , , , |

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.

Posted in , , , |

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.

Posted in , , , |

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 classicproblems.com. 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.

Posted in , , , , , |

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.

Posted in , , , |

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).

Weather

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.

News

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).

Events

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 Indeed.com 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

Posted in , , , , , |

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.

Posted in , , , , , , , , |
Copyright 2012-2020 David Kopec. Powered by Blogger.

Search

Swedish Greys - a WordPress theme from Nordic Themepark. Converted by LiteThemes.com.