DEV Community: Don Denoncourt

The Donut Scam

Don Denoncourt — Mon, 06 Jan 2020 13:09:33 +0000

When I was twenty two I was a systems operator for the Information Technology department of a manufacturing company. My hours were 10 AM to 7 PM. I was a fanatical fitness guy and I typically would run six to ten miles every morning before work. When I got to the office I was always ravenously hungry. The computer center was on the second floor. As I walked through the dozens of clusters of office desks on the first floor, I'd sometimes spot a box or two of donuts that still contained a few leftovers despite the late morning. I'd make note of the location and go to the computer center.

After about twenty minutes or so of initial work, I'd begin my donut scam.

The office was outfitted with green screen dumb terminals that communicated with an IBM System/38. From the S/38 I was able to view the status of all terminals. I could see who was logged in and if the machine was in a transaction. If a machine close to the leftover donuts was not in use, I would disable it. And wait. Soon I'd get a call about a nonfunctional terminal. I'd ask some questions and say I'd be right down to look at it. I'd also ask where they were located (even though I knew damn well the box was right by my coveted donuts.) I'd go down to the first office floor and fiddle with the terminal a bit. Maybe whack the side of the machine once or twice. I'd check the connection cables. I’m not sure (these were the 80s and my memory is fuzzy) but I might have gotten under the desk and looked up. I'm trying to say it was really obvious I knew what I was doing! Then I'd tell the greenscreenless team I needed to go back to the mainframe and investigate the communication status. A quick trip upstairs and one keystroke made the terminal functional again. I'd go back downstairs to the unsuspecting group and try it. Obviously, the terminal would be working just fine. I'd chat with the ladies a bit and then, if they hadn't directly offered, I'd -- for the first time - - coyly notice the leftover donuts. "Do you mind if I take a donut?" I'd politely ask. Sure they'd always say.

The pods of desks that I targeted for the donut scam were always populated by thirty- to forty- something ladies. Looking back, I realize that part of the scam was that I was a good looking twenty-something fit and muscular man (my wife assures me I used to be good looking.) Had the pod of desks been populated by men I'm quite sure they would have body blocked the donuts.

Unfortunately my donut scamming didn't last long because, after a couple months, I moved from second shift system operator to first shift programmer. But I wasn't running in the morning so hunger was less of an issue.

Nowadays, when I ask about spare donuts, co-workers look at me like they want to say: "I don't think you need a donut. Maybe you should go for a run instead." Plus the thirty- or forty- something ladies are a bit less than impressed with this sixty year old pudgy man. Anyway, the end of this story is now I must buy my own donuts.

One Too Many Monitors

Don Denoncourt — Fri, 13 Dec 2019 13:30:01 +0000

You have One Too Many Monitors

And if you do have only one monitor... It's probably too big. I work exclusively off my Macbook Pro. No external monitor. No mouse. I recently started a job where their twenty-five or so developers are treated well. Everybody gets the tools they believe will help them be productive. Even though I'm one of a half-a-dozen remote developers, I was required to be on site my first week. I got my brand new Mac and sat down at my designated work area. It had a monstrosity of a monitor, an external keyboard, and a mouse. The coder beside me was the guy that recruited me. I'd known him for over a decade. I picked up the mouse by its tail, dangled it in mid air and said: "What's this?"

My problems were just beginning. I plugged in the mouse and keyboard. Apparently, even after a couple years of rodent free development, I was still able to use a mouse. But when I plugged in the monitor, the iMax-like screen scared me. I yelped and pushed my roller chair back into another programmer (who was otherwise happily coding on a similar Mac and monster screen configuration.) I apologized and rolled back to my workspace. I figured I better use this somewhat standard configuration or I'd look like I was more familiar with mainframe mouse-less green screens (of which I am very familiar.)

A half-day later I unplugged the mouse (resisting the urge to step on it) and disconnected the keyboard. Moving my hand continually away from the keyboard seemed a waste of time. My thumbs worked the Mac trackpad quite effortlessly. But I kept the iMax screen attached. I was being on-boarded by my friend and the monitor made it easier for him to see my screen from his pod beside me.

