Not What I Set Out to Do

Software Design by Example Using JavaScript is now available on Leanpub, and printed copies will soon be available as well. I’m glad it’s finally out, and I hope you find it useful, but it has fallen short of my original hopes in two different ways.

The first is that there’s been no interest in the book among people who teach software design and software engineering. I taught a course called “Software Architecture” several times at the University of Toronto in the early 2000s; while lots of textbooks had those two words in their title, none of them spent more than a few pages describing the designs of actual systems. My frustration with that led to Beautiful Code and The Architecture of Open Source Applications, but as popular as they were among working programmers, only a handful of teachers used them in class. The chapters were written at very different levels and used many different programming languages, which meant they required far more background knowledge than most undergraduates had.

SDXJS fixes that by tackling problems at more or less the same level, in a domain that software engineering students will be familiar with (programming tools), and by using a single language that most potential readers will already have encountered. Despite all that, and being free, none of the software engineering faculty I’ve reached out to have shown interest in using it.

But that’s the lesser of my disappointments. (Like all authors, I’ve become very good at cataloguing and ranking disappointments…) I never wanted to write this book myself: instead, my plan was to write a few chapters to get the ball rolling and then invite people who aren’t yet well known, but should be, to contribute a chapter each. When I look at Beautiful Code now, what strikes me is how homogeneous the contributors were: while a quarter of the people we reached out to were women, 35 of the final 36 contributors were men (and almost all of them were white). AOSA wasn’t quite as bad, but I wanted SDXJS to be better because I want computer science and the tech industry to be better.

Because here’s the thing: you’re not reading this because I program—you’re reading this because I write. Thanks to a few lucky accidents (like my father being a high school English teacher) I can put words together better and faster than most people. Whatever clout I have is a result of that, not my middling-good ability to code in C or Python, and I figured that if it worked for me by accident then maybe it could be made to work for other people by design.

When I started work on SDXJS three years ago, my plan was to invite people from groups our industry has marginalized or excluded to write chapters, and to turn those chapters into conference talks, to help raise their profiles. Of the people I contacted, though, only three agreed to, and none of them delivered. I understand why not: if you’re not a straight white or Asian male then you already have to do a lot of extra work to get ahead in tech. Doing even more work on the off chance that it will lead to something else is a bad investment, and being asked to do extra work without pay—again—is just wearying.

I’m pleased with the book itself: there are still some formatting glitches, some of the diagrams could be clearer, and I still don’t think I’ve explained JavaScript promises well, but it’s not bad for a first release. If I could wind the clock back to 2018, though, I wouldn’t have started it. Designing things well matters to me—thinking and talking about it reminds me of my brother—but fixing our broken industry matters more. I still hope to see it adopted in courses, and I still think a second volume with contributions from people who deserve to be on stage just as much as I ever did might make a difference, but looking at it now, I think I could have helped more people with those hours by doing something else.

Footnote: I received two messages within minutes of publishing this post. The first told me not to be so down on myself to which I replied that I need to decide whether to put in a hundred hours to finish Building Software Together; if I don’t reflect on this project, I’m unlikely to do better with the next.

The second told me, “Don’t be such a bleeding heart. If diversty [sic] hires don’t want to work hard to get ahead they don’t deserve to.” I’m willing to bet those “diversity hires” have worked harder than the person who wrote that message has ever had to; I’m also willing to bet that he’ll never let himself see that.