My first on-site internship — and learning to think in Lisp

This was something new for me: my first on-site internship, at Technosoft — a company that builds knowledge-based engineering software — right in the middle of Beirut. Up to this point, most of my building had happened at my own desk, on my own clock. This was a different world.

The challenges showed up before the code did. There was the daily commute into Beirut and back, and the shape of a real working day — a steady 8-to-5 you don't get to renegotiate. None of that was "hard" in a technical sense, but adjusting to a new city, a new rhythm, and a new set of expectations is its own skill, and by the end it all felt normal. Quietly, that's one of the things I'm proudest of.

Then there was AML — built on Lisp

The first surprise on the technical side was the language. I'd come in fluent in web development and Python — and the work here ran on AML, short for Adaptive Modeling Language: a knowledge-based engineering language that Technosoft builds on top of Lisp. So beneath AML's own constructs, what I was really reading and writing was Lisp — one of the oldest programming languages still in use, dating all the way back to the late 1950s.

If you've never seen it, Lisp looks unlike almost anything modern. Instead of the keywords and punctuation you'd expect, nearly everything is written as lists wrapped in parentheses, where the first item is the operation and the rest are what it acts on — so "add 1 and 2" becomes (+ 1 2). Code and data share the exact same shape, which means a program can read and rewrite other programs as naturally as it handles numbers. It's a small idea with enormous consequences, and it makes the language feel less like a set of features and more like a material you shape. AML then layers its own modeling world on top of that foundation — so learning it meant getting comfortable with the base language and the ideas built over it at the same time.

Coming from everything I'd learned before, that was exactly the appeal. It wasn't hard so much as different — and complexity is the thing that pulls me in rather than pushes me away. I wanted to understand why it was built this way.

The first few days were slow, the way the first days with anything unfamiliar always are. But somewhere inside that first week it clicked. The concepts stopped being rules I was following and became intuition I was using. The clearest sign was the question I caught myself asking: at the start it was "can I even do this?" — and before long it had quietly turned into "what's the cleanest way to do this?" That shift, from wondering whether the tool can to reaching for how, is what fluency actually feels like.

Being trusted with a real piece

The other thing that made it memorable was being handed a genuine slice of a project and the room to work it out myself. There was no tidy tutorial waiting — the problem was mine to understand. It leaned heavily on math, and I got to build the reasoning from the ground up: sketch the intuition, work out the approach, and turn it into something that ran correctly. Being given that kind of ownership this early is rare, and solving it end to end was easily the most satisfying part of the whole internship.

More than any single skill, that's what I took home — proof that I can step into an unfamiliar company, an unfamiliar city, and an unfamiliar language, and make myself useful.