Self-promotion is hard

I’ve never really written this blog with the intent of gaining a massive audience. Mostly, I don’t even notice if people read it or not. As much as anything, I write it as a way to document things for my own purpose or to express opinions that could never fit in a tweet. This is made plainly obvious by the fact that I almost never promote my posts. It’s fairly rare anymore that I even share them on my own social media feeds. I certainly don’t submit them to sites like Reddit.

This is partly because it feels like blog spam, and partly because I generally don’t think very highly of the posts I write. It’s way more rewarding when someone else sees a post and says “hey, that’s worth sharing.” Like my post about the PR blunder made by the elementary team. My friend Andy thought it was well-written and submitted it to /r/Linux. A little while later, it was at the top of that subreddit. Holy crap, I’m a real thought leader now!

A screen capture showing one of my posts at the top of the Linux subreddit.

Blog Fiasco at the top of /r/Linux

As of this writing, Andy has gained 622 link karma from the post. Karma that could have been mine, but I couldn’t bring myself to post my own blog. (Of course, I pretty rarely submit links anyway. My second-most karmatic submit is a Blog Fiasco post from three years ago. That’s the last time I self-submitted.)

Sometimes I think this pseudo-humility holds me back. I could probably gain more recognition in the field and achieve my dream of being a preeminent thought leader if I would just be more willing to force my writing on people. But that seems like a jerk move. So for the time being, I’ll just sit here and write in relative obscurity. If I get noticed and made into a star, that’s great. If not, well at least I’ll always have post 1652.

The death of the adult snow day

Jesse Singal had a well-circulated article last week about the death of the adult snow day. As I write this post on a snowy Sunday afternoon, I can’t help but think he really nails it. Some of the commenters on the article focus on the snow day itself. In particular, “joy2b” wrote:

Playing in the snow is fun, but there’s really no need to spend all day doing it.  It should be possible to find a couple of opportunities to go out and play during a snow day.  If it isn’t, your typical work day is probably optimistically over-scheduled.

Isn’t that the point of the article, though? At least, that’s the message I took away. A little over a year and a half ago, I took a job where I was able to work from home on a daily basis. On the balance, it’s been good. I can eat lunch with my wife. I can do quick chores during the day. I can sit on the couch and keep an eye on my three year old daughter while my wife sleeps in. There are downsides, though. My family doesn’t always know when it’s okay to interrupt me and when it isn’t. Temper tantrums and crying babies sometimes carry on the phone. Worst of all, the line between working and not working has blurred.

This isn’t entirely due to working from home. I had a similar problem in previous jobs because work email didn’t stop arriving at closing time. In the past few months, I’ve begun disabling the sync on my phone outside of working hours. I’ve finally reached the point where I don’t end up manually checking it anyway. That has helped me immensely, but the line can still be a little blurry.

I never expected to say this, but there are times I miss my commute. Having a distinct time between work and home allowed me to shift gears and take a little bit of time to read a book or watch a few minutes of Netflix, or whatever. Now I go directly from work to home with no chance to make a smooth transition.

But back to the subject of snow days. When I worked at Purdue, snow days were pretty rare. After a particularly heavy snow storm in 2007, the university closed for a day and a half. I lived in an apartment then, so I didn’t have to worry about shoveling snow. My wife and I spent the time watching movies and having snowball fights with the upstairs neighbors. It was fun. Last winter, the university close again. This time, my former colleagues were expected to work from home. I don’t know that the University was any more productive than it would have been if the IT staff had been able to take the day off, but at least people weren’t getting paid to do nothing. Maybe that’s the reason the snow day is dying. But maybe that mindset is part of the problem.

The amateur weather website hype machine

Word on the street is that a certain amateur meteorology site is starting to tease about a large snowfall event a week or so out. It must be winter again!

