• High fidelity recording and playback of most iPhone gestures including touches, drags, and shakes.
• Integrated script editor and test runner.
• Recording and playback on both the simulator and actual iPhone device.
• Extensible framework can be customized to provide specialized command recording and playback for custom components.
• Simple Objective-API can be used to run FoneMonkey scripts using OCUnit.

I recently celebrated my 40th birthday.  A friend joked to me, “Hey, guess that means you’re too old to program anymore!”  I laughed on the outside, but it gave me pause.  Age discrimination is nothing to laugh about in our field.  COBOL guys faced this problem years ago as Java guys like me were ascending the ranks, and we laughed heartily about legacy code and their inflexibility with new technology.

Now the joke’s on me.  Maybe you too.  And if it’s not now, it will be soon enough.  Still laughing now?  Yeah, I thought so.

Source: CRE Taulbee Survey, 2007-2008, pub 5/09

Source: CRE Taulbee Report

Our field is ripe for age discrimination in so many ways.  We value hot, new technologies, the ability to absorb them at unheard of rates, working insane hours to push products out the door–all things attributed to the younger workers of our field.  And did I mention that younger workers are cheaper?  A lot cheaper.  But the trends of computer science degrees do not bode well for having a plethora of young, cheap workers at a manager’s disposal indefinitely.  In fact, all data point to one conclusion:  CS degrees enrollments have been declining or flat for almost a decade.  And if anything, the candidate pool for hiring is getting worse, at least according to Jeff Atwood.  You’re going to have to hire someone to write your next project, and with the backlash against outsourcing, who you gonna call, Egon?

If you’re thinking you’re going to avoid the “grey matter” of software development, think again.  There are a number of myths about older software developers that continue to be perpetuated in IT and software development that somehow put older, experienced workers at a disadvantage in our field.  But they’re largely crap and considering the degree trends, ignoring everyone 40 and over because we’re too old seems plain foolish.  Let’s debunk these myths one-by-one.

MYTH: Older software developers are more expensive than younger ones, making younger developers more desirable.

REALITY: The real reason experienced developers are labeled as expensive is because staff salaries are the #1 expense of any software organization.  The fact is, younger means cheaper.  But, while inexperienced, younger developers may save you budget, but they will cost you in the long run if that’s all you have on your team.  Younger developers haven’t taken the lessons of failure to heart.  They haven’t had enough time to learn those lessons yet. And guess whose money they’re going to be learning on?  Yours.  Think that won’t cost you money in missed deadlines and incomplete projects?  Think again.

Yes, older software developers have higher salaries than younger ones.  But what exactly are you paying for here?  With an experienced software developer, you’re paying for all the experience that comes with past project successes and failures.  Those are expensive lessons if you want to pay for them directly during your tenure as a manager.  But if you buy into an experienced worker, that’s like getting insurance against some of those classic mistakes in project management and software development that you don’t have to repeat.  Meaning you look better on your annual review because you hired smart people that know how to get the job done.

MYTH: Older software developers are less flexible and less capable of learning new technologies because of their legacy knowledge.

REALITY: It’s actually because of their past experience, that more experienced software developers can migrate to new technologies, frameworks, and systems more quickly and in greater depth.  For example, if you learn a GUI framework in C/C++, you have a mental model about message passing, event handling, MVC patterns used to design the system and separate presentation from back-end logic.  The very first time you learn a GUI framework, in addition to the syntax, the examples, and the quirks of the library, you also need to learn all the conceptual stuff.  And after two, three or more GUI frameworks, you notice that they all have very deep similarities outside of the syntax.  You might even notice newer frameworks have overcome substantial limitations that you used to have to work around with complicated hacks.  Those insights are lost on someone new to the framework.  And those insights can really boost productivity in ways you’re not able to directly measure.

MYTH: Older software developers are less able to perform the arduous tasks of software development (read:  work long, painful hours) because of family commitments and other attachments that younger workers don’t have.

