Why Twitter has lost; Or, against brevity

In the wake of the rumors that Twitter was going to up its character limit, I started spiffing up my Twitter profiles: I added a few photos, started adding people to my various lists, and even started using it a bit more. Then, of course, it seems that those rumors provoked such a backlash within the hardcore Twitter community that Jack Dorsey was forced to shelve any modifications to the format. Here we have, in a nutshell, the reason that Twitter has lost: it’s utterly unwilling to make any modifications to its established product that might make it attractive or useful to those who aren’t already committed users.

For better or worse, for example, I’m friends with a lot of colleagues on Facebook. This is annoying– sometimes I just want to post something silly or random, and it’s annoying that I have so many professional colleagues mixed up in my FB. (And yes, I know there are ways to tweak that, but who has the time?)

In a way that’s only rivaled by a very few high quality email listservs, Facebook is the place I go to hear what people in my field are talking about and working on (and from a usability standpoint, it’s actually easier to skim and follow discussions on Facebook than in my Gmail). My colleagues make comments about work they’ve been doing, share fellowship, grant, and job postings, pose questions, and generally take advantage of the fact that we’re all working on our computers N hours a day. My colleagues from grad school have a really phenomenal little group that often contains very specialized questions: requests for bibliography, questions about translations, and the like. It would be nice, in some ways, if some of these discussions were on Twitter: we could draw on the breadth of Twitter’s userbase, have discussions in real time to a greater extent, and get away from some of the ickiness that attaches to FB (and perhaps bring in people who stay away from FB because of said ickiness).

But just as a for instance, I was messing around this morning with looking at the character length of these discussions. These aren’t Tolstoyan ruminations or Herodotean digressions: most of these discussions are sparked by a brief, sometimes humorous comment someone has made about their work or something they’ve found in their research. Perhaps unsurprisingly, almost all of them are over 140 characters. Even just setting up the necessary context for many of these comments takes more than 140 characters. The only comments by my colleagues that fall under the 140 character limit are quick, humorous, and usually relate to popular culture (and so don’t have anything to do with professional communication at all).

Let’s be clear here: these are professional writers, and ones who’ve had a lot of success, too. These are people who write books and articles, and who and communicate for a living, who– as their posts make clear– are constantly engaged in the process of moving their ideas from insights to well crafted arguments, and for a variety of audiences, too. The argument that these people are incapable of concision and brevity strikes me as completely off base. (I make no such claims about my own capacity for brevity, however.)

The reality, I think, is that Twitter works great for subjects where everyone knows what you’re talking about: if you’re just railing about the latest idiotic or offensive thing that Trump has said, or some piece of celebrity gossip (and we all do), you don’t need any context. If you’re have something to say on subjects that require context or nuance, forget it.

But it’s not just that: I’m frequently astonished at how often Twitter falls down at its core functions: many, many times the most salient or compelling quotation on the news just won’t fit into 140 characters: I found a great analysis of some of the religious freedom legislation that’s been going through legislatures around the country a while ago, but the best quotations from and the core insights of the article just wouldn’t fit into 140 characters, and so I never ended up posting that analysis.

The result is that other services are eating Twitter’s lunch. Facebook, as I said, is pretty standard for a lot of scholars in my field. People in visually or design-oriented fields make a lot more use of Instagram than they do of Twitter. But it’s more than the fact that people self-select into platforms tailored to what they do instead of Twitter: it’s that these platforms are constructed in such a way that allows for novel kinds of use, and meaningful discussions beyond (and perhaps in spite of) the intentions of the platform’s designers in particular. I was surprised by how much substantive discussion there was on Instagram, for example, after the Freddie Gray murder and the unrest in Baltimore, and in a way that totally changed my feelings about the platform. Facebook allows for (even if it does not always brilliantly facilitate) real moments of connection: a friend going through medical difficulties, contact after a long period of disconnection, political debate that (sometimes) goes beyond kneejerk reaction. (And these are just things that have happened to me in the past week or so.) Every time I’ve tried to recommit to Twitter, I’ve had the opposite reaction: a lack of users beyond a narrow band of journalists, technology writers, and bots; friends with accounts who never post anything (and whose tweets get lost pretty quickly in the maelstrom); and, above all, the utter lack of any meaningful contact or communication through the platform, and the sheer disinterest of the company in fostering it. Twitter’s decision to stick with the current design of their broken platform may keep its users in the short term, but will do little to win anyone else over.


Cranky about OS X