The next day, I gave up on the monster monitor. I unplugged the screen and happily went back to the workspace configuration with which I felt most productive: the MacBook Pro monitor, keyboard, and trackpad.

What's my deal with monster monitors?

What was wrong with the endless real estate of a grandios monitor? Developers love them. My nephew, a Drexel grad, has three of them -- forming a one eighty around him -- in his home office. Let me give a quick rundown on my issues with the iMax monitor madness before elaborating in detail in the remainder of this post:

1) The font was too big and my eyes labored over them like text on neon signs.
2) The width of the editor was too wide, my eyes tired from incessant movement, and I was less able to grok code quickly.
3) The browser and editor windows were so far apart that my neck tired from side to side movements.
4) Noise. The voluptuous windows of the editor, browser, Slack, bash, and documentation were distracting.

Balderdash you say. Studies have shown that developers are more productive with, not just big monitors, but multiple monitors. Understand that these studies were financed by monitor manufacturers.

iMax and monster monitors are great for big scenes. We've been viewing big scenes for several hundred thousand years. Our brains evolved to process that pictorial style of information. But we've been reading for merely hundreds of years. Written words, maybe 9,000 years, but alphabetical, phonetical systems have been around far, far less. My point is that the human brain hasn't evolved to the point that it can comprehend some four to five hundred square inches of text as easily as it understands graphics.

As to multiple monitors -- my chickens can process two monitors at the same time. But their eyes are at the side of their heads to look for predators. We humans have eyes at the front to focus on one thing.

Consider the Real World

Hundreds of years ago, when printers began to mass produce books, a page size was carefully selected. That page size has been extremely successful and it is one we know and expect today. Web designers know this. Try as you might to expand your browser of a well designed page to the full width of your iMax-like screen, the text stays at the accepted standard of a readable 45-75 characters per line.

Quick tip: if you are reading text you'd like to comprehend and it doesn't wrap at at least 95 characters per line, narrow your page and things will come to you more clearly.

The Benjamin Franklins of the world -- a few hundred years before today's mega monitors -- knew what they were doing. They figured out that you should not have to move your head to read. Furthermore, they understood that you can only comprehend so many words at one time. Think about the limit of short term memory: five to seven things. If the average word length is say five to nine letters and you divide your character width of 45-75 (or up to 95) characters, you get your five to seven things. Especially when you consider your brain clumps (in a process known as chunking) words into single concept phrases. Five to seven clumps and that line break comes at the perfect time because that brief pause from consumption gives your brain an opportunity to digest those words into information.

The Kindle reader on my Kindle Fire 10 and iPad automatically switches to a two pages display when I switch to landscape. Why? Because the designers at Amazon and Apple know it's easier to read when line lengths are a comprehensible 65-95 characters.

Still skeptical? Consider shop and industry standard for statement length limits in code. Typically the limit is around 80 characters. Those limits are for comprehension. If you agree that 80 characters is a reasonable limit, why would you need a monitor that supports line widths that would show short stories in a single line?

Code analyzers (like Rubocop, for Ruby; or eslint, for JavaScript) check not only widths but also height. JavaScript length limits are around 100-500 lines but Ruby constraints are often only 10-30 lines per method with total file length of 150-250. These coding constraints evolved because we've learned too deep and too wide is too much [to comprehend].

Information Overload

Certainly you don't read one file at a time. You need to look at several. Perhaps code for a model, controller, and a view. And perhaps coding examples from another application. But it's often more than that. You a!so want to see the rendering of that page in a browser. You may need documentation in yet another page. And you need a shell session. All that stuff, you tell me, fills up your monster monitor.

But all those open windows cause your brain to go into information overload. Your eyes and concentration get all befuddled and confused. It's kind of like you're playing whack a mole. There it is. No over here. Your head moves back and forth and you get nothing done. What you need is to limit the mole holes to a manageable couple. Some holes close to one another... where you can just whack that hammer back and forth between two mole holes. Bam. Got it!

If you reduce your whack a mole holes to a manageable three or four, you can master the game. Leave the holes -- the windows -- at nine or so and your eyes unconsciously travel over every hole looking for that damn mole. You eyes, and brain, waste time glancing at windows even when you are pretty sure a hole won't produce a mole. Basically they are noisy distractions.

