0.4Introduction to Rust development

Last updated June 11, 2026

Before we write our first program (we're getting close, promise), it's worth seeing the whole road map. Software development looks something like this:

1. Define the problem you want to solve
2. Design a solution
3. Write the program
4. Compile the program
5. Build the executable
6. Test the program
7. Debug the program

This lesson covers steps 1 through 3. The next lesson (0.5) covers 4 through 7. Those are the steps with machinery attached, and the machinery deserves its own lesson.

New programmers tend to assume the job is mostly step 3. Professionals will tell you, with the weary look of experience, that the job is mostly everything but step 3.

Step 1: Define the problem

First, figure out what you actually want the program to do. This sounds too obvious to be a step, and yet "I wasn't sure what it should do in this case" is the root cause of an enormous amount of broken software.

The statement can be a single sentence: "I want a program that converts measurements between units." "I want a tool that renames all my photo files by date." "I want a game where the player guesses a secret number." (That last one isn't hypothetical; you'll build it in chapter 7.)

Step 2: Design a solution

Knowing what you want is not the same as knowing how to get it, and not all hows are equal. A good solution tends to share a few traits: it's no more complicated than it needs to be, it handles the surprising inputs as well as the expected ones, it's organized so a change in one place doesn't break three others, and someone reading it later can tell what it's doing. "Later" includes you: in six months, your own code reads like a stranger wrote it.

Design is the habitually skipped step. Sitting down and typing feels like progress; sketching the shape of a solution feels like stalling. But studies of software projects have found, again and again, that most of a program's lifetime cost goes to maintaining and extending it, not writing it the first time. Code that was hacked together is exactly the code that's miserable to maintain. The minutes you don't spend on design have a way of coming back as hours.

We'll come back to design with practical techniques in lesson 2.6, once you've written enough Rust to have something to design.

Step 3: Write the program

To write a program you need two things. The first is knowledge of a programming language: that's the rest of this course. The second is an editor to type it into, and your source code goes in plain text files. Rust source files end in .rs, and by convention the main file of a program is named main.rs. You could write Rust in Notepad; in lesson 0.7 we'll set you up with an editor that colors your code as you type, flags mistakes before you compile, and fills in the boring parts. (The tooling will even create a correctly named main.rs for you. One decision you'll never have to make.)

An aside: the first "bug"

Since step 7 of every project ever has been debug the program, the word deserves its origin story.

Engineers were calling mysterious defects "bugs" long before computers existed: Thomas Edison used the word in his letters as far back as 1878. But the most famous bug in history was a literal one. On September 9, 1947, the team operating the Harvard Mark II computer (an early electromechanical machine, run for the U.S. Navy, with the soon-to-be-legendary Grace Hopper among its programmers) traced a fault to relay #70, panel F. There they found a moth. They taped the deceased into the day's logbook and wrote beneath it: "First actual case of bug being found."

The team had, in their own words, debugged the machine. The logbook, moth still attached, survives in the Smithsonian's National Museum of American History. Hopper told the story so well and so often that it's usually attributed to her personally; the historians' fine print is that the log entry was probably written by another member of the team. The moth declined to comment.

The lesson hiding in the anecdote: bugs were never figments of careless programmers. They're a permanent feature of building anything complicated, which is why this course gives debugging a whole chapter (chapter 3) instead of treating it as something that happens to other people.

Next up: what actually happens in steps 4 through 7, and the tools Rust gives you for them — some of the best reasons to learn this language in the first place.