I don’t begrudge amateur meteorology sites in general. In the Internet age, there’s a lot that you can teach yourself and plenty of access to raw model data from which to build a forecast. As in most fields, the passionate amateur can be more skillful than the trained professional. Of course, this is generally limited to a specific skill, which is why the better amateur weather sites tend do focus on a particular thing.

Focusing on hyping winter weather events a week or more out is not an area that should be focused on. This is particularly true when the hype is completely unjustified meteorologocially and ends up requiring professional meteorologists in the National Weather Service and local media to spend time telling the public not to believe the “information” that should never have been shared in the first place.

Forecasting the weather is hard. Effectively communicating the uncertainty inherent to that forecast to the public is even harder (and not done nearly enough). Posting an outlier scenario to Facebook is easy. Any site that provides forecasts for public consumption and (somehow) finds a way to get partnerships with legitimate media outlets needs to eschew the easy. Otherwise, it’s simply self-service and not public service.

On Linus Torvalds and communities

This week, the Internet was ablaze with reactions to comments made by Linus Torvalds at Linux.conf.au. Unsurprisingly, Torvalds defended the tone he employs on the Linux kernel mailing list, where he holds no punches. “I’m not a nice person, and I don’t care about you. I care about the technology and the kernel—that’s what’s important to me,” he said (as reported by Ars Technica). He later said “all that [diversity] stuff is just details and not really important.”

The reactions were mixed. Some were upset at the fact that an influential figure like Torvalds didn’t take the opportunity to address what they see as a major issue in the Linux community. Others dismissed those who were upset by pointing to the technical quality of Linux, cultural differences, etc.

I don’t subscribe to the LKML, so most of the posts I’ve seen are generally when someone is trying to point out a specific event (whether a behavior or a technical discussion), and I don’t claim to have a good sense for what that particular mailing list is like. Torvalds and the Linux community have developed a great technical product, but the community needs work.

Speaking to open source communities in general, too many people use the impersonal nature of email to mistake rudeness for directness. Direct and honest technical criticisms are a vital part of any collaborative development. Insults and viciousness are not. Some people thrive in (or at least tolerate) those kinds of environments, but they are incredibly off-putting to everyone else, particularly newcomers.

Open source communities, like any community, need to be welcoming to new members. This allows for the infusion of new ideas and new perspectives: some of which will be obnoxiously naive, some of which will be positively transformative. The naive posts of newcomers can be taxing when you’ve seen the same thing hundreds of times, but everyone has to learn somewhere. The solution is to have a team armed with pre-written responses in order to prevent frustrated emails.

Not being a jerk doesn’t just mean tolerating noobs, though. Communities should have an established code of conduct which addresses both annoying and mean actors. When the code of contact is being repeatedly breached, the violator needs to be nudged in the right direction. When a community is welcoming and actively works to remain that way, it thrives. That’s how it can get the diversity of ideas and grow the technical competency that Linus Torvalds so desires.

In defense of the bazaar

Earlier this week, I came across a 2012 article from Poul-Henning Kamp entitled “A generation lost in the bazaar“. This is a reference to Eric S. Raymond’s seminal The Cathedral and the Bazaar, which advocates for making the sausage, so to speak, in public. Using the Linux kernel and his own fetchmail program as examples, Raymond emphasizes the benefits of rapid, iterative development and of fostering a user community that acts as co-developers. This stands in contrast to the “cathedral” style of development where a product is worked on by a small number of people until it is ready to be revealed to the public.

Kamp’s point (and subtitle) is “quality happens only when someone is responsible for it,” which I endorse wholeheartedly. However, he is mistaken to blame Raymond’s bazaar for “a clueless generation of IT ‘professionals’ who wouldn’t recognize sound IT architecture if you hit them over the head with it.” What he observes is the democratization of programming, which is due to ever-cheaper hardware, free (as in beer) software, and the Internet. Had The Cathedral and the Bazaar never been written I doubt the world would look dramatically different, at least in this respect.

