The wisdom from the previous century

That was a rainy Thursday afternoon. After a great surf session, I headed to pick up my wetsuit from repair. I broke the zipper, and instead of throwing it away, I decided to get it repaired. The other reason was that I was too cheap to buy a new one, but I prefer to think it was a purely eco-driven decision. When I arrived at the destination, I quickly chatted with the lady who fixed my broken zipper. Instead of replacing it, she just reversed it. Pretty clever, I thought. Then she educated me on how to care for my wetsuit, pointing out what I had been doing wrong for the past five years. Lesley was a woman in her late sixties, brilliant and opinionated. After a few minutes of conversation, she told me she would fix some minor cuts on the wetsuit, probably because she couldn’t stand my ignorance about its condition. While waiting for the glue to harden, we continued our friendly conversation. We touched on politics and the current situation in Ukraine, and she looked at my previous wetsuit fixes. “Terrible” was the short review I got, and I knew she was right. It was an awful workaround that did the job, but it was not something I should be proud of. I finally told her that I’m a programmer as the conversation continued. “I used to code as well between the ’70s and ’90s,” she responded. That was something I didn’t expect to come, and it was very exciting at the same time. I’ve never met anybody who was programming back then. I eagerly asked questions and listened to many stories about the IT industry from the last century.

That was a different world back then. The machines had minimal memory, and nobody even considered the concept of immutability. Every byte mattered, and efficiency was the main driver. She used languages like Fortran and Cobol, which I think are imperative ones. No Lisp nor other functional or early adoptions of OO. It was a bit surprising for me at first, but I can understand that they needed a much more direct way of instructing the machine back in the days. Being declarative comes with costs if you start thinking about the constrained environment’s performance at that time. The imperative approach was the most significant difference I found in how I look at coding in the early 2020s. I believe immutability and composability are more critical than memory consumption. It is not the bottleneck anymore. I would never consider super short variable names to save memory, and sometimes I prefer to iterate twice over a short list if it adds clarity to the code. Those were not the options in the ’70s and ’80s.

Those things have changed, but the fundamentals remain the same. We both agreed that code is for people to understand and maintain, not just for machines to run. Leslie described the strict frameworks and patterns she used to name and organise the code, which made her code stand out and helped other people quickly introduce changes with confidence. Full of curiosity and admiration, I listened to the stories about when she spent long hours delivering a bulletproof code within the limited time that saved her company a ton of money. I could hear the passion in her voice, and I saw that she loved what she used to do as much as I love what I do today.

She mentioned parallel testing, which I didn’t understand. Still, I imagine it was some semi-automated way of ensuring all works as expected before pushing it to production—something we do these days as part of Continuous Integration. Back in the 80s, there were not that many programmers, and I believe, on average, they were much brighter than we are today. They didn’t have the resources, scale, and hardware that we take for granted, but they had a lot of brainpower per person.

After chatting about the technicalities, she mentioned something that I hope to prove wrong someday. She said something along the lines of “This is a young man’s game”. She advised having a plan B in case I’m no longer welcome in the programming community. However, I hope to steer my career from coding to architecture and remain technical for the rest of my life. If I fall out of the IT train, I will take the advice to have something that can provide me with income. I know that thinking, “This time it will be different,” is highly naive, so I will prepare for the dark days while hoping for the best.

Once again, I’ve seen that if we let people speak and listen to their stories, we can discover that the world is a much better and more exciting place than it initially appears to be. “While talking to people, always assume they know something you don’t”, I’m paraphrasing, but I’ve heard something along those lines in a TED talk about the good conversations. I firmly believe that this is one of the best ways to make our discussions more engaging and productive.