Strategies for Successful Development

Process and technology for small teams building real software

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.


Beliefs

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

 

About these ads

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

  1. John said

    Forgive me for coming late to the party, but I just found your analysis of my blog post this afternoon. It is certainly very detailed and makes some very salient points. I thoroughly enjoyed it and appreciate the constructive criticism.I was interested in the conclusions you drew about my personal opinions on some of the issues that I discussed in the article. Some were accurate, but I think others reflected more my perception of the likes/dislikes of the people I have worked with over the course of my career and not so much my own.The intent of that article was not so much to promote a particular agenda, but rather to inspire some useful dialog about the inevitable issues that we will have to confront in our careers as we get older in this business.PS: My last name is spelled "Fuex" and not "Feux." No worries though, it is a common mistake given how unusual the name is.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: