Archive

Archive for October 30, 2009

Why it’s always difficult to find exceptional software engineers

October 30, 2009 1 comment

It’s 6:30 PM.  My cell phone rings.  “Leon, how are you?  By any chance do you know …

– Senior Java architects with deep SaaS experience and exceptional problem solving skills

– Rockstar product manager that launched at least 3 enterprise software products

– Another rockstar build engineer with experience automating software build procedures (automated deployment and testing also required)

.. and they have to live within 20 miles of the future employer”.

Of course I try to help.  But – great people, especially people that can play their part in making a software product sell itself are rare.  Why?

Rockstar software engineers are usually identified as early as in 3rd or 4th year in college, work as interns during the summer, and then join a team that knows how to attract and retain real talent before anyone else does.  These individuals tend to have fewer jobs during their career, perhaps 4-5.   Job offers 4 and 5 are extended by people they most likely worked for in the past.  So they pursue a new opportunity with those they trust and believe in.

There isn’t much room in this career cycle to attract a real superstar.   And that’s why it’s so difficult to find these people.  Recruiters that can find these rockstaars have my outmost respect and gratitude.  Thank you.

Categories: Hiring

How does a good error message look like?

October 30, 2009 1 comment

It’s not easy to write good error messages.  One of my mentors many years ago told me, “it’s easy to determine if an error message is good.  One week later, wake up at 2:30 in the morning and try to understand it.  If you can easily understand what the message indicates, then the error message passes the test of being a good one”.

It’s true.

Best-of-breed error messages share these attributes:

– Unique component or caller identifier + a unique number

– Severity level:  I = informational, E = error, W = warning,

– Error description (which passes the ‘2:30 in the morning sanity test’)

– Action taken by the system as a result of the error

– Action recommended to the user – if applicable

– Detailed diagnostic information (if enabled) to quickly determine the root cause and reduce diagnostic time to the bare minimum

This is a real error message which has been subject of a recent design discussion.

Before:

– “Error:  transmission failed”

After:

– TRX-SEND-0012E Transmission failed.  File=<name>, Source=<location>,Destination=<new location>.   10 MB of 50MB transmitted.  Transmission will restart in 3 minutes.  No action required from the user.

This message clearly passes the ‘2:30am in the morning sanity test’.   No one in the software engineering team will get a call from the client or technical support team.