antipaucity

After a very long time of looking, we have found a piano to add to our home – and my wife is quite excited!

It’s a spinet style, which is perfect for our living room. And it helps displace the tv which all too often can become the focal point of a home, family, and marriage – not that we don’t still have a tv (we have a couple), but it’s no longer the focus when entering the house

A few months ago one of the Groupons available in Lexington was for the first hour of flight along with an initial ground school lesson at the private pilot training company next to the airport.

This Saturday from 1300-1500 I’ll be taking ground school. Woot!

I’ve known a lot of pilots in my life, and have always wanted to join the ranks

I’ve had a domain sitting [basically] unused for several years, but have finally found a purpose.

Along the lines of freshnews, I have launched an rss aggregator/launch service at datente.com.

There are several categories of feeds (imperfectly broken-up, but it’s what makes sense to me) that display in quasi random order. And on the front page is a smattering selected randomly from the master list.

I would love suggestions of feeds to add, and maybe even new categories, too.

…and in with the new.

On the 31st of December of last year (boy that sounds weird to say “last year” and it only be 4 weeks ago), I traded-in my 2004 Ford Escape which had served me well for 4.5 years (including racking-up nearly 90k miles in the time I had it (and for almost a year it was driven less than 10k miles … which I think means I used to drive a lot)) for a new vehicle.

my cute wife, and our new car

We had been looking at replacing one of our cars for a while, and with the end of the year incentives in place, it was a good time for us to do it.

So we are now the proud owners of a 2012 Ford Fusion in “steel blue”. It’s not quite fully loaded, but it’s more than adequate for our needs.

If the Mayans are right, in 11 months (give or take), all our debts disappear.

But since they’re not (more accurately, it’s merely the next roll point on their calendar like 2000 was for us), we have a host of things to look forward to this year and beyond: a presidential election, graduations, births, new friends, and more I cannot think of right now.

So, to all 5 of my readers, welcome to 2012!

As mentioned recently, I am about to be switching hosts from my current VPS provider, Tektonic.

I have found a non-VPS ISP that meets the requirements I’d previously outlined, and have everything but the MySQL databases for WordPress instances sync’d to the new host.

With a bit of luck, the migration will be invisible to all 4 of my readers

Related to a previous post on career development, I thought it could be interesting to look at one approach to the technical screen that I have used over the past few years when interviewing candidates.

1. for folks with no “real” experience yet, I ask them to rank themselves on a few key technologies on the “Google scale”
• the range is 0..10 where a 0 is no knowledge, 1 is some, 10 is “you wrote the book”, 9 is you could’ve written the book, or you edited/contributed
• on a few occasions, I have had folks ask to change their ranking from their initial [overconfident] statement to one that is much closer to inline with their true experience/comfort/knowledge level – and that’s OK in my book – honesty is always the best policy here
2. a couple quick “about us” questions – open-ended inquiries that let the candidate tell me what they’ve done for work
• this verifies their resume
• gets them warmed-up for the rest of the call
• allows the candidate to brag on something
3. perhaps a couple quick probes to find out more about a specific experience
4. a few basic / intermediate questions to assess candidate’s technical chops (ie, verify that their resume is accurate)
• this goes along with my personal rule of “never put anything on a resume you don’t want to be asked about”
5. open-ended, intentionally-vague questions to gauge problem solving ability, and methodologies
• see how they go about refining the problem statement (if at all)
• gauge estimation skills
• gauge teamwork and delegation aptitude
6. a few intermediate/advanced questions about an area they *don’t* know anything about – to gauge their response to unfamiliar/stressful situations
• in my field in particular, it is impossible to know every new technology or even (probably) to be truly 100% aware of those that you do use every single day
7. a few intermediate/advanced questions in their now-articulated fields of expertise (presuming I have any)
• this verifies more of their stated (and unstated) job experience, and helps determine at what title/work level they should start
8. lifestyle/workstyle questions
• how much they enjoy travel
• how they handle last-minute demands and “requests” by customers and management
9. a few questions to gauge flexibility of response to changing requirements
• for example, switching a project from being Solaris-based to Windows-based part way into implementation because a new CIO has come in, or new licensing is available, etc
10. open time for them to ask me whatever they may wish to know that I can tell them
• this usually ends-up being very short because the candidate was stressed-out over the interview, and can’t think of anything about the company they want to know on the spot

What I try to NEVER ask:

• “trivia” questions – I bet there are C questions even K&R couldn’t answer

