Strategies for Successful Development

Process and technology for small teams building real software

Archive for June, 2009

Quick glance at Seesmic

Posted by S4SD (Seth Morris) on 2009/06/28

I’ve been told I’m too grumpy-pants lately 🙂 So here’s a quick non-rant with what is, I hope, constructive feedback for an app I think I might wind up liking in a few revs.

I asked @dariusdunlap what he was using to follow hashtag searches on Twitter, since Twitter itself is so horribly broken about them and he was so well on top of the Community Management Unconference happenings a few weeks ago. He recommended Seesmic Desktop (@askseesmic). So, I’ve been giving it a quick glance-over.

As always, I’m just hoping the developer (who seems far too nice and with-it to do this) comes back and says, indignantly, "That feature is is the product!" because I love quoting the lesson my friend Sarah taught me with an off-hand comment once that changed my whole understanding of product design, especially from my end of it with the coders: "If the user can’t find a feature, it isn’t in the product." But I suspect Team Seesmic is ahead of that already.


+ It’s worth a look if you need to follow search results regularly or if you want to separate people you follow into subsets for viewing purposes, both quite reasonable use cases most Twitter apps don’t support.

No thought to the interaction metaphor or user flow means you’ll be learning to work around how the designer thinks instead of how to get your job done and the technology it’s built on (Adobe AIR) is a famously least-common-denominator platform that will leave you reaching for common, everyday conveniences Windows added in the 90s.

= Integrates Facebook viewing into Twitter, but only for one Facebook account and it doesn’t really "get" the difference in Facebook use. It’s really just a view of some Facebook stuff in your Twitter feed, so it’s a nice-but-not-important feature in the current implementation


  • Great for watching one or two of N things at a time and switching which one or two at will
  • Bad for grazing content
  • Badly needs some help text. I think this is what I needed to know when I started, but nothing actually tells you how to use the app unless you want to spend time watching videos:
    • The nav bar and the column immediately to the right are the whole of the basic UI. Some columns will be pulled out and stacked to the right of the nav bar’s column; these are called "detached," but they are still attached.
    • The "Home" view is what all of your accounts can see, in one timeline
    • The @Replies view is a search on Twitter for all of your accounts (but does nothing for Facebook)
    • When you send a tweet, check which of the accounts it will send it through: you may be very surprised (and embarrassed!)
    • Searching via the search box makes a saved Twitter content search. Searching via the search tab of an account searches for a Twitter username.
    • Make a userlist and add people to it. Then exit the app and check that you did it the way it expected. When you have it right, it will begin aggregating new status updates from those people into that list. It is not a search function: it is a new, special bin for new items to be copied to.

Some nice stuff
  • Love the handling of text over the length limit (graying out text after the line and changing the chrome UI)
  • Userlists are quite nice. Well, they would be if they worked (if they worked as expected, but they’re pretty nice so far)
But, some major, major problems

(These are probably showstoppers for using Seesmic in any non-toy capacity at this stage, but it’s still very much in development)

  • No app should change what a user writes without explicit authorization: the default install converts urls via some url-hiding company. This needs to be opt-in.
  • If you have Facebook enabled, scrolling down the timeline is unusable. As you scroll, it downloads images which cause it to resize the cells you’ve scrolled past, making things on-screen jump down, off-screen. Basically, if you have Facebook installed, you shouldn’t try to scroll the timeline unless you scroll it all the way (by paging, not by jumping the thumb) and then walking away until every picture it passed has been loaded, then heading back up. It’s amazing to me how unusable this is. I wouldn’t have expected it (and clearly Seesmic’s creator didn’t either, although s/he could have tested it)
  • Adobe AIR is easy to code for and can be a lot of fun, but it really isn’t ready for end-user apps: AIR eschews interaction standards on the OS; instead it behaves like Adobe’s former Macromedia people think the universe should.

    Even if you agree with them, having Seesmic be the one app on your system where control-right takes you to the end of the word, rather than the beginning of the next word, means you have exactly one app where all text editing takes all of your attention and breaks all of your habits. Sadly, I can’t recommend using any AIR app that hasn’t been custom-built to your needs, since it’s going to be so broken in little ways you won’t feel until after you’ve paid for it.

Some details

Bad UI

(Some of these might be AIR’s fault, but I don’t think so. I haven’t written for AIR in about a year, though)

  • Can’t resize columns. Hope they’re at a size you like(they aren’t for me)
  • Can’t stack columns. Horrible for splitting out several things to watch at once
  • Can’t fill people into a userlist unless you have content from them
  • Creating a userlist doesn’t do back-searches, even if the content is already present. I made a userlist on Friday and it doesn’t aggregate content until people start tweeting on Monday. Stupid.
  • Scrolling is horrible as images get pulled in, moving what you’re reading around while you’re reading it

Definitely AIR problems:

(Seesmic touts AIR’s ability to run on multiple platforms, which is kind of nice, but it means, at least in this case, that the UI implementation sucks on them all—it’s the same reason any UI in Java1. Consistency with the platform is why we don’t have to spend all of our time remembering what keys do what and can instead complain about what happened when they did it. If it works exactly the same on a Mac, then those users are just as unhappy in different ways.)

  • Whole-word selection is inconsistent with the platform
  • Control-arrow behavior is inconsistent with the platform
  • Can’t resize window except at lower-right thumb
  • Context menu behavior odd and inconsistent
  • Mis-reports its frame size. Maximize it and it will spill over onto the next monitor
  • AIRs drop-down lists don’t behave much like Windows lists (well, they behave similarly, but they try not to look like it, leading to user confusion).

