Remaining Relevant Over Four Decades
Four decades is a long time to be a programmer. I started in 1981 and retired in 2021. During that time, almost everything changed, and I had to change with it. While my situation may be different than starting today, much of what I learned over time can still be helpful to programmers today.
Keep Your Eyes Open
Every day I worked, I started by reading about technology and anything new in programming. Before the Web existed, it was magazines, journals, catalogs—whatever I could find. The Web made it much easier to read things. I never read just about whatever I was doing, but anything even remotely interesting, even if there was no apparent need at that moment.
By spending 15 minutes daily, I could see trends, notice things long before they became popular, and better understand what to learn more about. It seems trite but is very powerful, though admittingly more complicated today as there is so much new every day you can't see more than a small amount.
This helped me learn C as the future in 1984, object-oriented programming in 1985 (I added my own extensions to C in 1988 for Deltagraph), and Java 1.02 (I tried to drag the consulting firm I worked for in 1999 to switch to Java). I learned about XMLHttpRequest and immediately began building something akin to single-page web apps before there were any useful frameworks (for which I got yelled at by the rest of the architecture team for supposedly buying "new" technology). I studied Swift when it first came out; in my last job in 2016, we had the first working module in our two main apps that were not in Objective-C.
Of course, you can't guarantee you will see the future early, but by keeping up with a broader sense of what is happening, you will likely be ahead of most of your peers who only focus on their immediate needs.
I have known a lot of programmers who either failed to learn anything new or were openly hostile to any other technologies. A friend spent his career doing systems programming on IBM mainframes; when his employer eliminated them, he could not switch to anything else and had to install networks. A team at the financial services company bragged how great their 4GL tool was and laughed at the "stupid" Java programmers. A couple of years later, they were no longer employed as programmers. It's even more critical today to learn something new, as things change a lot, and unless you have a broader skill set, you might be less employable.
All of the programmers I knew in the 1980s ended or are ending their careers supporting obsolete technologies, switching to management, or switching careers. Nothing is wrong with being paid to do boring technology—it still needs doing, and many industries don't change much. However, if you want more meaningful and interesting work, learning is a must, and it was for me.
Most programmers never get the chance to start a project from the beginning without any help and see it through to shipping and even many major releases. So today, most programmers work on something others started, organized, and designed. Having that responsibility is not something everyone wants—but it is a great teacher, even if you fail.
I started two companies in 1985 and one in 1987 until 1994 building Trapeze, Persuasion (for the author), and Deltagraph (for the publisher). We kept it going for 9 years, and the experience was amazing even though we couldn’t continue during the Mac slowdown after 1994. Being President, lead programmer, product manager (or one of two), and UI designer was a great teacher.
In one way, my experience is not likely anyone who started their career in the past 20 years: I started in the early 80s when there was no Web, no blogs, few books or magazines, no email or cell phones: I had no one to even ask for help, so I had to figure everything out myself. No one can get that today, having to depend solely on yourself. Today the problem is that there is too much information, and the real skill today is to find the needle you need in the haystacks of useless or incorrect help. But, of course, I still prefer today, where you can find almost everything you need, assuming you can cut through the noise. Sometimes the code I write for my art feels like the old days in that there is little to help me, and I get to be creative again!
Make A Difference
I always looked for jobs where I could make a difference, as I never wanted to be one of a thousand programmers. The Googles and Facebooks of the world never interested me, as I could never make a difference there, just be a warm body in a seat. I preferred to work in small teams or even being the only programmer, working in jobs where nothing was cast in concrete, often where no one had any idea how to do things, and if I was successful, I could see it. I started many projects from scratch where there were no standards, pre-conceived process, or even any idea of how software should be made taught me a lot about how to organize software projects. It's also much more fun to do!
Working for a big company where you are part of a large, established team is not bad when starting, but you should try finding jobs where you can have more individual responsibility and extend yourself beyond what you think you can do. Even in positions where I wasn't expected to do anything but what I was told (generally the few contract jobs I had), I still tried to find something I could add to improve things or fix something broken even outside my area. The shortest contract I ever took was two weeks long to help fix a few bugs before a release (email client/server for Mac, the mid-90s). Despite the short-term and mundane need, I dug deep into the code and discovered the entire low-memory handling code had been disconnected, leading to many crashes for several releases. They took me out to lunch on the last day!
You don't have to do anything special, but it is personally rewarding, and you wind up being more valuable and individualistic, sometimes leading to new opportunities. I got the job before my last one because ten years earlier, I had done something special on a customer's project, and the CIO I was interviewing with remembered it and hired me on the spot. In the job before that, when our manager left to work for the big company my final position was at, he offered me a job there before he even started (it did take more than a year to make it happen). It won't always work out like that, but going out of your way to make a difference is still a good plan.
Don't Settle For Bad Jobs
Not every job I took turned out well. You should never stay at a crappy job, no matter how much they pay you. Two places where I worked turned into hostile workplaces. Several employers went out of business (one ended at 4:30 on a Thursday when we were told we had 20 minutes to exit the office), and I was laid off a few times, often before the company or division ended. Sometimes the job seemed exciting when I took it, but I eventually found it was a seriously lame environment. Unless the market is terrible for programmers (like in the early 2000s), there is a much better job elsewhere. You might have to be patient when looking if you can wait. Life is too short to work in a horrible job!
In conclusion, keep your head up and pay attention to what is new, keep learning new things, look for positions where you can make a difference, always try to find something you can do to make things better, and never settle for a lame job.
Four decades is a long time, and even though I can't tell you what programming will be like in the future, I can confidently say everything will change, and while programming will not vanish any time soon, it will be different. When I started, almost nothing existed that today we all depend on, and I had no idea about the future, but I learned very quickly that I could never settle and stop changing.
In my previous blog I used the metaphor of a steamroller rolling behind you as time progressed; if you stopped and thought you knew everything, it would run you over. Keep moving!