Over the summer, my wife and kids went up to northern Wisconsin to visit family and do some outdoor activities. My older son was going to a summer camp in a couple of weeks, and we needed to get some medical forms to the camp. We called his doctor and asked if we could send her the forms from the camp, but she said she couldn’t accept those forms via email. She said there were standard medical forms on her website that we could fill out and send to her so she could release my son’s information to the camp, but we had to fax them.
Now, I have never set up any fax software on my laptop in … well, it’s been quite a long time. Plus, my sons wanted to get out of the hotel and over to the cabins where their cousins were from California, so they were getting impatient. Fortunately, the person at the front desk said they had a fax machine and would fax the documents for me if I sent them to her email account. Pressed for time, this seems like the best solution, so I went back to my room, filled out the forms and emailed them to her. I went back to the front desk and confirmed she got the documents, and off they went through the fax machine. In a couple of days, we confirmed the camp got the information and all was well.
Now, why am I talking about fax machines? Typically, fax machines are considered a “dead” technology. People younger than me (and there’s more of them all the time!) view a fax as archaic and “nobody uses them”. The issue is, they’re still in use by a fair amount of people.
The same thing applies to programming languages. We view COBOL as a “dinosaur” language. It’s extinct and nobody programs in that language (at least willingly). But there are still lots of programs written in COBOL that haven’t died out and are still being maintained. I’ve been to conferences this year where companies that sell COBOL IDEs have vendor booths. A friend of mine works at a company where COBOL hasn’t fossilized yet, and they still need to add features to these programs.
Sometimes I read blog articles where a developer loudly proclaims that they’re “moving on” from a particular language or framework. I’m all for learning new things — in fact right now I’m spending time learning Rust. Why? Because I’ve never done a lot of systems-based programming, and Rust seems like a language well-suited to that task. Plus, I’m hoping to learn some new things about programming languages that I didn’t know before.
But am I abandoning all that I learned about .Net over the last 14+ years I’ve been in that world? Of course not. If anything, my personal knowledge base will increase, and I can use these new ideas to enhance my .Net programming skills.
Technology doesn’t die; it just fades off into the long tail of obscurity. Keep in mind that the “fade time” can take years and years to happen. I’m not suggesting that everyone brushes up on COBOL, but that shiny new language that you’re coding in right now may end up feeling archaic in 5 to 10 years. Plus, applications that you’re writing in that language that you love and hold so dear may still be around and in use years after you leave.
Case in point: back in 2005, I had a client dealing with an issue with a VB6 application and they needed someone to come out for 1 day to assess the code and see where the problem was. I hadn’t touched a VB6 editor for years, but VB was something I did a lot of between 1995 and 2001. While I was no longer proficient in the editor, I was able to recall my skills rather quickly that day and figure out where the performance issue was in code. I have no desire to ever go back to writing applications in VB6 (it was shocking to see that the editor wouldn’t remember where my breakpoints were when I closed the IDE!) but having the ability to go to a client and help them out was a small win.
The moral of the story? Build upon what you know, learn new languages and stay current with technology trends. At the same time, remember that there may be opportunities where knowing how to get a fax out the door may come in handy. Until next time, happy coding!
This article is published as part of the IDG Contributor Network. Want to Join?
