A few days ago a .NET developer told me he was worried about what AI will do to our profession. My answer was short: we have to evolve.
Then I realised I owed him, and myself, a longer answer. On my site I say I have 30 years of experience. That is the professional part. To be honest, I have been writing code for 44 years.
In 44 years I have seen languages arrive, become fashionable and fade away. I have seen paradigms that looked definitive replaced by others. Looking back at that path, I think, is the best way to explain why I am not afraid of what is happening now.
BASIC, at six
It started in 1982, when I was six, with BASIC on a Commodore VIC-20.
The VIC-20 was the first computer to sell a million units. It had 5 KB of memory, of which about 3.5 KB were left for your BASIC program. Every line counted, every variable had a cost. Without knowing it, I was learning that resources are never infinite.
Then came the others: a Commodore 16, a Commodore 128D, a Hiro 286, a 386SX, an Amiga 500, an Intel Pentium. After that I lost count, until I got to Apple.
Each of those machines had its own way of doing things, and each time you had to start learning again. It is a feeling I would get to know very well.
I don't remember much about the projects of those years, except the first one. At six or seven I wrote a program in BASIC to manage table bookings for a family friend who had a pizzeria. My first software had a real user, and a real problem to solve: tables, times, people.
Pascal, COBOL and a stray Fortran
At fourteen, in 1990, I started programming in Pascal and COBOL. Almost by chance, in the same period, I also came across Fortran.
Three languages that could not be more different, each the child of a different idea of what a computer is for.
Pascal was created by Niklaus Wirth in 1970 to teach structured programming: order, clear types, procedures. COBOL, born in 1959, was designed for business data and written to look almost like English, so that it could be read by people who were not programmers. Fortran, from 1957, was designed for numbers and scientific computing.
After the freedom, and the chaos, of BASIC, Pascal was a lesson in discipline. COBOL showed me that software lives inside companies, among accounts, records and reports. Fortran was a glimpse of another world.
A bank, Cineca and Netscape
In 1995 I started working in a cooperative credit bank. Because of my passion for computing, I was able to work with CESVE, the service centre of the cooperative credit banks of the Veneto region (today part of Allitude).
My first internet connection, with Netscape, came through Cineca in Bologna. That is when I started writing HTML.
Netscape Navigator had come out at the end of 1994, and the web was still a collection of grey pages, links and the first images. Writing a page by hand and seeing it appear in a browser had something magical about it, and it was the beginning of the work I still do today.
In those years I also discovered C++. At first it did not fascinate me at all, and it took me some time to really understand object-oriented programming.
Moving from procedures to objects is not a matter of syntax: it is a different way of looking at a problem. It is one of those changes that you understand slowly, and then you can no longer think without it.
Java, which I never loved, and PHP
Between 1996 and 1998 I got to Java. Its first version had come out in January 1996, with a powerful promise: "write once, run anywhere".
I never particularly loved it, but I developed a lot with it.
In the same years, especially for the web, I preferred a more agile language: PHP. It had been born a few years earlier as a small set of tools for personal home pages, and it was growing fast exactly where I was working: on the web.
That preference has followed me ever since. I have always looked for the lean option: the lighter language, the system with less weight to carry. It is the reason I disliked Java. I respected what it could do, but I always felt it was too heavy for what I needed.
The 2000s: Python, Symbian and C#
In 2000 I started with Python. It was the year of Python 2.0, and the language was still far from the popularity it has today.
In the early 2000s someone convinced me to write software for Symbian, the operating system of the smartphones of that time, and that is how I approached the mobile world. Years before the iPhone, mobile meant small screens, little memory and many constraints: the VIC-20 lesson, all over again.
At the same time I started to understand C#, which I appreciate and which I like more than C++.
There is a curious detail here: its lead designer, Anders Hejlsberg, was the same man who had created Turbo Pascal years earlier. Somehow, the circle with my school years was closing.
I never stopped working in PHP, and with its new versions I finally brought object-oriented programming to my old friend as well. PHP 5, in 2004, gave it a real object model, and it stopped being only a language for small scripts.
Rails, and the day MVC clicked
If I look back, some moments really changed my work. The first was meeting Ruby and Ruby on Rails, when Rails was little more than a year old. That is how I arrived at the MVC pattern.
MVC was not new: it had been described at the end of the 1970s, in the Smalltalk world. But Rails turned it into an everyday way of working, together with an idea that was revolutionary at the time: convention over configuration. You did not have to decide everything; many decisions were already made, and made well.
For someone who has always looked for the lean option, it was the right lesson: separating data, logic and presentation is not a burden. It is what keeps a project light as it grows.
MVC really simplified the way I make software. Before, every project had its own shape, and often the shape was the one it had taken by accident, one file after another. With MVC, every piece had a place: the model knew the data, the controller knew what to do with a request, the view only knew how to show the result.
That order had a consequence I had not expected: my software became much easier to document. When the structure is clear, the structure itself is half of the documentation. You can explain a project by explaining where things are, and anyone who knows the pattern can open it and find their way around.
For me it meant better-structured projects, easier to hand over, to maintain and to extend, even years later.
In 2006 I also started working with Django, which brought the same discipline to Python.
And I took MVC back home to PHP: first with CodeIgniter, then with Laravel. PHP, my old friend, had grown up, and so had I.
Go, and the search for lightness
Between 2011 and 2012 I started with Go, the language Google had presented in 2009 and that reached version 1.0 in 2012.
Once again, the lean option: few concepts, a simple syntax, fast compilation, and a clear idea of what the language should not do.
Go was another huge simplification in the way I write code. After MVC had brought order to the structure of my projects, Go brought simplicity to the code itself.
Its designers deliberately left things out: for years it had no generics, and it still has no inheritance. There is usually one obvious way to do something, and the standard formatter, gofmt, ends every discussion about style before it starts. Errors are values you have to look at, not exceptions that fly somewhere else. Concurrency, which in other languages is a delicate art, becomes a matter of goroutines and channels.
Simplicity was not only on the page. With Go I built my first low-energy microservices: small, compiled services that start in an instant and need very little memory and CPU to run. Even better than what I had achieved with Ruby.
The result is code that you can read months later, or that someone else can read on day one, without reconstructing the author's intentions. For someone who has always looked for the lean option, it felt like the destination of a long journey. I have written about it in a practical comparison between Go and Rust.
Services instead of servers
The other big change came with services and tools for building applications: Supabase, Next.js, Vite.
Supabase puts a Postgres database, authentication, storage and APIs behind a single service. Next.js brought the server and the client of a web application into the same framework. Vite made the development environment almost instant.
They changed the way I build apps once again. The question is no longer only how to write a component, but which pieces to choose and how to connect them.
Context before code
BASIC, Pascal, COBOL, Fortran, HTML, C++, Java, PHP, Python, C#, Ruby, Go, JavaScript. Every language taught me something, and every change of paradigm forced me to change.
But after 44 years, the most important lesson is not about a language. I have always programmed and I have always looked for the leanest tools. Over time I understood that, before knowing how to program, you need to know the context: the people, the business, the problem you are really solving.
The pizzeria program was already about this. It was not a matter of BASIC: it was a matter of understanding how a family friend managed his tables.
Programming gave me logic. Understanding context is what keeps me here today, working with AI and with the requirements that AI asks of people like me.
I have written before about AI and the illusion of efficiency. A model can write the code. It still needs someone who knows what the code is for.
So this is my longer answer to that .NET developer. We have changed languages, paradigms and tools many times, and every time we evolved. AI is one more change. The people who understand the context will not be left behind.