So I needed a laptop for work, and, perhaps against my better judgment, I decided to go with a Macbook Pro. I’ve had mixed experiences with PC laptops, where I think build quality varies wildly and it’s hard to consistently get a good piece of hardware (though I am somewhat curious about the Dell XPS ultrabook line, though unenthusiastic about its weak keyboard).

Along with this is that I’ve always liked the fact that OS X is built on top of Unix; not a variety of Unix I know well, to be frank, but still. What do a few cosmetic changes matter compared to a shared POSIX heritage?

Welp. I am now regretting my decision, and to a not inconsiderable degree. Where to begin? The lack of a decent package manager? The fact that in El Capitan Apple has made the Disk Utility completely worthless for partitioning? The fact that it’s impossible to write an .iso to a flash drive without mucking around with the dd command?

My naive belief was that OS X is an operating system that hides some of the complexity of its internals from the end user, but that makes up for that with a polished user experience; my hope was that, beneath the hood, OS X still had a lot of good functional tools for the power user. I’m finding myself somewhat disappointed in the first respect, and deeply frustrated in the latter. The iOS-ification of OS X is much, much worse than I thought, and has really made me miss a lot of the functionality of Linux. Hell, I’d settle, in some respects, for the advances that Windows has made in 7 and 10.

Klemens, 21st Century C (2nd ed., O’Reilly, 2014)

As everyone knows, Mark Twain defined a classic as a book that everyone wants to have read and no one wants to read. Everybody who does some programming knows that K&R is a classic, by any standard– it’s the Rosetta stone of modern C programming, but it also helps to clarify the design principles (and of course the syntax) of many of the modern programming languages that are derived from C. Even beyond languages with a clear C lineage, it’s easy to see the way that a whole host of other modern programming languages have been written to simplify things that are tedious or risky in C. At the same time– and like a lot of other people, I’d imagine– K&R sits on my shelf and stares at me most of the time. When I open it, sometimes I think “What an impressively written book! What concision and clarity!” Most of the time, though, I think, “Wow, how gnarly– thank God for Python!”; or I wonder whether any of the details K&R fuss over are relevant today.

Ben Klemens’ 21st Century C is intended to resolve some of this shock, and to serve as an introduction to modern ways of working in C. The first part of the book presents tools and best practices for this (including debugging, testing, and version control), while the second half discusses how to write modern C– C in a world where, among other things, the rigid memory constraints taken for granted in K&R no longer apply. Some parts of the book (like the discussion of pointers) are clearly meant as an introduction or refresher for readers who aren’t comfortable in C, and the book includes a handy appendix on the basics of C. Other parts live up to the book’s billing as an explanation of what has changed in the world of C. The discussion of new structures in modern C, for example, is a highlight of the book. Klemens’ discussion of string handling in Chapter 9 was also interesting, though briefer than it might have been. (Perhaps with good reason: as someone who works almost exclusively with strings– and even though Unicode in modern languages isn’t always fun, either– I remain unconvinced that working with strings in C is something I want to do on a regular basis.)

As my comments above suggest, I am not an experienced C programmer (despite the occasional stab at the exercises in K&R), and am thus rather unqualified to pass judgment on the soundness of any of Klemens’ code. I can only assume that the infelicities and problems mentioned in reviews of the first edition of the work have been resolved. As a C tyro, though, I felt that Klemens effectively explains the ways that different practices– and the C standards, as well– have evolved over the years. It would be tempting, I think, for the book to remain at the level of vague generalities, but the book strikes a nice balance between high-level discussion of the way C programming has changed over the years and detailed discussion of what’s going on under the hood. It helps immensely, I think, that Klemens has a light, humorous touch– he notes that the manual memory model “is why Jesus weeps when he has to code in C”– and the humorous asides help to leaven some of the necessarily technical passages of the book.

Klemens’ book has the unenviable task of competing with K&R, and there are parts where 21st Century C suffers for the comparison. I still prefer K&R’s discussion of pointers; and I felt that there were a handful of sections that add little to what’s already in K&R. Klemens is fond of comparing C to punk rock, and upon reflection, I believe the comparison is an apt one. To push the metaphor further, there are ways in which K&R is, like a classic punk album, indelible in its simplicity and directness. To my mind, Klemens’ book is a worthy attempt to take that simplicity and directness and make it speak to a changed world. Klemens’ book isn’t perfect; if we’re honest with ourselves, though, even the hardiest classics aren’t always, either.

Goodliffe, Becoming a Better Programmer (O’Reilly, 2014): A non-professional’s take

