· By Wataru Ito · Coding  · 4 min read

An Unexpected Path into Web Development

Why philosophy, art, and a builder's mindset have felt unexpectedly useful in my path into front-end development.

Why philosophy, art, and a builder's mindset have felt unexpectedly useful in my path into front-end development.

Recently, I came across an X post in Japanese—yes, I still call it a tweet, but anyway—that stuck with me. The post recalled something an instructor had said during new-grad training: some of the strongest programmers they had seen came from philosophy backgrounds.

There is also a Japanese collection of reactions and follow-up discussion.

A quick bit of context: in Japan, graduating and getting a job straight out of college has traditionally mattered a lot. Many people are hired as new graduates, and companies often train them on the job. For new developers, that can mean a few months of bootcamp-like training while they’re already on payroll. Things are changing, but that expectation still shapes the job market.

One instructor’s comment isn’t a rule, obviously, but something clicked for me.

I studied art. Now I do front-end development—mostly self-taught—and I work on the visual side as well as a lot of business logic. I genuinely enjoy both.

At a previous job, some of the senior colleagues who had interviewed and hired me later asked me to sit in on interviews. There were candidates with master’s degrees in computer science and experience with AI training. On paper, they seemed much more qualified than I was. But they still decided not to hire some of them. I kept wondering why I had been hired when they had not.

Looking back, I think they wanted a builder: someone who enjoys taking an unclear idea, working through the details, and making something that actually works. I did enjoy that kind of work. Maybe that was part of it.

In college, I did some independent study with a philosopher-in-residence, and I kept reading philosophy afterward. I also played around with Java a little while I was there. What surprised me was how often programming concepts felt familiar—not because philosophy directly explains programming, but because it had already trained me to sit with abstract ideas.

The connections felt almost one-to-one. In object-oriented programming, you spend time with abstractions, interfaces, classes, instances, and polymorphism. I don’t mean that those ideas come directly from Plato or Aristotle, obviously. But if you’ve spent time with Plato’s Forms, Aristotle’s attention to particular things, and the Socratic habit of asking what a concept really means, then that vocabulary doesn’t feel totally alien. An interface is a promise about what something can do; an instance is one particular thing that fits that abstraction.

Something similar happened when I started reading about functional programming. If you’ve ever spent time thinking about free will—whether we really make choices, or whether everything is already determined—then conversations about pure functions, side effects, and context feel a little less strange. I learned the word monad through functional programming, not philosophy, but I was already used to following an argument through a lot of abstraction.

The big ideas never scared me away. I could keep reading and learning without needing to understand every detail immediately. This was before AI assistants became a normal part of learning, when we mostly Googled our questions instead of asking a chatbot. Being comfortable with “I don’t get it yet” was useful.

Anyway, my takeaway isn’t that everyone should study philosophy. Logical and critical thinking are definitely useful, especially in an AI-heavy workplace, but I don’t think there is one correct background for doing good work.

You don’t really know what will become useful, or when. So it makes sense to bet on what you’re genuinely drawn to. People have different interests, and I think that is a good thing. If we all follow different threads, then collectively we’re placing bets on more possible futures—kind of like an index fund, but with human curiosity.

These days, I sometimes trace art history in my head and try to map its ideas onto programming paradigms. Greenbergian formalism valued medium-specific purity. That makes me think about the appeal of keeping a function pure or a component clear about its job. Minimalism is often reduced to “simple art,” but debates about Minimalism as “literalist” art make me think about the contrast between an abstract class and a concrete object—between a concept and the actual thing in front of you.

These aren’t strict translations, and I don’t know if they make me a better programmer in any direct way. But they give me extra angles. That kind of diversity—between people, and even between the ideas inside one person’s head—feels like a good way to prepare for a future we can’t see yet.

Back to Articles

Related Articles

View All Articles »
What Is the Best Primary Key?

What Is the Best Primary Key?

Auto-increment IDs are fast and simple—but are they the best choice for a primary key? A practical breakdown of UUID v4, UUID v7, ULID, cuid2, Nano ID, and when each makes sense.

JavaScript Event Loop

JavaScript Event Loop

Understanding how JavaScript handles asynchronous operations through the Event Loop, Macro Stack, and Micro Stack mechanisms.