Hiring is Only for Managers?

A friend of mine told me that he just met the new guy on their team. I thought it was odd that he was just meeting a new team member, so I asked if he wasn't around during the interviews, and he told me that the developers on the team never interview candidates - only managers do that. As near as I can tell, they do this to minimize the time required during interviewing. This is just wrong.

In the words of Manager Tools, "hiring is the most important job that a manager does" because, in part, failures pull down the whole team for months or years. And, team-fit is a crucial part of that interviewing process. All things being equal (which they never are), it's better to hire a technical 8 who has a 10 personality than it is to hire a technical 10 who was only an 8 (or less) personality. If nothing else, you can teach technical stuff, but you can't teach personality.

Dave Ramsey describes his lengthy, multi-round interview process that even includes dinner with spouses to ensure team (in the largest sense) fit. As lengthy as the process is, he points out that fixing a hiring mistake costs much more than the added time of proper interviews.

I'd even argue that this manager-only interviewing process produces shortcoming in the technical area, too, because the manager works off of a superficial checklist that s/he has to get through quickly in the interview. Thus, if a candidate is asked "do you know web framework X," and the answer is "no, but I know frameworks A through F, and I wrote a framework I call G," that candidate is treated the same as someone straight out of school who doesn't know any frameworks. This narrow-mindedness leads to hires that know framework X, but they store passwords as plain-text because no one told them not to, and none of them knows how to use MD5 to store a password (another story from my friend). These are what Erik Sink calls programmers not developers - you want (well-rounded) developers.

So, with apologies to Georges Clemenceau, interviewing is too important to be left exclusively to the managers.

JIRA Workflow Transition Displaying Wrong Text

I've been doing some JIRA administration and customization for a client, and I ran into a problem that was driving me crazy. I created a new workflow to deal with an Issue Type called Change Request by copying an exsiting workflow. I renamed one of the transitions from "Close Issue" to "Decline CR," and I associated a screen with the transition (the reason for creating a new workflow).

The name of the transition ("Decline CR") displayed correctly in the administration page, but in the regular display page of a Change Request issue, the name of the workflow action was still the old value ("Close Issue") from the original workflow. I tried a few things to fix it, but nothing seemed to help. I even tried changing the workflow scheme and changing it back. Still nothing.

This morning while fishing around in the administration pages, I found the problem. The transition included an internationalization property, jira.i18n.title, that specifies what appears to be the title of the workflow action, closeissue.title. I picked up that property when I cloned the workflow - the ultimate origin of the workflow was the JIRA's default workflow, which was internationalized. Removing the property got the workflow action name ("Decline CR") to display correctly. (I'm not working in a multi-language environment, so I don't need any localization.)

World's Ugliest URLs

I live outside the city of Monmouth, Oregon (beneath the Western Skies, of course). Our city's official website has URLs like:
http://www.ci.monmouth.or.us/index.asp?Type=B_BASIC&SEC={F6D36CB4-8AB1-4E2F-9F16-EEB14A3A83DD} - Things to See & Do
http://www.ci.monmouth.or.us/index.asp?Type=B_BASIC&SEC={6010A930-F666-42AF-A359-971AC53933A1} - City Government

OK, maybe they're not the ugliest in the world, but those bad boys have gotta rank way up there. Anyway, when I first heard Jacob Kaplan-Moss talk about pretty URLs in Django, I thought some of criticisms were a little nit-picky. Initially, I didn't see anything wrong with index.php, but I could see the basic point even before seeing Monmouth's URLs. When I converted the Evergreen Terrace Farms site from PHP to Django, cleaning up the URLs was something I was pleased with. For example, www.et-farms.com/animals/detail.php?name=bart became www.etfarms.com/animals/bart. So, I guess I have drunk the Kool-Aide, and I have become a bit of a URL snob.

Regardless of how picky you are about URLs, I think any sane person would agree that those URLs for the Monmouth site are just crazy. Just imagine trying to read one of those to your mom over the phone - "no, it's 42AF, and the A and the F are capitalized."

In my opinion, the saddest thing is that the site is a commercial product created by a company that boasts about how many governments they've sold it to. It would be one thing if some students created something like that for a senior project, but when you're charging people money for something like that you should at least not expose the ugliest of the ugly Microsoft crap from the depths of the implementation (I assume those are UUIDs generated by .Net). I guess I'm also disappointed that no one in the city even noticed those URLs before putting out taxpayer money.

Charles.

Presenting an Updated Version of OSS Jobs Talk

I'm giving an updated version of "How to Get a Software Job w/o Experience" at Willamette University tomorrow, 9/24/09. It's a fun talk that I enjoy doing. I updated the SlideShare version, rather than uploading a new version, so the old version is publicly unavailable.

How to Get a Software Job w/o Experience

View more documents from Charles Anderson.

Mercurial for the Homeless

Generally, I'm not one to talk about crazy dreams. You know those ones right before you wake up that seem like a Salvador Dali painting? Anyway, I had one the other day where either I was homeless living out of a car, or I was observing someone like that. Anyway, it dawned on me in the dream that Mercurial (or any DVCS) would be perfect for that situation because I figured that the homeless person would only have intermittent network connectivity, but he still needed to get work done.
OK, maybe the part about someone living out of their car "needing" to get coding done is a bit crazy, but I already admitted that it was a weird dream. I suppose jet-setting open-source gurus might feel kinda homeless from time to time, and they do need to make use of their time on planes, so maybe it wasn't so crazy after all. And, when you get right down to it, the two use cases are more similar than different, and Mercurial and other DVCSs excel at it.
For the record, the rest of the dream was related to work I'm doing for a client converting from CVS to SVN without necessarily having shell access to the server machines. I thought of a zillion ways where I could do something trivially in Mercurial but SVN (without shell access) just kept kicking my butt. I just hope shell access comes through, so the dreams can cease.

