Blog Fiasco

January 20, 2015

The amateur weather website hype machine

Filed under: Musings,Weather — Tags: , , — bcotton @ 12:38 pm

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.

January 18, 2015

On Linus Torvalds and communities

Filed under: Linux,Musings — Tags: , , , , — bcotton @ 4:06 pm

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.

January 2, 2015

In defense of the bazaar

Filed under: Linux,Musings,Project Management — Tags: , , — bcotton @ 9:22 pm

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.

December 22, 2014

It is done!

Filed under: Musings — Tags: , , , — bcotton @ 2:32 pm

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

December 16, 2014

Calling people people. What’s in a name?

Filed under: Musings,Project Management — Tags: , , — bcotton @ 11:12 pm

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?

November 10, 2014

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.

October 9, 2014

The UX of a microwave

Filed under: Musings,Project Management — Tags: , — bcotton @ 8:34 pm

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.

September 7, 2014

FAQs are not the place to vent

Filed under: HPC/HTC,Musings,The Internet — Tags: — bcotton @ 2:42 pm

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.

August 28, 2014

Job requirements: often counterproductive

Filed under: Musings,Project Management — Tags: , , , — bcotton @ 7:53 pm

My friend Rikki Endsley shared an article from Quartz entitled “job requirements are mostly fiction and you should ignore them“. Based on how quickly my friends re-shared the post, it seems to have resonated with many people. The article is targeted at job applicants and the TL;DR is “apply for the job you want, even if you don’t think you’re qualified. Job postings are written to describe ideal candidates, even if they’re not realistic, and most hiring managers would gladly take someone who meets some of the requirements. When a characteristic is listed under “requirements” instead of “preferred”, potential applicants assume that they shouldn’t bother applying.

This isn’t true in all cases, of course. In some places, the requirements are well-written and the hiring manager doesn’t consider any applications that don’t meet the requirements. Other times, the initial evaluation is done by the human resources department and they apply the requirements strictly (as an anecdote, I know I’ve been rejected for more than one position because my degree was in the wrong field. This despite that I had experience in the position and the hiring manager asking HR for my resume specifically). In many cases, though, the “requirements” are a high bar. The Internet is full of (possibly apocryphal) stories of job postings wanting 7 years of experience in a 5 year old programming language.

Hiring managers aren’t addressed directly in the article, but there’s a lesson here for you: be careful when writing job requirements. Apart from scaring away people you might have otherwise ended up hiring (especially women, who are more likely to pass on jobs where they don’t meet all of the qualifications), you’re robbing yourself of a good way to weed out the truly unqualified. Especially when someone else is pre-screening applicants, I prefer to craft job postings as broadly as possible. I would much rather spend extra time reviewing applicants than miss out on someone who would have been a great hire. It’s a low-risk, high-reward decision.

It’s not cheap to hire people. Especially in small organizations, you don’t want to risk hiring someone who you’ll have to get rid of in six months. But turnover isn’t cheap, either. I haven’t studied this, but speaking from my own experience, I’m much more likely to leave a position when I feel like I’ve stopped growing. By hiring someone who is 80-90% of the way there instead of 100%, you buy yourself more time with this person, reducing turnover. Sure, you get less productivity initially, but allowing an employee to grow is a cheap way to keep them interested in their work.

Likewise, I don’t want to apply for a job where I could step in on day one and do everything. If I wanted a job that I could do easily, I’d still be in my first job. I bet I’d be really good at it by now, but my skills wouldn’t have expanded. As a friend-of-a-friend said “I don’t think I’ve ever applied for a job that I was qualified for.” If employers can write job requirements aspirationally, then potential applicants should be aspirational in job applications.

August 4, 2014

How I keep organized despite being an unorganized person

Filed under: Musings,Project Management — Tags: , , , , — bcotton @ 8:45 pm

I am not, by nature, a well-organized person. I’ve known people who are always on top of what they need to do and where things are. I can’t do that. And even though I generally do my best to make sure I meet my responsibilities on time, I’ve been known to let things languish too long by accident.

When my wife became pregnant with our second child, I was forced to adapt. Although the pregnancy ended with a healthy, full-term baby, it was a rough one for my dear wife. She was, much to her dismay, effectively confined to the couch for the better part of nine months (at least to the degree that one can remain stationary while parenting a two year old). This left me responsible for the bulk of the housework, in addition to working, grad school, and trying to be a husband and father.

Clearly, I needed to step up my organizational game. For a long time, I used TuDu to manage my todo list. It’s still, from a feature perspective, my favorite such tool, but the fact that mobile access required SSHing to my desktop was not the best user experience. I found Wunderlist and soon decided it was not only a great application, but also worth paying for.

Wunderlist soon became my crutch. Everything I had to do went into Wunderlist. With due dates, categories, and hashtag searches, I could easily see only what I needed to see. I knew the only way I would do things like clean the bathroom on a regular basis was if I had a gentle reminder, so I loaded up with recurring events. During a particularly hectic April (a major project at work had me working almost every night and weekend), I completely outsourced my days to Wunderlist. Whatever the list said, I did. I’m fortune that no one compromised my account,  because I’m not sure I would have paused to consider a “give me all your money” task.

Wunderlist, and more importantly my regular and dedicated use of it, has helped my organization tremendously. Gone are the days of accidentally forgetting to pay a bill because it wasn’t due at the same time as the rest (yes, yes, autopay. I only do that for bills that are semi-regular.) Despite being a one man show, the house is probably cleaner than it was with both of us able to contribute simply because things were regular and scheduled.

Another tool that I’ve fallen in love with, though I haven’t yet started making full use of is Trello. I was introduced to Trello at work. It’s what we use to track development work and large projects. I recently took my list of blog post it was out of Wunderlist and put them into Trello. Now I can have various posts in a variety of states and see at a glance where they are. I’ve introduced it to a community blog I contribute to and to a local free/open source software group I’m a part of.

Of course, I still use TaskJuggler for some things, but it’s not necessarily well-suited for managing my entire life. If I were to attempt to put all of my personal and work projects into a single TaskJuggler project, my computer might explode.

The downside to having everything I need to do mapped out for me is that it’s all so damn visible. When I get sick or tired (as of this writing, I’m a little bit of both), this wall of todo can be incredibly overwhelming. But I am disorganized and lazy by default,  so the fact that I have tools available to help me overcome these traits is generally a life-improver. Now if only there were an app that would clean my office for me…

Older Posts »

Powered by WordPress