Broken Bits

  • I cannot find a single link to the Seesmic web site anywhere in the app
  • Defaulted to editing my tweet text and using without my approval. Editing my words should be opt-in!
    Note that I believe url hiding services are an evil that is rarely necessary.
  • No way to indicate that there new items in a search (this may be a feature request at some level, but it begs an interesting question: are searches polled or are they pulled on demand? the configuration UI implies that they are refreshed on demand…)
  • Need context menus on items in the left nav bar
  • Why does clicking a hashtag launch the web site instead of searching in the app?
  • Need to be able to size or hide the nav bar
  • YouTube videos are not a replacement for documentation. Ignore your ego, be willing to spend some actual effort writing words instead of code, and pen a few lines people can read (without devoting blocks of time and without needing audio) to decide whether to use your app and to learn how.
  • Sending a tweet seemed to send from two accounts at once when I didn’t expect it to. That’s an advanced use of the app, don’t make it so easy to blunder in to. Now that I know about it, I’m reasonably safe
    • As an aside, it says something that I assume the checkboxes on the account selector were a mistake and were meant to be radio buttons. The rest of the app is pretty clean, but that seemed like a likely mistake given the limitations of AIR, the stage of the product, and the general level of attention to detail in the interactions throughout the app.
  • Use of the X (standard meaning when on bar of icons affecting a window: close this window) to mean "delete the item that launched this window" is horrible. That it follows up with a task-interrupting modal dialog should be the clue that it’s bad design

    Let’s be more specific: here are the buttons on the title bar of a search frame:
    After the "refresh" button, we have 1) a trash can, 2) an X, and 3) a "go back (through the door)." Which one means "reset the data", which means "delete the search", and which means "close the window"? I’m betting on 99% of people getting it wrong the first time.

    And remember, every search frame will have all of those buttons forever, no matter how tired you are. Don’t ever click that X thinking it shuts the window…

  • Userlists remember that they are in "edit" mode far too much. Make editing a task, not a state.
  • Similarly, having "search for a person" be a state of an account means I can’t return to that account without cancelling the search and I can’t search for two accounts at once. This interaction model needs some thinking,
  • Button to enter edit mode on a userlist is nowhere near the buttons to end it. Very confusing, especially with the current bad IA around what editing means. Very easy to think you’ve renamed a list, but be wrong.
  • No feedback when refreshing
  • Adding a search us completely unlike adding anything else, but shouldn’t be. It’s one line of text, just like a new userlist, so it should have a plus sign on the nav bar

Missing features

  • Multiple Facebook accounts
  • Drag and drop to userlists (actually, dnd is missing everywhere)
  • # of new items by userlist and search (in the nav… the popup notification is nice but it doesn’t work well for "what’s new over lunch?") At least bold out the search if there have been new items since it was last active (showing in the special, left-most columns or showing in a detached column that has the focus)
  • Context menu on an unselected hyperlink should refer to the link, not the whole text of the item
  • Context menu on an unselected user id should refer to the user, not the whole text of the item
  • Export to some local format. Given the passable search handling and the very nice userlist feature, this would be essential to use this for actual business purposes
  • Let me separate the detached frames to a different top-level window or to the desktop. They are fundamentally different from the one, magic frame tied to the nav bar. This UI metaphor is pretty broken, but it isn’t easy to see what would be better, so give me a stopgap. I spent 10 minutes just trying to figure out why I couldn’t rearrange and resize the detached columns, since they are still completely attached, just not "leftmost"
  • Minimize to Tray
  • View list of people I’m following (and friends on Facebook) and apply to userlists from there

Wrapping up

It’s an interesting product and fun to use. I recommended that my gf use it to track some work with a client and I may make it my preferred "search watch" interface (at least until Trillian Astra gets one). Take a gander.

And if you’re on the Seesmic team, nice job for a 0.3 app! I’m happy to expand on my gripes if you want, I’m happy to shut up (at least to you) if you want, and I promise you: I only write this much about apps I think have promise and I it’s all intended to be constructive.

Technorati Tags: ,

1) Well, Java UI is also doomed because the client implementations leak memory, the Windows implementations crash, and new Java features aren’t free anymore, so the garbage collector fixes that would help most are only available to enterprise customers who buy the "non-free java" license. AIR’s way ahead of that. And it has scroll-wheel support, which means it’s at least caught up to 1998 user-side technology.

Listening to: Lou Reed – New York – Busload Of Faith


Posted in Opinion | 2 Comments »

re: Opera Will Reinvent The Internet On June 16

Posted by S4SD (Seth Morris) on 2009/06/13

I saw this via @da_lind, somehow: Opera has a teaser campaign for some new product releasing on June 16th (at 9:01 AM, no less). predicts it will be a "browser in the cloud," based on the image they’re using as a logo:

Seems reasonable. The buzzword traffic alone should generate loads of subscriptions. (Opera is a pay-to-play web browser1.)

I commented on the ghacks story:

Great. More important software with personal information moving to remote servers I can’t control at home and my IT department can’t manage. I can’t imagine what my end-user benefit might be, but at least Opera doesn’t have to worry about handling addons or extensions, since it’s still purely a networking/HTTP-and-rendering/javascript tool instead of a productivity platform.

