Why I blog

I started this blog in January of 2008. Initially the posts were infrequent and poorly-written (as opposed to now when they are frequent and poorly-written). At the time I had a LiveJournal account that I regularly updated, but felt like I wanted to separate personal and technical content. Seven-plus years later, I haven’t logged into my LiveJournal account in years but Blog Fiasco is still going strong.

I was but a young sysadmin at the time, and this blog was an opportunity to share things I learned. Mostly for my own benefit, but I figured if it was new to me, maybe it would be new to someone else, too. As I started training our student technicians, I starting writing blog posts as a way to plan lessons for them. These days, the posts are less technical and more opinionated. That’s not really a change in me so much as a change in my focus.

In all of the years I’ve been writing this blog, I have made exactly zero dollars from it. That’s fine. Despite the half-hearted Amazon ads and the occasional affiliate link I toss in a post, I’m not here to make money (though I certainly wouldn’t object to it). Mostly I write for my own benefit. Occasionally, I hope that my bloggery will make me well-respected throughout the land. There’s still time for that.

It isn’t just that I enjoy writing. Every so often, a post will turn out to be really helpful to people. Less often, they will tell me that, and it makes me feel good. For example, back when GEMPAK was much more difficult to install than it is today, I spent several hours getting it to compile. I wrote a post, mostly so that when it came time to build it again, I’d already have the steps written down for me. Much to my surprise, people found it, and found it useful. In the comments, readers were even helping each other.

More recently, I finally got around to enabling site statistics. I was really surprised when I saw that another post from 2010 was still getting regular page views. I described how I hunted down and solved a problem with printing. As recently as 2014, people were still finding it useful enough to leave nice comments. Since I enabled site statistics, that page gets an average of six views a day. It doesn’t sound like much, but I’m generally getting 20 or so on days I don’t post, sot hat’s a sizeable contribution.

Another great thing about site stats is finding out that a quote has become very popular. One of my earliest posts used “reading is a basic tool in the living of a good life” as the title. I had never heard the quote before, but I wanted a title and I searched for quotes about reading. From May 14 through June 14 (the first month I had site stats on), the post got a total of 10 views. It’s had 33 more since then (and probably more than that by the time this post publishes). Either someone famous repeated the quote, or it’s being used in a freshman literature assignment.

I don’t always write here, either. I used to write for the local newspaper, basically as a public service. I’ve been a conference blogger for the LISA Conference for a few years, and have really enjoyed the experience. I would not have had the opportunity were it not for this blog. Lately I’ve also been contributing my company blog and to opensource.com. Now I just need to start monetizing all of these words. Maybe next year…

Kids these days

A while ago, I heard about a website called Class 120. The service is designed to allow parents, coaches, and the like to see when college students are going to class. It uses the student’s smartphone location and class schedule to determine if the student attended the class or not. When I first heard of this, I rolled my eyes. I suspect many others have a similar reaction.

But the more I think about it, the less objectionable it seems. Going off to college is often the first time a teenager has real independence. It’s unreasonable to expect them all to do well with no experience. A little bit of passive supervision might be just what it takes to turn a $20,000 waste of a year into something more immediately useful. Sure, it could be a crutch, but sometimes crutches are necessary.

Speaking for myself, something like this might have been really useful in 2001. My first year as an undergraduate was pretty lousy academically, in part because I missed a lot of class. I learned my lesson eventually, but at the cost of effectively a wasted year. People have various ways to motivate themselves, some intrinsic, some extrinsic. Who am I to judge?

Unlimited vacation policies, burnout, etc.

Recently, my company switched from a traditional vacation model to a minimum vacation model. If you’re unfamiliar with the term, it’s essentially the unlimited vacation model practiced by Netflix and others, with the additional requirement of taking a defined minimum of time off each year. It’s been a bit of an adjustment for me, since I’m used to the traditional model. Vacation was something to be carefully rationed (although at my previous employer, I tended to over-ration). Now it’s simply a matter of making sure my work is getting done and that there’s someone to cover for me when I’m out.

I’m writing this at 41,000 feet on my way to present at a conference [ed note: it is being published the day after it was written]. I’m secretly glad that the WiFi apparently does not work over the open ocean (I presume due to political/regulatory reasons). Now, don’t get me wrong, one of my favorite things to do when I fly is to watch myself on FlightAware, but in this case it’s a blessing to be disconnected. If a WiFi connection were available, it would be much harder to avoid checking my work email.

It took me a year and a half at my job before I convinced myself to turn off email sync after hours. Even though I rarely worked on emails that came in after hours, I felt like it was important that I know what was going on. After several weekends of work due to various projects, I’d had enough. The mental strain became too much. At first, I’d still manually check my mail a time of two, but now I don’t even do that much.

This is due in part to the fact that the main project that was keeping me busy has had most of the kinks worked out and is working pretty well. It also helps that there’s another vendor managing the operations, so I only get brought in when there’s an issue with software we support. Still, there are several customers where I’m the main point of contact, and the idea of being away for a week fills me with a sense of “oh god, what will I come back to on Monday?”

i’ve written before about burnout, but I thought it might be time to revisit the topic. When I wrote previously, I was outgrowing my first professional role. In the years since, burnout has taken a new form for me. Since I wrote the last post, two kids have come into my life. In addition, I’ve gone from a slow-paced academic environment to a small private sector company which claims several Fortune 100 companies as clients. Life is different now, and my perception of burnout has changed.

I don’t necessarily mind working long hours on interesting problems. There are still days when it’s hard to put my pencil down and go home (metaphorically, since I work from a spare bedroom in our house). But now that I have have kids, I’ve come to realize that when I used to feel burnt out, I was really feeling bored. Burnout is more represented by the impact on my family life.