• I guarantee I can ask you a question about your area of expertise you cannot answer…just like I guarantee you could do the same to me
• since that is the case, trivia questions are pretty pointless, and more of an ego stroke to the asker than anything else
• pointless “MindTrap“, lateral-thinking questions

• riddles are fun – but only add to the stress of the interview
• pointless problem-solving and estimation problems

• for example, “how would you move Mt Fuji”, “why are manhole covers round”, or “how many gallons of water flow into New York Harbor from the Hudson River per hour”
• estimation problems are wonderful tools and games to play, but not in an interview
• illegal questions

• sometimes they slip out, but it’s never intentional

I adjust my questioning to fit the situation, timing, and candidate responses – so it’s [somewhat] different every time.

When the interview is done, I write-up my evaluation of the candidate and send it on to the hiring manager. In line with Joel Spolsky‘s “Guerilla Guide to Interviewing“, I make sure to put my firm conclusion of Hire/No-Hire near the top, and again at the bottom – with my reasoning in between.

One thing I have noticed about almost every interview I have ever taken or given is that I end up learning something in the process – and not just about the candidate (or company). It’s important to listen to both how and the candidates responds to questions, and what they say.

So, if you ever get the chance to interview with me, you have an idea of how I’m going to run the show

All who knew Kirk Aragon are still in shock over his sudden and tragic loss Sunday.

The N&O called me this week for a brief interview, and some of what I had to say is in an article published today by Aliana Ramos, along with the following preliminary information about the crash:

The private-plane crash that killed an Apex man this week probably was not caused by mechanical failure, according to early findings by an investigator with the National Transportation Safety Board.

…

Aragon’s plane went down about 12:45 p.m. Sunday, minutes after radioing to air traffic control that he was departing. A pilot who was in the air at the time told investigators that Aragon’s plane appeared to be lower than usual and losing altitude before crashing.

“The entire airplane was consumed by fire,” Rayner said. “The engine was significantly damaged; the gears are melted together; the instruments have been destroyed.”

…

Aragon was alive immediately after the crash and managed to separate himself about 10 feet from the plane, said Deep River Fire Chief Larry Kelly. A trio of area residents managed to reach Aragon before the fire department arrived and helped to remove some of his clothing.

“They helped to keep him calm until we could get there,” Kelly said. “He was conscious. I was able to talk with him to find out if anyone else was in the plane. He was in a lot of pain. He did not give any indication of what happened.”

My prayers are with his family especially today.

Kirk Aragon was a former direct coworker, and long-time colleague of mine. Kirk died Sunday doing what he loved to do.

I first met Kirk a few days after starting Opsware in January of 2007. He was one of the “named resources” for dealing with our biggest customer, EDS. Kirk’s professionalism, friendliness, and over-powering happiness that exuded from him constantly was a fantastic encouragement to the entire team in Support. A few months later, he returned from his loan from ProServe to go back on the road.

I had the opportunity to learn from him frequently on a variety of subjects – flying (his passion), family, technical intricacies of the product we worked on, great places to eat, work/life balance, etc.

I’m going to quote one of the members of senior HP Management with regards to Kirk:

Kirk Aragon was a kind and loving person, helpful, professional, and a true gentleman.

For Kirk, aviation was his passion and true love. He embodied the American story. As a former Air force captain of 4 years he fuelled his passion for flight, and carried this on to building and flying his unique kit plane. While serving in the Air force, Kirk Met his wife Archana, and later became a very proud and loving father of 2 daughters (12 and 9).

He was beloved, respected and admired by his managers, his teammates and his customers.

Kirk will be remembered by all of us.

“Kirk was always happy as he seemed to always be upbeat. He was an awesome guy and demonstrated everything a professional could.”

“All he talked about was his wife, his beautiful girls, and his love of flying. Kirk was one of those guys you just had to love, and I know our team will miss him as much as I do.”

“Kirk was a gentleman, a friend and a professional.”

“I have not felt this way for a long time. My eyes are moist, and my heart is saddened. It is a sad, sad day. I’ve known Kirk since the days at Opsware. We had SA boot camp and dinner together a number of times. He is a great person, respected colleague, strong teammate, SA expert and friend. He always brought a colorful perspective to our exchanges and made the conversation lively. He is helpful, open and friendly. You feel close and personal with him. His ‘baby’ face is hard to forget. I miss him a lot.”

I am privileged to have counted Kirk as a dear colleague and am deeply grieved by his unexpected death. I hope our memories of Kirk will comfort us. Let us all support Kirk’s family with our deepest sympathy, prayers and thoughts.

Further, some comments left by his friends and colleagues on social sites:

