Well, I take it back. I want to remember your name, and I’m terrible at names. So it helps if I have your name in front of me.
Dead-Tree Resume
“But,” you ask, “How will you know if the candidate has the skills and experience you need?”
Good question. Let’s look at the purpose of an interview.
The Two Questions
An interview must answer two questions:
Can the candidate do the job now and in the future?
Will the candidate be a good fit for the team?
Neither of these questions are answered by the candidate’s resume.
Wait a minute
Unless the candidate worked for a company doing the exact work, for the exact clients you have, their experience will not tell you if they can do the current job at your company.
Put it this way: would it make sense to compare your company to another in a different industry, with different customers and a different product, and then make a judgement about performance based upon that comparison?
Company
Industry
# Customers
# Employees
Product
MyCorp
Pharmaceutical
3
7
Blue Pills
Acme, Inc
Energy
150
70
Batteries
Initech
Accounting Software
3,200
1,500
TPS Reports
We will investigate the 2 questions in a future post.
Well, I take it back. I want to remember your name, and I’m terrible at names. So it helps if I have your name in front of me.
Dead-Tree Resume
“But,” you ask, “How will you know if the candidate has the skills and experience you need?”
Good question. Let’s look at the purpose of an interview.
The Two Questions
An interview must answer two questions:
Can the candidate do the job now and in the future?
Will the candidate be a good fit for the team?
Neither of these questions are answered by the candidate’s resume.
Wait a minute
Unless the candidate worked for a company doing the exact work, for the exact clients you have, their experience will not tell you if they can do the current job at your company.
Put it this way: would it make sense to compare your company to another in a different industry, with different customers and a different product, and then make a judgement about performance based upon that comparison?
Company
Industry
# Customers
# Employees
Product
MyCorp
Pharmaceutical
3
7
Blue Pills
Acme, Inc
Energy
150
70
Batteries
Initech
Accounting Software
3,200
1,500
TPS Reports
We will investigate the 2 questions in a future post.
In other words, the script was not developed defensively. This makes sense: it was just a bang-out.
The script had no inline documentation†, and if a favicon file that already existed in the current directory would be silently overwritten—not good.
I’m clumsy: I delete and overwrite files all the time, so I could use a little help. Maybe I can tidy up the script?
Ensure command-line parameter
Whenever your script requires a command-line parameter, display a help if it is not provided or is the wrong type. Why? Because in 6 months you will forget how to use it.
if [[ -z "$1" ]]; then
echo -e "\nUsage:\n\t$0 image.png\n\n\tWhere 'image.png' is ..."
exit 0
fi
Easy! The -z means “if empty”. And $1 contains the first parameter. When we display the error message, we use $0, which contains the script’s filename and path. So if I run my script like this “/foo/bar/somescript”, that is what $0 will display.
Ensure Source Image Exists
# Check to is if source file exists
if [[ ! -e $1 ]]; then
echo -e "\nFile '$1' not found."
exit 0
fi
I added the comment because I can never remember what “-e” means. When scanning the source, I can quickly tell what this section does without reading much further into the code.
Ask the user before overwriting
# Warn if favicon.ico already exists in current directory
if [[ -e favicon.ico ]]; then
echo -e "Warning:\n\tfavicon.ico exists in current directory."
choice "Overwrite? [y/N]: "
if [ "$CHOICE" = "y" ]; then
echo "Overwriting favicon.ico"
rm favicon.ico
else
echo "Exiting"
exit 0
fi
fi
Another defensive-coding best-practice. Before doing anything destructive that isn’t the primary purpose of the script, let the user decide if they want to proceed. By “primary purpose” I mean that the only reason someone would run the script was to destroy something.
What’s worse is destroying something silently, which is why I let the user know when we overwrite favicon. Keeping the user informed needs to be balanced with flooding the user with too many messages.
Note that the “choice” statement above isn’t a build-in command, but a very handy one I got from O’Reilly’s “bash Cookbook”.
Is Imagemagick installed?
Actually, I don’t care because I use it so much that I always install it on whatever system I’m using. An approach I might take would be
type mogrify
And compare the result. †A good discussion of self-documenting code vs. inline documentation may be found in chapter 11 of: McConnell, Steve (2004). Code Complete (2nd ed.). Pearson Education. ISBN 9780735636972.
Debugging a php script with emacs in geben mode. (Photo credit: Wikipedia)
I was recently testing some wordpress plugin code for an upgrade. As part of my testing, I turn on debugging to see if any errors or warnings show up.
Imagine my surprise when several errors appeared, many of them deprecation warnings. After troubleshooting to determine the source of the errors, I discovered it was coming from the theme I was using.
Without turning on debugging, the site appears to behave normally, which is problematic. One of my objections to many languages and frameworks is that they hide problems from the developer. In many cases, for example, deprecation warnings don’t mean much—except they’re a ticking time bomb. At some point in the future, the code is going to break. Better to fix it now while it is easier to do, than scramble to diagnose and fix lots of code just after an upgrade.
In the case of WordPress (or PHP in general), it would be helpful if the admin area showed everything – bugs and warnings. For novice admins, of course, this would be a support nightmare, as they would have little clue what was going on. The upside is (hopefully) sloppy coders would fix their stuff promptly. Nothing will get a plugin/theme pulled faster than getting an error right after installing it.
CRUD: Create, Read, Update, Delete; actions for managing data usually stored in a database.
Data model (credit: Wikipedia)
A system I maintain has a very unusual quirk: when adding a new element (“blub”) to a list of elements (“blubs”), the system crashes with a generic error.
What this tells me is there is an unmet dependency, probably a join to another database table. I suspect the original developer (OD) created all the blubs manually, then later added in CRUD screens to manage them. For some reason OD never tested creating a new blub.
For any list of things, unless they are constants that will never be CRUDded (okay, reading is okay), the app should be able to Create/Update/Delete them without any manual steps.
Why? Because someday, some schlub who maintains your code is going to have to CRUD. And they will be screwed.
I recall a conversation I had with a coworker years ago. This fellow mentioned he thought differences between languages (e.g., Perl and PHP) were simple syntax.
example of Python language (Photo credit: Wikipedia)
This is true, sort of. The nuts and bolts for each language (displaying a variable’s value and the like) are same in concept and similar in construct.
<?php =someVar ?>
or
<% puts someVar %>
You get the idea.
The difference (and where the coworker was wrong), is the concept of how the data flows through the system and which pattern(s) are encouraged/discouraged.
Some languages encourage MVC, whereas others encourage spaghetti and still others encourage a hybrid (or something else entirely, like modules).
What is a language best at?
Going beyond this, what is the language best at doing? Is it installed in places you want to host your code? Do you have data structures/stores that fit better with one language than another?
Picking the best tool for the job is important in delivering a quality product. Choosing which language to use isn’t trivial and can make it easier—or harder—to deliver the solution.
Goals differ from intentions or ideas in several key aspects.
Every goal:
Has a deadline
A goal is achieved at some point in the future. By having a deadline, the goal is focused, even if the deadline is not specific: “next week”, “next year”, etc.
A goal without a deadline is an intention.
Is measurable
One or more conditions that indicate when the goal has been reached, such as “built my house” (the house is ready for occupancy); “completing a course” (I passed the final / learned the material); “saved up to buy a car” (I have enough money to buy the car)
Has an owner
The person responsible for moving work forward to achieve the goal; may not be the same person as the one who does the work.
Must be reviewed on a regular basis
Conditions and people change, so it is important to review every goal to determine if it needs to be adjusted to fit reality.
Sometimes goals may no longer be necessary so continuing to pursue them is time better spent in other ways.
Recently I had to convert about 250 RAW image files to PNGs. For neatness, I wanted to convert the upper-case filenames the camera assigned with a lower-case name.
A little bash script-fu is all it took:
clean_pics.sh
#!/bin/bash
# Extract from SD Card
for i in /Volumes/SDCARD/DCIM/100ND40X/DSC_0*; do
filename=$(basename "$i")
lower_file="$(echo $filename | tr '[A-Z]' '[a-z]')"
# verify it doesn't already exist
newfile="${lower_file%.*}.png"
echo -e "Processingnt$i tont$newfile"
if [[ -e $newfile ]]; then
echo "****SKIPPING"
else
convert "$i" "$newfile"
fi
done
echo -e "Detoxing..."
find . -iname "*.png" -exec detox "{}" ;
echo "Procedure complete."
(“SDCARD”, etc is the path to the source files)
Once the script was up and running, it took about 1/2 hour to process all the files. Meanwhile, I was off doing something else!
Note: the post “I don’t hire unlucky people” was written by Raganwald on posterous.com, which unfortunately went belly-up April 2013. It is too important a lesson to let disappear, so I’m posting it here. For all you fellow unlucky people, I hope you get hired soon. 🙂
Bertram Wooster and Ernestine Anderson were staffing up their teams. Bertram was hiring trainees to work in the company’s retail stores, Ernestine was hiring software developers to build a new supply chain system for the company’s operations. “Bert,” Ernestine asked, “I have hundreds of resumés, how do I whittle them down to a handful of calls and a few interviews?”
Bertram smiled. He grabbed a pile of resumés from his desk, then started dealing the resumés out, first one back onto his desk, second into the recycle bin, third onto his desk, fourth into the recycle bin. When he was finished, he had thrown half of the resumés away. “It’s simple.” Bertram told Ernestine. “Just don’t hire anybody who’s unlucky.”
Ernestine tried that for a few weeks, throwing half the resumes out and the combing through the remainder looking for qualified applicants. She got nowhere, even if the people looked good on paper, when she talked to them on the phone it was quickly apparent that they weren’t capable of writing FizzBuzz. Meanwhile, Bertram was staffing up nicely.
Ernestine decided that the needed a new approach, so she went for coffee with Mark Fidrych to get his advice. Mark was the company’s CFO, and she worked closely with him on the company’s supply chain. Mark was also an angel investor on the side and he knew a little about the software industry. He nodded sympathetically when she explained that what was working for Bertram wasn’t working for her.
“Look,” he explained, “The essential difference between your situation and Bert’s is that Bert has a lot more qualified people applying for his positions. Sure, there are klunkers. But let’s say that half of the resumes he gets are decent. If he gets a hundred resumes and throws fifty away blindly, he’s still left with twenty-five decent ones on average. Essentially, Bert’s problem is how to organize his time, not how to find good people. When you asked for his advice, you described your problem in the same terms, so naturally he told you how he does it.”
“But you don’t really have a how-to-organize-your-time problem, you have a finding a needle in a haystack problem. There are way fewer qualified people applying for programming jobs. If you get one hundred resumes, you might have no qualified people, you might get one, if you get two or three in a hundred you’re doing well. If you have one good person in a hundred and you throw fifty away randomly, you now only have fifty resumés to sift through, but there’s a fifty-fifty chance you won’t find anyone worth interviewing, much less hiring.”
Ernestine nodded. “So,” she essayed, “I need to be a lot more selective about the resumés I discard because I have a much lower signal-to-noise ratio?” Mark stared at her blankly, then laughed as he caught her meaning. “Right!”
Ernestine stopped throwing half the resumés away and started treating her job as one of finding that elusive one good person in a hundred. It took time, and she found herself making a lot of adjustments.
two years later
Ernestine and Mark left to found a supply chain management company. Their startup grew quickly, and Ernestine found herself in a meeting with Oscar, an unkempt but talented team lead she had just promoted. Oscar was holding a stack of resumés and he wanted advice about hiring. Ernestine smiled and told him about her experience trying to implement Bertram’s advice, and how Mark’s advice turned things around for her.
Oscar seemed a little grouchy. “That’s a nice story,” he said, “but what specifically did you do?” Ernestine smiled, Oscar could be brusque. “Well,” she began.
“First, I stopped caring so much about little things like how ‘professionally’ a resume was formatted or whether the cover email had spelling mistakes. I realized that throwing people away because of a spelling mistakes was really another way of discarding half the resumés because you don’t want to work with unlucky people.”
“Wait,” said Oscar, “but surely all things being equal, the person who takes the time to get the email right is better than the person who doesn’t?”
“Sure,” agreed Ernestine, “But all other things aren’t equal. What if the email with the spelling mistake came from someone who’s really busy because they’re talented and have a lot to do in their current position?”
“No way,” argued Oscar, “If they want to work here, they’ll take the time to check their spelling.”
“That’s true,” agreed Ernestine, “And if I had fifty great people, I want to speak to the twenty-five who want to work here before I speak to the twenty-five who aren’t sure. But if I have a pile with ninety-nine duds and one good person, I’m more interested in finding that one good person first and deciding whether they want to work here second.”
“The problem with filtering people by spelling mistake is that we’re making up a little theory about whether a spelling mistake tells us something important about the candidate’s abilities. Which would be fine if we didn’t have anything else to go by, but we do have something else to go by, we have their resumé and their code samples and we can call them on the phone and talk to them. So I gnore the little theories and go with what really matters.”
Oscar considered this. “Ok,” he continued, “What else?”
“Well,” continued Ernestine, “I took the same thinking to everything I did when hiring. Every way of selecting or rejecting a person is either a direct measurement of their ability to do the job or an indirect measurement. Indirect measurements are things like computer science degrees. They—“
Oscar interrupted her. “Look,” he said, “University teaches you important things, things that are essential to doing your job. A degree is a requirement, and I don’t mean as a test of conformity.” Ernestine nodded. “Well, it’s true that nearly everyone we’ve hired has had a degree. But all the same, I didn’t sort resumes by degree or by school, I simply looked for relevant experience and reviewed the candidate’s code samples or portfolios when they had them to share. It turns out that almost everyone with the experience we wanted also had a University Degree.”
“But it’s dangerous to confuse correlation with causation. And especially dangerous to confuse correlation with necessity. If University is a great idea for a programmer, it will sort itself out when you look at their experience, look at their code, and interview them. I take the same approach to stuff like whether they blog or have hip hobbies like rock climbing. Most of our folks climb, mountain bike, or paddle, but I ignore that when looking at resumés.”
“After all, having the wrong hobby would be very unlucky. And I don’t throw unlucky resumés away.”
hiring programmers, not ascetics or rock stars
Oscar thought about that for a while. Ernestine continued. “Obviously, we don’t ask people to share their social media with us. But I try to resist the temptation to read anything personal about a candidate, even if it’s public. I don’t want to be subconsciously prejudiced for or against them. It’s a disaster if I miss the one in a hundred because they’re a friend-of-a-friend and I can see on their Facebook that they espouse political views I abhor. That’s not only illegal, it’s bad for business.”
“I also don’t want to be prejudiced in their favour because they seem to be a like-minded soul. If there’s only one in two hundred resumes worth considering, quite a few people are going to be really nice people that nevertheless aren’t right for us. The best thing is to avoid reviewing anything that isn’t pertinent to the task at hand, which means code or words about code.”
“They can spout all they want about politics and Freedom Zero on their blog, but if I’m considering them for a job, I don’t want to know what they think about stuff like that, and I stopped myself from reading anything off-topic when researching candidates. As far as hiring is concerned, having compatible opinions is a question of luck, not qualifications.”
Ernestine was warming to the subject. “Another thing I did was start advertising in plain English. We tried placing ads for ninjas, rock stars, and so on, but I discovered this was the cultural equivalent of advertising for white males who drink dry martinis. Not that white males who drink dry martinis can’t do the job, but there’s no real difference between advertising for a Ninja and throwing half your resumés away because you don’t like unlucky people. Either way, you end up with fewer resumés.”
Oscar spoke again. “But what if the Ninja ad attracts more qualified respondents than the plain ad?” Ernestine smiled. “When you’re programming, how do you know which code to optimize?”
Oscar smiled. “I measure. Premature optimization is the—Oh, I get it!”
“Right,” Ernestine continued, “I measure too. And you ought to. Advertising for people is no different than selling things online. You track everything and measure everything. You A/B test. You run analytics. And you don’t throw half of your market away.”
“But,” Oscar protested, “You say our problem is finding that one person in a hundred or one in two hundred. How does being so damn inclusive help? We still need to reject ninety-nine people.”
“Ah,” explained Ernestine, “What I do is raise the actual talent bar higher to make up for removing all the other hurdles between a candidate and an interview. You shouldn’t reject people because they don’t look or sound like the last good person you hired, but you can and should reject people who can’t do the job. I don’t give anyone a free pass. I don’t care if they say they have Lisp experience and I heard them speak at RubyFringe and they let it drop that they were talking to Brendan Eich at Christian Jaekl’s wedding. I grill them, hard, on actual programming and actual software development.”
Oscar nodded. “Thanks,” he said, then hesitated. “Hey,” he said, “I think I just realized why you hired me when so many other places wouldn’t even give me a phone screen. Thanks a lot.”
“No thanks necessary,” said Ernestine, “You’re a great programmer and you’re going to be an even better team lead. You belong here. We’ll do great things together.”
The path is set via a myriad of config files. It is very easy to accidentally add the same directory to the path, and there is no built-in mechanism from preventing this situation.
While it has no impact on performance, it does make reading the path more difficult (for example, when trying to see if a particular directory is in the path).
Easy Fix
When you find your path cluttered up with duplicate directories, it is relatively easy to correct this. Simply use pathmunge to add directories instead of the typical
export PATH=/fizz/buzz:$PATH
Procedure
First, edit your /etc/bashrc (or equivalent) and add the following function:
pathmunge () {
if ! [[ $PATH =~ (^|:)$1($|:) ]] ; then
if [ "$2" = "after" ] ; then
PATH=$PATH:$1
else
PATH=$1:$PATH
fi
fi
}
Now you can call this function in your ~/.bashrc, ~/.bash_profile, or wherever you need to add a directory to the path. There are two ways to do this.
Insert at the beginning of the path
Using
pathmunge /path/to/dir
is the functional equivalent of
export PATH=/path/to/dir:$PATH
Append to the end of the path
pathmunge /path/to/dir after
is the functional equivalent of
export PATH=$PATH:/path/to/dir
In either case, the directory won’t be added if it already is in the path, preventing duplicates.
Recently I had to convert about 250 RAW image files to PNGs. For neatness, I wanted to convert the upper-case filenames the camera assigned with a lower-case name.
What happens with the Path