Friday, February 27, 2015

Quote of the Moment

"Life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP [live long and prosper]"
The final tweet from Leonard Nimoy, actor, director, and artist.

Thursday, February 26, 2015

Snowy Day, Not a Snow Day

Clickety-clack, I keyboard through the day.
Yells and laughs, I can hear children at play.
Drip, drip, drip, the snow refuses to stay.
Quiet sigh, the sun slowly fades away.

Tuesday, February 17, 2015

Lists of How to Interview Programmers Make Me Cranky

The web loves lists. Why? Well, let me give you the top ten reasons... Just kidding.

Once upon a time, an experienced programmer and business owner wrote a set of quick questions that could be used as a smoke test when evaluating prospective jobs to see how many of their basic ducks are in a row. He called it The Joel Test. The beauty of it was its speed. Every question is direct and unambiguous (with the possible exception of number nine).

Many years later another programmer came up with a list of things he likes to see in a potential programmer hire. And then he compared it to The Joel Test, which makes for a good blog headline, but completely undermines what he was trying to do. And so I am going to cast aspersions on that list today because while equating this list to The Joel Test makes for a great blog post headline, I think it completely misses those qualities that make the Joel test useful.

Let me state my beef up front: programming is a large, intellectual field driven by people and interactions between people, and as such programmers can not be successfully evaluated outside the context of specific situations. In other words, quick lists of how to hire good programmers are never generally applicable. Never.

And now on to the unwarranted derision of something produced by someone who is just trying to help.

1) Can you use source control effectively?
I will pause to note the first sentence in the extended description for this question starts, "I hate to use the word effectively..." This is good, because it means that he knows, deep inside, that the answer can only be situational. So instead let us substitute the actual things he wants from the extended text: know more than just how to check out and check in code, know how to compare revisions, handle merges, work in isolation or with other developers, and "You should really be an expert at using whatever source control technology you are using..." (emphasis mine). Now I was fine with the actual list of requirements, right up until the need for expert knowledge. Aside from expert being another meaningless qualifier like effective, nothing about that list is expert knowledge. That list is general knowledge of source control. Expert knowledge is how to use your source control system to manage builds and releases, how to recover from corrupted files, how to administer the server(s) the system runs on, etc. Just drop the qualifiers and ask the question you want to ask: can you use source control?
Yes, I can.

2) Can you solve algorithm type problems?
Oh for the love of, I'm not going to make it through this. What have we said about vague qualifiers? OK, more from the extended description. "Even though most real world problems don’t resemble the type of algorithm problems you are often asked at a job interview, the same types of problems do exist in the real world. In fact, the only way to really recognize them is to have some experience solving those types of problems in general." So you are judging me by whether I've seen the types of problems that I can only recognize if I have seen them before, but don't constitute the majority of my real work? Why are you asking this question again?
OK, sorry you want to know if I can figure out if two strings are anagrams. Would you be upset if I asked you to define anagram? What if I wasn't a native English speaker? Can I show you fizzbuzz instead? Can we discuss the dining habits of allegorical philosophers? Sigh. You can tell if two things are anagrams by counting the occurrences of the letters within them and checking that they are equal. Can we move on to something related to the actual work I will potentially be doing now?

3) Can you program in more than one language or technology?
The example used for outside the comfort zone was switching from C# to Java. Points for at least including the technology stack, because that's what's hard in switching from C# to Java, not the languages.
In my case, yes, I have worked on a product that used six different languages. I have worked on products that were written on one OS and run on another. Two of the languages I programmed on for years I had never used before the first day starting on the product. Languages are not a big deal. Learning the ins and outs of your product or system is the big deal.

4) Do you do something to increase your education or skills every day?
Why do you ask? Are you not going to provide your valuable employee, who you have invested time and money in training for your product and business, the opportunity to stay current on the job and thus apply the fruits of this knowledge and learning to your company? Don't worry, I'm just pulling your leg. Nobody actually does that. In answer to your question, no, I don't do something every day. I have a full-time job. I devote the lions share of my time and my mental energy to that job. Some days, I'm doing well to recover in time for the next unreasonable deadline... er... opportunity to excel. Please don't confuse my profession with my life.

