Professional Facepalms: A Six-Part Series
Because if you can’t laugh at your own career mistakes, someone else will.
Part #3 - Keep Learning Beyond Your Job Description
Why “I already know enough” is the professional equivalent of “hold my beer.”
Welcome to Part 3 of Professional Facepalms: A Six-Part Series. This installment is brought to you by the ghost of every training opportunity I politely declined while sprinting headlong toward the next fire that needed extinguishing.
How to Build a Career Without Ever Updating Your Résumé
I spent 32 years as a COBOL programmer. That’s not a typo. That’s a full and complete sentence. And I served it with honour. My job titles changed, my pay scales fluctuated, but the language stayed the same. COBOL was my bread and migraine… I mean margarine. Darn auto-correct.
COBOL was already a dead language when I started. Odd, considering that funeral procession still winds its way through every bank, insurance company, and government system on earth. Hundreds of billions of lines of active code still power core transactions. If there’s a COBOL system somewhere generating cheques, then this “dead” language is literally paying the bills. At least for somebody.
In IBM iSeries shops like the one I spent my career in, that reality isn’t just alive — it’s running victory laps. Recent surveys show iSeries hardware remains business-critical for many organizations, with a significant share still running the majority of workloads on those platforms. Maybe it’s their hyper-reliability — iSeries systems boast 99.999% uptime, which translates to less than five minutes of downtime per year. That kind of performance builds trust. And just for some added context, the original iSeries hardware and software was released 37 years ago.
Businesses with deeply entrenched legacy systems often struggle to justify the time and expense of migrating to new platforms. Despite exponential growth in computing power, they cling to ancient code—not out of stubbornness, but because it works. When a system is stable, supported, and spinning like clockwork, modernization feels risky. And when your system’s “wheel” only stops spinning for five minutes a year, there’s little incentive to reinvent it. So modernization gets delayed. Again. And again. And again. The people maintaining those prehistoric platforms end up dedicating their entire careers to keeping them alive, leaving little room — or justification — for learning new languages, databases, or development tools.
If your company’s modernization project has a five-year window, and you’re five years or less from retirement, congratulations: you’ve unlocked the COBOL cowboy endgame. Just keep your head down, stay the course, and ride off into the 8-bit sunset — where your horse is an amorphous block of pixels, the colour scheme runs the gamut from light brown to dark brown (with an ample 14 shades in between), and your legacy system is still generating cheques like it’s 1987. That’s what it was like for me.
If you're unlucky enough to be maintaining legacy code on the Oregon Trail, however, there's a good chance you won't live to see retirement, let alone the modernization project.
Training? During Fire Season?
I figured I’d survive my career without learning another language — because even though the company was modernizing, I’d be retired before the project finished. Go me!
But the truth is, my epic quest to preserve post-University ignorance actually started much earlier.
For years, I had bulletproof logic for skipping training:
I had a skillset.
The company needed people with that skillset.
There was more than enough work to be done.
If I took two weeks to learn something new, the sky would fall, our accounts receivable would implode, and the office would descend into anarchy.
I also clung to a personal myth: that learning only sticks if you use it immediately. I believed that if I didn’t start using my newfound knowledge the Monday after certification, it would vanish by that Friday. That’s not how skill development works. But myths are convenient when you’re swamped and trying to dodge change.
It’s not that I wasn’t offered training. My boss regularly encouraged me to take courses. There was always money in the budget. There were glossy brochures to look at. Some week-long classes even provided muffins on day one — and the same muffins on day five. But I convinced myself that stepping away to learn something new would mean falling behind on the fires I was already trying to put out.
I recently joked with my boss about this, saying to him in faux indignation:
“Why were you encouraging us to take training? Were you not paying attention to the real work all around us that needed to be done?!?”
We laughed… or maybe it was just me. But the truth is, I let the urgency of the day-to-day override the importance of long-term growth.
Professional Development and the Rest of Us
In some professions, professional development isn’t optional — it’s a requirement. Teachers in Manitoba, for example, get several PD days a year. Doctors, lawyers, engineers, and accountants all have to log hours, earn credits, or attend training to keep their licenses.
Meanwhile, in legacy IT shops, PD is often a suggestion — like flossing or reading the Terms and Conditions. It’s available, encouraged, but rarely enforced. And when fires are burning and you’re the one holding the extinguisher, it’s easy to convince yourself that learning something new is a luxury.
Speaking of Terms and Conditions, Apple includes a friendly reminder not to use your iPad to create a small, tactical nuke.
Because you just know that somewhere there’s a guy who made Apple’s lawyers say, ‘Yeah…we should probably put that in writing.’
But here’s the thing: if regulated professions require PD to stay sharp, maybe the rest of us should take the hint. Because the systems we build, maintain, and duct-tape together are evolving, even if our job titles aren’t. And the pace of change in IT makes PD less of a perk and more of a survival strategy.
Credentials are fine. But then there’s real growth. The kind that keeps you relevant and, dare I say it, visible within your department. And it requires more than a certificate in Visioneering (yes, that’s a real thing) and a laminated name tag dangling from a lanyard.
I did collect some credentials: an Applied Management certificate in the late 90s, ITIL Foundation in 2017, and a Leadership Development certificate in 2018. All useful. All perspective-building. All capable of padding out my résumé and providing me with a new vocabulary of buzzwords I could break out at my next meeting. They taught me how the organization works and what good process looks like. But none of them gave me modern, hands-on experience.
You need to treat real, skills-based education as a serious investment in your career. Because if you don’t, you risk giving off a quiet signal of complacency — like growth isn’t even on your radar. And that signal doesn’t stay private. It’s broadcast. It’s noticed. It’s tracked. Believe it or not, the people above you in the corporate food chain can spot stagnation from a mile away.
And you know what stagnation looks like? It looks exactly like a five-day-old muffin sitting untouched in the training room.
So you need to ask yourself: Is that really how I want to be known at the office? As a Johnny StaleMuffin?
Specialists in Silos
Of course, learning isn’t just about formal training. It’s also about understanding the people and systems around you.
We built software for every department — but we didn’t always understand what those departments actually did. Sure, “we” had a general sense. That is to say, if you got all of us into a room together, at least one of us could speak somewhat intelligently about everything that was going on around us. So, as a whole, our IT shop was pretty savvy about the business overall. But each of us, individually, had our own specialties and fortés: the Claims Guy, the Rates and Coverages Guy, the Keeper of That Ad-Hoc Program We Administered in 2011. If your name showed up next to “Author” in the COBOL code, then congratulations — that system had your stink on it and you became the subject matter expert until retirement or death by dysentery (whichever came first).
We talked about cross-training. But it never became a priority. There were always pesky things like work and deadlines that got in the way. Taking time to learn each other’s bailiwicks always felt like a luxury we could ill afford. The consequences of that? Let’s just say they deserve their own chapter.
Some companies do this differently. Structured cross-functional training, job shadowing, and mentoring programs are increasingly common in Canada. They build resilient teams, foster empathy, and help employees understand the business beyond their own department. Apparently.
All kidding aside, I think that that kind of exposure is genuinely invaluable irrespective of what you do and where you work. For an IT professional, it could change how they gather requirements, design systems, even name variables. And maybe the end result would be translating all of that into code that doesn’t require a decoder ring and a séance channeling the ghost of Kreskin to interpret.
Reflection
Looking back, I don’t regret being a COBOL lifer or being considered reliable. I got to do challenging, meaningful work with and for people I respected. My skills were useful so the company got what it needed, and I slept fine knowing the systems I maintained generally ran without too much problem.
What I do regret is assuming that dependability and growth were mutually exclusive. I missed opportunities to grow, not because they weren’t offered, but because I didn’t prioritize them. I missed genuine opportunities to learn how to be a subject matter expert from other people in our shop.
If I could rewind, I’d carve out standing time to learn and use the new stack even if I couldn’t deploy something business-critical right away. I’d prototype something small, maybe a “proof of concept” thing. And maybe that little Lego brick I created could become part of a grander, more purposeful system down the road.
I’d ask people in other departments to show me the annoying part of their day so I could see things through their lens. I’d corner the team member who guarded the system I feared most and trade them a case of beer for a walkthrough.
Lesson Learned
Learning beyond your job description isn’t just about career advancement. It’s about remaining inquisitive, continuing to be relevant, and connecting to that part of the business that exists outside your cubicle’s walls.
If you’re keeping the proverbial lights on, you’re doing important work. But you also need to keep the lights on in that room in your brain where curiosity dwells. Whether it’s shadowing another department, picking up a new language, or just asking “What does your team actually do?” — it all matters and is important.
So if you get the opportunity to learn something new, take it.
And if you don’t, ask for it. Demand it.
Because “I already know enough” might be the most dangerous thing you can say when the company around you is evolving. And the job skills you need are evolving within that evolution even faster.
It doesn’t matter whether the outlay is time, money, or both. Just remember: If you think education is expensive, try costing out ignorance instead.
Like what you read? I write, rewrite, overthink, rewrite again, and eventually post these things in hopes they resonate. If something struck a chord, sparked an idea, or — most importantly — made you laugh, please drop a comment below. Sarcasm is welcome, cruelty is not. So be honest, and be nice. It’s possible to do both.
And if you'd like to support the effort (or just bribe me to keep going), you can buy me a coffee. No pressure — but caffeine is a powerful motivator.
Full disclosure: you can’t actually make me buy a coffee with your donation. I might use it for a beer instead.