I know I need to take time off, even if it’s just to sit around the house with my family. It’s just hard to do knowing that I’m the first — and sometimes last — line of support. But I’m adjusting (slowly), and I’m part of a great team, so that helps. Maybe one of these days, I’ll be able to check my email at the beginning of the work day without bracing myself.

Lessons and perspective from fast food

I started working in fast food when I turned 16 and needed to fund my habit of aimlessly driving around the backroads. I ended up spending five and a half years in the industry (the last few of which were only when I was home from college), advancing from a meat patty thermodynamic technician to crew trainer to floor supervisor. In the end, I was effectively a shift manager. I supervised the store’s training and safety programs.

It’s should be no surprise that I learned a lot about myself and about leadership during that time. Even a decade on, stories from my fast food days come up in job interviews and similar conversations. As a result of my time in fast food, I’ve learned to be very patient and forgiving with those who work in the service sector. I’ve also learned some lessons that are more generally applicable.

Problems are often not the fault of the person you’re talking to. This is a lesson for service customers more than service providers, but most providers are customers to. In fast food, when your order is wrong it’s sometimes the fault of the counter staff putting the wrong sandwich in the bag, but sometimes it’s the fault of the grill staff for making it wrong. In any case, it’s rarely the result of malice or even incompetence. People, especially overworked and under-engaged people, will make mistakes. This holds true for customer service staff at most companies, particularly large ones where the tier 1 staff are temps or outsourced. (That doesn’t imply that actual malice or incompetence should be acceptable.)

Sometimes the best way to deal with a  poor performer is to give them responsibility. One story I’m fond of telling involves a crew member who was, in many ways, the stereotypical teenage fast food worker. He was smart, but lazy, and didn’t much care for authority. The fact that I was only a year older than him made it particularly hard for me to give him orders. He’d been working for a few months and was good at it when he applied himself, so the trick was to get him to do that. After a little bit of fumbling around, I found the trick. I started spending more time away from the grill area and more time up front, and I made it clear that he was in charge of the grill. I gave him some autonomy, but I also held him accountable. Lo and behold, his behavior improved. He also started taking opportunities to teach new employees the tricks of the trade. He could have let the authority go to his head, but instead he acted like an adult because he was being treated like an adult.

Don’t nitpick behavior, but don’t put up with crap. The standing philosophy on my shifts was “don’t make life hard for me and I won’t make life hard for you.” I didn’t like bossing people around (in part because they were either old enough to be my grandmother or because they were 16 and all the bossing in the world wasn’t going to have any effect). If people were doing their jobs well, I put up with some good-natured shenanigans (the exceptions being food safety, physical safety, and customer satisfaction). One time a fellow supervisor had written up a crew member for a really trivial infraction. I went to her file later and tore it up. This person was a good worker and harping on her for minor issues was only going to drive her away. By the same token, I came in from taking the garbage out one night to find two normally good workers having a fight with the sink sprayer. They were both sent home right away (granted one of them was off in 10 minutes anyway).

Spread the unpleasant work around, and be willing to do some yourself. Some of the managers and supervisors liked to make the same people do the unpleasant tasks all the time. I hated that approach because it just seemed to reinforce bad behavior. The people who made my life unpleasant certainly came up in the rotation more often, but everyone had to clean restrooms, empty grease traps, etc. Including me. I didn’t try to make a show of it, but I wanted the people who I worked with to see that I wasn’t using my position to avoid doing things I didn’t want to do. And if I’m being completely honest, there was something I enjoyed about emptying the grease traps (except when I’d lose my grip and pour them into my shoe).

Don’t be a jerk. I won’t delude myself into thinking I was universally loved. I know I wasn’t, and I’m okay with that. But for the most part, I think I was pretty well-liked among the crew and management because I wasn’t a jerk. I took my job seriously (perhaps too seriously at times), but I was flexible enough to try to work with people the way they needed to be worked with. I tried to make work fun and cooperative, because working in fast food sucks and anything that can make it less sucky benefits workers and customers alike.


Being a good troubleshooter

Not too long ago, my friend Andy said “I think that’s how i convince so many people I’m decent at being a sysadmin, I just look at logs.” It was a statement that really struck a chord with me. On the one hand, I feel like I’ve had a pretty successful career so far, and if I haven’t been excellent, I’ve at least been sufficiently competent. On the other hand, I don’t feel like I have a lot of the experience that “everyone” has. I’ve never run email servers, I’ve only done trivial DNS and DHCP setups, and so on.

In my current job, I work with some really smart people, few of whom have much if any sysadmin experience. Andy and I, because of our sysadmin background, have become the go-to guys for sysadmin questions. It’s a role I enjoy, particularly when I’m able to solve a problem. Sometimes it’s because I have direct experience with the issue, but more often than not, it’s because I know how to poke around until I find the answer.

There are many skills required for successful systems administration. Troubleshooting is high on the list. The ability to troubleshoot new and unusual problems is particularly helpful. I’ve found my own troubleshooting abilities to depend on the ability to build off of previous (if unrelated) experience and being able to piece together disjointed clues. It’s sort of like being a detective and also a human “big data” system.

Fishing for clues in log files is great, too, if you can find the needle in the haystack. But what seems to separate the good troubleshooters from the bad that I’ve known is intellectual curiosity. Not just asking what happened, but finding out why. Being willing to ask questions and learn about unfamiliar areas instead of immediately deferring to those more knowledgeable builds a strong skill base.

Of course, without Google, we’d all be out of luck.

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.