Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Software Engineer

A software engineer designs, implements, tests, reviews, and evolves maintainable software systems, which is a perfectly reasonable way to spend a career until you remember that the code which has worked for fifteen years must not be touched, the comment "// TODO: fix this" is dated 2014, and the algorithm whose complexity was perfectly adequate last quarter is now being introduced to a customer who arrived in numbers. You learn to translate "we need a feature" into modules, abstractions, tests, reviews, a release pipeline, and a backlog of decisions whose rationale outlives the meeting that produced it. Software is not a noun; it is a very long argument with a compiler, a series of trade-offs about time and memory, and a comment that someone will eventually have to read aloud in a code review while the author is on holiday. This guide travels from writing one working function to setting engineering strategy across systems, with practical stops at construction, testing, debugging, design, delivery, and the recurring discovery that a bug which reproduces only on the reviewer's machine is technically a form of weather. The grand objective is software that does what it claims for as long as it is wanted; the daily evidence is usually a test that fails for a reason you can name, a review that finds the problem before the customer does, and a deployment that, when it breaks, breaks in a way someone once anticipated in a document now considered prophetic.

Things to recognise

• A test that passes proves the code ran; only a test that fails for a reason you can name proves the test was worth writing, since the rest is a ceremony performed for the build badge's benefit.
• Commits, branch names, and review comments accrue whether or not anyone is using them to do anything useful; name changes so the future can locate them without resorting to archaeology or a medium.
• Confirm the branch, base, and review target before pushing, because a correct change on the wrong branch remains impressively visible and surprisingly difficult to unsee.

Take the useful exit

Level 1 · Novice

Read the function before asking the compiler to deploy opinions

You read existing code, run small programs, use source control to inspect history, and review trivial changes, learning how a perfectly polite branch can introduce a subtle defect before anyone finishes reading its message.

You begin with read-only artifacts: a repository's file tree, commit history, build instructions, test output, and a style guide expressing recent opinions. A program is a sequence of statements a language runtime executes; a branch is a line of development source control tracks independently; a commit is a reviewed, dated change whose message is often the only documentation the future will receive. You review these with developers, testers, and an experienced engineer so everyone can trace how input, logic, and output connect before anyone merges a change whose green build badge is also a promise.

Suppose a team wants to add a small field to an existing form "in the code." In a feature branch with no production access, you read the relevant module, run the existing tests, add the field, watch two tests fail, and note that one failure reproduces only when the locale is set to German, which the CI matrix runs but your machine does not. You record the change, the failing assertions, and the one line that assumed a comma where a period lived. One brisk commit is an anecdote with good posture, not an architecture; but it prevents the team from shipping a feature that breaks only for a customer the test suite remembers and the developer had not met.

Words from the spaceship manual, translated

Program: A sequence of statements a language runtime executes to transform input into output. The runtime is meticulous about what you said and entirely indifferent to what you meant, which is the comment's job.
Branch: A line of development a version-control system tracks independently of the main line, allowing changes to be reviewed and merged or politely abandoned. A branch is a hypothesis with a merge button.
Commit: A dated, authored, reviewed change to the repository, with a message that is often the only documentation the future will receive. A commit that says "fix" is a postcard from someone who has since left the company.
Build badge: An indicator that automated checks ran and passed on a given commit. It is evidence of running, not of correctness, and a green badge on a broken test is merely a confidence with excellent posture.