Forgotten truisms

Just some quick observations from unrelated stories in the morning news read.

When someone "tells it like it is", they're just telling you what you want to hear.
Projecting your inner world onto a politician is never a good idea. Remember "plain talking" Bush Jr? How about "hope and change" Obama? Hire a functionary, not a crowd-pleaser.


The performance is entirely about the performer, not about you.
That's why you're the one paying for the privilege of being there. All that stuff about "the customer is always right" that spoiled children entitled narcissists shout when they don't get their way? Turns out that only applies to the retail and service industries -- and even then, it's because the cost of giving a customer a freebie is immediately recouped when they return with additional business. Not about you; never has been.


Nobody with either class or integrity takes part in a reality TV show.
This one really needs no explanation, as to date there is no known counter-example. General rule: do not give money to anyone involved with a reality show, nor take behavioral or aesthetic guidance from them.

labor relations for the working programmer

There's a bit of a trend this past decade or so that can only be described as programmers acting against their long-term interest.

This started off innocently enough, with Agile methodologies that sought to make individual developers easily replaceable. We're not talking about "easily replaceable" in the preventing-evil-sysadmins sense, where a single employee can hold the company hostage because they keep the details of their work a secret. With Agile methodologies, "easily replaceable" means not only automating the development process so that it can easily be taken over by a trainee, but even keeping two people performing the same development task ("pair programming") so that losing a developer to insult or injury is of no consequence. I don't intend for this to be read as a slam on Agile methodologies, just adding a bit of perspective for the labor side of the equation, for whom the benefits of Agile methodologies are less clear-cut (than they are for, say, management).

All well and good. But then something odd happened: the impatience of programmers to release code to the world -- which is a rather irresponsible urge, to be sure -- has resulted in programmers taking on more and more of the work that was previously assigned to specialists.

First came test-driven development. Tired of waiting for QA to clear your code? You can be your own QA department! Just write your own tests, prove to your own satisfaction that code works the way you think it should, and it's read for release! 

Now, every programmer worth their salt tests their code regardless, and TDD has resulted in better testing tools (programmers, forced to use them, have now started to pay attention when writing them). But testing is not QA. For that matter, TDD is not testing. The rule is quite simple: the person who tests the code must not be the same person who wrote it. In other words, the person who signs off on some code as being product-ready or release-ready should be anybody but the person who wrote that code.

Next came NoSQL databases. Tired of waiting for that DBA to make your changes to the database? You can be your own DBA! Just ditch the RDBMS and use a key-value datastore! No waiting!

OK, so you lose referential integrity and ACID compliance, but for the kind of stuff you're storing (let me guess: user clicks) it doesn't really matter. You have also lost that domain expert whose entire job is to make sure you, the developer, didn't screw up the data or the database with some short-sighted decision intended to just make the damn code work.

So, you are now writing your own tests and maintaining your own database, as well as, you know, writing code. Well, so far it's only a 60-hour work week, and that's normal for start-ups, right?

Now we have devops. Tired of waiting for the sysadmin to push your code out to production? Impatient with the "official" versions of webservers or frameworks being half-a year behind cutting-edge? You can be your own sysadmin! Just set up everything you need as a container, then push that container to virtual hosting (er, sorry, the cloud) and you're good to go!

Alright, now you've lost the person whose job it is to make sure that everything works together, that all the security patches are in place, and that there hasn't been some gaping security hole introduced to the system because, hey, the developer can't be bothered to modify the default configuration of the software they're using -- after all, they're not a specialist in this sort of thing!

Starting to see a pattern here? Developer gets impatient when having to work with others. Developer comes up with a way around working with others. Developer brings more work upon themselves, introduces more bugs into the system, and ships lower-quality product. The developer loses, the customer/userbase loses, the formerly-employed specialist loses. The only person who gains from this is the employer: they get to pay fewer salaries, and they have somehow managed to convince some of the most highly-paid non-executive employees to work longer hours, which translates to lowering their effective wage.

There's a lesson buried in here somewhere. Learn to work with others. Accept that your timeline is not their timeline. And while you're waiting for them to get around to the work you need done, do what your father and your grandfather did in your position: knock off early for a beer.

manufactured HR crisis

Employers are aghast at the job-hopping nature of young employees -- something that has been part of our culture since the mass layoffs and destruction of pensions in the 80s.

For some reason, the rabid newscycle has decided this is not the modern start to a career, but rather a Millenial Problem. Headlines like "Companies across the board are struggling to retain Gen Y workers" and "How to Attract, Retain, and Develop Millenial Employees" abound.

