Writing my own podcatcher

Since I started moving off of Mac OS X, I’ve been looking for a replacement for iTunes for downloading my podcasts. I wanted something that would run on Linux, and either be fairly configurable or hackable.

gPodder probably came closest to providing the same basic function as iTunes for downloading, but it’s not very configurable.

Also, I don’t really want yet another program that I have to keep open all the time on my Linux desktop. I’d rather a command-line tool I can run from cron. Armangil’s podcatcher looked pretty good, except it’s in Ruby. Nothing wrong with that, I suppose, but not something I have any experience with.

Last night I came across Bashpodder. This is a podcatcher in about 20 lines of bash, only calling out to a few other command-line tools. Whoa. I had no idea it was so simple!

I briefly considered hacking on Bashpodder, but quickly decided instead to write my own in Python, because I’m much more productive in Python, and besides, it’s more fun.

So, last night, starting from scratch, I wrote a podcatcher that can download the most recent podcasts from each of my podcasts if they haven’t been downloaded before. It checks ETag and/or Last-modified to skip needless work if the feed hasn’t changed. It constructs the download filename using the feed title, episode title, and publish date.

Of course, I had a little help :-)  As usual when working in Python, people have come before me and written awesome libraries to do the heavy lifting.  In this case, feedparser and requests.

At this point it’s functional, but not anything I’d want to make public. It has no doc (not even a README), no tests, and the list of podcasts is embedded in the code. But as a proof of concept – success!

Helicon 1932

Lane Motor Museum

While I was visiting my folks in Nashville last week, I took a trip to the Lane Motor Museum.  This is a car museum, specializing in European cars, many of which I’d never heard of.

Helicon 1932They’ve got some really weird ones. This Helicron works just like it looks like it would – pulled along by the propeller.  (Not surprisingly, never produced commercially.)




King Midget RoadsterI found some other cars more interesting, though, especially the really tiny ones. Like this one cylinder King Midget Roadster – doors optional!






Peel P50Some of them, though, seemed to me to go a bit too far, like this Peel P50 – like all their three-wheeled cars, it doesn’t even look stable to me! Yikes.





You can see lots more pictures at their web site, and do check it out if you’re ever in Nashville.


IBM and forced ranking

I left my job at IBM more than two years ago. Years before that, I had concluded that those running IBM no longer valued the employees. When I started, the company was proud to steer their relationship with their employees by the phrase “respect for the individual”.  Not coincidentally, I haven’t heard that phrase around IBM in a long time. That wasn’t the only reason I left, but it was definitely a major factor in why I was no longer happy working there.

One of the things that led me to that conclusion was the process used for the annual performance reviews.

Rather than evaluating whether an employee performs their assigned job well, the review process is to rank all the employees in an organization who are at the same level, and then assign their grade on a bell curve. There are quotas for each grade within an organization. The executives will deny that all day long, but I’ve talked to managers involved in the process who confirm that as practiced, the process can only end up with that effect.

This isn’t unique to IBM, by the way. Wikipedia calls this the Vitality Curve method. Jack Welch was credited with popularizing it when CEO of GE.  ”Forced ranking” seems to be the more common name for it, and I think a more accurate one.

There are lots of criticisms of this method. Here’s how I viewed it from the employee’s side, and how it made me feel.

While IBM’s implementation of forced ranking didn’t automatically fire the bottom ranked employees each year, they were obviously the first ones considered when IBM wanted to reduce employees. So, in combination with IBM’s strategy of improving results by cutting expenses rather than improving revenues (about which I might write more later), the effect was similar.

At the beginning, this has the effect Welch claimed – the employees not contributing were removed.

But you can’t sustain this. After firing the bottom performers this year, who are you going to fire next year? Did you hire a new 10% of incompetent employees at the same time? So within a few years, you’ve trimmed the fat, and now you’re hacking off the company’s muscle.

This also points out my second problem with this method: people who are doing their jobs acceptably get graded as performing unacceptably. You might say, this just raises the bar so everyone is motivated to do their job better. That might work if there’s always room to do every job better, and the rankings are objective and fair, accurately reflecting how well employees do their jobs. Unfortunately, neither of those are the case.

How are the rankings actually determined? The managers get in a room together and argue about whose employees are going to get the good rankings in the organization. Okay, if you’re a lousy employee, you’ll certainly end up with a lousy ranking in this system, but you would in any system.

If you do your assigned job well, though, that really doesn’t help you much here. Two other, mostly unrelated things have the most influence: if you happen to work for a manager who is the strongest arguer in the room (and likes you), and/or if you happen to have done good things over the year that the other managers have heard about.

Who you work for is mostly a matter of chance. Sometimes you can seek out a transfer to a project with a good manager. Then, as likely as not, IBM will do a re-org the next week and your manager will be replaced with the worst manager in the organization, or you’ll be moved to that manager’s department. (Over my 19 years at IBM, I had more than 20 managers. Very few of those changes were due to my changing jobs.)

Your other route to a good ranking is visibility outside your own department. Some jobs naturally provide that, but many don’t. In that case, your most likely way to get visibility is involvement in crises. Now, if you do your job well, you shouldn’t have crises. A good programmer will write code that just works. Who gets pulled into crises? Those who have done a crappy job, resulting in their product breaking. If you’re one of those people who can make themselves look good in a crisis, even when they might have been the initial cause and had little to do with resolving it, guess what? You get noticed, you get the good ranking, and leave the mediocre ranking for the guy in the next cube who quietly does their job well every day.

One more thing about how IBM used this system: they dedicated the vast majority of their recognition and rewards to those who got the highest level rankings. And they weren’t quiet about it.

Bottom line: those who quietly do a good job get no recognition or respect, and even are at risk of losing their jobs when the next arbitrary cut is decreed.

On American Exceptionalism | Popehat

“Nearly two hundred and fifty years ago, revolutionaries said this:

“We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.–That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed . . . .

“That was the statement of an ideal — a goal — and our founding fathers swiftly went about falling short of it, as all of us routinely fall short of our best intentions.”

via On American Exceptionalism | Popehat.

Long trip in Miata

I just finished my first long trip in my Miata.

I’m glad I did it. I got to show off the car to my family, and my Dad really enjoyed being driven around town with the top down.

Still, 9 hours at a time in the Miata on the Interstate makes me think that taking the Prius next time would be SO much more comfortable. I think I’ll save the Miata for running around town from here on.

Update on ukulele strings

I solved my sopranino string problem more simply than I expected – I just put new strings on it. Regular soprano strings, Aquila. And it sounds great, with the typical ukulele GCEA tuning! That was a great relief to me. I had thought it needed special strings or a special tuning to sound good.