I studied law. Seven years later, I did an MBA. At no point during either degree or in my work in between did anyone pull me aside and say, “Hey, you should probably learn to write a ‘for loop’.” And yet here I am, running a legaltech startup, shipping production code, and mass-texting my cofounder screenshots of features at 2 am.
I’ve been chewing on the idea of the “Humanities Engineer” since about 2018-2020, back when I first taught myself to code through books, Udemy courses, FreeCodeCamp rabbit holes, and a frankly concerning obsession with Stack Overflow.
So, what is a “Humanities’ Engineer”? It’s someone who studied humanities, arts, or some flavour of social science, and who crosses into technical building; specifically, software engineering. Here, we’re not thinking of someone who pivots their careers and abandons everything they learned before, or a bootcamp graduate who memorised JavaScript flashcards for twelve weeks after a history degree per se. A “Humanities’ Engineer” is someone who brings all the analytical training, close reading, critical thinking, and genuine human curiosity from their education straight into the codebase.
How does one actually become a “Humanities’ Engineer”? In this article, I want to lay down some actual, concrete steps and the right mindset to become one. Because there has never, in the history of computing, been a better time for a philosophy major or a history nerd or a literature obsessive to become an exceptional builder. n
Wait. “Should People Even Learn to Code Anymore?”
You’ve probably seen this debate floating around. Jensen Huang, CEO of Nvidia, stood on a stage at the World Government Summit in Dubai in February 2024 and told a room full of powerful people that kids shouldn’t learn to code anymore. His argument: AI will make human language the programming language, so people should focus on domain expertise instead.
There is an entire cottage industry of Medium posts, and LinkedIn takes arguing about whether Jensen is right or wrong. I think the whole debate is a red herring, at least for us. It is out of scope for “Humanities’ Engineers.” We are our own different thing. The question for us isn’t “should the average person learn to code?”, it’s “I have ideas, I have taste, I can read 400 pages about the Peloponnesian War for fun. Can I build things?” And the answer is: absolutely yes, and it has never been easier.
When I first started learning, I felt like there were a few gatekeepers. You see them everywhere – condescending Stack Overflow answers, textbooks written for people who already knew what was in the textbook. Simply, loads of places where you ask a question and get a response that makes you want to close your laptop, walk into the sea, and start a new life as a fisherman. The astonishing thing now is that I can ask an LLM to explain something to me like I’m five, and it will do it patiently, repeatedly, at 3 am, without ever making me feel stupid.
What I’m Assuming About You
I’m going to assume you have up to a 10th-grade level of maths education. Even that isn’t strictly necessary. It’s just nice to have, especially the concept of functions: something goes in, something comes out. But if you hated maths, don’t worry.
I’m also going to assume you can swing about $20/month (or roughly £18 per month if you’re in the UK like me) for an LLM subscription. Claude has been my go-to (full transparency). But ChatGPT and Gemini are solid too at this stage. Cursor IDE is, in my opinion, the best tool available right now for AI-assisted coding.
If you can’t spare $20 at this moment, that’s completely fine. You can still do this. ChatGPT’s free tier is okay. There are open-source models you can run locally (look into Ollama and open-weight models like Llama, DeepSeek, Kimi, etc). Many IDEs have free AI integrations now. It’ll be a little more friction and a little more switching between tabs, but the core path is the same.
If you went to university, I’m going to assume you studied humanities, arts, or some form of social science (though again, not necessary at all; you just need to bring your passion for the humanities). And most importantly, I’m going to assume you have ideas you want to build, or at least a nagging feeling that you want to find your place in the world of making things. If you’re juggling extraordinary circumstances (raising kids solo, working two jobs, whatever it is), I’m also going to assume you’ll carve out some time, even if it’s small. In my experience, small and consistent beats large and sporadic for the Humanities’ Engineer.
Step 1: Find an idea YOU want to build
Most articles will tell you to just follow a tutorial, build a to-do app, and then somehow emerge as a fully formed engineer. That’s like saying “to become a chef, first make toast, then open a restaurant.”
But what if you could start building something right now, this second? What would it be?
I have asked this exact question to people, and the answers are stunningly diverse: Tracking car races in real-time. A personalised, agentic life-organisation tool. A virtual try-on for fashion (“how would this jacket look on me before I buy it?”). Creative advertising platforms (AR, VR – the world is your oyster!).
Chances are that whatever you’re thinking is genuinely unique to you. And you should chase it.
The secret sub-step within this step is this: go look at “competitors.” I’m using that word very loosely because you’ll probably build this project to learn, or open-source it, or maybe just show your friends. But look at how others have approached similar problems. Say you love fashion and you want to build that virtual try-on thing. Search for existing products. Look at their features, their UX, what they do well, what they do badly. Then ask an LLM: “How would I start building something like this?” The point isn’t to copy. The point is that seeing what exists will spark new creative ideas for you.
At this stage, you will feel daunted. You’ll look at what’s already out there and think, “Oh my god, everything that could be built has already been built.” I promise you it hasn’t. From cafes to cars to chatbots, the amount of room for differentiation is staggering. NOBODY has built YOUR version of the thing yet.
Step 2: (Probably) choose Next.js and TypeScript (but keep an eye out for Python).
You hear a lot of conflicting advice about which language to learn first. Some people say, “just learn the general concepts and syntax of programming.” That’s not how we’re going to do this as “Humanities’ Engineers.” We are prioritising building. We want to get ideas out of our heads and into the world as fast as humanly possible, with as few potential for bugs as possible.
Before LLMs, I used to recommend Python. Python is still my favourite language. It’s elegant and concise. But these days, I’d say go with Next.js and TypeScript.
(Quick note: Use an LLM to break down these next two paragraphs if you aren’t kinda familiar with these concepts already and ask it to ELI5.) Next.js has become the go-to React framework. It has over 138,000 GitHub stars and powers massive products used by Netflix, TikTok, Nike, Uber, Starbucks, and Spotify. We use it at my startup too, and I’ve been happy with it. The hosting ecosystem is mature: Vercel (which created Next.js), Render, AWS Amplify, Railway, Netlify, and all the major cloud platforms let you deploy directly. You can build end-to-end products. Frontend, backend, API routes, the whole thing. It’s your gateway drug to making real things real people can use.
With Python and Django, there’s a bit more setup overhead to get a full-stack app running. Do I think Python and Django are conceptually easier to learn? Honestly, yes. But as “Humanities’ Engineers,” we’re optimising for one thing above all: building. Getting your idea live. You can always pick up Python later (and you should, it’s wonderful).
A good mental trick: Pretend you’re building a startup. Act like you’re going to launch this thing. Get your friends and family to try it out. Give yourself a name, a landing page, a deadline. We aren’t play-acting here. This is how you create urgency and avoid the procrastination (yes, it still counts as procrastination!) that spending four weeks picking the “right” CSS library can be. This is how you avoid feeling that weird existential dread of being stuck doing something no one – not even yourself, it seems – will see.
Step 3: Your Superpower. You Can Read.
This is the part where the “Humanities” part of being a “Humanities’ Engineer” makes a difference.
We are used to reading long, dense, sometimes boring material: Fantasy trilogies. Legal textbooks. 19th-century Russian novels. Entire Wikipedia rabbit holes about obscure historical events. This is actually a superpower in software engineering, and I am not trying to just hype up our (often, unfortunately, degraded as “useless”) degrees.
There’s a running joke that engineers don’t read the documentation. As “Humanities’ Engineers,” we will not only read the documentation (i.e. the manual of how a bunch of code works together), we will read the code itself. My legal training taught me that when you’re reading a contract or a statute, every word matters. You don’t skim (unless you’re confident of the text). You read each clause, and you ask why it says what it says. I brought that same habit to code, and it has been the single most useful skill transfer of my career.
How do you apply it practically? Whatever code an LLM writes for you, interrogate every single line. Let’s say it gives you something like:
export function calculateTotal(items: CartItem[]): number {
return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}
Ask the LLM to explain every piece of this. What does export mean? What does function mean? Why is “calculate total” written like it’s commanding something, why is it concatenated and the first letter is not capitalised? Why are there parentheses? What’s CartItem[] and why is there a colon after items? What does : number at the end mean? What on earth is .reduce? Why is there a 0 at the end? What’s the difference between a parameter and an argument?
THIS IS IMPORTANT! Treat your understanding of syntax like a very long walk. Like, say, 100,000 steps. Each step counts. Every single little piece of syntax you understand contributes to that journey. I hear a lot of vague advice like “don’t be intimidated.” Obviously, you’re going to be intimidated. A hundred thousand steps is a long way. So be intimidated. And then take the next step anyway.
Step 4: Build the MVP. Show It to People. Be Embarrassed.
If you’re using something like Cursor, you can get a minimum viable product up surprisingly fast. Build it, deploy it, then show it to someone.
They say that if you’re not embarrassed by the first version of your product, you shipped too late. This is annoyingly true. Your first version will be ugly. It will have bugs. Someone will click a button, and the whole thing will break in a way you didn’t know was possible. That’s fine. Get feedback, add features, fix things, and learn every single line of your codebase along the way.
Step 5: Start to Develop Your Own Taste
This one used to frustrate me. People in the tech world would say “develop good taste,” and I’d think, amazing, thanks, but that’s like saying “to win at basketball, just put the ball in the net more than your opponent” Sure. But how?
What actually helps is a bit more tedious: as you build your understanding of syntax and logic, make your code read like English. If an LLM or a tutorial uses some clever, compressed syntax that you don’t understand, rewrite it in the simplest, most readable way you can. Even if it’s “less efficient,” or someone you know who’s an “actual” engineer rolls their eyes. As a “Humanities’ Engineer,” you should write code that you find readable and useful. Fancy syntax can come later, once you actually understand what it’s doing.
I’ve found writing about my code helpful, like rubber-duck debugging (Google this term, it’s very cute <3), but on paper. Explaining what a function does in plain language forces you to understand it. Your humanities training makes you better at this than you’d expect.
The best book I can recommend for developing taste in code is Clean Code by Robert Martin. Fair warning: the first time you read it, even the chapter titles will seem alien. But that’s okay. Come back to it after a few months of building. It’ll click each time differently.
Step 6: NEVER Skip the Part They Tell You to Skip
This is the big one. This was my biggest regret from the tutorial era, and fixing this habit was the single biggest accelerator in my learning.
There’s this funny YouTube video called “Every Programming Tutorial”. It’s about 30 seconds long, it’s been watched millions of times, and it perfectly captures the problem. Programming tutorials spend an eternity on basics like “this is a variable, this stores information,” then suddenly jump to building something impossibly complex, and the moment you hit the hard part, the instructor says: “Don’t worry about this section, we’ll come back to it later.”
They never come back to it. And “that section” is always the critical part.
The advantage of LLMs is that you can stop and say, “Wait. Tell me exactly what this part does. Be casual about it. Explain it like I’m at a pub.” More often than not, the thing you were told to skip is the thing that would have unlocked your understanding.
I’ll give you a real example: I was working with an image classification library that Claude suggested. It wrote a bunch of code, things kept breaking, and I tried to debug things I didn’t even know existed just ten minutes ago. Nothing was working – shocker! Then I remembered this exact rule. The Primeagen (a popular programmer and content creator) once made a really funny observation about how developers’ eyes just mentally gloss over regex (regular expressions, those pattern-matching strings of text that look like a cat walked across a keyboard like (..+?)\1+). He was going over the CrowdStrike outage from July 2024, which, by the way, crashed about 8.5 million Windows computers. The root cause involved CrowdStrike’s Content Interpreter, which uses a regex-based engine, hitting a parameter mismatch that caused an out-of-bounds memory read. Regex was probably at the centre of one of the largest IT outages in history, partly because people’s instinct is to look at it, shudder, and move on.
I noticed I was doing the same thing. Claude had suggested some library functions I didn’t understand, and I was just accepting them. When I forced myself to stop and interrogate every single part, I found the bug in about ten minutes. The rule works.
Step 7: The First 100 Hours
Even though I’ve recommended building with Next.js and TypeScript, I have to mention that Angela Yu’s 100 Hours of Python course (on Udemy) is genuinely fun and well-structured. If you want to start there before jumping into Next.js, go for it. Writing things down as you learn will help. Keeping a notebook, even a messy one, forces you to process what you’re absorbing instead of just passively watching videos.
Speaking of which: “tutorial hell” used to be a real thing (and probably still is, even in 2026). It’s the trap of watching tutorial after tutorial, feeling like you’re learning, but never actually building anything. LLMs have mostly killed this trap, because you can learn by doing from day one, but the ghost of tutorial hell still haunts people who spend weeks “preparing” before they start building anything. Just start. You’ll learn what you need as you need it.
The Rule to Come Back To
I saved this for the end because I wanted you to have the practical steps first, but this is the thing that honestly matters most. Since you read to the end, you’ve earned it!
The number one thing you need to bring to this journey is a quietly audacious belief that you can become an exceptional builder. “Quiet” is the critical word there. You don’t need to announce it on LinkedIn or post “Day 1 of my coding journey” content (unless that genuinely motivates you, in which case, amazing). What you need is an internal conviction that you can do this, paired with the tenacity and discipline to actually prove it.
People from humanities backgrounds have so much to bring to this field. We read closely. We think critically. We communicate better than most. We’re trained to handle ambiguity and complexity, to maybe over-analyse and ask “what does this actually mean?” rather than just accepting things at face value. But it’s not over-analysis when, increasingly, English itself is becoming a way to write programs. I work in legaltech, and I watch non-technical lawyers interact with AI tools every day and produce things that would have taken a development team weeks just a few years ago.
The barrier between “person with ideas” and “person who builds things” has never been thinner – it’s practically translucent at this point.
So build. Now. Today. Open Cursor, spin up a Next.js project (#notSponsoredByNextJS), and start making the thing you’ve been thinking about.
The world has enough people writing think-pieces about whether coding is dead.
It needs more people to build.