Skip to content
Allen Jones

Back to blog

What Is Computer Programming? A Clear Explanation for Beginners and Non-Technical People

Allen Jones.

Posted on Jun 19, 2019

Every app on your phone, every website you visit, every payment you make online, every traffic light that changes at the right moment, all of it runs on computer programs written by someone who learned to communicate with a machine.

Computer programming is that communication. It's the process of writing instructions a computer can understand and execute. Those instructions are called code, and the languages used to write them are called programming languages.

That's the simple version. The longer version is more interesting.

What a computer program actually is

A computer program is a set of instructions that tells a computer what to do, in what order, and under what conditions.

When you tap a button in an app and something happens, that's a program executing instructions. When a website loads your profile picture, that's a program fetching data from a server and displaying it on your screen. When your bank declines a suspicious transaction, that's a program checking your spending pattern against a set of rules and making a decision in milliseconds.

Programs range from a few lines of code that add two numbers together to millions of lines that power operating systems used by billions of people. The complexity varies enormously. The fundamental idea does not: instructions, written by a person, executed by a machine.

Programming languages

Computers don't understand English or any human language. They understand binary, sequences of zeros and ones at the hardware level. Programming languages exist as a layer between human thinking and machine execution. They give developers a way to write instructions in something that resembles readable text, which then gets translated into something the machine can run.

Different languages were built for different problems. Here's an honest summary of the most widely used ones:

Python: designed for readability. The syntax reads almost like plain English, which makes it a strong first language. Used heavily in data science, machine learning, scripting, and backend web development. The tradeoff is speed. Python is slower than compiled languages for computationally heavy work, which is why its most performance-critical libraries, like NumPy, are written in C under the hood.

JavaScript: the only language that runs natively in every web browser. Originally built for adding interactivity to web pages, it has expanded into server-side development through Node.js, mobile apps through React Native, and desktop apps through Electron. It's everywhere, which makes it valuable and also means it carries a lot of historical baggage.

TypeScript: JavaScript with a type system added on top. It compiles down to JavaScript but catches entire categories of bugs before the code runs. Most serious JavaScript projects at scale have moved to TypeScript. Both Formgrid and SheetRocket, the two products I've built and run, are written entirely in TypeScript.

Java: designed for write once, run anywhere. A Java program compiled on one machine runs on any machine with a Java runtime installed. Used heavily in enterprise software, Android development, and large-scale backend systems. Verbose by modern standards but extremely mature and stable.

Rust: a systems programming language designed for safety and performance. It prevents entire categories of memory bugs at compile time, the same bugs that cause crashes and security vulnerabilities in C and C++ programs. Growing fast in infrastructure, WebAssembly, and anywhere performance and reliability both matter.

Go: designed at Google for building fast, concurrent backend systems. Simple syntax, fast compilation, an excellent standard library for networking. Used widely for microservices, CLIs, and infrastructure tooling.

The right language for a project depends on the problem, the team, the performance requirements, and the ecosystem of libraries available. Experienced engineers choose based on fit, not familiarity.

How a program gets built

Writing code is one part of building software. The full process involves more than that.

Understanding the problem. Before writing a single line of code, a good engineer understands what problem is being solved, for whom, and what done actually looks like. This is where most projects go wrong. Building the wrong thing correctly is still building the wrong thing.

Design. Deciding how the solution will be structured: what data needs to be stored and how, what the different components are and how they communicate, what can go wrong and how those failures will be handled. Good design decisions made early save weeks of refactoring later.

Implementation. Writing the actual code. This is what most people picture when they think of programming. It's a smaller fraction of the total work than beginners expect.

Testing. Verifying that the code does what it's supposed to do, including in conditions that weren't anticipated. Automated tests catch regressions when future changes accidentally break existing behavior. A codebase without tests is a codebase where every change is a risk.

Deployment. Getting the code running on a server or device where real users can access it. Modern deployment involves version control, continuous integration pipelines, and infrastructure that can roll back a bad release without taking the service down.

Maintenance. Software is never finished. Requirements change, bugs surface in production, performance degrades under load, security vulnerabilities get discovered. Maintaining a codebase over time is often where the real engineering judgment gets built.

The tools engineers use

Version control. Git is the universal tool for tracking changes to code over time. Every change is recorded with who made it and why. Teams collaborate through platforms like GitHub without overwriting each other's work. No serious software project runs without it.

Code editors and IDEs. The environment where code is written. VS Code is the most widely used editor today. IDEs like JetBrains add deeper, language-specific tooling for larger projects.

Debuggers. Tools that let you pause a running program and inspect its state at any point. When something breaks in a way that isn't obvious from reading the code, a debugger lets you watch it break in slow motion.

AI coding assistants. Tools like GitHub Copilot and Cursor have changed how code gets written. They suggest completions, generate boilerplate, and explain unfamiliar code. They don't replace engineering judgment, but they've meaningfully changed the ratio of time spent thinking versus typing.

Libraries and frameworks. Pre-written code that solves common problems so you don't have to solve them from scratch. React for building user interfaces. Express for HTTP servers in Node.js. Prisma for database access in TypeScript. The ability to evaluate, integrate, and sometimes reject a library is a real engineering skill.

What actually makes a programmer good

Technical skill matters, but it's not the whole picture. The engineers who create the most value share a set of habits that go beyond knowing a language.

They understand the problem before they write the solution. A developer who can translate a business requirement into a technical design without losing what the business actually needs is rare and valuable.

They write code other people can read. Code is read far more often than it's written. Clear, well-named, well-structured code isn't a luxury. It's the difference between a codebase a team can move fast in and one that slows everyone down six months later.

They know what they don't know. The ability to recognize the edge of your own understanding and research or ask rather than guess is one of the most important skills in engineering. Confident guessing in production causes incidents.

They think about failure. Good engineers ask what happens when this goes wrong before shipping something. Network calls fail. Databases go down. Users submit unexpected input. Code that handles failure gracefully keeps systems running. Code that doesn't creates 3 am incidents.

They care about the outcome, not just the output. A feature shipped that nobody uses isn't a success. An engineer who understands why they're building something and can evaluate whether it worked makes better decisions at every step of the process.

Closing

Computer programming isn't a mysterious skill reserved for people with a particular kind of brain. It's a craft that improves with practice, feedback, and exposure to real problems.

The fundamentals, writing clear instructions, reasoning about failure, understanding the tools and their tradeoffs, and understanding the problem before reaching for a solution, apply across every language and every type of project.

If you're learning to program, the most valuable thing you can do is build something real for someone who will actually use it. The feedback loop of a real user with a real problem teaches things no tutorial covers.


I'm Allen, a full-stack TypeScript engineer and the founder of Formgrid, an open-source form backend and lead pipeline, and SheetRocket, a tool that turns any Google Sheet into a REST API and no-code embeddable widgets. More at jonesstack.com.