The Pursuit of Value

I remember being fourteen when I showcased my first program. It was at a school expo; I had made a choose-your-own-adventure, text-based game. A friend and I spent many hours imagining and writing every scenario we could, and made a video to “promote” it at the expo. It was filled with inside jokes and more nested ifs than I can count.

The code was difficult to read and maintain. I didn’t use version control. I didn’t deploy it to a website. It didn’t follow SOLID, nor other OOP best practices. It didn’t have an amazing UI, but that’s not what I remember it by. I remember feeling proud when I heard people comment to each other that they wanted to try it. Other people found value in it, enough to say so and play it multiple times.

Lately I’ve been thinking about what it means to work in this industry. Years of study and work, a few jams, countless sleepless nights trying to get something to work properly. I’ve delivered executables on CDs and pen drives to teachers, stored copies of projects with names like “really final this time”.

Then I got into college. Learned about Git, what little I could, then wondered why I didn’t learn it before. I learned about good practices and programming paradigms: imperative, functional, object-oriented, logical. Later came system design and architecture. Each new concept gave me another way to distinguish good code from bad.

Years went by. I gained experience and learned new technologies, but something changed. Somewhere along the way, whether by trying to hone my craft or by reading the market’s signals, I began focusing too much on the technology. I no longer measured my work primarily by other people’s appreciation, but by the quality of the code—the abstractions, the simplicity, the reviews. Craftsmanship had become the clearest measure of my ability.

That worked for a good while for me and a lot of other people, except that code is essentially not a scarce resource anymore. Non-technical people are bootstrapping their own applications, sometimes even using Excel as a database, and successfully meeting real needs for themselves and the people around them. Meanwhile, developers who refuse to adapt increasingly compete with people who are more ambitious, less attached to the code itself, and more focused on reaching an outcome.

So, should we stop reading code or caring how it is written? I don’t think so. Reliability, maintainability, security, and performance still matter. Craft matters. But craft is not the same as value, and it never was.

What has changed is scarcity. Producing code is becoming cheaper, and capabilities that once distinguished an engineer are becoming available to almost anyone. The difficult part is moving upward through the levels of abstraction: from how code should work, to how systems should fit together, to what deserves to exist in the first place.

In Argentina, the “hard” sciences have a long tradition of looking down on the “soft” ones. Engineering appeared useful and objective; the humanities appeared subjective, pursued by people who merely found them interesting. There is some irony in watching software move toward the very questions we treated as secondary: what people need, how they behave, what institutions reward, and what consequences a system creates.

I can still take pride in an elegant abstraction. But elegance does not prove that the abstraction needed to exist.

When I think back to that school expo, nobody cared how the game was written. They cared that it was funny, that it surprised them, and that they could play it again. Years later, after learning how much was wrong with the code, I don’t feel any less proud of it.

AI has not changed the source of value. It has only made it harder for us to confuse value with code.