At least I’ll get to pay for the privilege of letting them control my updates and mine my personal and corporate click-trails, usage habits, and bookmark data, which sounds great.

And some people think Alexa, an opt-in service with a no charges, a privacy mode, clear pro-privacy policies, is evil! But Opera is the browser we geeks love to extol–as long as we don’t have to use it!

(Posted from Opera Mobile; yes, I *do* like the browser, even if I hate the hypothetical cloud-browser
idea and I don’t think Opera is quite worth what they charge.)

(Disclosure: I used to work for Alexa, I trust the policies I have seen there, I still have friends there, and I am slightly bitter at having to tell every major anti-malware product not to remove the opt-in service–with code *I* wrote–shouldn’t be removed just to artificially up their statistics.)

[Note: I cleaned up typos and inserted hyperlinks. My editing on my phone isn’t always the best.]

My quick takes:

  • "Cloud Computing" means distributing data and processing across fungible, remote, and anonymous computers
  • "The Cloud" means doing this over the internet via some corporation’s computers
  • A browser is a piece of code that
    1. Downloads data from a remote server
    2. Renders it appropriately for your client computer (screen resolution, bit depth, window size, input method, accessibility tools)
    3. Renders some extensions such as Flash, music, and video players what both assume they are running locally and wouldn’t be reliably useable if run remotely (they’d have to push down screen-scrapes at a furious and consistent rate)
  • By their nature, browsers know—and often remember—everything you browse:
    • This user made POST requests to the purchase page of these 3 gardening sites this month, but did not make POST requests to this other
    • After visiting LocalBookstore’s web site, this user went to and did not return to LocalBookstore
    • This user just started visiting job sites
    • Between 9 and 5 local time, this user visited 20 shopping sites, 15 comedy sites, and 3 public utilities

          Of course, your ISP and IT department already have this browsing information, even if you haven’t set a proxy server. You don’t think all that traffic on port 80 is secret, do you?

  • Anonymized and in aggregated, this is extremely valuable:
    • These 3 gardening sites are the most popular in terms of purchase-visits. Would YourGardeningSite like to know this? Do you have cash and a service contract2?
    • LocalBookstore gets hits, but users head to to purchase (would LocalBookstore like to know what pages they left the site on? Does LocalBookstore have cash and a service contract?
    • Would JobAnalysisGroup like to buy a monthly report of aggregate job site visits across multiple sites? Would they also like to know how many users just started visiting job sites? How many stopped? Does JobAnalysisGroup have cash, a service contract, and a promise to report the data as "supplied by"?
    • Would JournalistPerson like to report on business-hour site usage? Would JournalismUser like the source broken down by home DSL/cable (telecommuting) versus corporate networks (reverse telecommuting)? Will JournalistPerson use our name prominently in the article, the statistics graphic, and any search tags?
  • Web browsers also need to record bookmarks, which is more potentially minable data
  • Many web browsers offer to store account and password information for users, often including corporate accounts for users at work

I’m not seeing what a "cloud browser" would add for the user, but I do see what it could do for Opera. There are some plusses and minuses that do look interesting, though:

  • Cloud applications are upgraded and maintained by the service company, which relieves end users of the patch/update burden but also removes IT department control of upgrades, preventing them from vetting updates and managing security configuration
  • Cloud applications carry your preferences to wherever you logon. Whether you want the same bookmarks, cookies, and security settings at work and home is an interesting question. If you do, Opera’s hypothetical "Cloud Browser" would compete with many services that already move some of your data (I like IE7Pro, personally).

Of course, a "cloud browser" is speculation at this point, but even if Opera doesn’t do it it does seem like a reasonable direction for Yahoo! or Google to go.

We’ll know on Tuesday.

1) Well, Opera has always been a pay product in my experience, and I know the mobile version is (I’m still evaluating if I want to pay $24 for a web browser on my phone). I can’t find a link for the price of the desktop version (although they do tout that their beta version is free, which is usually a sign that the stable version isn’t); of course, many products online try to hide their costs until after you have them installed.

2) Of course, we don’t want Our Cloud Browser to look like an evil data miner. I don’t know why so many net pundits like to say that anonymous data mining is evil, even as they quote it, and I love how so many claim the supposed openness of the web means it can adapt to user needs, without mentioning that you can’t adapt to information unless you collect the data. So some other company, owned by Our Cloud Browser or its parent company, gets to sell the data. It buys the usage trails from Our Cloud Browser as a way to launder the money.

Listening to: Donald Fagen – The Nightfly – New Frontier


Posted in Opinion | Leave a Comment »

Re John Feux: “Programmers: Before you turn 40, get a plan B”

Posted by S4SD (Seth Morris) on 2009/06/12

Several friends recently sent this to me, which (given that it was written almost a month ago) probably means they know my birthday is coming up…

(From John Feux) Programmers: Before you turn 40, get a plan B1

Interesting stuff and well worth considering. I don’t know that I agree with Mr. Feux’ interpretations, but I certainly don’t take the rosy view some of the comments on his blog propose.