Charles.

Problem with Hudson as a Windows Service

Setting up Hudson to run as a windows service is wicked easy. However, at a client we ran into a problem with the user that the service runs as. By default, the service runs as the Local Service (or maybe Local System) user. Also, by default Hudson runs out of the .hudson directory under the user's home directory (in Documents and Settings).

This ran fine until someone logged into the console. Hint number one that there was a problem was that Windows took forever to log the user in while there was a huge amount of disk activity. Then, suddenly Hudson reverted to its state from several weeks before - recently added users and builds were missing. Looking around I could see that many users had a .hudson directory (as well as Maven .m2 directories), which made no sense - only the Local Service user was running Hudson.

As near as I could tell, logging in on the console was somehow changing the value of the Local Service user's home directory. And for some reason, Windows thought everyone should have a .hudson directory. (Thus the long time to login - Windows was copying the Hudson directory to the new user.)

Anyway, the solution was to create a real directory for Hudson - C:\Hudson, and to point Hudson at that by setting the HUDSON_HOME environment variable. To make this as easy as possible, I just set it via the Control Panel as a system-wide environment variable. I filled the directory with the contents of the .hudson directory in my home, as it seemed to have most/all of the recent users and jobs.

Also, while fixing all of this up, I created a limited (non-administrator) user to run the service. This is just good security that was skipped when Hudson was initially set-up (by someone else) as a quick proof-of-concept prototype.

enjoy,
Charles.

Book: The Principles of Successful Freelancing

The Principles of Successful Freelancing by Miles Burke
ISBN 978-0-98004552-4-6

The Principles of Successful Freelancing is a comprehensive introduction (if that's not a contradiction of terms) to striking out on your own as a freelancer. This book is perfect for someone who is considering moving to freelancing or possibly for someone just starting out.

Mr. Burke covers all of the basic areas of starting and running a freelance business. He discusses how to set up your business and your office, how to sell your services, how to manage your money, and how to give good customer service, which is ultimately the most important aspect of a personal freelancing business. He also addresses how to balance work and life beyond work, which is hard in general and specifically hard in a one-man shop. He concludes with something I haven't seen in a "start you own business" book - where to go next. Do you want to remain as a one-man shop, do you want to grow into a "real" business, or do you just want to "retreat" to the old 9-to-5 job? I don't recall a book like this consider the option of going back to the grind.

Each chapter concludes with two "case studies" - Emily and Jacob. These two characters represent two very different people who might want to go into freelancing. The studies at the end of each chapter explain how these personality types might react to the issues and challenges discussed in the chapter. This device helps the reader envision how he or she might deal with the issues discussed.

Early on, I got the mistaken impression that this book was a bit fluffy. The typography has a fair amount of white space, and it looks kinda arty rather than serious and dense. (OK, I grew up with punched cards and line printers. When's Matlock on?) But, by the time I finished the book, as I looked back across it, I really couldn't think of anything that wasn't covered. Sure, there are whole MBAs built around marketing, and this book only has one chapter on it, but the Mr. Burke provides a perfectly reasonable introduction to the subject. I think I got this "fluffy" mis-impression because immediately prior to reading Successful Freelancing I read Eric Sink's The Business of Software, which is very detailed about a few aspects specifically related to running a small software business. Successful Freelancing covers a wider range of topics, and it is not aimed specifically at software freelancers. If anything, it's aimed more at web designers who probably like nicer typography.

To conclude, The Principles of Successful Freelancing is a great first introduction to the idea of freelancing. It covers all the bases to help someone evaluate whether or not to go into business for himself.

enjoy,
Charles.

Choosing Java Versions on Mac OS X

While debugging another manifestation of the "wrong library for groovy webtest" bug recently, I found an email thread that makes reference the java_home command (sadly, I can't find an online manual page to link to) to cleanly select a specific version of the JVM under OS X. Here I thought manually pawing through /System/Library/Frameworks to look for versions to set JAVA_HOME to was the "right" way to do it. Learn something new every day.

enjoy,
Charles.

Dealing with DreamHost Server Migration

DreamHost sent me an email telling me that my account had been moved to another server. OK, fine - "what's that mean to me, Al Franken?" They said that it shouldn't affect most sites, but that you'd have to look out for paths in your applications that look like "/home/.something/username".
So, when when on my clients emailed me to say that his WordPress site was giving him an error message that read:

Unable to create directory /home/.spuds/user/domain.com/wp-content/uploads/2009/07. Is its parent directory writable by the server?

I knew that I had been bitten by this error. OK, how to fix it? I grep'ed the WP PHP files, but couldn't find a path like that. So where was it coming from?

On a hunch, I decided to look at the wp_options table in the WP database and found a row called upload_path, and sure enough, it contained the offending directory. I just removed the ".spuds" portion of the path, as per DH's directions, and it all worked.

So, if you're on DreamHost, and they moved your WordPress blog, and it suddenly stopped working with that error message, try looking through wp_options in your databse. (FYI, DH puts a random string between the wp and the options to prevent collisions with other users in the same database.)

enjoy,
Charles.

Aliens have taken control of my PowerPoint!

I just cut-and-pasted some text from a PDF into PowerPoint, and this is how it rendered:



The aliens are the bullet points from the source PDF. WTF?