REALITY: I think it would be fair to state that experienced software developers are less willing to work those long, painful hours because they’ve learned the hard way that there are productive limits to pushing yourself 80 hours a week for months on end.  It’s called burnout, and I’m willing to bet that anyone who has already experienced it in the past simply isn’t as eager to go there again.  But with that said, the supposed reason of “family commitments” is bogus.  High-quality, experienced software engineers are ruthless time managers, and those with families are even more motivated to get things done in allotted times.  They may have dance recitals and soccer games to attend to, but they also make up that time in off hours and highly focused work during the 40 hours they’re given in a week.  Good software engineers with families must become highly efficient with personal time management or they quickly get buried with the deluge of work coming their way.

MYTH: Older software developers are less mentally agile than younger ones.

REALITY: Aging does affect the brain and it is measurable to show that older workers think more somewhat slowly than younger ones.  But mental agility is only part of the equation.  Thinking faster isn’t always better.  What about judgment?  There’s an old expression:

Good judgment comes from experience, experience from bad judgment.

Lost mental agility is a poor excuse to not hire an older software engineer in light of the fact they’ve seen, done, and lived many more successes and failures than a younger developer.  Experienced developers have tons of past projects to draw from and assist in avoiding bad decisions today.  Younger developers have new ideas which are important, but often untested and unproven.  Having both perspectives on your team is of great value.

MYTH: Older software developers are more jaded and cynical and therefore, less desirable in the workplace than younger ones.  Younger developers are more enthusiastic than older ones.

REALITY: Anyone who believes this is probably someone who doesn’t like their ideas criticized by those who’ve been around long enough to see really stupid decisions put into practice again and again.  Experienced software developers smell crap a mile away.  They don’t buy your stories about how the product isn’t well received in the marketplace because they’ve been interacting with the customers for years and know you’re trying to cover up a future layoff in the company.  They won’t put up with managers asking them to work 80 hours a week because the customer wants the software next month and they already told you it will take 3 more months to complete with the features agreed upon.

Younger developers haven’t been in those situations as frequently and therefore, have less resistance to bad management practices.  The only desirable trait management wants here is naivete.  If you want a great team and great products coming out of it, having people that can call you out on bad decisions will save your bacon again and again.  But only if you have the courage to admit you don’t know everything.

And as far as enthusiasm goes, you can’t tell me age dampens enthusiasm.  If that was the case, Donald Knuth, Ward Cunningham, Bill Joy, Bill Gates and hundreds of others who’ve crossed the magic 40 barrier would be less interested in our field just because of age.  But they’re not.  Passion is passion. If you have it when you’re 40, chances are you really love that field.  That kind of love isn’t going to die overnight.  Younger developers still finding their footing in the world may have short-term passion, but that can be swayed in the face of obstacles and challenges in the field along the way.

In conclusion, let me be absolutely clear about a few things:  Young is not necessarily bad. Old is not necessarily good. And most importantly, anyone who can’t program their way out of a wet paper bag shouldn’t be hired, no matter how old or young they are. Keep your teams a vibrant mix of age and experience–where diversity exists, learning can take place.  But if you’re the person looking to hire someone, don’t write off the dude with the gray hair sitting across from you.  Let go of your age prejudice and see if they can impress you.

Someday that dude (or dudette) may be you.

Related posts:

1. Older Developers: Bad Habits Are Killing Your Career

I needed a very simple Twitter cache for a project I’m working on. And I was very happy to trade off some realtime accuracy for reliability. In addition to caching the tweets, I also needed to pre-process them into css-able html with clickable links, usernames, and hashtags. The web had a few nice examples of how to use regular expressions to parse the raw tweet text, but I decided to take what I liked and do the rest myself.

Links

Here’s the PHP code for parsing links out of the raw tweet text:

$text = preg_replace(
    '@(https?://([-\w\.]+)+(/([\w/_\.]*(\?\S+)?(#\S+)?)?)?)@',
     '<a href="$1">$1</a>',
    $text);