Goodliffe’s Becoming a Better Programmer is marketed to a wide range of readers: to veterans, newcomers, and also to those who do some programming on the side as a hobby (Hi!). This is not entirely accurate– the book clearly has professional developers in mind most of the time– but I found the book to be an interesting discussion of aspects of the art and craft of programming all the same.

The first two parts of the book discuss a number of features of writing and working with code, both the theoretical/philosophical side and lower-level issues like producing and maintaining consistently formatted code. These sections are clearly oriented primarily towards professional developers, who are probably working in a production environment, have an existing codebase to work with, and may well be under pressure to skimp on design or testing in order to ship code more quickly. Even so, in talking about all of the problems that particular code or a particular codebase can have, these parts also talk at length about the principles and design behind good, sane code, and I found these sections useful and interesting. He discusses cohesion and coupling, omitting needless code (the YAGNI principle), and producing simple and sufficient code– along with practical advice about stuff like testing and version control.

The last three parts of the book are concerned with the softer side of being a developer, both personally and interpersonally– working well with your team, responding to superiors, and even personal things like ethical considerations and the importance of good posture. These sections are lighter weight (and often briefer), and sometimes repetitively summarize earlier points in the book. But they’re an easy read, and can be humorous in a way that the sometimes strained jokes of other sections aren’t. (For example, Goodliffe talks about your relationship with your primary language as a marriage, but then notes that, unlike most marriages, it can be quite helpful to play around on your “spouse.”)

It’s worth pointing out that Goodliffe’s book seems much more oriented towards discussion than to armchair reading. Each chapter takes up a subject, discusses different approaches to that subject (sometimes briefly), and then gives a set of questions. In most cases, Goodliffe is undogmatic– he lays out his position in the text, but the questions leave open the possibility that other experienced developers might have a different take. This format seems like it would work well for reading with a mentor (as the book suggests) or even a book club.

Goodliffe’s language-agnostic approach makes the book broadly accessible but also somewhat abstract. I think the book would have been stronger if he were clearer about applying principles to particular languages. Goodliffe’s book will not replace the resources that give advice and best practices for the idiomatic use of whatever language you’re working in, therefore, but it’s a quick read, and may get you thinking about the way you code, even if it’s only something you do in your spare time.

Janssens, Data Analysis at the Command Line (O’Reilly, 2014)

It normally takes me a week or two to read through a new tech book, but Janssens’ Data Science at the Command Line went by quickly. In part, this was because I was unusually excited about the premise of the book. I’ve been working with a number of my own data files recently, both on the command line and in Perl, and I was eager to learn new tricks and techniques. Does Janssens’ book live up to my (admittedly high) expectations? Partly, but the book was also a quick read because it’s more limited than I had hoped.

To start with the positive, Janssens’ book introduces users to a number of the most important command line tools: sed, awk, and grep, among others. A real strength of the book is that Janssens covers a number of lesser-known tools that are welcome additions to the usual suspects: jq (for working with JSON data), curlicue (a curl variant that handles the hassle of OAuth authentication), and the tools of csvkit (for both working with CSV files and converting other formats to CSV). Janssens has even written a few of his own tools that serve to soften the sometimes steep learning curve of the command line.

Furthermore, Janssens gives a helpful overview of ways of working with data on the command line. Like many users, I know a fair amount about working with text at the command line, but Janssens opens up topics like creating attractive visualizations and using GNU Parallel for managing parallel commands. In giving this overview, Janssens demonstrates how the philosophy of the *nix command line can be applied to data analysis. However, the book seems to be intended to prove the viability of doing data analysis at the command line more than to serve as a systematic introduction. Important points are occasionally glossed over; the book fails to mention that regular users will be unable to chmod files outside of their home directory without sudo, for example (pp. 44-5). Likewise, I imagine many readers would benefit from a clear discussion of using the tee command to drop data into a file when you’re piping data all over the place. Janssens gives examples of using sed and awk, but with only brief explanations of how they operate; I imagine that many users will need to turn to the clearer, more systematic discussions in other resources (like Classic Shell Scripting or Unix Power Tools) to really move beyond the examples Janssens provides.

Furthermore, if you’re more comfortable with another way of working with your data than the command line, I’m not convinced that the command line is always the best approach. Some of the approaches Janssens suggests are rather clunky, for example. There are heaps of XML (and HTML) data out there, but the book suggests the awkward approach of converting HTML to JSON to CSV. Having spent time fussing with XML parsing, I genuinely understand the attraction of this approach, but it would have been nice if he’d covered both proper XML parsing as well as just dumping everything into CSV files. (To be frank, I’m not sure there is a robust way to work with XML on the command line, though.)

