The Any Key: Concepts You Skipped by Being a Designer
The all-killer-no-filler hitlist for UX people, designers, and anyone who went straight to the visual layer without touching the plumbing.
I have always been at a particular advantage and disadvantage that in my heart I’m an artist and a writer and creator, but what interests me is using computers and technology to do that, not the typical medium of art.
The people who inspire me as a designer aren’t designers. They’re people like Alan Kay and Adele Goldberg, Bret Victor, Richard Stallman, others who invented the technologies and things that we use today that you’ve never heard of because they weren’t marketers, they weren’t flashy, and typically they were so deeply interested in what they were building, they didn’t pay attention to the optics and PR that the Gates and Jobs did.
When I lived and worked in Silicon Valley, I would go to the Computer History Museum in Mountain View and just spend hours looking at every exhibit. All of these people who invented these technologies, the hyper focus and the dedication to exploring things and building things and making things.
They were all designers and yet they didn’t have fashion, taste or craft. They were designers and that they were inventing on principle. They were doing things creating function out of form.
And so as I evolved as a designer from being a teenager into an adult professional, my lens has always been through that of computer science and through the history of computer science, not design. I’d rather talk to you about Smalltalk and Lisp and Xerox PARC than I would about Eames or Leo Burnett or any of the big inspirations behind design.
So here is a brief collection of things where if you’re coming to this AI coding and running your own development pipelines on your own with coding agents, here are some of the things you can do to start learning the fundamentals about what it takes to work in software development, some of the background of computer science and terms you may have heard but don’t know, or some things that may be new altogether.
1. Version Control
Tools/terms you may have heard: Git, GitHub, GitLab, Bitbucket, commit, push, pull, branch, merge, repo, clone, fork
What it’s for: A time machine for your files. Every save (commit) is a snapshot you can return to. Branches let you experiment without breaking the main thing. Merging combines experiments back together. It’s how teams work on the same codebase without overwriting each other.
Why you care: Without version control, you’re one bad save away from losing everything. With it, you can experiment fearlessly.
Read/watch:
Git for Designers: free ebook, visual explanations
The Missing Semester: Version Control: MIT lecture, excellent
2. The Terminal / Command Line
Tools/terms you may have heard: Terminal, CLI, bash, zsh, shell, command prompt, PowerShell, iTerm, Warp
What it’s for: Talking to your computer with text instead of clicks. Faster for many operations. Required for most developer tools. Looks like hacking in movies, but it’s really just typing file commands.
Why you care: Claude Code runs in terminal. Git runs in terminal. Servers run in terminal. You can’t avoid it forever.
Read/watch:
The Command Line Crash Course: Zed Shaw’s free appendix
Warp Terminal: modern terminal with AI built in, good for beginners
BONUS: Get my quick list of terminal commands here
3. Files and File Systems
Tools/terms you may have heard: Directory, folder, path, root, home directory, file extension, .txt, .md, .json, .py, .js, .html, .css
What it’s for: Everything on a computer is a file. Code is text files. Images are binary files. Folders organize files. Paths describe where files live (/Users/erika/projects/fictioneer/README.md). File extensions tell programs how to interpret the file.
Why you care: If you don’t understand file paths, you can’t tell Claude where anything is.
Read/watch:
How Computers Work: Files: Code.org explainer
Just practice: navigate your own file system in terminal using
cd,ls,pwd
4. Text Editors vs IDEs
Tools/terms you may have heard: VS Code, Sublime Text, Vim, Neovim, Cursor, Zed, WebStorm, PyCharm, Xcode, IDE, text editor
What it’s for: Where you write and edit code. Text editors are simple (just edit text). IDEs (Integrated Development Environments) add features: autocomplete, debugging, file browsers, terminal integration. VS Code is the dominant choice. Cursor is VS Code with AI bolted on.
Why you care: This is your workspace. Picking the right one (and learning it) makes everything faster.
Read/watch:
VS Code for Beginners: official tutorial series
Just download VS Code and start using it.
5. Programming Languages
Tools/terms you may have heard: Python, JavaScript, TypeScript, HTML, CSS, Java, C++, Ruby, Go, Rust, Swift, SQL
What it’s for: Instructions computers can execute. Different languages for different purposes. JavaScript runs in browsers. Python is general-purpose and readable. HTML structures web pages (not technically a “programming” language). CSS styles them. SQL queries databases.
Why you care: You don’t need to be fluent, but you need to recognize what you’re looking at.
Read/watch:
Eloquent JavaScript: free, excellent, web-focused
Automate the Boring Stuff with Python: free, practical, beginner-friendly
6. Frontend vs Backend
Tools/terms you may have heard: Client-side, server-side, frontend, backend, full-stack, React, Vue, Angular, Node.js, Django, Flask, Rails
What it’s for: Frontend = what users see and interact with (runs in browser). Backend = the server, database, logic (runs on computers you don’t see). Full-stack = both. React/Vue/Angular are frontend frameworks. Node/Django/Rails are backend frameworks.
Why you care: When something breaks, knowing which side broke it is half the battle.
Read/watch:
Frontend vs Backend Explained: Fireship, 5 minutes
How the Web Works: MDN fundamentals
7. APIs (Application Programming Interfaces)
Tools/terms you may have heard: API, REST, GraphQL, endpoint, request, response, JSON, HTTP, GET, POST, webhook, Postman
What it’s for: How software talks to other software. Your frontend asks the backend for data via API. Third-party services expose APIs so you can use their features. When you “call an API,” you’re sending a request and getting a response (usually JSON data).
Why you care: Everything connects through APIs. Claude is an API. Supabase is an API. Understanding this unlocks integrations.
Read/watch:
What is an API?: MuleSoft, excellent 3-minute explainer
Postman Learning Center: hands-on API exploration tool
8. Databases
Tools/terms you may have heard: Database, SQL, PostgreSQL, MySQL, MongoDB, Supabase, Firebase, table, row, column, query, schema, CRUD, NoSQL
What it’s for: Organized storage for data that persists. Tables hold rows of records (like spreadsheets but powerful). SQL is the language to ask questions of the data. CRUD = Create, Read, Update, Delete (the four things you do with data). Supabase/Firebase are “database as a service” managed for you.
Why you care: Every app stores data somewhere. Understanding databases means understanding where your stuff lives.
Read/watch:
SQL for Beginners: freeCodeCamp, comprehensive
Supabase Quickstart: if you want to skip setup and just use one
9. Servers and Hosting
Tools/terms you may have heard: Server, cloud, AWS, Azure, Google Cloud, Heroku, Vercel, Netlify, Railway, localhost, deploy, production, staging
What it’s for: Servers are computers that run your code 24/7 so others can access it. “Cloud” means servers owned by Amazon/Google/Microsoft that you rent. Localhost is your own computer pretending to be a server. Deploying means putting your code on a real server. Vercel/Netlify host frontends. Railway/Heroku host backends.
Why you care: Code on your laptop is a prototype. Code on a server is a product.
Read/watch:
How the Internet Works: great 5-minute primer
Netlify Docs: easiest way to deploy a frontend, free tier
10. Package Managers and Dependencies
Tools/terms you may have heard: npm, yarn, pip, package.json, requirements.txt, node_modules, dependencies, install, library, framework, module
What it’s for: Code other people wrote that you can use. Instead of writing everything from scratch, you install packages (libraries, frameworks). npm manages JavaScript packages. pip manages Python packages. package.json lists what your project needs. npm install downloads everything.
Why you care: Modern projects have hundreds of dependencies. Understanding this system prevents “it works on my machine” disasters.
Read/watch:
npm for Beginners: straightforward guide
The Basics of Package Managers: Fireship
11. Environment Variables and Configuration
Tools/terms you may have heard: .env, environment variables, secrets, config, API keys, dotenv, process.env, staging vs production
What it’s for: Settings that change between contexts. Your API keys, database URLs, and secrets shouldn’t be in your code (anyone could see them). Instead, they live in environment variables that get loaded at runtime. Different environments (dev, staging, production) have different values.
Why you care: The #1 security mistake beginners make is committing secrets to Git. This is how you avoid it.
Read/watch:
Environment Variables Explained: Fireship
dotenv Documentation: the standard tool
12. Testing
Tools/terms you may have heard: Unit tests, integration tests, end-to-end tests, TDD, test suite, Jest, Pytest, Cypress, CI/CD, coverage
What it’s for: Code that checks if your other code works. Unit tests check small pieces. Integration tests check pieces working together. End-to-end tests simulate real user flows. CI/CD runs tests automatically when you push code. Catching bugs before users do.
Why you care: “It works on my machine” isn’t enough. Tests are how you prove it works everywhere.
Read/watch:
Testing JavaScript: Kent C. Dodds, excellent (paid but worth it)
Pytest Documentation: Python testing, beginner-friendly
13. DevOps and CI/CD
Tools/terms you may have heard: DevOps, CI/CD, continuous integration, continuous deployment, GitHub Actions, Jenkins, Docker, Kubernetes, pipeline, build, deploy
What it’s for: Automating the path from code to production. CI (Continuous Integration) = automatically test code when pushed. CD (Continuous Deployment) = automatically deploy code that passes tests. Pipelines define the steps. GitHub Actions is the most accessible entry point.
Why you care: Manual deployment is error-prone. Automation means pushing code and walking away while robots handle the rest.
Read/watch:
GitHub Actions Quickstart: free, integrated with GitHub
DevOps for Dummies: IBM, solid overview
14. Containers and Docker
Tools/terms you may have heard: Docker, container, image, Dockerfile, docker-compose, Kubernetes, K8s, microservices, VM, virtual machine
What it’s for: Packaging your app with everything it needs so it runs identically everywhere. A container is like a lightweight virtual computer that contains your code, dependencies, and configuration. “It works on my machine” becomes “it works in this container, which runs anywhere.”
Why you care: Solves environment inconsistency. Also how most cloud deployments work under the hood.
Read/watch:
Docker in 100 Seconds: Fireship
Docker Getting Started": official tutorial
15. Authentication and Authorization
Tools/terms you may have heard: Auth, OAuth, JWT, session, token, login, SSO, SAML, 2FA, Supabase Auth, Auth0, Firebase Auth, Clerk
What it’s for: Authentication = “who are you?” (login). Authorization = “what can you do?” (permissions). OAuth lets you “Sign in with Google” without sharing passwords. JWTs are tokens that prove you’re logged in. Most apps use auth services (Supabase Auth, Auth0) instead of building from scratch.
Why you care: Every app with users needs auth. Getting it wrong is a security disaster.
Read/watch:
OAuth 2.0 Explained: great visual walkthrough
Supabase Auth Docs: practical, modern approach
16. HTTP and Web Protocols
Tools/terms you may have heard: HTTP, HTTPS, SSL, TLS, request, response, headers, status codes (200, 404, 500), GET, POST, PUT, DELETE, REST, WebSocket
What it’s for: The language browsers and servers speak. HTTP defines how requests and responses work. HTTPS adds encryption (the lock icon). Status codes tell you what happened (200 = success, 404 = not found, 500 = server error). REST is a pattern for organizing API endpoints using HTTP verbs.
Why you care: Every web interaction uses HTTP. Understanding it helps you debug when things break.
Read/watch:
HTTP Crash Course: Traversy Media
MDN HTTP Overview: reference
17. JSON and Data Formats
Tools/terms you may have heard: JSON, XML, YAML, CSV, Markdown, schema, parse, serialize, stringify
What it’s for: How data is structured for storage and transmission. JSON (JavaScript Object Notation) is the dominant format for APIs, human-readable, nested key-value pairs. YAML is similar but with cleaner syntax (used in config files). Markdown is for formatted text (like this document). Understanding these formats lets you read and write data.
Why you care: Every API response, every config file, every data exchange uses one of these. JSON fluency is non-negotiable.
Read/watch:
JSON in 10 Minutes: Web Dev Simplified
Just practice: look at any API response, parse it mentally
18. Architecture Patterns
Tools/terms you may have heard: MVC, MVVM, microservices, monolith, serverless, event-driven, pub/sub, client-server, three-tier, separation of concerns
What it’s for: How to organize code at scale. MVC (Model-View-Controller) separates data, display, and logic. Microservices split apps into independent services. Monoliths keep everything together. Serverless runs code without managing servers. These are design philosophies for structuring systems.
Why you care: This is the “systems design” level. Understanding patterns lets you make intentional architectural choices instead of spaghetti.
Read/watch:
Fireship: 10 Design Patterns Explained: fast, visual
Designing Data-Intensive Applications: THE book, dense but excellent
19. Technical Debt and Refactoring
Tools/terms you may have heard: Tech debt, refactor, code smell, legacy code, spaghetti code, clean code, DRY (Don’t Repeat Yourself), SOLID principles
What it’s for: The accumulated cost of shortcuts. Every quick hack adds debt that slows future work. Refactoring is rewriting code to be cleaner without changing behavior. Code smells are patterns that suggest problems. Managing tech debt is managing long-term velocity.
Why you care: The God file you’ve heard me complain about is tech debt. Understanding this concept helps you balance shipping vs. quality.
Read/watch:
Clean Code: Robert Martin, the classic
Refactoring.guru: catalog of patterns and smells, free
20. Documentation
Tools/terms you may have heard: README, docs, API documentation, inline comments, JSDoc, Swagger/OpenAPI, wiki, runbook, changelog, CLAUDE.md
What it’s for: Explaining what code does and how to use it. README = project overview. API docs = how to call endpoints. Inline comments = explanations in the code itself. Good documentation lets others (including future you, including AI) understand and contribute.
Why you care: CLAUDE.md is documentation for AI. The skill of writing clear documentation transfers directly to writing effective AI prompts.
Read/watch:
The Documentation System: the best framework for thinking about docs
How to Write a README: practical guide
Bonus: The Meta-Skills
21. Thinking in Systems
What it’s for: Seeing connections, not just components. How does data flow? Where are the boundaries? What are the dependencies? This is service design applied to software.
Read/watch:
Thinking in Systems: Donella Meadows, foundational
You already have this. It’s why you’re here.
22. Reading Error Messages
What it’s for: Errors tell you exactly what’s wrong, if you read them. Stack traces point to the line that broke. Error codes map to documentation. “Google the error message” is a legitimate debugging strategy.
Read/watch:
Practice: when something breaks, read the ENTIRE error before panicking
How to Google Your Error Messages: yes, this is a skill
23. Knowing What to Google
What it’s for: The difference between beginners and experts isn’t knowledge: it’s knowing how to find answers. Learning the vocabulary (from this list) unlocks the ability to search effectively.
Read/watch:
How to Google Like a Senior Engineer: Fireship
Practice: notice what terms you search, refine them
The Learning Path
If you’re starting from zero, go in this order:
Files and File Systems: foundation of everything
Terminal / Command Line: how you interact with dev tools
Version Control (Git): how you save and collaborate
Text Editors: where you work
Programming Languages: what you’re editing
Frontend vs Backend: the two halves of every app
APIs: how the halves talk to each other
Databases: where data lives
Servers and Hosting: where code runs
Everything else:d as needed, when needed
The Mindset Shift
You don’t need to master all of this. You need to:
Recognize terms when you see them
Know where to look when you need to go deeper
Communicate with developers (and AI) using shared vocabulary
The goal isn’t to become an engineer. The goal is to stop being blocked by not knowing what things are called.
BONUS CONTENT: Roll call of the figures in the header image!
From left to right, row 1 and 2.
1. Ada Lovelace (1815-1852)
What she did: Wrote the first algorithm intended for machine execution, for Charles Babbage’s Analytical Engine. Recognized that computers could manipulate symbols, not just numbers, the conceptual leap that makes software possible.
Why she matters for the 20 concepts: She saw that machines could manipulate symbols, not just crunch numbers; the leap that makes software possibles. Every programming language traces back to her insight.
2. Charles Babbage (1791-1871)
What he did: Designed the Analytical Engine, a mechanical general-purpose computer with memory, processing, and input/output. Never fully built in his lifetime, but the architecture was sound.
Why he matters for the 20 concepts: He conceived the separation of “store” (memory) and “mill” (processor). The architecture patterns we use today echo his 1830s designs.
3. Grace Hopper (1906-1992)
What she did: Invented the first compiler (A-0), which translated human-readable code into machine code. Created COBOL, one of the first high-level programming languages. Popularized the term “debugging” (literal moth in the hardware).
Why she matters for the 20 concepts: She made programming accessible to humans. Without compilers, we’d still be writing binary. Every programming language owes her.
4. Douglas Engelbart (1925-2013)
What he did: Invented the mouse, hypertext, networked computers, and video conferencing. His 1968 “Mother of All Demos” showed a complete vision of personal computing decades before it existed.
Why he matters for the 20 concepts: He invented the interface layer, the idea that humans and computers could have a conversation. Every frontend concept traces to him.
5. Ken Thompson (1943-) & Dennis Ritchie (1941-2011)
What they did: Created Unix (the operating system) and C (the programming language) at Bell Labs. Unix became the ancestor of Linux, macOS, Android, and most servers. C became the ancestor of most modern languages.
Why they matter for the 20 concepts: The terminal, file systems, pipes, and the entire concept of “everything is a file”, all Unix. The way we structure code and systems is their inheritance.
6. Steve Bourne (1944-)
What he did: Created the Bourne shell (sh) at Bell Labs — the original Unix command-line interpreter. Every modern shell (bash, zsh) descends from his work.
Why he matters for the 20 concepts: The terminal/command line concept (#2 in the list) exists because of him. When you type commands, you’re speaking a language he designed.
7. The Xerox PARC Team (1970s)
Key figures: Alan Kay (pictured), Adele Goldberg (pictured)
What they did: Invented the graphical user interface (GUI), the desktop metaphor, Ethernet, laser printing, object-oriented programming (Smalltalk), and WYSIWYG editing. Steve Jobs famously “borrowed” their ideas for the Macintosh.
Why they matter for the 20 concepts: The entire frontend paradigm, windows, icons, menus, clicking, came from PARC. Alan Kay’s Smalltalk pioneered object-oriented thinking that underlies modern architecture patterns.
8. Richard Stallman (1953-)
What he did: Founded the Free Software Foundation, created GNU (the tools that make Linux usable), wrote the GPL license, and championed the idea that software should be free (as in freedom, not price).
Why he matters for the 20 concepts: Open source, package managers, the entire ecosystem of shared code, all built on his philosophical and legal foundations. npm, pip, and every dependency you install exist because he insisted software should be shareable.
9. Linus Torvalds (1969-)
What he did: Created Linux (1991) and Git (2005). Linux runs most of the internet’s servers, all Android phones, and most cloud infrastructure. Git is the version control system that powers GitHub and modern development.
Why he matters for the 20 concepts: Version control (#1) and servers (#9) — both directly from him. When you git commit, you’re using his tool. When your code deploys to a server, it’s probably running his operating system.
10. Tim Berners-Lee (1955-)
What he did: Invented the World Wide Web at CERN; HTML, HTTP, URLs, the first web browser, and the first web server. Made the web free and open rather than proprietary.
Why he matters for the 20 concepts: HTTP (#16), the entire frontend/backend split (#6), APIs (#7) all exist because he created the web as an open platform. Every web developer is building on his foundation.
11. You
Go make something.
You didn't have to write this - you could have just said, if you don't know what all those terms mean, look them up yourself. But you aren't a gatekeeper. I love that.
My first job out of community college (eons ago) was as a part-time web designer for the college, which led to a full-time job for a corporation. I loved it. But I moved into other roles and away from developing. So some of this isn't new to me, but is sentimental; I remember it. I hear the rest of the terms all the time, in the job descriptions I scour, and in the discussions I follow. Could I skill up into that role again (in some meaningful amount of time)? I'm doubtful. It's like I'm a karaoke singer - I can follow along and enjoy myself, but don't have the chops to actually go it alone. I still find all of this worthwhile. It informs me so I can ask good questions and look at what people/companies are selling with an objective eye. I think what you're doing is important to more than just the people who do this work. And you make it interesting and understandable. Thanks for sharing your excitement and bringing us along!
Hearing you “bash” away on the keyboard was a beautiful reminder that designers who are informed can directly wield this tech, experiment and converse across disciplines. Reminded me of sitting in my dorm room at university, typing my first strokes into file systems, wondering what I had just wandered into, if I was supposed to go there as a designer of digital things, then realizing it was foundational to realizing my vision. Thank you.