petdance

The problem with that is that far too few geeks are interested in winning friends or influencing people.

Still, the Carnegie book is great.

Where did you see ack as "far, far better than grep". My Ctrl+F finds nada.

The reason I took "betterthangrep.com" as a domain name, besides it being catchy, is that I want people to think beyond stock grep as a tool, to know that they have options. The page http://betterthangrep.com/more-tools/ is just a listing of other tools that may be better than grep, depending on the use case.

That kind of mentality is exactly why it's wrong to have "svn blame" and "git blame" as commands. The very commands that we use to look at code history teach us that it's all about finger-pointing.

It's not for the human readers to skip the section so much as to simply acknowledge that you're doing it for the machines.

If I'm a human and I'm reading a skills section that includes PostgreSQL, PL/pgSQL, SQL and RDBMS, I might think "Aw, she's padding her resume, those are all related." But if I slap a "Buzzwords" section on there, now it's clear why it's there.

And I do think that's important. Say you've got an HR drone who is told to look for candidates who know SQL. He might see a resume including Oracle, Postgres and DB/2. We all know those require knowing SQL, but the HR guy doesn't. He won't see the magic word "SQL", so there's a good chance your resume will get ignored.

That example is also why I suggest that no hiring manager ever let HR screen resumes. It's just too important to be left to a filter that doesn't have the proper knowledge set. Sure, your recruiters at Google and Microsoft and other big operations know these tech things. But most tech jobs aren't at tech companies like that.

The idea of listing categories is fine, but don't rely on those descriptions to give enough detail. What you think might be "good" knowledge of X might be strictly amateur to someone else. Better to tell stories and give descriptions of how you've used the technology in question.

Also, if you know something good enough to say that you're good at it, there better be multiple bullets up above explaining how you've used that technology. I've had resumes where someone says they have expert knowledge in a given technology, but nowhere in their work history do they have anything that says that they've used it. You know Oracle? Then you have to have it in a bullet up above.

Another way that you can get those details in the resume about what you know is by quantifying as much as possible. Instead of saying you wrote a Ruby app to do such-and-such, say that you wrote an N,000-line Ruby app to do such-and-such. The numbers give a sense of scale that's missing without it.

More from my blog about the importance of numbers: http://petdance.com/tag/numbers/

Depends on if you include time to type the command.

If your find command looks like

    find . -name '*.pl' -o -name '*.pm' | xargs grep foo

and it takes 1 second to finish, and your ack command is

    ack foo --perl

and it takes 1.5 seconds to finish, you can say the grep is faster.

But I just timed the time it takes to type those, and they took me 9.2 vs. 2.3 seconds.

So which is faster: 9.2+1.0 or 2.3+1.5?

Not only that, but that guy also linked back to the original and said it was a modification of the previous post.

Nobody said anything against really short names.

I'm more than happy to include findrepo on the betterthengrep.com/more-tools page. If you'll make a page for it, or at least have something for newbies to read, I'll add a link.

My concern is that someone who's new to all of this isn't going to understand what to do if I just link to http://www.pixelbeat.org/scripts/findrepo

It's a joke but not. The less typing you have to do, the better. Less typing means fewer mistakes and less time waiting for the search to start.

Defaults matter. ack is all about having sensible defaults for your most common uses.

Oooh, I forgot about your project when I did the betterthangrep.com website overhaul. I just added it to http://betterthangrep.com/more-tools/

Hey, if you've got a solution for it, I'd love to hear.

But a trend of what? I don't see how anyone can conclude "X is used more (for whatever 'more' means) than Y" simply because there are more documents on the web about X than Y.

But why bother to improve it?

Why is the question of "What programming language is most popular" one that needs an answer?

The title of the article is wrong. A correct title would be "The number of documents on the web about C is now larger than the number of documents on the web about Java."

There is no reason to believe, and no facts are given to support the notion, that there is ANY correlation between popularity of a programming language and the number of web documents related to that language.

TIOBE just leaves it to us to draw that conclusion ourselves, and then we commence arguing over it.

Same harm as any other spewing of unlikely but plausible stories.

Same harm as repeating the story about not flashing your brights at another car lest they come kill you. Just wasted time and overly dramatic.

Same harm in telling about how Rod Stewart had to have his stomach pumped because there was a gallon of semen in it. Just wasted time and overly dramatic.

Same harm in parroting a story you heard about some virus that will make your computer blow up. Just wasted time and overly dramatic.

There's no direct harm, but we're gullible enough as a society already. Living in a Headline Nation is teaching us that we don't need to think for ourselves. When the only facts we have about a story is that "they" are doing something bad, then we'll believe most anything.

Corrections & police undergo more severe scrutiny, and therefore are not relevant data points. This is in the original article, and was not "made up".

The mute/moot mistake was made by a poster, not the author.

I tried going down the road of finding specifics that could be verified. Here's one claim:

"There are several companies that are now revising their HR policies so that providing your FB password on a steady basis is a requirement of your continuing employment. You've already been employed 5-10 years? Provide it now, or be fired tomorrow."

http://politicartoons.livejournal.com/3026559.html?thread=70...

The poster rattled off some company names, but when I pressed for specifics, like how she knew these things, she claimed that I was "in the pay of a corporation as part of a 'hit squad'."

> the inane-stream media whipping up a phony crisis.

But it's our own fault. There was one little AP story, and it got pushed everywhere, and what did we do? We clicked the link, and then we said "OMG LOOK AT THIS I HAVE TO POST THIS TO FACEBOOK" and the people with the websites said "ooh, look at those clicks."

The only reason this was whipped into a crisis is that we allowed it to be.

It's 2012, and we are the media.

I think the worst slop is that when faced with lack of hard data, the writers fall back on "more".

"More companies are asking job applicants for their social media passwords." More than what?

The problem with that approach is that its combative, which does you no good. That's why I suggest the following, from the article:

> The best answer is to calmly and respectfully say “I believe it’s best for business to keep business and personal life separate. That’s why I keep my private life private.”

> I do have one question, why does the author use BOLD text in the article in such a haphazard manner?

You could post a comment on the blog and ask. I'd have answered.

I bold the text for the key points that I want people to take away. I suspect that most people skim articles longer than a few paragraphs anyway, so I want to help them to the key points.

Some of the comments I'm seeing about the article only reinforce my conclusion that many readers never read beyond the headline or first paragraph.

I've never heard of these "brogrammers". Perhaps I'm not reading the right blogs so as to be whipped into a proper frenzy.

Rejecting code and docs is a fine strategy for the short term. In the long term, people and enthusiasm are the scarce resources. Taking the time to cultivate them as members of the community pays off down the road.

I don't agree with your assumption that "the time span it takes to go from clueless to good is probably longer than the period in which the person is involved in [the] project." If I can spend some time shepherding the new person, who is probably more naive than unqualified, it will pay off in spades later.

There were about 30 items I left out for the sake of article length.

I'm going to be expanding all of them into a website that will have a page for each of them.

When my dad bought a DEC Rainbow 100, I loved loved loved that I could move the keyboard. Such a boon!

They shipped it with 82 failing tests.

http://gcov.php.net/viewer.php?version=PHP_5_4

Why even bother having a test suite?

> it doesn't really matter if your opinion of them drops

Of course it matters, unless you don't care who you work for. You're interviewing the company just as much as they're interviewing you.

Your IRC experience is not an uncommon one, unfortunately. Next time, check out #perl-help, which is a bit less hostile.

Work on whatever you actually use.