In conclusion, then, Janssens’ book is worth a read, and I will be exploring the possibilities of command line data analysis in greater detail after reading this book. On the other hand, Janssens book is something of a missed opportunity: it is not the final statement on the subject, and is a bit skimpy as an introductory resource.

DuBois, MySQL Cookbook, 3rd ed. (O’Reilly, 2014)

MySQL (and SQL more generally) is a funny beast; or maybe it’s more like a familiar (but still odd) country. You can get around on the subway and get your bearings on the street, but you go to the post office or try to do something at the bank and realize that you’re still not thoroughly acclimated to the country. I’ve felt that way about MySQL from time to time– I have a sense of how to write basic queries, but there are parts of MySQL I don’t visit because I don’t have any idea they’re there; and there are things about MySQL that still seem a bit odd. The new, third edition of DuBois’s MySQL Cookbook is a rich handbook for MySQL, a Baedeker for those occasions when you need to venture out into the MySQL countryside.

There are many, many helpful recipes in this book, to the extent that picking particular ones out for praise becomes difficult. The discussion of working with strings and character set collations is quite nice, and shows how to do a fair amount within MySQL; Chapter 9 (on stored routines and triggers) is great; and the discussion of joins in Chapter 14 was one of the best I’ve read. I’ve felt at times that my ability to work with MySQL has been hampered by an imperfect sense of its possibilities; and browsing the Cookbook demystifies and demonstrates how to do useful things in MySQL.

However, one weakness of the book is that it tells you how to do lots of things in MySQL (and often covers the range of ways to do things in MySQL) without giving a sense of whether it makes sense to do it in MySQL at all as opposed to a proper programming language. For example, the book discusses regular expressions within SQL, but leaves for the end the important point that SQL regular expressions do not work with multibyte character sets (UTF-8, most crucially).  Similarly, some of the non-MySQL code in the book seems old-fashioned; chapters 18-21 include some Ruby and Python code, but lean very heavily on Perl. To return to the travel metaphor, it’s like a travel guide that is very solid on its main subject, but much less reliable about the towns across the border. On the other hand, though, the book is quite good at telling you what is MySQL-dependent, and what is portable across SQL and database implementations. As this qualification suggests, this caveat only reduces the usefulness of the book slightly, though; as a guide to using MySQL, the book is both thorough and impressive.

Fluent Conference 2013: JavaScript & Beyond Complete Video Compilation (O’Reilly)

I want to begin this review by emphasizing that I am not primarily a Javascript person, though it’s hard to do web stuff and not need to do Javascript now and again. I also want to point out that, as other reviewers have noted as well, I have not had time to watch all of these videos, and further exploration will likely uncover more useful material from this conference.

That said, I found the videos from this conference only somewhat useful for viewers, like me, who only work with Javascript in passing. Some of the topics– such as the extended tutorial on AngularJS– will probably seldom be of use to the casual JS user (though I thought this presentation was very well done). Other topics were more immediately relevant– such as Manor’s presentation on improving your jQuery, but Manor’s occasionally nervous manner distracted from the content of his presentation to some extent. Not all of the presenters of this conference were equally confident as public speakers; this might not be a problem in the moment, but might make the collection somewhat less useful as a point of reference.

I wonder, too, whether the value of such a video collection is diminished by the passing of time. Brendan Eich has given a more recent talk on the state of Javascript in the interim, and it’s unclear whether Content Security Policy, the subject of Ben Vinegar’s talk and a method of preventing XSS by restricting the domain of origin of a script, is still a live subject in 2014– much of the activity on the subject seems to have petered out in 2013, after a lot of activity in 2011 and 2012.

The advantage of such a conference (and such a video collection) is that it can give you insight into the way things work in the wild, in production environments, and in the leading companies in the world– insight into the way that leading figures in the field are currently thinking about a subject. This thinking can take a while to be codified in books and other instructional materials. As a casual JS user, I hesitate to say that I found the snapshot of the Javascript world from this 2013 conference to be essential viewing, but other viewers may get more from it.

Then again, one of the perks of attending a conference– and even watching the videos online– is serendipity: as an afterthought you attend a talk that turns out to be quite useful. I found many of the non-JS talks to be rather good. McKesson and and Wilson’s brief talk on “responsive publishing” and the O’Reilly Atlas project– the interface of books, ebooks, and web publishing– was actually really fascinating; Kalin’s talk on licensing was too brief, but interesting and informative; and Verou’s discussion of web standards was illuminating.  Similarly, Bootstrap isn’t something that’s been on my radar, but I was glad to have an extended introduction in Jen Kramer’s tutorial.