As I read it, Feux’ general points are

  1. Experienced developers cost more than inexperienced developers but can’t have more experience on any new technology.
  2. As a developer, you need to base a career plan on the assumption of age discrimination. He lists some options:
    • Consult, with the assumption that the experience:cost ratios are treated differently for consultants
    • Advance out of programming. He gives a variety of reasons he finds this distasteful; these are presented as caveats, not as definitive arguments. He also lists some elements of management he finds positive. You may find his opinions backwards at times, but the points are worth reading.
    • Pick some technology and stay with it as it becomes less "cool" and more rare. Feux describes this as inherently unpalatable (a clear indication of his values and his assumption that all programmers share them), but it certainly can be lucrative and stable.

As usual, I’d like to look at presuppositions and their implied values and beliefs. This is one of my favorite parts of reading anyone’s comments, and blogs are especially good places look.

He says, regarding a 1998 study

The use of dubious sampling of only computer science graduates to support its conclusion undermines its credibility…. It completely ignores the significant number of working programmers who either earned their degree in another discipline or never finished college.

It’s a great criticism, but I don’t know that his unsupported follow-up comment, that "the Government has been very slow to grok the software engineering trade" is either true or relevant.

1. "The Government2" used CS grads as a measure because they thought it was especially relevant, rather than, say, because no other rubric came to mind

2. The "software engineering trade" comprises one thing to be grokked—or not—as a whole. I suspect, from reading Feux’ blog, that he has considered that "the Government" has a good, deep understanding of some aspects of some kinds software development, but they are the kinds of development which Feux doesn’t care about and doesn’t usually consider.

Mr. Feux makes a clear—and interesting—belief statement:

The software engineer depreciates only slightly more slowly than the machine he or she toils behind

3. Software engineering is "toil," at least in the corporate or professional world.

4. Software engineers lose value over time—they "depreciate."

5. (Included for completeness.) Development hardware depreciates at a rapid rate. Most of us would agree with this immediately; using it to support the other beliefs is less universal, however.

Feux supports this belief with a 13-year old statement by a former President at Intel who had himself moved from the world of technology to the executive world on his path to multi-millionaire-dom. It isn’t clear if Dr. Barrett, the executive quoted, considered himself, a materials scientist, to be governed by his own statement, which was about hardware and software engineers. At any rate, he had been out of engineering directly for 22 years and does not appear to have ever been an engineer at the company3.

In describing Dr. Barret’s quote, Mr. Feux takes pains to defend the value of the statement even though it was made by "a suit," so let’s add:

6. The opinion of a manager or executive is suspect when it regards engineers or engineering.

Mr Feux makes an interesting comparison: in conventional wisdom, "a programming career is roughly the same [length] as a professional basketball player’s"

The article then moves into the issue of age discrimination, which isn’t the only possible way to interpret the data or the quotes. So the presupposition is:

7. The small number of software engineers over 40 is the result of age discrimination


Those 10 years of C++ experience made the veteran candidate progressively more expensive as they leveraged the value of that experience in jobs requiring C++. The problem is that the marginal utility of that extra experience must exceed the marginal cost of hiring the veteran to justify paying the premium.
[emphasis mine]

Note that confusion around the word "marginal" might mislead some people:

"Marginal" has two meanings here. In "marginal utility" it seems to both mean and imply a small amount of utility. In "marginal cost" it connotes small, but the word seems to mean (denote) "incremental."

This leads the reader to a confused comparison: is the utility of the experience small (as Feux seems to imply) and if so, is the cost also small (favoring the veteran) or simply "incremental"? I read is as: the cost is incremental, but Feux would like us to assume or believe it’s small. I don’t think it was intended to mislead, but it’s a pitfall worth calling.

Let’s take the misleading word "marginal" out of the quote and see how it reads:

…the utility of that extra experience must exceed the cost of hiring the veteran to justify paying the premium.

Clearer and less likely to introduce bias. It’s also a good statement of hiring ethics

Feux weighs in on whether the extra experience a veteran developer has is relevant:

Herein is the source of the problem. The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes….

8. As an engineer ages, (large?) portions of their experience becomes irrelevant. (I suspect that his belief goes on to state that this is monotonic, but it is possible Mr. Feux would disagree.)

I am sure that Mr. Feux would agree that which portions of a candidate’s experience are relevant is highly contextual. Given his bias for switching to new technology, however, I also suspect he would describe certain experience as inherently irrelevant.

The unfortunate truth is that unlike other forms of discrimination that are more arbitrary and capricious, age discrimination can often be a result of objective and sound business justifications

I have worked with many, many managers and senior engineers who considered their discriminations—whether based on age, sex, medical conditions, personality traits, clothing, or attractiveness—to be the result of objective and sound business justifications4.

In fact, I have never worked with someone who both described their prejudices as irrational and suggested using them as a basis for hiring.

In every case, the sound and objective business justifications seem good until you look at them.

I’m not trying to justify it as an acceptable practice, but just trying to describe the pickle it puts the manager in trying to make a sound business decision without compromising the ethical and legal obligations of the company.

This is one of those areas where engineers and technical managers need to call on outside expertise. A good, trained, and experienced HR person is your safety net. They are there to recognize your biases and tell you whether they are reasonable or not.5

…a little gray hair and a smattering of experience in different technologies can create a beneficial bias for companies when they are renting brains instead of buying them outright. It may have something to do with the tendency for consultants to be vetted from higher up in the management chain where the silver foxes live.

9. Like calls to like: It takes older managers to hire older engineers.

Let’s ignore the slipped-in insult. It’s beneath Mr. Feux and I doubt he was aware of it when he wrote it.