It boils down to focus. I think of it as view ports. Think of filmmaker putting up their index fingers in the air with hands joined at the thumbs. They are limiting the view port to focus on what is important. Like blinders on a horse.

I've established that there are often times where a half a dozen files are part of a contextual problem. You need to compare files. Understand that the human brain has problems choosing between more than two things at one time. Even with copious amounts of screen real estate at your disposal, you really should only be focused on two files at one time. Context should be split out into tabbed editor sections.

My layout

Code Editor: I put my code editor to the top left of the screen. It takes 40-60% of the screen real-estate.
Browser: My browser I put on the top right.
Shell: My bash tabbed terminal session goes in the bottom left.
Slack: Slack goes in the bottom right and is most always (but for one character height) is overlayed by the browser or bash window.
Others: Like Activity Monitor, SQL Editor, and Evernote, get plopped in the middle and are closed as soon as I’m done looking at it.

First note that I hide the top menu on my Mac. That gives me an itty bitty bit more real estate. If I move my mouse up, the top menu appears -- otherwise you don’t need it... as it’s just noise.

And I also shrink the dock icon size.

Editor

I could write a whole piece on my editor of choice -- Mac Vim. But I’ve seen too many other developers with better Vim development strategies so I won’t be writing that piece. Nevertheless, I will summary my strategy here. I open one Mac Vim session per application and make sure I overlay each vim application window. Command-tilde toggles quickly between Vim application editor sessions. Every now and again I might drag a Vim editor window to the right side of my screen for comparison. I use Vim tabs with veritical and horizontal split screens heavily. All editors have similar vertical and horizontal code splitting features. Yet I still see folks with too many tabs open for each of the dozens of files they’ve taken a look at. I put vertical and horizontal split often for code that I’m working one. For instance, unit test code goes at the horizontal bottom with the code it tests above it. When copying or referencing similar code, I use vertical splits.

Back to my comment about viewable height of code, If I have a huge file I split the source or use folding option. Most IDEs have this feature.

When my Mac Vim tabs get past 3 or 4, I close some. If I have a crazy amount of splits in one tab, I close some sections. If I have a beautiful set of split code windows showing insightful information, I take a screenshot and name the image appropriately. Then I close some of the splits back to a more comprehensible number.

Browser

For my browser, I use the Chrome pin feature and put my common use tabs to the left: email, corporate docs (Confluence), project management (JIRA), and calendar. I open standard tabs for other stuff. Here’s my rule for tabs: If I can’t read the titles, I have too many tabs open and need to close some. If you have a bunch of really, really important tabs you think you need open, I say book mark it. I use the bookmarks bar for heavily used links and I abbreviate or completely remove the textual title. And then I make good use of nested bookmark folders (as I covered in Relearning to Learn ). Sometimes, every so often, I’ll pull a tab into its own browser window -- so I can compare it with another -- but I put it back as a tab when done.

Bash

I use a single tabbed bash terminal window. Typically I have a tab for each application running in a Docker session, I probably resize my bach window more often than any of my other Mac application windows. Typically the only line of interest in a bash session is the last line output from a running process. So my bash is typically (but for the last couple of character lines) overlayed by my editor window. I resize my bash window if I’m using a debugger or browsing through logs.

Slack

Slack is a wonderful piece of software. But it is noise as it provides the human interaction we all crave. If I see a message pop into a channel, I can’t help but read it. It may be that someone’s cat did something funny and I can’t miss that! So I make sure Slack is overlaid but for the bottom. And, even then that’s only so I can quickly thumb mouse and click to open it -- when I’m ready for distractions. I enable Slack notifications for important channels.

