“There And Back Again Lane” — Past Present and Future from 3 senior IT professionals.
Working around 25 years in our field (IT and software development), I started to look back and think about what did change and how. I decided to try and give a unique perspective from different angles: frontend, backend, and operations. I asked two past colleagues and good friends, to answer some questions about the past, present, and the future of our field.
I know Gidon Miller and Liron Blecher for many years, I worked with both of them in “Voltaire”, and “Qlusters” in the mid-2000s. In the last couple of years, they became friends, and we like to exchange ideas online (and when i visit Israel offline) about many things from geek culture, and since all of us are working in the software industry, there are always debates about that. I decided that the community can benefit from our talks, and made them in an interview. I hope you will enjoy it.
Tell us a bit about yourself and your experience?
Yair: I am Yair, I am working on our field for 25 years on and off. I worked in the past as a network administrator, system administrator, QA engineer, and DevOps expert. My first technological job was doing telecommunication for the IDF.
After that, I worked for seed startups, big corporations, and various verticals. I studied for MA in German history of thought.
Liron: My name is Liron, and I’ve been developing for the past 15 years. Most of that time was spent developing UI — initially in Java and then transitioning to Web development. I began working for large enterprise corporations and later moved to small startups. I also have been teaching Java and Web development for 6.5 years in Tel-Aviv Academic College. Luckily I still really enjoy coding for a living.
Gidon: I’m a 45-year-old backend developer with a degree in CS and philosophy. I learned to program in the IDF, where I worked on real-time embedded systems. I then spent my career climbing up and down the stack from the kernel in c to networking applications in Java and c++ and most recently distributed computing in the database space in python. In the past ten years, I’ve been mostly managing coders rather than being one.
When you think about your first role and your last or current role, what is the most significant change you feel happened?
Yair: My first role was network administrator, and my current position is DevOps Lead. From my perspective, two things have changed; Agility and Physicality. Everything in the 90s was so much slower, imagine that every server you ordered was real hardware, and were shipped to your office. Deployments could take weeks, and the whole notion of time was different.
We used to deal with a lot of hardware, building and replacing units in our computers, fixing and making network cables. The work was more physical, and many times you had to go to the data center to fix a problem physically.
Liron: My first role was implementing a parser for cell tower logs — a classic task for someone who just finished a CS degree. My last position was building a new UI for a system from the ground up.
For me, the most significant change would have to be the end-user — after that first role, I requested to be assigned to the UI team because I wanted to see pixels on the screen (and not just text in terminals).
During my career, I realized that it’s not just the pixels on the screen that matter but what they convey to the person using it.
Gidon: The most significant change has been in the role and perception of developers in organizations. Twenty years ago, developers were seen as an executive arm of managers and product-managers. Their input was less valued, and the only way to make your mark was by climbing the management ladder. Today developers have a high cultural standing, and this also applies to their role in companies that are much more central.
Can you describe your biggest challenges back in the day and now?
Yair: I think in the past, my biggest challenge was to promote a sane culture where i worked. People worked under extreme pressure and long hours. I think this one of the reasons why I burned out so many times in the past.
Now my biggest challenge is to find the right tools for a specific task. There are too many opinions and a lot of the documentation and professional books that are not well written, and it’s hard to trust and or understand how a new tool would fit your needs.
Liron: Throughout the years, my biggest challenge was the realization that there are a lot of factors that come into play when deciding which features should be implemented — marketing, competitors, and big customers requests, to name a few. Not all the code that is being written is for the sake of making a system work better.
Gidon: Since my role has shifted from development to being a manager, my daily challenges are very different. I do miss being a full-time developer and intend to go back in a year or two.
Can you think a bit about how your daily routine changed?
Yair: It was much more strict back in the days. We were expected to be physically in the office at certain hours, and if we were late, we had trouble with our managers.
Weirdly, one of the primary metrics for a “good” employees back in those days was the amount of time you spent in the office. We had no option to use other people’s code and examples or git clone repositories because the information on the internet was scarce, so we invented the wheel many times.
Liron: The number of technical resources on the internet has EXPLODED during my time as a developer. Every day I got through dozens (or more) of articles regarding various technologies and design.
FOMO is my biggest enemy.
Gidon: I think the two most significant changes are around collaboration, which has become better and more intense. There is a better understanding of the impact of the team, and this is more prominent. The 2nd difference is the fuzzy boundaries between work and home life.
In the past, people were expected to stay late at the office when there was a deadline. As an employee, you were excepted to be at the office at certain hours in the morning. Today mobile remote work gives me lots of freedom and flexibility and more time with my kids but has me working at weird hours and promotes an always-on mentality. I mostly push this off well, but not always.
Describe something that you miss when you think about the old days?
Yair: I miss the solitude of being alone in huge frozen rooms full of computers.
Liron: I miss the feeling of not having to be continuously updated on the latest tech and buzzwords. Back then, I was just a Java UI developer — and that role stayed the same for a more extended period than today. The update cycles for Java were so slower than the updates cycles for web technologies today.
But mostly, it’s just that feeling.
Gidon: it’s amazing today that you can get and use someone else package that implements a logic that you need. This notion is compelling and enables the creation of incredible things much more straightforward.
I do miss that in the old days, you had no way of getting things without paying for them (and you needed lots of convincing to get something since developers input was not valued), so you had to implement basic ideas yourself. You would get to handle interesting algorithmic problems that today there is no reason to do yourself, and someone has already done it better. You implemented basic data structures and did real Dijkstra type things. Today is better, but those free frontier days were fun.
Describe something that you don’t miss about the old days?
Yair: I don’t miss the “integration hell” or any other manual work we used to do. Back then, we can spend a lot of time releasing software, fixing last minutes bugs, copying files, and disk images from storage to storage. Each server was a unique snowflake, and if something happened to the machine, it was not trivial to spin another one and correctly install all the software.
Liron: It would be nostalgic for me to say that things were simpler back then, but the truth is they were just harder — I could find myself spending hours (or days) and a problem instead of searching stack overflow for an answer (and get it in several minutes).
Problem-solving has become way more accessible and quicker today than it was back then — Instead of asking your colleagues to help you out with a problem you do a simple search and voila! Someone else on the internet already encountered this issue solved it, and was kind enough to post their solution too.
Gidon: I don’t miss that everything was so manual, and you had to repeat so many things. I remember the first time I automated an idiotic build process ( partially manual build processes were the norm back then), and I was pleased as if I invented the wheel. Automated tests were also rare, then and QA departments were huge (3 QA for each Dev).
I remember we had a manual sanity test rotation, so once every few weeks, you were tasked to perform a manual smoke test to verify that the only official build of that week was decent like a human ci.
Looking back at your career, what tool or methodology pushed your work forward?
Yair: For me, its Unix and Git, Unix changed the way i was thinking about operating systems, I love the Unix philosophy of one software that does one thing and does it well. I think if you understand the Unix system, it makes you know many other computing paradigms.
Git opened the door for better understanding and collaboration between developers and operators. If we use the same tools and the same cultural terms (branch, pull request), it’s easier for us to understand that we are one team working together.
Liron: Design collaboration tools have got better in recent years, instead of emailing drafts, photos, pdf, images, and whatnot back and forth between the design teams and development teams.
It is so much better just to share a single place for design artifacts that can be reviewed, commented on, and published once finalized.
Gidon: On my third job, I worked writing code in the Linux kernel and needed to do quite a lot of shell work. Both of these frameworks boosted my knowledge, understanding, and confidence. The kernel taught me a lot about how the software works on the lowest levels. The shell taught me how to be effective and to understand and appreciate the Unix philosophy. Both the kernel and the shell inform my designs and thinking always.
Do you think there were any cultural differences between nowadays and the past? Can you describe them?
Yair: I think nowadays, in general, the working culture is more open, less hierarchical, and more diverse. There is massive room for improvement, but it’s slowly getting better.
Liron: I think the transition to agile development caused team leaders to be less involved in the day to day coding and more on managing tasks. In a way, it weakened their technical abilities and authority.
I’m not sure whether it’s good or bad (in my opinion, it’s terrible because I prefer a team leader who’s a great manager and also a technical focal point).
Gidon: My first answer describes the biggest change. Another very significant change is the move to more realistic and agile planning and execution, coupled with more streamlined delivery and integration. Our industry has matured and is moving towards constant improvements.
What do you think will happen next?
Yair: Certain roles and fashions would go away, and new ones would come. The hot trend right now is outsourcing your services to someone else from cloud providers to CI/CD or your project management tools. I think this model was sold to us as being cheaper, but it’s not always true, i strongly believe that a new hybrid model will arrive and offer an alternative.
We will see more abstractions of our infrastructure and better tooling for managing and monitoring our infrastructure. My last guess would be that the microservices model will be abandoned, and companies who have different needs would use something else that would fit them better.
Liron: I have no idea — the fact of the matter is that although we have new technologies created all the time, and at a rapid rate, coding remains the same as it was 10+ years ago.
When it comes to building a large scale application, there are no tools to shorten the development time/complexity itself.
Gidon: I think ml and AI will change the software landscape. We will, in time, create generic engines that can handle lots of different problems, and these will be employed to build apps quickly. On the infra/hardware side, ubiquitous, rapidly provisioned hardware will and already is changing how things are managed and executed.
My concern is that on both these fronts, software, and infra big corporations will own these platforms and control the industry and the global economy. All that doesn’t sound good for creativity, prosperity, and happiness in general.
Everyone said there are no developers aged 40 in our field, what do you think about it now?
Yair: I used to answer that when I started using computers, we had one color screen and ASCII graphics for games. I was amazed when i saw the first RGB monitor and heard decent sounds. I think people with our prospective and knowledge would be in need as long as we have interest and curiosity towards our field. It’s a very young industry, and we barely scratch the surface of what we can achieve. Let’s kick ass!
Liron: Pffff…. There are a lot of them.
I wonder what they’ll say about those 10x developers in ten years.
Gidon: In most of my career, I was the average age developer. I think this because the industry was young then and there weren’t many devs. So as I aged, the industry aged with me. It stopped ten years ago, and the average age I think is around 33, but there are plenty of over 40 engineers, and on average, they are better developers and appreciated for it.
I’m still worried about my prospects at 55 but not as much as before. Before, I used to worry about my current age, so maybe when I’m 55 or 65, it will still be fine. I’m a natural optimist.
Making developers happy is what we what our team at Polar Squad loves doing? Feel free to contact me or anyone from our team. Empathy is one of our values, and now might be a good time to start doing some first steps in the realm of DevOps transformation. Feel free to drop us an email or Linkedin message! Maybe we can help you or guide you in the right direction.