…management thinks that everyone including technologists harbors a deep longing to “graduate” into their ranks. I think it a fallacy that no one would continue to design and build software for 20 years unless they had no ambition or growth potential. However, people like me that respect such dedication to the craft are in the minority.

This one’s a straightforward belief statement, and one well worth looking at in the context of this article.

10. Staying in development is a sign of dedication and craftsmanship.

11. (All/most) managers consider engineering nothing more than a stepping-stone.

12. Management roles are a step up in prestige from engineering.

A couple of quickies from his notes about management:

[If you become a manager] Meetings, politics and dealing with unrealistic requests will pretty much become your life.

13. Engineers don’t have to deal with meetings, politics, and unreasonable requests (or not as often as managers)

14. (All?) Engineers want to avoid meetings and politics (and unreasonable requests)

[If you become a manager] You may try to avoid it, but management-speak will creep into your vocabulary

15. There is such a thing as management-speak, and it has no or little value. (All?) engineers want to avoid it and will spend energy avoiding it.

[As a manager] even when you make it succeed, your team should get the credit. [Emphasis mine]

16. Engineers take (and prefer) individual credit as opposed to passing credit on to their team.

[As a manager] you’ll have to check your ego at the door

17. Engineers are not asked to check their egos, nor should they be.

I know you love programming because you like technology, so this may go against your very nature, but no one says you’ve got to jump every time….

18. (All?) Programmers (always?) want to jump to new technologies.

And a corollary, which I suspect is very true of Mr. Feux:
19. Developers prefer wide-if-shallow experience to narrow-but-deep.

It is highly likely that you will still be able to earn some decent coin in the technology you know and love even after a few decades

20. Even though developers prefer to jump to new technologies, working with an old technology can be personally rewarding if it’s one you love.
This is a nice complementary belief to #18 and #19.

There are some interesting beliefs here, some of which I agree with entirely and some I think are good descriptions of the industry’s beliefs as a whole.

My take, as an almost-40 programmer and consultant

I was fortunate enough to have the first time I was daunted by someone’s age be with a guy named Dave (I’ll add his last name if he is OK with that). He was quite a bit older than we were (the whole team was under 25 at the time and the team lead had just turned 21) and, we quickly learned once we hired him, relatively conservative and highly religious, in a conservative protestant sort of way. We had the hung-ho, 1995, startup mentality. We worked 60 hour weeks at a minimum, we played loud heavy metal in the darkened dev pit, and we took breaks for six-player games of Descent and Doom.

When he started, we made a few changes:

  • We stopped playing any music over the speakers unless we were in a serious crunch mode. Even then, we avoided Nine Inch Nails, which had been our favorite. Dave got jumpy when we played Closer on a loop.
  • We moderated our swearing. We had been a foul-mouthed group that liked to shout obscenities at our code. He wouldn’t complain, but we realized something pretty mature for our age: making him uncomfortable just wasn’t good teamwork.
  • We learned that he was even more excited about new technologies than we were: he had been around enough that he could quickly explain pros and cons and apply old patterns to new problems. We learned from him and he tolerated our naivety with apparent amusement.
  • When he left at 6 or 7 (and came in ridiculously early, given our late nights), we started out kind of "making allowances for his age and lifestyle," but that couldn’t last. He was contributing as much as we were and he was learning as fast as we were and he didn’t have as many bugs to fix because he was careful and experienced; instead, we realized that his coming in on a Saturday—or, when the chips were really down, a Sunday—meant he was showing as much or more dedication than we were at 3 AM.

I’m still learning from Dave, even though I haven’t seen him since 1995.

I’ve given a lot of thought to the age discrimination I felt when I first met Dave. I know what it was for me and I strongly believe it was the same for my teammates. There were two issues:

  1. We had convinced ourselves we were better than other people because we were doing what we were doing so young. When we got pulled on to special projects and advanced work ahead of older programmers, we decided it meant we were better6. Seeing someone in his 40s doing the same work we were threatened us by making him seem as "good as us," with added expertise.
  2. None of us were sure we could be doing what we were—what he was—when we got to his age. We thought we would slow down and we would want to go home and sleep instead of coding all night and we would calcify and stop being able to learn as fast. We projected those insecurities on him and when he defied them he both reassured and scared us: what if he could do it, but we couldn’t?

All poppycock, of course. Research shows we stop learning if we stop learning, sleep is good for thinking at any age, and deep knowledge in any area of technology transfers to sudden insight and intuition when learning another.

But we were just kids. We didn’t know that yet.

On the hiring side I’ve seen age discrimination in action and I’ve seen people try to justify it several ways:

  • "He’s too young to hire as a senior engineer"
    This is the most recent one I saw. The manager saying it also liked to talk about whether female candidates were attractive enough, whether a candidate with a lazy eye was going to be too "creepy" to work around, and so forth. When challenged on this, he stopped letting HR into the debriefings and complained that it was allowed in his country7.
  • "He won’t fit in with the culture"
    This is the dodge I see most often. If it’s used about people regardless of age, it may be a valid opinion, but look around: are they describing a culture that presupposes everyone is under 35, is single, is using drugs, or meets other ridiculously narrow criteria?
  • "He has lots of bad habits from COBOL/C/JAVA/RPL/whatever that he can’t unlearn"
    Check this for ageism versus technical religion. Squash it either way, but know which one it is.
  • "I’m not sure he has the energy"
    This is practically a code phrase for "too old." If you hear it, slap the person around and then demand to know what they mean.