What could those crazy kids want? What is it that makes them so hard to please? "Helping Bosses Decode Millenials" cites standard perks such as a flexible schedule, working fewer hours, Fridays off. You know, the things everybody wants, and that employees are rewarded with once they have demonstrated their commitment and responsibility. Nobody gets a flexible schedule and a short work week right off the bat, because if you give the new hires that, half of them stop working entirely.

There's also some nonsense in that Decoding article about Millenials preferring "stories over numbers" and wanting their work to be meaningful, but eh, that is invariably what young people want from their employment.


But here's the cognitive-dissonance (remember that word? newscycle has long forgotten it) inducing part: Millenials are the most under-employed generation currently in the workforce. That means that, guess what? There's always another Millenial.

So who cares if they stay? If your Young Person employee feels they are under-appreciated, and that they could do better in another company, let them move on! Hire somebody leaner, more desperate to prove themselves. Somebody willing to put the time in to demonstrate their commitment and sense of responsibility.

Face it, there's a lot of exploitation of workers going on, especially in the tech industry. There's a lot of refusing to pay people what they're worth, a lot of mandatory office time for work that only requires a laptop and an internet connection, a lot of hiring only clones of the company's founders (young, white, male, with a CS degreee).

Let's fix all of that, instead of worrying about how to motivate a twenty-year-old with an over-inflated sense of self-importance.

run amok

Yale professor resigns over shockingly inoffensive email.

Rational discourse has officially lost the war to the Outrage Machine.It's over; lay down your arms and accept the prophesied future.

"as-is" MEANS "as-is"

Announcing the BSD-compatible POGO open source software license.

It was only funny the first time

A fair number of authors fail to appreciate that facetious titles are best left unrepeated.

Among them:

• * For Fun and Profit
• * Considered Harmful
• The * Manifesto

There needs to be an RFC addressing this.

opdis 1.0.5

A new version of opdis with some minor build fixes has been uploaded to the opdis repository.

Note that the opdis command-line utility and C library have been moved from the tg-community repository into a dedicated opdis repository.

The Ruby gems are still at rubyforge. They might be folded into the Github repo at some point.

How to ensure your educational material is useless

Material intended to educate is most useful when it is searchable, when it can be processed without a computer, and when the audience can determine the speed with which information is presented.

Thus, to guarantee that educational material has no lasting power, has a limited audience, and will ultimately fail to present new information as efficiently as possible, choose one of the following presentation formats:

* Video : The ultimate cop-out. Why organize the material and present it in a thoughtful manner when one can just start babbling at a webcam? And the audience has no idea whether you are wasting their time until the end credits roll -- surely that very suspense will keep them interested!

* Audio : Sure, the audience can do something else while listening -- which ensures that they are not concentrating on the material. As for the rest, see Video.

* Scribd and similar web-only readers : No reading offline (e.g. in a plane/train/limo)? Limitations on copy/paste? Latency for every page turn? Sounds awesome! The only thing missing is to require a login in order to read something. Oh, you're working on that too? Fan-tucking-fastic!

Seriously, any educator unwilling to invest time in writing up their material is unlikely to be presenting anything well-thought-out or well-researched. Learn to write or go home!

An open note to authors of technical books

When writing the nth book on Ruby/Python/R/Lucene/Hadoop/etc to hit the shelves, there is absolutely no need to include a "How to Install Ruby/Python/R/Lucene/Hadoop/etc" section.

News item: there's this thing called "the Internet". Anyone following your instructions on downloading and installing the very subject of your book probably already has access to it.

dircomm 1.1

After demonstrating its general usefulness, dircomm is now available to the general public.

dircomm is a utility for finding duplicate files in one or more directories. It uses the SHA1 of the file contents to determine if two files are identical. The default output groups the paths to identical files (tab-separated) on the same line. Any number of paths can be specified; if no paths are provided, the current directory (.) is assumed.


Usage: dircomm [-adhlLv?] [-f fs] [PATH]...
Find duplicate files in one or more directories.
Options:
    -a, --all
    -d, --directory                  Do not descend directories
    -f, --field-separator fs         Set field separator
    -h, --human-readable             Display human-readable report
    -l, --long                       Long listing format
    -L, --dereference                Follow symbolic links
    -v, --version                    Show version info
    -?, --help                       Show this help message

New versions will be made available at the tg-community git repo.