I’m old. I’m OK with it. I don’t lay awake at night worrying about it. But I do understand quite well that I’m definitely old – at least, in a “programming” sense.
Most outside this career field would laugh at the idea that I’m old. In most careers, being in your mid-40s is the prime of your professional powers. But in software development, anyone north of 40 is often viewed with some suspicion. Anyone north of 50 is frequently weeded out of the resume pool. And anyone 60+ had better have a very solid retirement strategy in place.
But this isn’t an article about outward bias against the Olds. This article is about the fact that “more-experienced” devs do often have a tougher time adjusting to any particular job / task / environment.
It’s not just bias. It’s real. I’ve experienced it firsthand. I’ve seen it in others. I’ve felt it in my soul.
I don’t know if this will help anyone. In any way. But I feel compelled to point out (some of) the reasons why Olds like me find it increasingly more difficult to simply fit in – let alone, excel.
I don’t claim to speak for all Olds. And I’m not saying that there aren’t some aging devs out there who are absolutely thriving in their environments. The following observations are mine and mine alone. Your mileage may vary.
Political Fatigue
When I was younger, I was content to play all of the standard corporate political games. Heck, at times, I even enjoyed them. But nowadays…? Well, let’s just say that I’ve become the polar opposite of a political player – and my unwillingness to “play along” frequently causes tangible problems in my job.
I used to be in management. At one point, I had 60 devs, organized in 6 different teams, that all reported up through me. At that time, I was much more concerned with making sure that I couched my thoughts in the “right” verbiage. I was much more inclined to burn hours writing reports (that I knew would never be read) and checking off audit boxes (that I knew no one really cared about).
About 5 years ago, I purposely stepped away from management. I wanted to “just” be a coder again. I wanted to get as far as possible from standard corporate politics and allow myself to overdose on code.
But a funny thing happened on my way to being “just” a coder again. The politics seems to have… followed me. On a good day, I’m doing nothing but staring at my IDE. But on far too many days, I find myself expected to tell executive management what they want to hear. On far too many days, I’m still bogged down in meetings and endless administrative details.
Since I’m griping about this here, you might have the impression that I’m one of those Cranky Olds. You know, the guy who’s gotta complain about every decision – no matter how trivial. However, I don’t think this describes me at all.
I’m perfectly happy talking to “the business” or “the client” or “the stakeholders”. And I can typically talk to them in a manner that avoids techno-babble and doesn’t demean anyone. People can ask me for all manner of questionable deliverables – and I calmly explain to them, in laymen’s terms, how those deliverables could have nasty unintended consequences down the road.
For weeks, or even months, on end, these interactions cause me no problem whatsoever. But then it happens…
It is that moment when someone wants you to do something in the code that, quite literally, makes absolutely no sense at all. But they don’t just tell you to do it. They fervently ask for your opinion. They insist on making you feel like you’ve contributed – even when your only logical contribution is to say that this whole idea is batshit-crazy.
But you can’t tell them that it’s batshit-crazy. In fact, you can barely tell them anything at all – unless it backs up their original request. That’s because they keep soliciting your feedback. But they don’t want your feedback. They just want you to nod along and do whatever crazy thing they’ve asked.
When I was younger, I had a much easier time swallowing my objections in cases like these. But nowadays…? Well, while it’s easy for me to avoid being abusive or confrontational, it’s not easy for me to couch my feedback in such milquetoast terms that the bigwigs can delude themselves into believing that I support the idea.
I don’t yell at anyone. I don’t use unprofessional language. But you’d better believe that if you ask me what I think of an idea that is truly, epically stupid, I’m going to tell you, in no uncertain terms, that it’s a horrible idea. It’s amazing how often this simple tendency causes me repeated headaches in my work.
Rejecting the Churn
With every year that slides into my rearview mirror, my patience for technology’s relentless “churn” grows a little thinner. That sentence probably makes me sound like a dinosaur. But I’m not complaining about learning or adopting new technologies. (Like nearly any programmer, the process of learning new tech is usually exciting to me.)
I’m complaining about (what I perceive to be) an accelerating trend to throw out established tech – and dive headfirst into new tech – often for no better reason than the fact that someone really likes the new tech (or really dislikes the old tech). If you’ve read some of my other articles, you might’ve noticed my frequent use of the term: fanboy.
If you’re hyping any particular tech, but you can’t make a cogent empirical argument for that tech, you’re probably a “fanboy”. If you’re badmouthing some other tech, but your primary argument against it is that it’s old or stupid, you’re probably a “fanboy”.
Fanboys may sound like a harmless hazard of this line-of-work. But fanboys can cause real damage. If the fanboy is some little-respected kid right out of college, his irrational passions probably won’t cause any real problems. But fanboys can be anywhere.
Your manager can be a fanboy. The ivory-tower architect who’s friends with the CIO can be a fanboy. The guy who’s been working for the company for the last 20 years can be a fanboy. Heck, even the CEO could be a fanboy.
And once the fanboy decides that they hate the tech you’re currently working in (the tech that you’ve probably invested thousands of hours into), and once they have the ear of the decision-makers, it’s only a matter of time until you’ll be rewriting all your stuff. Or you’ll be looking for a new job.
This “churn” doesn’t just apply to top-level tech. It can apply to NPM packages. Or style guides. Or… any trivial aspect of our work. And once the opinion in your shop has “evolved”, you’ll find yourself having to radically change the basic way in which you do your work. Or you’ll be looking for a new job.
Do you wanna know why something as (supposedly) trivial as tabs-vs-spaces can still, to this day, infuriate people? It’s because you have some people who have been coding with tabs/spaces for years and it’s never been a problem. And then one day, someone walks in and says, “OMFG! I can’t believe you’re still using tabs/spaces!” Pretty soon, you need to follow the herd on whatever trivial decision has been made – for you. Or you’ll be looking for a new job.
Please don’t confuse this section to mean that I don’t want to learn new tech (or techniques). I’m as excited as the next programmer to dive into something that promises to solve a problem. But I’m not excited to switch out languages / frameworks / tools / etc. just because the old way is supposedly “stooopid” and the replacement is supposedly the New Hawtness.
The Cynicism of Experience
When I started in this career, I can think of many instances where my naivete was almost… an asset. You see, sometimes I was too stupid to realize I was being used. But in the process of being “used”, I also gained valuable experience. Or I impressed the hell out of the people who saw me breaking my back to make everything work.
In my 20s, any slight suggestion that extra work was needed would lead to me pulling a 24-hour coding marathon. Or working through the weekend. Any suggestion that we adopt some (counterproductive and poorly-supported) technology would lead to me diving in headfirst to learn-and-implement said technology. Any hint of stock options or future IPOs would get me all giddy thinking that I was working for the next Google and I could work myself nearly-to-death – because… I’d be rich!!!
Nowadays…? Well, let’s just say that I’m more discerning with my efforts.
I will (and frequently do) work overtime. But the moment I get the sense that my willingness to work overtime is being abused, we’re gonna have a little chat. And if our team loses someone, and the company’s “solution” is to simply spread the work onto the remaining employees – while keeping all the due dates the same – you can guarantee that I’ll be telling everyone, very clearly, that I will not be absorbing someone else’s entire workload.
I don’t get all giddy anymore about the empty promises of most companies (especially startups). If the comp package includes some stock options, that’s great. But if you expect me to consider those options to be all, or a major component, of my comp, then I suggest you start recruiting at the local colleges. I have mortgages (plural). I have bills and commitments. And even if I like your company, I promise I don’t like it so much that I’m willing to forgo a market-rate salary.
Here’s another scenario where my experience (cynicism) can sometimes cause me problems:
Once you get a reputation in an organization as a proficient coder who can really get stuff done, you can suddenly find many “off the books” requests landing in your lap. I’m talking about those scenarios where someone outside your team’s pipeline comes over and starts saying things like, “Hey… How difficult would it be to make this one little change to this app??”
20s Adam would get all excited about those kinda requests. A few brief meetings and I might end up working nights-and-weekends just to implement some kinda guerilla project. Sometimes I’d do it because I was excited about the tech. Other times, I’d do it because I was eager to please. In a few cases, I even got in trouble for doing it. But I almost always found that the boost within the company to my reputation was well worth any short-term blowback.
These days, I rarely indulge these folks. You know the ones. The people who figure that they can completely subvert the dev pipeline by directly cozying up to one of the programmers.
I’ve had executives try to do this to me (who were, nevertheless, completely outside of my chain-of-command). I’ve had young ladies try to do this to me, sitting closer to me than is natural and smiling at me more than anyone truly wants to smile at me.
But these days, my response to these folks is always exactly the same. I listen politely to them. I provide any immediate feedback I can which might help to steer them in the right direction. But as soon as they want to push me to actually do the work – outside of the normal dev pipeline – I politely (but firmly) decline.
This may sound like the “right” way to handle this situation. But I’ve noticed that once I tell someone “no”, it tends to come with all sorts of long-term side effects. I’ve had managers tell me, in performance reviews, that I’m “difficult to work with”. Yet when I try to figure out where this assessment came from, it turns out that it’s from the same people who were trying to get me to subvert the normal flow of things.
In fact, it’s amazing to see some of the stunned looks on peoples’ faces any time I tell them, in a professional and unemotional tone, “No. I won’t be doing that.” Or, “You’ll have to talk to the project manager about that.” Or, “You’ll need to negotiate that priority directly with the client.”
For some people, it doesn’t matter how professional (or justified) you are. They will still hold a grudge against you if you dare to deny their request.
Little Tolerance For Double-Speak
Maybe this doesn’t much bother the Olds. Maybe it just bothers me. I’m not sure. But I know that, over the last 2+ decades of corporate work, my patience with blatant corporate double-speak has steadily dwindled.
To be clear, I understand that corporations have their own vernacular. It doesn’t bother me when someone says that we should “touch base offline”. And “think outside the box” is a hackneyed (and near-meaningless) phrase, but when someone spews those words, I pretty much know what they’re trying to communicate.
But if you tell me that we need to do some “right-sizing”, I’m gonna vomit a little bit in my mouth. If you keep preaching to me about being a “disruptor”, I know that your idea of “disruption” is for me to work nights-and-weekends to realize your vision. If you ask me to take an “action item”, it’s your subtle way of trying to assign new work to me without consideration for current project priorities.
I could go on, but you get the point. I’ve really grown to hate this incessant need to doctor distasteful ideas in some vague form of New Speak.
This hang-up of mine is particularly glaring when someone wants me to chime in on a proposal – and that proposal has no redeeming factors. I can pretty much talk around most potential ideas. But if the idea is simply without merit… I’m going to say so. And that’s where people start talking about me like I’m some grumpy old bear that can’t be reasoned with.
Knowing Your Worth
How can knowing your worth possibly be a bad thing?? Well, let me explain.
In my 20s, I already had a ton of knowledge and pretty decent programming skills. But I had a sparse resume – and it was more-than-difficult to initially get my foot in that door.
When you’re in that part of your career, you tend to think very carefully before quitting, or job-hopping, or getting on the bad side of one of your coworkers. But it’s been a lonnnggg time since I had such worries about my resume.
I’m blessed to work in a field where there has always been very strong demand for my skills. And my CV is now at a level where I no longer fret over any particular entry. For the most part, these are good things. But it also means that my willingness to put up with other peoples’ crap is frighteningly scant.
I recently had a contracting gig where my entire team was remote – but they wanted me to come into the office every day. So… I wasn’t there for long.
I recently had a gig where several of the executives were blatant, boisterous racists. (And misogynists. And anti-Semites.) So… I wasn’t there for long.
I once had a job where they made me jump through ridiculous hoops to certify the security of my code (including many audit checkboxes that would do nothing to actually secure the application). But when I showed them how I could easily hack the employee database – and anyone else outside the company could do the same – they didn’t care at all. So… I wasn’t there for long.
Generally speaking, this sort of hyper-mobility is an asset. I mean, who wants to be stuck in a job where some aspect of it has become onerous?? But the flip side is that it becomes very difficult to justify dealing with anyone else’s crap – even for a short period of time.
Again, that’s generally a good thing. But I’ve met other Olds like me who just can’t be bothered to hunker down and build a solid history with any single company – because those companies always do something that’s rude or unprofessional or just downright stupid. Follow that pattern through 3, or 4, or even more sequential employers and, before long, you have a reputation as this cranky Old who just can’t “fit in”.
The Cookie-Cutter-ing of Software
One of the most soul-sucking trends in dev over the last decade-plus has been the constant effort to reduce programming to some sort of assembly line kinda process. Although I can understand the desire to refine a complex process into a simpler one, the end result of these efforts is that the programmers often end up being treated like… assembly line workers.
Look, I get it. Software development is hard. And complex. And expensive. And time-consuming. And I also understand that organizations are constantly looking for new ways to simplify these (inherently complex) projects.
But you can’t build a sizable, brand new app from scratch and expect that you can just hand a pile of all-encompassing specs to the dev team and have them crank it out like they’re building a bird feeder. You see, everyone wants to chase this Holy Grail idea that they can just brainstorm over a big set of specs, hand those specs to the dev team, and voila! out comes the app they were envisioning.
I don’t know how many times I’ve been building some component, and working my way through the specs, when I realize that the client has asked for something that’s completely contradictory or nonsensical. And that’s fine – as long as I can ping them and have an intelligent conversation about the issue.
But now it seems that, with increasing frequency, the stakeholders wanna just shoot me over a bunch of specs – and then they want me to go away until I have a finished product. Sometimes, they literally get annoyed if I hit them up with questions. And even if they don’t mind my queries, god forbid that I ever go so far as to question(!) the design they’ve asked for.
Most people in my position don’t just know how to write code. They know how to build better apps. They know a great deal about what works – and what causes end-user nightmares. Now, I don’t have any desire to be a BA or a PM. But the idea that I should never provide any functional feedback on the design of the app itself is, well… it’s just ignorant.
When I was younger, I’d offer my meager suggestions. And sometimes the client would even listen. But if they completely ignored me, I didn’t much care. I just did it exactly how they’d asked for it.
But I’ll admit that, at this point in my life, it’s pretty damn frustrating when the client’s asked for something that I know will fail or need to be changed once it goes live – but if I bring this up, in any way, the annoyance in their voice is palpable. You can almost hear them thinking, “Why won’t this guy shut up and just build the app exactly as we’ve asked him to??”
Go through that process with enough clients and you’ll find yourself wondering why you’re even in this career field at all…
Conclusion
I could go on like this for an additional 100,000-or-so words, I’m sure. But this piece is already getting pretty long. I’ve decided that I’m going to spin up a new series where I actually go through some specific stories of things that I’ve experienced.
For now, I just wanted to lay out some of the reasons why older programmers really can have problems fitting in with “modern” dev shops. It’s not because they’re “stuck in their ways”. It’s not because they can’t understand the latest technologies. Frequently, it’s because their own experience is almost, in some ways, working against them.
I’ve noticed this often when looking at myself. I find myself wondering, “How much longer can I keep doing this?” Because some of the stupidity I deal with daily can occasionally get me very depressed.