In every case, your response, as a responsible, ethical, law-abiding, and generally human engineer or manager, has to nip it in the bud. The response is the same as with any discrimination.

  1. Stop the person right then, right there, even if it’s in a group debrief. This is not the time to "praise in public, punish in private." You aren’t correcting the behavior for that person’s benefit. You are showing the team as a whole that a) discrimination is not part of the culture, and 2) you are aware of it and will do something about it. It is bad for a team to have one openly-discriminating member, but it is far worse to have that and the feeling that people in charge are clueless.
  2. When they defend their actions, don’t attack their defense. You don’t explain why fundamentally unacceptable behavior is not allowed, just like you don’t explain why they have to wear clothes and refrain from murdering coworkers.
  3. When they claim they are making sound and objective business judgments, reduce the objections to observable behavior:
    • When you say "energy," what do you see or hear from your coworkers that you don’t believe he can do and why is it essential to the job?
    • What duties of a senior engineer at this company, performed by other seniors will he fail at and what experience would a different candidate have to have to succeed?
    • What would happen on an average day with the team that he would be excluded from and how, specifically, would it leave him or someone else unable to do their job?
    • When you did your in-depth technical interview, what specific habits did he exhibit and how would they compromise the project at this company, at the level of this position? When you challenged these habits, how did he react?

      You may get reasonable responses to some of these questions. Take those responses seriously and do not let them off the hook for the discriminatory bias. If you were willing to accept prejudice, you wouldn’t need interviews.

  4. Record the event and get it to HR. They need to know.
    Some people feel this is disloyal to their coworker. It is. It is also loyal to yourself, your company, every candidate who will ever apply to a team the coworker is on, to every junior programmer who will ever learn from that coworker, and to the industry and every programmer in it.

On the candidate side, I’m pushing 40. My hair started salting in high school. I’m still using C++ regularly, both for clients with legacy code8 and on some of my personal projects. When asked to solve a problem, I’m as likely to use a batch file9, greppipsedpipeawk, or a quick VBA macro inside Outlook/Word/Visual Studio as I am to pull out a .NET 3.5 trick or mashup some twitter feeds10.

So, do I have to counter my age? Yes. I know some of these 21-year-old wunderkind are less excited to work with me than with some other whippersnapperyoungin’. I remember when I was 24 and we Dave; I had the same concerns and biases and prejudices.

My response is to meet it head-on. I ask interviewers if they think my age is a detriment. This has two good effects. Most programmers don’t want to be prejudiced; if they become aware of their biases, they’re happy to adjust for them. Most managers recognize that my awareness of the issue is a) a sign that I’ll work around it, and b) a sign that overt discrimination could lead to legal trouble. Item (b) isn’t really a good thing, but I don’t want to work with teams that care overmuch about avoiding people they may abuse to the point of a lawsuit11.

When I’m meeting a company, I want them to know a few things:

  • How does my age affect my energy/esprit/dedication? When I was 22, I was fine working 60 hour weeks. Now I’m not. I like to think it’s because I’m wiser, not older, but that may be self-delusion. In any case, I need them to know that a) I know what the job entails—crunch time happens, demos can’t me moved, and some bugs or last-minute features just take extra hours—and b) I’ll do what it takes. They also need to know that I won’t stay until midnight "just because" or to give "moral support" to someone else working late. Well, not usually.

    Basically, they need to be reassured that I’m focused on shipping the product. If my leaving at 6:00 or 6:30 on most days is a problem then it’s really one with their culture, not with me. Not as long as I’m willing to stay late or work weekends or work from home after hours to meet deadlines when necessary.

    Note that this is a different issue in a large, established software house than in a small startup. A company with a family-first culture (say, Intel) won’t ask me about this as much as the entrepreneurial startups I tend to work with.

    The takeaway:
    Tell them upfront what I will and won’t do. Show them that I know what’s expected. Give examples and be specific.

  • Have I kept learning? This is pretty simple to cover. They’ll think of me as a C dinosaur if I talk about C a lot. If I talk about their technology, they know I know it. If I talk about principles, they recognize that I can apply my expertise no matter where it came from.

    The takeaways:
    1) Show what I can do in their world. Use their language; know the SDKs they use. This isn’t really an old-guy thing, but it’s more important to demonstrate when they worry that I’d prefer to hand them an 8" floppy with some assembly on it12.

    2) Leave the wistful reminiscences for later. Even with an engineer my age, talk about what I can do today and what I know now rather than wax poetic about the Good Old Days.

    3) Talk about principles. Principles are experience reified. Mentioning common closure, dependency inversion, command patterns, etc., and how I’d use them to solve whatever problem we’re talking about goes a long way; mentioning how I’d apply the principles in their technology of choice goes further; but mentioning how I’ve applied them across languages, target environments, and APIs goes furthest.

    4) Tell them about hobby work. I write programs for fun; most of us do. I write programs to solve problems that only I have; many of us do. When an older programmer shows you an actively-developed, open-source project he or she is doing, it goes a long way toward reversing the assumption that they’re "slowing down."

  • Am I relegated to "old person" things13? In other words, am I a management type more than a coder? In my case, I’m firmly in both camps and proud of it. Once I show some coding skill, though, most programmers don’t want to pigeonhole me as a manager even at my advanced age. Most programmers are good people at heart; I have to remind them that I have project management and process improvement skills to offer.

    In fact, managers and executives are far more likely to treat me as having multiple skill-sets than programmers are. They see the value of the "soft" skills even when programmers don’t and they tend to assume the technical skill once they see someone else respecting them.

  • Do I love this? In the end, this is the only one that matters. If they can see that I love what I’m doing, petty assumptions around my age become as irrelevant as they should have started.

    Show them that I love what I do and show them what I love about it. If that’s what they’re doing—if I love coding and they code, if I love games and they write games, if I love databases and they use a database, whatever—they’ll want me to do it with them. Wouldn’t you?

    This isn’t really a takeaway for being an older candidate. It’s a guideline for living and working. Let people know what you’re passionate about; they’ll want to help you do it and they’ll want to do it with you.