IT is in its awkward teenage years. It has been around long enough that it can do pretty cool things, but not so long that it has accumulated much wisdom. The fact that anyone can write software (or copypasta snippets from various example sites and fora) and make it available to others is simultaneously a wonderful and terrible thing. Nonetheless, that doesn’t make the bazaar style wrong.

Kamp described the end result of the bazaar as “a pile of old festering hacks,” and I’ll agree that its an apt description for a lot of software. It’s probably just as apt for a lot of software developed in the cathedral style. Raymond devotes a fair portion of his book to quality and good design, and it’s unfair to blame him for people not following that part (assuming they’re even aware of his work at all).

Raymond makes many unsubstantiated claims that the bazaar style of development leads to higher-quality software. That may or may not be the case. My own view is that the bazaar style is well-suited for open source projects. After all, open source is about more than code.

It is done!

About four and a half years ago, I decided to apply to graduate school. Though I had sworn I was done with school when I completed my bachelor’s degree in 2006, the idea of a master’s degree began to seem reasonable. With Purdue’s staff discount and my department’s forgivable loan scholarship, I could pay roughly a quarter of the “retail” price. In January of 2011, I began my coursework.

Since then, my wife and I have welcomed two children into the world. I have changed jobs twice, the second time leaving the university for a much more stressful and time-consuming role at a small company. For four years, I tried to balance my family, my academics, my employment, open source contributions, and (on rare occasion) my own mental and physical health.

It is the hardest thing I have done in my life, and although there is evidence to suggest that I performed well, I never felt like the balance was right. At least one area always got less than it deserved. Sadly, myself and my family were most often on the short end.

Nonetheless, my family remained unwaveringly supportive, even when I was basically non-existent for weeks at a time. My colleagues never complained (to me, at least) about my absences during odd hours of the work day. My professors praised my work, particularly the thesis which I defended in November (more on that in a later post). My Fedora contributions became effectively non-existent, but nobody seems to begrudge me for that, and I look forward to being able to contribute again.

I did not, and could not have, accomplished this on my own. I took great pleasure in having my family in attendance yesterday as I participated in a long-awaited commencement ceremony. For everyone else who provided support and encouragement along the way, no matter to what degree, I offer my most sincere thanks. We did it!

image

Calling people people. What’s in a name?

My IT service management professor once told the class “there are only two professions who have users: IT and drug dealers.” It’s interesting how the term “user” has become so prevalent in technology, but nowhere else. Certainly the term “customer” is better for a series organization (be it an internal IT group or a company providing technology services). “Customer” sounds better, and it emphasizes whose needs are to be met.

For a free Internet service, though, it’s not necessarily an apt term, if for no other reason than the rule of “if you’re not paying for it, you’re the product.” That’s why I find Facebook’s recent decision to call their users “people” interesting.

Sure, it’s easy to dismiss this as a PR move calculated to make people feel more comfortable with a company that makes a living off of the personal information of others. I don’t doubt that there is a marketing component to this, but that doesn’t make the decision meritless. Words mean things, and chosen the right word can help frame employees mindsets, both consciously and subconsciously.

In Fedora, contributors have been actively discussing names, both of the collected software (“products” versus alternatives) and the people involved (“contributors”, “developers”, “users”). Understanding what the general perception of these terms are is a critical part of selecting the right one (particularly when the chosen term has to be translated into many other languages). A clear definition of the people terms is a necessary foundation of trying to understand the needs and expectations of that group.

“People” may be too broad of a term, but it’s nice to see a major company forego the word “user”. Perhaps others will follow suit. Of course, “user” is just such a handy term that it’s hard to find a suitably generic replacement. Maybe that’s why it sticks around?

Open source is about more than code

The idea of open source developed in a closed manner is hardly new. The first real discussion of it came, as best as I can tell, in Eric S. Raymond’s The Cathedral and the Bazaar. A culture of open discussion and decision making is still a conscious act for projects. It’s not always pretty: consensus decision making is frustrating and some media outlets jump on every mailing list suggestion as the final word on a project’s direction. Still, it’s important for a project to make a decision about openness one way or the other.

Bradley Kuhn recently announced the copyleft.org project, which seeks to “create and disseminate useful information, tutorial material, and new policy ideas regarding all forms of copyleft licensing.” In the first substantive post on the mailing list, Richard Fontana suggested the adoption of the “Harvey Birdman Rule,” which has been used in his copyleft-next project. The limited response has been mostly favorable, though some have questioned its utility given that to date the work is almost entirely Kuhn’s. One IRC user said the rule “seems to apply only to discussions, not decisions. The former are cheap and plentiful, but the latter actually matter.”

I argue that the discussions, while cheap and plentiful, do matter. If all of the meaningful discussion happens in private, those who are not privy to the discussion will have a hard time participating in the decision-making process. For some projects, that may be okay. A ruling cadre makes the decisions and other contributors can follow along or not. But I see open source as being more than just meeting the OSI’s definition (or the FSF’s definition of free software for that matter). Open source is about the democratization of computing, and that means putting the sausage-making on public display.

The UX of a microwave

I’m not a UX expert except in the sense that I have experience using things. Still, I spend a lot of time at work serving as a proxy for users in design discussions. It’s hard to get UX right, even on relatively simple experiences like a microwave oven.

Years ago, my systems analysis professor got on a tangent about user interactions. He pointed out that it can be faster to enter a minute on a microwave as 60 seconds instead of one minute, that 111 seconds is faster to enter than 110. Design choices (including the design of instructions and documentation) that seem obviously correct are sometimes incorrect for non-obvious reasons.

It took a little while, but I eventually discovered that the “Quick Set” menu doesn’t have pre-programmed settings, it just adds a zero to whatever code is entered. So the quick set to cook two slices of bacon (20) simply sets the time to 2:00. In that sense, it functions less as a shortcut and more as a list of cook times.

On a whim today, I tried to warm a cup of coffee by using a quick set code of 6 instead of 10. It didn’t work. Apparently the microwave requires quick set codes to be exactly two digits. For a one-minute cook time, the quick set is hardly any quicker than a manual entry.
My microwave came with the house, so while I don’t know exactly how old it is, I know it’s at least seven years old. Maybe recent microwaves have a more sensible UI. Or maybe it’s a problem that will never quite be solved.

FAQs are not the place to vent

I’ve spent a lot of my professional life explaining technical concepts to not-necessarily-very-technical people. Most of the time (but sadly not all of it), it’s because the person doesn’t need to fully understand the technology, they just need to know enough to effectively do their job. I understand how frustrating it can be to answer what seems like an obvious question, and how the frustration compounds when the question is repeated. That’s why we maintain FAQ pages, so we can give a consistently friendly answer to a question.

You can imagine my dismay when my friend Andy shared an FAQ entry he found recently. A quantum chemistry application’s FAQ page includes this question: “How do I choose the number of processors/How do I setup my parallel calculation?” It’s a very reasonable question to ask. Unfortunately, the site answers it thusly: “By asking this question, you demonstrate your lack of basic understanding of how parallel machines work and how parallelism is implemented in Quantum ESPRESSO. Please go back to the previous point.”

The previous question is similar and has an answer of of “See Section 3 of the User Guide for an introduction to how parallelism is implemented in Quantum ESPRESSO”. Now that’s a pretty good answer. Depending on the depth of information in Section 3, it might be possible to answer the question directly on the FAQ page with an excerpt, but at least pointing the visitor to the information is a good step.

I don’t understand getting frustrated with a repeated FAQ. If the answers are so similar, copy and paste them. Or combine the questions. FAQs, user guides, and the like are great because you can compose them in a detached manner and edit them to make sure they’re correct, approachable, and not jerkish. FAQs are an opportunity to prevent frustration, not to express it.