5) Do you name things appropriately?
Again with the vague qualifier. Have you ever heard the aphorism that says, "there are only two hard things in computer science: cache invalidation, naming, and off by one errors"? I name things appropriately for me, and for some of the people I work with. Others communicate in a different way, or view certain problems from a different perspective that results in a different naming pattern. Naming is hard. Naming is subjective. I can not answer this question. If you ask people I have worked with whether I name things appropriately, you will likely get a variety of answers. I suggest you drop this entirely.

6) Can you communicate your ideas effectively?
Can we drop the e-word? It's just weakening your questions. Communications involve two (or more) parties. Results vary based on context, audience, preparation, and interaction level and time. See also the answer to the previous question.

7) Do you understand basic design patterns?
Are you asking me if I have read the book, seen them in action, or are you asking me to check off some buzzwords because you aren't really a technical interviewer?
Yes, singletons and factories everywhere. Facades and their leaky abstractions have been the bane of my existence from time to time. And don't get me started on tracing through publish/subscribe code.

8) Do you know how to debug effectively?
Again with that word. My results vary by defect, of course. I can tell you stories of the ones that got away. But I also worked for years on a system with only minimal (probe style) debugging capabilities and seemed to do fine with it. I once found a messaging defect caused by a vendor provided file with a lower case w instead of an upper case one. Admittedly, that one took weeks to figure out. Does any of this help your decision? Do you perhaps find that my specific examples were of use? Maybe ask for those next time.

9) Do you test your own code?
See how much better the direct question can be. Yes, I do. And I won't say anything else because I've encountered programmers that didn't. But just because I test my own code, doesn't mean I don't want you to run it through QA first. I'm only human.

10) Do you share your knowledge?
Another direct question! You are getting better at this. I try. Writing documentation is really useful for my future self. And sharing knowledge means it is possible to share work, which leads to better loading patterns and less overtime, at least ideally. I also sometimes leads to being asked to train colleagues with less experience or who are in lower cost regions prior to having your job eliminated. But that's just with evil managers. Managers at your company aren't evil are they? Sorry, did I say evil? I meant fiscally responsible. Where were we?

11) Do you use the best tools for your job?
Are you going to allow me to bring my own computer? No? Are you going to provide me the best tools for my job? Yes, I have a series of things like text editors, compression utilities, and image editors that I am familiar with and will use given the need, but they aren't nearly as important as the amount of RAM in my computer, or the process enforced by the revision control system, or the available bandwidth on the network, or the project management overhead, or ... you get the idea.

12) Can you build an actual application?
ruby -e 'puts "Hello, world!"'
Not enough? Then you are going to have to ask a more detailed, more specific question. "Actual application" is going to mean very different things to a client-side web developer, an embedded programmer, an enterprise DBA, a systems programmer, a mobile developer, or a desktop developer. It's a big field. I may have mentioned that earlier. I understand what you are trying to get at here, but trying to make this a generic question just begs for an incomplete answer. How does this relate to the job I am being interviewed for?

Oh well, at least it appears I can still call myself a theoretically hire-able programmer. As long as I don't show any of the attitude presented here in the actual interviews...

Thursday, February 12, 2015

Bookworming: Ready Player One

Ready Player One, Ernest Cline, ***
This is a book that will mean the most to a particular audience. I happen to be in that audience, so keep that in mind as I go forward. Ready Player One is an adventure set in an online world in a distopian future. So the central plot is one sci-fi readers or anime watchers will have read/seen before. The characters are sympathetic, if cliched, and the villain as cliched as one could get. There is some surprisingly good writing and world building here, both inside and outside the virtual environment. What ultimately gives the book its flavor is the exhaustive use of geek/nerd culture from the late 70s through 80s. Games, computers, movies and TV, this is an unabashed nostalgia trip. For a certain age and type of person. Yes, I quite enjoyed it. But that was the world I formed in. So it's a solid recommend for fans of old video game (or old video game fans), folks looking for one another coming of age story, or young computer geeks looking for some of their forebearers' history.