And in the end, there is one rule that only an old codger can really have learned: If they don’t want to hire me because I’m older, then they’re not good enough to work with me.

So, summing up: Age discrimination is very real in our youth-oriented industry, it requires vigilance on all of our parts to help show our coworkers when they exhibit it, the common justifications for it are both ridiculous and easy to respond to, and if you’re doing what you’re doing because you love it you’ll be fine.

The "Plan B" options

I really liked Feux’ "Plan B" options, but let me re-state them how I read them:

  1. Take your expertise and teach it to other people. Consulting lets you see a broad selection of projects, work with a wide variety of teams, and pass along your habits, beliefs, and skills everywhere you go.
  2. Manage teams, projects, or companies: Mentor people and apply your expertise across a large swath of the project at once. Make the hard decisions and shield the less-prepared engineers from the confusing world of departments with different values and criteria. Communicate what the engineers need to the rest of your company, translate what the company needs so your engineers can understand it, and build a culture that gives your programmers the learning, success, and chance to have a life that you may not have had.
  3. Find things you love and keep doing them, even when they become un-faddish. You love them for a reason and people still need them. You can still learn new things, both within your older technology and elsewhere, and you can handle working on more than one project at a time. If the one that pays well and keeps your family feeling safe about the mortgage and the college fund, spend your evenings and weekends on the bleeding edge. When you’re not spending that time with your family; finding that your family is a higher priority than you ever expected isn’t "growing up," it’s just "growing."

This, right here, is why I do what I do and why I’m so passionate about it. I consult with startups and small teams doing technology and dev process, but I measure my success by asking two questions: Will the client ship the next project, the one without me, successfully? And will the team’s quality of life be better for it? And I couldn’t have done this at 21.


Just some notes about the beliefs and presuppositions I see in Feux’ post. I grouped them arbitrarily and I’m sure he would disagree with many of my interpretations. I’d love to learn where I’m wrong; I hope he’d love to learn what a reasonably careful reader gets from his writing.

About programmers and programming

2. The "software engineering trade" comprises one thing to be grokked

I don’t think for an instant that Mr. Feux would agree with this consciously. I do suspect, however, that he unconsciously dismisses large swaths of the trade as uninteresting to him. I probably agree on what the interesting bits are, but I need to keep in mind that he may be ignoring something important to me and he is probably unaware of it.

3. Software engineering is "toil,"

Again, I don’t think he would agree with this consciously and it’s quite possibly he was being ironic or sarcastic14 with his poetic turn of phrase.

But I may surprise you: it certainly can be toil. At some point, it is for most people; some people get out of the industry then, some get through it and return to loving what they do, and the rest become the sad, embittered, mediocre developers we all fear turning in to.

10. Staying in development is a sign of dedication and craftsmanship.
14. (All?) Engineers want to avoid meetings and politics (and unreasonable requests)

These are projections, but largely true and useful beliefs. I’m sure they are motivating for many people. Including me 🙂

8. As an engineer ages, (large?) portions of their experience becomes irrelevant

This is really a belief about novelty: that technology is only relevant if it’s new. It’s not a business-focused or results-oriented belief; it’s a belief that learning new things is more important than producing reliable and reproducible results. It’s a good belief for an engineer to help his career. After a certain point, though, I would say that it’s a limiting belief. If I find a developer who is still focused on novelty over reliability and doesn’t find that old knowledge is always relevant, I have found a good, solid engineer, but not one ready to take on what I consider the duties of a senior software engineer.

16. Engineers take (and prefer) individual credit as opposed to passing credit on to their team.
17. Engineers are not asked to check their egos, nor should they be.
18. (All?) Programmers (always?) want to jump to new technologies.

These are core beliefs in the "Cult of the Programmer" belief system. They prize individual effort over results, cleverness over sustainability, and silo, cowboy programming over teamwork. It’s common "Type A" stuff that makes up the backbone of our macho, testosterone-fueled culture where programmers live out our adolescent power fantasies with code instead of capes.

I went through it and I still indulge in it sometimes. I see it destroy non-aggressive programmers, good projects, and good companies on a daily basis, though.

19. Developers prefer wide-if-shallow experience to narrow-but-deep.

This is a common, but not universal, belief and a common, but not universal, preference, in my experience. The "deep guru" is also highly respected, but I suspect that on average, it is true that a wide-but-shallow developer is more respected than a deep-but-narrow one.

I know that a wide-but-shallow developer can easily appear to be more skilled, more experienced, and more generally impressive than one with a narrower skill-set, even when that breadth is irrelevant to the task at hand. To sound smarter and better prepared than we are is an easy skill to master and one most developers learn extremely early (especially the more Type A, Cult of the Programmer-oriented ones).