“I remember the time a bunch of us went to ‘China Town’ for lunch and reallocated car pool distribution on the way back to the office and Kirk graciously volunteered to ride in the seat-free doggie/storage area in the back of my Forester since we were short a seat. Afterward, he just happily tumbled out with that impish smile that he shared so freely. I will miss Kirk.”

“Kirk was a great guy.”

“Wow…. this is very sad. He was a really nice guy.”

“I am so saddened to hear of Kirk’s passing.”

“Mourning the loss of a coworker. RIP Kirk. You were a great person.”

I know tributes like these don’t cover everything that needs to be said – and we always regret what we didn’t tell someone when we had the chance when we no longer do.

One thing I can be grateful for, though, is that I have no regrets about what I did say to the man in the years I knew him.

Good bye, Kirk – may God be with your family in this dark time.

I had a recent conversation with an old classmate, and he stated that using asserts when programming Java is useless because an exception can generate more useful information. Exceptions are only ”more useful” if you are a developer or perhaps supporting an application. When a bug report or support case needs to be created, supplying the “raw” errors can be a useful tool in finding a solution.

However, to go back to my friend’s point, he asked how an assert can “benefit someone that is running the application”. The short version is that NO ”error message” that is in the frame for a developer will [likely] benefit the person “running the application”.

David Pogue wrote about this more than a decade ago, but it’s something that still has not taken-hold in most applications: the human-friendly error message.

The C Compiler in MPW (a Macintosh programming tool kit) gives you messages like this: “You can’t modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler.” Or this: “Type in (cast) must be scalar; ANSI 3.3.4; page 39, lines 10-11. (I know you don’t care, I’m just trying to annoy you.)” Or how about “This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn’t wide enough to read this whole error message.”

The BeOS‘s native browser, Net+ (pronounced “net positive”), had amusing error messages – in fact, it was those amusing messages that spurred the name of the OSS reimplementation of BeOS, Haiku.

For instance, a user might see the following error message if they try to access a website that is unavailable:

Cables have been cut

Southwest of Northeast somewhere

We are not amused.

If the user tried unsuccessfully to authenticate against a website, they might see:

Server’s poor response

Not quick enough for browser.

Timed out, plum blossom.

One you might see, however, in a product I use frequently:

2011-09-08 19:03:58,590 INFO Thread-12 [org.apache.beehive.netui.util.logging.Logger] [info] Register RequestParameterHandler with
prefix: checkbox_key
handler: org.apache.beehive.netui.tags.html.CheckBox$CheckBoxPrefixHandler
2011-09-08 19:03:58,591 INFO Thread-12 [org.apache.beehive.netui.util.logging.Logger] [info] Register RequestParameterHandler with
prefix: checkbox_group_key
handler: org.apache.beehive.netui.tags.html.CheckBoxGroup$CheckboxGroupPrefixHandler
2011-09-08 19:03:58,592 INFO Thread-12 [org.apache.beehive.netui.util.logging.Logger] [info] Register RequestParameterHandler with
prefix: radio_button_group_key
handler: org.apache.beehive.netui.tags.html.RadioButtonGroup$RadioButtonGroupPrefixHandler
2011-09-08 19:03:58,592 INFO Thread-12 [org.apache.beehive.netui.util.logging.Logger] [info] Register RequestParameterHandler with
prefix: select_key
handler: org.apache.beehive.netui.tags.html.Select$SelectPrefixHandler

Gee, thanks Apache!

Compare that with Google’s Chrome browser that puts a frowny face on a file folder and says “Oh Snap!” when something goes wrong (whether it’s the browser’s ‘fault’ or not).

So why don’t more applications come with “friendly” error messages?

Part of it is because developers too often are concerned with getting something shipped (shipping is a feature, after all), that they don’t stop to consider who is going to actually use the software.

User. The four-letter-word of the development community. Developers all too often (I’m as guilty as anyone on this) of forgetting that what they are writing is for someone else to use. Not for them to work on, debug, develop, extend, and futz with. No, it’s to use.

The average user doesn’t care that some component interacted in a bad way and caused a stack trace… they don’t care that there even are components and stacks to trace!

It takes conscious effort to write message people can care about, or at least understand. And it’s not because the userbase of a given product are dumb: they’re just not developers. Doctors surely are not dumb as a group, but that doesn’t mean they’re qualified to understand a stack trace on the EMR system.

Developers need to take a step back from their work and remember that there are other people in the world beyond just them, and if the more easy and friendly a system is to use and interact with, the more likely people are to want to use it – which might just keep them employed