I always use a crisp san-serif font (SF Mono Regular for Vim and bash and I love Kindle's Bookerly.) A bit of an aside on how I remember what san-sarif is: Omar Sarif was the mustasiod man of Dr. Shivago and Lawrence of Arabia (if you aren't a boomer and haven't watched these movies, you need to.) He had a thick richly curly mustache. San means without so pick a font without thickly curly mustaches. Sorry Mr. Sarif, you can be on my big screen TV but not on my text as code on my Mac.

I also use an easily readable font size. That would be two-thirds times bigger than the smallest you can read. If you visit Mozilla Fonts You can see what size works well for you. For me the smallest font size I can read is 4 so that suggests that I should use 8 or 14 for my standard font size. Note: as my old eyes get tired during the day, I increase my font size. The Control plus (or Control minus) works in most apps on my Mac including Vim and Chrome.

For code reading, as to color, myself (and eyecare professionals) recommend black on white or black on yellowish better than dark mode. The only time I use dark mode when it is, well, dark, where I am working.

Transient Applications

My transient apps include Evernote, Activity Monitor, and an SQL Editor. So I can open them easily, I put them in the Dock. And I close them as soon as I am done the one-off task that I’m using them for.

Close It

Regarding applications and tabs, if you don’t know why it's open, close it.

All those open and viewable Windows are noise distractions. Close or overlap them. In the early 2000s I did a lot of onsite training. I found many developers would maximize their editor on their screen. I would say to them: "You aren't running Microsoft Windows, your running Microsoft Window." And then I'd recommend tiling application windows. Do you really think you need to compartmentalize with multiple monitors? Try virtual desktop options. Turning your head is harder than a simple control key stroke. When I was a free-lance contractor I used a virtual desktop for each client.

I do have to admit that a big reason I like to do Mac-only development is freedom. As you can see from the chicken photo above, one of my offices is my front porch. Another one is my hammock. I have the freedom to work anywhere: the beach, the doctor's office waiting room, or at the park. I'm not hampered by the unjustified requirement of an external monitor.

The Lying Desk and the Patate Technique

Don Denoncourt — Sat, 02 Dec 2017 15:32:04 +0000

The Lying Desk and the Patate Technique

We hear all about the stand up desks and even the treadmill desk. The shtick is that sitting at a desk is the new smoking. Well, that's all well and good, in terms of movement, exercise, calories, and such but understand that sleep is more important than exercise. Actually, experts say they are equal but they always list or say "sleep" before "exercise", so there you go.

Introducing the lie down desk. You can do it on the floor but I prefer a good couch.

The Patate Technique

My brilliance doesn't stop with the lie down desk: We all have heard of, and many of you may practice, the Pomodoro technique. Well, I'm ramped the Pomodoro up -- by reversing it. Instead of working for 25 minutes and then taking a 5 minute break, I nap for 25 minutes then work for 5. I call it the Patate technique (patate is Italian for potato and is basically the opposite of a tomato.)

It’s impossible to overemphasize the importance of sleep. Don't trust me. Listen to what world-wide expert on sleeping, Jim Gaffigan, has to say: "Given my passion for sleep, it is no surprise how I feel about naps. I believe in Naps." Gaffigan goes on about the importance of naps with: "I understand that naps are usually reserved for babies and old people, but I don't discriminate."

You're probably thinking: might all that napping during the day mess up your sleep at night? Well, that's the beauty of the lying desk and the Patate technique. I'm so rested after a day's ~~hard~~ work that I can use late night to do what is truly important in life: Facebook, binge watching Netflix, Snapchat, Twitter, and texting.

On Getting Old(er) in Tech

Don Denoncourt — Tue, 10 Jan 2017 22:26:12 +0000

After years of scoffing at talk of prejudice in the information technology field -- as a white male with good hair --, I'm starting to call prejudice against my being old(er). It's true: age discrimination is a real thing.

Since 2008, the number of age discrimination complaints has grown to around 25,000 a year. Some may argue that everywhere we turn these days, someone is complaining about something being unfair. Alright. Let's not just take complaints into account. But rather, let's look at the average age of IT workers at well-established companies. Facebook: 28. LinkedIn: 29. Google: 30. To put that into perspective, the average age of all U.S. workers is 42. Well above the average age at these companies. Even Mark Zuckerberg once publicly said, at an event held at Stanford: “I want to stress the importance of being young and technical. Young people are just smarter.”

By my clock, it's 3 till 60, so, yeah, I'm starting to get touchy about this topic. Having the insight that white -- mustache -- hair brings, I'm in a good position to debunk the younger is smarter philosophy. Allow me to point out what I've done throughout my decades of work -- yes, decades plural -- to stay employable, and share with those of you who are getting older (which is everyone), what you can do to avoid being put out to pasture once you pass 30.

No Country for Old Men?

“Younger people are smarter. Balderdash. So that means companies shouldn't hire Sandi Metz, Kent Beck, or Uncle Bob Martin? All 30-year veterans. “They're just anomalies. Not in my experience.

Six years ago, with the help of John Staler, I developed kettlerusa.com. I did the Groovy and Grails front-end, and John did the RPG back-end. John is one of the best programmers I've ever worked with. Yet, John has been around for... quite a bit. Let me put John's age into perspective with a quick story: I'd regularly test checkout by buying kettlerusa.com's cheapest product: ping pong balls. I'd often forget to cancel my orders, which resulted in the delivery of numerous packets of ping pong balls to my house. Anyway, Captain Kangaroo was a popular children's TV series from 1955 to the mid-'70s. The Captain regularly had ping pong balls dropped on him as a prank by his moose friend. One day, I made a Captain Kangaroo reference to my growing stock of ping pong balls. I assumed John had watched the show. But, when I saw that he was confused about the reference, I described the sight gag to him. John responded: "Don, I grew up without a TV. It was the early â€˜50s." That's right, not only was John pre-Node.js, pre-Ruby, pre-Java, and pre-Internet, he was pre-television. Yet, you aren't going to find a better programmer -- RPG or otherwise. Not even including the self-proclaimed "smarter" 30-year-olds and younger.

Yeah. OK. So he's RPG. Want an example where the programmer codes in something other than “antiquated RPG? How about HTML5, JavaScript, and C#? Then, read my blog post on Jim Stanicki, the guy that got me into this field back in the early â€˜80s.

20 Years of Experience Versus 1 Year 20 Times

When I hear someone say they have 20 years of experience, I wonder if that's really true or if they merely had 1 year of experience 20 times. I've known too many developers that used the same techniques they learned in their first year of employment for the entire span of their career. I found this to be true in the IBM AS/400 RPG marketplace with 40- and 50-year-olds, but I've also found it to be true with 30-something Java developers. In the early 2000s, I traveled the country teaching Java seminars to RPG developers. I had expected that those RPG developers would be familiar with modern modular RPG programming techniques, but what I found was that most of them were still using old-school RPG. They had stopped enhancing their core skill set -- much less acquiring new ones. Then, between 2008 and 2010, I was training Java developers at Circuit City on Groovy and Grails. These folk were mostly late 20s and early 30s, and they were just fine sticking with good-old, write-everything-yourself, don't-bother-with-frameworks, Java.

My point is certainly not that these younger developers were smarter. It's that many programmers let themselves grow stale. And the bigger problem is, after doing the same year's worth of experience ten times, many programmers forget how to learn. Not only can it be extremely hard to catch up with ten years of technology, it can be next to impossible if you've forgotten how to learn.

If you plan on being in the IT field for more than 10 years, you need to be a lifelong learner. I've always been a lifelong learner. I've learned and developed with numerous programming languages, frameworks, and strategies. As a result, I've honed my learning skills. Case in point: I've been told that you can't learn a second language when you're in your 50s. I'm here to tell you: that is false. I started teaching myself Italian when I was 52. Now, I read and listen to novels written or spoken in Italian on a daily basis, and I'm way past “conversational Italian. And so, for me, learning another programming language or framework is a piece of cake.

Only as Good as Your Last Two Years of Accomplishments

Kent Beck has suggested that, with consistent use of pair programming, the capabilities of programmers don't differ much after two years of experience. Understand that this is in an environment where techniques and skills are seamlessly shared. An environment where the secrets of veterans become common knowledge. My take-away, when I first heard this decades ago, was 1) pair and otherwise compare myself to other developers as often as possible, and 2) don't think that my decades of experience guarantees marketability or warrants higher salary.

I often say that I'm only as good as what I've accomplished in the last two years. I could tell you about all my accomplishments over three decades, such as replacing the use of a System/3 punch card system with the AS/400, writing a Cobol debugger, or…. Ah, I'm boring you. What you do care about are things I did in the last two years. Things like: learning and developing with ElasticSearch, configuring multiple applications on AWS OpsWorks, setting up Docker for multiple client applications, converting Rails 2.x applications to Rails 4.2, upgrading Ruby 1.9 to 2.2, and making more effective use of Git and, more specifically, GitHub.

Forget my age. I'd be willing to bet that my list of accomplishments in the last two years rivals any 20-to-30-year-old's. The perennial question then is: what am I going to say are my accomplishments two years from now?

How Developers Can Make Those Two Years Count

Learn, adapt, and learn some more

Treat this year as if it were your first year as a developer and assimilate everything you can. Reclaim the energy you had in your first year of coding. Regain the drive you had to prove to yourself and to your employers that you were “all that for this IT field. Resume reading about tech, playing with new techniques, and persuading others to teach you. Reacquire the excitement of collaborating on newfound knowledge with other developers. Be a lifelong learner and investigate all forms of learning, including:

Podcasts

I like Greater Than Code and The Bike Shed.

Webcasts

Ruby coders continue to love RailsCasts and, I've lately been enjoying Ruby Tapas.

Magazines and newsletters

I subscribe to: InfoQ, Ruby Weekly, DZone Daily Digest.
I also subscribe to ThoughtWorks Radar to stay on top of what technologies are hot.

Online interactive courses

I was a Rails instructor for CareerFoundry, but there are hundreds of options available.

Conferences and seminars

Try to get to one conference a year. Understand that you often learn more in conference hallways than you do in the sessions.
If you can't get to conferences, take advantage of the fact that many sessions are available online. I recommend confreaks.tv/conferences as it lists sessions from dozens of conferences.

Blogs

Follow a few quality blogs -- like the Corgibytes blog and Giant Robots Smashing into Other Giant Robots -- where you're notified of new posts.
Have your own blog and post regularly. Everyone comes up with solutions to problems or has an opinion that others would benefit from. Plus, writing a blog post solidifies your knowledge.

Also take the time to discover and leverage what kind of learner you are. Do you learn best from books (that's me) or do you need a classroom environment? Are you an audio learner? Whatever your learning style, try to learn something new every day.

No work is an opportunity to learn

Being between jobs is no excuse for not learning new technologies. You don't have to be employed to get experience. Do your own internet startup. Platform As A Service (PAAS) hosts, like Heroku and AWS, can be free or almost free. Come up with some goofy idea and flesh it out. Put it on GitHub as a public repository so others will see it. Do the whole cycle from backend database and maybe some NoSQL and a simple front-end. Later move that front-end to a single-page app like Ember or React or Angular. Add checkout with credit card processing.

Here's a bad idea for a startup, but one that would give you loads of real-world experience: Virtual Lemonade. Create a site where someone can use their phone's current location to see what lemonade stands are available. That means you'll need Global Information System (GIS) enablement and a database of stands. You'll need server-side code and then client-side. And then, you'll need to provide the ability for kids to register their stand with your service. Maybe give them notifications of a traveller looking for a stand so they can say they are open. You may not become the next Zuckerberg, but you certainly will pick up a full gamut of marketable skills.

Be and look fit, but don't worry about looking younger

I don't think, as some career counselors recommend, that you should try to look younger with hair dye or plastic surgery. What you should do is exude energy. To remain relevant in an industry that seems fixated on youth, it's crucial to be spirited. And an overweight 50-something wheezing smoker does not suggest vitality.

A year or so ago, I was attending a two-week training session with about a dozen 20- or 30-something developers. The training was on the 22nd floor and, every day after we came back from group lunches, I'd always take the stairs. The first day or two, one or two of the kids would join me, but I got no repeats. It's pretty hard to be considered a has-been when they can't keep up with you.

Don't go overboard just to prove a point. Be yourself. Only, your best self. Fitness can be as simple as a daily brisk walk. Maybe stuff in your earbuds and listen to a tech podcast on that walk. I watch webcasts while on the crosstrainer at the YMCA, and I listen to podcasts while unicycling. I prefer lunch workouts because it clears my head in the middle of the day, and I'm refreshed when I get back at it in the afternoon.

I don't believe you should go to extremes to look younger. I could look younger simply by shaving my white mustache off (the hair on my head is full with only a few flecks of grey). But I earned those white hairs and wrinkles; they're badges of experience. I once had someone say to me: “The eighties called, they want their mustache back. “Well, I quipped, “This mustache is from the eighties, so I'm keeping it.”

Be interesting

I don't care what age you are, if you're a couch potato, I guarantee that you will elicit boredom in an interview. Be interesting... to yourself. Everyone benefits from hobbies. It doesn't matter if others think your hobby or passion is odd or a bit off. For example: I keep bees and ride a unicycle. I also know civil war reenactors -- which you'd have to pay me to do --, but I find these people fascinating. I'm sure, if you don't already have a hobby, you have interests that you just haven't turned into hobbies. Having a hobby is essentially a fun form of lifelong learning.

Be upfront about your age

I feel that you should provide clear indication to potential employers what your general age is so you can weed out age-discriminatory employers. Do you want to work in an environment where they look at you as dead weight or one that values your energy and experience? Here are the first two sentences from my cover letter to Corgibytes: “Your team is looking for someone with â€˜7+ years software development experience' and a â€˜Polyglot programmer with skills in 5+ programming languages and 2+ frameworks.' How about 7+ years of C/C++, 7+ years of Java, 2+ years of PHP, and then 3+ years of Ruby (not to mention 7+ years of RPG and Cobol, otherwise, you could do the math and guess my age). So I gave a tongue-in-cheek account of my age in the first paragraph.

Take a cut in salary for new opportunities

I have taken big cuts in salary three or four times in my career. I'm talking 10-20 thousand dollars a year. And not because I was out of work. I left existing jobs because I did not see myself growing technically in those positions. I've also turned down big salary jobs because I felt they'd stifle my technical growth. Some of my job changes ended up, arguably, being bad choices as they ended up being dead ends, but I make sure that I always walk away from a project with accumulated and marketable knowledge.

I've seen too many people lock themselves into technologies (like Lotus Notes and Domino) and find themselves unmarketable after spending 10 years in that industry. Even if you have a high-paying salary, don't let the tech world pass you by. Be sure to be up on the latest technologies. And, if you can't do that at your current position, maybe it's time to move on.

Be Forever Young

As I mentioned earlier, yes, age discrimination is here and real. Our bodies get old and some -- like Zuckerberg -- will use that against us. But the biggest mistake would be to compound that by letting our minds and spirit get old as well. That is where we can stay "young."

Bob Dylan said it best:

"May you build a ladder to the stars

And climb on every rung

May you stay forever young"

"May you grow up to be righteous

May you grow up to be true

May you always know the truth

And see the lights surrounding you

May you always be courageous

Stand upright and be strong

May you stay forever young"

"Forever young, forever young

May you stay forever young"

Note that when Bob Dylan released his 33rd album, Together Through Life (which climbed to number one in Britain), he was 68 years old.

Hi, I'm Don Denoncourt

Don Denoncourt — Thu, 05 Jan 2017 20:45:03 +0000

I have been coding for 35 years.

You can find me on Twitter as @denoncourt

I live in Richmond, VA.

I work for Corgibytes

I mostly program in these languages: Ruby, Groovy, Java, and JavaScript

I am currently learning more about Python and Django.

Nice to meet you.

DEV Community: Don Denoncourt

The Donut Scam

One Too Many Monitors

You have One Too Many Monitors

What's my deal with monster monitors?

Consider the Real World

Information Overload

My layout

Editor

Browser

Bash

Slack

Font Size

Transient Applications

Close It

The Lying Desk and the Patate Technique

The Lying Desk and the Patate Technique

The Patate Technique

On Getting Old(er) in Tech

No Country for Old Men?

20 Years of Experience Versus 1 Year 20 Times

Only as Good as Your Last Two Years of Accomplishments

How Developers Can Make Those Two Years Count

Learn, adapt, and learn some more

Podcasts

Webcasts

Magazines and newsletters

Online interactive courses

Conferences and seminars

Blogs

No work is an opportunity to learn

Be and look fit, but don't worry about looking younger

Be interesting

Be upfront about your age

Take a cut in salary for new opportunities

Be Forever Young

Hi, I'm Don Denoncourt