I should write an article about it. I’ve actually taken classes in acting more intelligent than I am 🙂

20. Working with an old technology can be personally rewarding if it’s one you love.

I love this one. I’d take the word "old" out. Actually, I’d take "an old technology" and replace it with "anything," but that’s outside the scope of Feux’ blog and mine.

About management

  6. The opinion of a manager or executive is suspect when it regards engineers or engineering.
11. (All/most) managers consider engineering nothing more than a stepping-stone.
15. There is such a thing as management-speak, and it has no or little value.

This is related to the Cult of the Programmer belief set, but it’s also a variant of the beliefs that every culture has about other cultures, especially ones it believes have power over them. They’re broad generalizations that break down in practice as often as they stand up, but they are so much a part of our culture that they act as "signifiers" indicating membership in our self-appointed elite.

12. Management roles are a step up in prestige from engineering.

This is an interesting observation and a belief about what other people (people who are not in technology, even) believe. I suspect it’s true, although managers are seen as more accessible and understandable than engineers. Engineers are still viewed as a priesthood with mysteries and as unattainable to the average person, although that is finally changing.

13. Engineers don’t have to deal with meetings, politics, and unreasonable requests (or not as often as managers)

I don’t understand this one. It’s completely untrue in my experience. But it would be nice.

About age

  4. Software engineers lose value over time

I know for me, when I held this belief it was a projection of insecurity. I doubt it is for everyone. I know I don’t believe it and I haven’t seen any evidence of it.

I would like to see a reformulation, though: "Software Engineers lose value if they don’t change over time."

9. It takes older managers to hire older engineers.
7. The small number of software engineers over 40 is the result of age discrimination

I need to think about these two. I’m not sure that either is a law of the universe, but they are certainly true in many people’s experience.

I believe that both are changeable, both in the small, through each person doing what they can to work around them, and across the industry as a whole… through each person doing what they can to work around them.

Personal to John Feux:

Thank you for writing such an interesting article! Great post and I’m really excited to see the active discussion it’s provoking.

I hope my comments are taken in the spirit intended: friendly, respectful, and supportive. Your blog has made it to my feed list. You write some great stuff.


1) I just want to say that I really, really thought this was an article about programmers and sex when I saw the title. But that’s probably me; I assume "Plan B" doesn’t bring up the same interpretation for everyone.

2) Gotta watch "The Government." It isn’t really one thing, it doesn’t have one set of goals, and it doesn’t have motives in the abstract.

3) To be fair, the article I read about Dr. Barrett was on Wikipedia, so all I saw was what the last anonymous internet user chose to write.

4) It’s not really a secret that engineering is a sexist, racist, ageist culture that wants to forgive almost anything in the name of intelligence. At one company I vetoed a candidate for saying that he managed two employees, but because they were women he couldn’t give them anything important to work on. He backed that up by saying that they "would just get pregnant and quit" when deadlines approached.

The sad part was that none of my coworkers thought that was a problem in any way. Some even thought he had been prudent.

5) Sadly, the average white, male, American programmer would rather take advice from a 90-year old, female, non-white, foreign programmer in a suit than from the best of HR reps.

6) It never occurred to us that a) we were the people not already assigned to important projects and b) we were the people the CEO liked to hang out with and relive his youthful techie days.

7) What country did you first think of? It was Ireland, btw.

8) "Legacy code" is a code phrase at small companies and startups. It means "anything I didn’t write or anything I wrote using a tool I’m bored of." For many programmers today, that means any C++, even if it’s brand-new and running on the cutting-edge platform.

9) Okay, I’ll name it .cmd instead. Call me avant-garde.

10) If you’re reading this more than a month after it was written, pretend that wasn’t horribly outdated. I’m on to something new, I hope.

11) In general, you don’t want to sue over this kind of thing, unless you want to switch into activism as a lifestyle or career for a few years. You don’t want to imply that you’ll sue. But you can’t prevent a good HR rep from considering it.

I have a not-so-funny story about a good HR rep, an Irish engineering manager, HIPPA, and me not suing, but this isn’t the place for it.

12) Actually, I do have some 8" floppies with some assembly code on them, but only because I don’t know how to get rid of them.

13) It’s worth thinking about this: in software, we do have roles we assume older people (i.e., over 35) will take, just like we have rolls that women will take. It’s wrong and wrong-headed in both cases; it’s dangerous because it’s out of our awareness and because we don’t talk about it.

Scrum-master, Manager, MS Project, writing specs, … Are these what we think a programmer over 35 does? Does s/he do it as well as code, or instead of? If s/he moved into programming at 30, does that change anything (i.e., is it based on age or experience)?

UI design, community management, running focus groups, HR, coding the "easy" pieces with user interaction instead of the "hard" pieces with data mining: Are these what we expect a woman hired into the team to be doing?

Sure, we all know of counter-examples. The ageism Feux is talking about is a great, and more acceptable to challenge, entry to recognize other prejudices that permeate software.

14) According to the definitive linguistic analysis in the book Lamb, "Sarcastic" is what "ironic" becomes if you know you’re doing it.

Listening to: Fairport Convention – Old-New-Borrowed-Blue – Matty Groves/Dirty Linen


Posted in Opinion | 1 Comment »