I only wanted http and https links, with an optional query part (\?\S+)? and an option anchor part (#\S+)?. The conversion of a text link into an html link is done using back references, which in PHP is $1, $2, etc. In the expression above, I use $1 twice to put the matched link into both the href attribute and the link text.

Users

Here’s the PHP code for parsing Twitter usernames:

$text = preg_replace(
    '/@(\w+)/',
    '<a href="http://twitter.com/$1">@$1</a>',
    $text);

Nothing special, just take the @ and all following word characters (letters, digits, and underscores), and turn it into a user link.

Hashtags

Here’s the PHP code for parsing Twitter hashtags:

$text = preg_replace(
    '/\s+#(\w+)/',
    ' <a href="http://search.twitter.com/search?q=%23$1">#$1</a>',
    $text);

Getting the hashtags right was the most tricky of the three. I decided to only grab hashtags that were proceeded by one or more spaces. The real magic is the %23 in the query string, which forces a search on the complete hashtag, including the # part. For example, compare a search for #flex to a search for flex.

The Cache

The cache is just a simple cron job that periodically queries Twitter and retrieves the latest tweets. Most importantly, the cache fails gracefully if Twitter is inaccessible, which it does by doing exactly nothing if Twitter is down. This guarantees that my app always has valid data (when my server is up, the cache is up too), but with the possibility that the data is a little old.

Here’s the notable function in the cache:

function getTweets($user, $num = 3) {
    //first, get the user's timeline
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, "http://twitter.com/statuses/user_timeline/$user.json?count=$num");
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    $json = curl_exec($ch);
    curl_close($ch);
 
    if ($json === false) { return false; } //abort on error
 
    //second, convert the resulting json into PHP
    $result = json_decode($json);
 
    //third, build up the html output
    $s = '';
    foreach ($result as $item) {
        //handle any special characters
        $text = htmlentities($item->text, ENT_QUOTES, 'utf-8');
 
        //build the metadata part
        $meta = date('g:ia M jS', strtotime($item->created_at)) . ' from ' . $item->source;
 
        //parse the tweet text into html
        $text = preg_replace('@(https?://([-\w\.]+)+(/([\w/_\.]*(\?\S+)?(#\S+)?)?)?)@', '<a href="$1">$1</a>', $text);
        $text = preg_replace('/@(\w+)/', '<a href="http://twitter.com/$1">@$1</a>', $text);
        $text = preg_replace('/\s#(\w+)/', ' <a href="http://search.twitter.com/search?q=%23$1">#$1</a>', $text);
 
        //assemble everything
        $s .= '<p class="tweet">' . $text . "<br />\n" . '<span class="tweet-meta">' . $meta . "</span></p>\n";
    }
 
    return $s;
}

First, we query the user’s JSON timeline using cURL. Second, we use PHP’s awesome json_decode function to convert the JSON into objects. And lastly, we iterate over the tweets and parse everything into our desired HTML output.

Here some sample output from my twitter feed:

<p class="tweet">Been reading Programming Goggle App Engine. Actually feeling dumber now than before I started. Too much to learn.<br /> 
<span class="tweet-meta">2:58pm Feb 14th from <a href="http://www.tweetdeck.com/" rel="nofollow">TweetDeck</a></span></p>
 
<p class="tweet">Blog Post :: Async Testing with FlexUnit 4 :: <a href="http://bit.ly/cGLnaI">http://bit.ly/cGLnaI</a><br /> 
<span class="tweet-meta">3:33pm Feb 11th from <a href="http://www.tweetdeck.com/" rel="nofollow">TweetDeck</a></span></p>
 
<p class="tweet">Blog Post :: A Better HTML Template for Flex 4 :: <a href="http://bit.ly/70DLsj">http://bit.ly/70DLsj</a><br /> 
<span class="tweet-meta">12:55pm Jan 25th from <a href="http://www.tweetdeck.com/" rel="nofollow">TweetDeck</a></span></p>

Once I have the output, I can do whatever I want with it: save to disk, stick it in the database, keep it in memory, cache it in memcache, etc. In my case, I wanted the simplest possible option, so I chose to write it out as a static html file.

The end. The rest of the app’s not ready yet…

1. Transform any internal data representation into any external representation without creating dependencies on either side.
2. Transform any component interface into the interface required by any caller, again without creating dependencies.
3. Perform branches into any point in existing code, and returns from any point in existing code, allowing for maximal reuse without recoding where logic already exists to perform some function.
4. Intercept attempted calls to any unimplemented method and send an email request to support to perform the operation manually