DEV Community: I Want To Learn Programming

The rocket equation explained by coding it

I Want To Learn Programming — Mon, 15 Jun 2026 14:00:07 +0000

The Tsiolkovsky rocket equation is the single most important formula in spaceflight, and it explains why getting to orbit is so brutally hard. It is one line, and coding it makes its consequences (including why rockets have stages) impossible to miss.

The equation

The change in velocity a rocket can achieve, its delta-v, is:

import math

def delta_v(exhaust_velocity, mass_initial, mass_final):
    return exhaust_velocity * math.log(mass_initial / mass_final)

In words: delta-v equals the exhaust velocity times the natural log of the mass ratio (the rocket fully fueled, divided by the rocket empty). Two things give you more delta-v: faster exhaust (better engines), or a bigger mass ratio (more fuel relative to structure).

Why the log is the tyranny

That logarithm is the whole story. Because delta-v grows with the log of the mass ratio, getting more delta-v needs exponentially more fuel. Want to double your delta-v? You do not need twice the fuel, you need the mass ratio squared.

ve = 4500   # m/s, a decent chemical engine
# to reach low Earth orbit you need roughly 9,400 m/s of delta-v
# (after losses). Solve for the mass ratio that requires:
required_ratio = math.exp(9400 / ve)   # about 8.1

A mass ratio of 8 means roughly 88% of the rocket at liftoff has to be propellant, leaving only about 12% for the engines, tanks, structure, and payload combined. That is why rockets are giant tanks with a tiny payload on top. This is "the tyranny of the rocket equation."

Why rockets have stages

Staging is the workaround. Once a tank is empty, you are dragging dead weight, which kills your mass ratio. Dropping spent stages lets the remaining rocket have a fresh, favorable mass ratio. The total delta-v is the sum of each stage's:

def staged_delta_v(stages):
    # stages: list of (ve, m_initial, m_final)
    return sum(delta_v(ve, mi, mf) for ve, mi, mf in stages)

Coding it shows why a single-stage rocket to orbit is so hard with chemical fuel, and why nearly every orbital rocket sheds stages on the way up. The equation is not just trivia; it dictates the shape of every rocket ever flown.

Build the rocketry

The aerospace with Python track builds up from physics like this to real rocketry and simulation, all from scratch and graded in your browser. The first project is free.

One line of physics explains the size of every rocket. Code it, and the whole design logic of spaceflight falls out.

PID control explained with a line-following robot

I Want To Learn Programming — Mon, 15 Jun 2026 14:00:03 +0000

PID control runs an enormous share of the physical world: thermostats, cruise control, drones, 3D printers, and the steering of self-driving cars. It sounds technical, but a line-following robot makes every part of it intuitive. The robot's job is simple: stay on the line. PID is how it decides how hard to turn.

The setup

A line follower has a sensor that tells it how far off the line it is. Call that the error: zero means dead center, positive means it has drifted right, negative means left. PID turns that error into a steering command, using three terms.

P, the proportional term

The simplest idea: steer in proportion to how far off you are. Drifted far right, turn hard left; barely off, turn gently.

double correction = Kp * error;

P alone often works, but it tends to overshoot and weave across the line, because it only reacts to the current error, not where things are heading.

D, the derivative term

The derivative looks at how fast the error is changing and damps the motion. If the robot is racing back toward the line, D eases off so it does not overshoot. It is the term that smooths the weaving.

double d = Kd * (error - prev_error);
prev_error = error;

P says "how far off am I"; D says "how fast am I correcting," and together they give a smooth approach.

I, the integral term

The integral accumulates error over time, to fix a small, persistent offset that P never quite closes (for example, if the robot consistently rides slightly to one side). It builds up until the bias is corrected.

integral += error;
double i = Ki * integral;

I is powerful but needs care, because the accumulator can grow too large (a problem called integral windup).

Putting it together

double steer = Kp * error
             + Ki * integral
             + Kd * (error - prev_error);

That single line is PID. Tuning the three gains (Kp, Ki, Kd) is the art: too much P weaves, too little is sluggish, D smooths, I removes drift. A line-following robot lets you feel each gain's effect immediately, which is why it is the classic teaching example.

Build it and tune it

The robotics track builds a line-following robot with PID control in C++ and simulation, so you can watch each term change the behavior and tune the gains yourself, graded in your browser. The first project is free.

Understand PID on a line follower, and you understand the algorithm steering drones and cars.

What embeddings are, explained by building one

I Want To Learn Programming — Sun, 14 Jun 2026 14:00:07 +0000

Embeddings are behind search, recommendations, and most of modern AI, and they are usually explained with intimidating diagrams. The core idea is simple and worth building yourself: an embedding turns a thing (a word, a document, a product) into a list of numbers (a vector) so that similar things end up close together in that number space.

Why turn things into vectors

Computers cannot compare meaning directly, but they can compare vectors. If "king" and "queen" are nearby points, and "king" and "banana" are far apart, then "closeness of vectors" becomes a usable stand-in for "similarity of meaning." Once your items are vectors, search and recommendation become geometry: find the nearest points.

Measuring closeness

The standard measure is cosine similarity, the angle between two vectors. Identical direction scores 1, unrelated scores near 0, opposite scores -1.

import math

def cosine(a, b):
    dot = sum(x * y for x, y in zip(a, b))
    na = math.sqrt(sum(x * x for x in a))
    nb = math.sqrt(sum(y * y for y in b))
    return dot / (na * nb)

With just this, you can already build a tiny semantic search: embed your documents, embed the query, and return the documents with the highest cosine similarity.

A first embedding you can build by hand

You do not need a neural network to feel the idea. A simple bag-of-words vector already places similar documents near each other:

def embed(text, vocab):
    counts = {w: 0 for w in vocab}
    for w in text.lower().split():
        if w in counts:
            counts[w] += 1
    return [counts[w] for w in vocab]

Two documents about the same topic share words, so their vectors point in a similar direction, so cosine similarity is high. That is the whole mechanism, in miniature. Real embeddings (word2vec, or the ones inside large language models) learn far richer vectors where direction captures meaning, not just word overlap, but the principle is identical: similar things, nearby vectors.

Why building it matters

Once you have built a vector space and searched it by cosine similarity, the buzzwords resolve: a "vector database" is a store of these vectors with fast nearest-neighbor search; "semantic search" is exactly what you just did; retrieval for AI is embedding your documents and finding the closest ones to a question. You will understand the systems instead of trusting them.

Build it for real

The AI and Deep Learning track builds embeddings from scratch, from counting vectors to learned representations and the attention that powers transformers, all graded in your browser. The first project is free.

Turn things into vectors, and a huge amount of modern AI becomes geometry you can reason about.

SQL injection explained safely with a toy login

I Want To Learn Programming — Sun, 14 Jun 2026 14:00:03 +0000

SQL injection has been at or near the top of web vulnerability lists for two decades, and yet it is genuinely easy to understand once you see it happen. The safe, legal way to learn it is on a toy login you build yourself: watch it break, then fix it properly. This article is about defense, not attacking anyone's system.

How the bug happens

Imagine a login that builds its query by gluing user input into a string:

# VULNERABLE, do not do this
query = f"SELECT * FROM users WHERE name = '{username}' AND pw = '{password}'"

The problem is that the input is treated as part of the SQL, not as data. If someone types this as the username:

admin' --

the query becomes:

SELECT * FROM users WHERE name = 'admin' --' AND pw = '...'

The -- comments out the password check, and they are logged in as admin without knowing the password. The input changed the structure of the query. That is injection.

Why string-building is the root cause

The vulnerability is not really about SQL; it is about mixing code and data in the same string. Whenever untrusted input can change the meaning of a command (SQL, shell, HTML), you have an injection class of bug. SQL injection is just the most famous member.

The fix: parameterized queries

The correct fix is to never build queries by concatenation. Use parameterized queries (also called prepared statements), where the database is told the query structure separately from the values:

# SAFE
cur.execute(
    "SELECT * FROM users WHERE name = ? AND pw = ?",
    (username, password),
)

Now admin' -- is treated as a literal username string, searched for, and not found. The input can never change the query's structure, because structure and data travel separately. This single habit eliminates the entire vulnerability class.

The other half: validation and least privilege

Parameterized queries are the core fix, but defense in depth helps: validate input (a username should not be 5,000 characters), hash passwords properly so a leaked table is not catastrophic, and give the database account only the permissions it needs so a breach is contained.

Learn it by building both sides

Understanding the attack from the inside is what makes the defense stick. The cybersecurity track covers web security, including building a vulnerable endpoint and then securing it, plus the crypto and forensics around it, all run safely in your browser. The first project is free.

See injection happen once on your own toy app, and parameterized queries stop being a rule you follow and become a thing you understand.

Orbital mechanics with Python, from circular orbits to Hohmann transfers

I Want To Learn Programming — Sat, 13 Jun 2026 14:00:07 +0000

Orbital mechanics sounds like it needs a graduate degree, but the core results are surprisingly reachable with high-school physics and a few lines of Python. If you can compute an orbital velocity and a transfer, you understand the foundation that mission planning is built on.

A circular orbit

For a circular orbit, gravity provides exactly the centripetal force, which gives a clean formula for orbital speed:

import math
MU = 3.986e14   # Earth's gravitational parameter, m^3/s^2

def circular_velocity(r):
    return math.sqrt(MU / r)   # m/s at orbital radius r (meters)

A satellite in low Earth orbit (about 200 km up, so r is roughly 6,571 km) moves at close to 7.8 km/s. That single formula already explains why orbital speeds are so high: lower orbits need to move faster to stay up.

Orbital period

How long one lap takes follows from Kepler's third law:

def period(r):
    return 2 * math.pi * math.sqrt(r**3 / MU)   # seconds

Plug in geostationary radius (about 42,164 km) and you get roughly 24 hours, which is exactly why those satellites appear to hang still over one spot on Earth. The formula predicts the orbit that makes GPS and communications satellites work.

The Hohmann transfer

The classic, fuel-efficient way to move between two circular orbits is the Hohmann transfer: one burn to enter an elliptical path that just touches both orbits, and a second burn to circularize at the new altitude. The two velocity changes come from the vis-viva equation:

def hohmann(r1, r2):
    v1 = math.sqrt(MU / r1)
    v2 = math.sqrt(MU / r2)
    a = (r1 + r2) / 2   # transfer ellipse semi-major axis
    vp = math.sqrt(MU * (2 / r1 - 1 / a))   # speed at perigee of transfer
    va = math.sqrt(MU * (2 / r2 - 1 / a))   # speed at apogee of transfer
    return abs(vp - v1) + abs(v2 - va)      # total delta-v

That total delta-v is the fuel budget for the maneuver, the number a mission planner actually cares about. With these few functions you can already reason about real transfers, like raising a satellite from a parking orbit to its operational altitude.

Build the whole thing

This is the kind of problem where coding it is understanding it: change a radius and watch the velocity and delta-v respond. The aerospace with Python track builds orbital mechanics and much more from scratch, graded in your browser. The first project is free.

The math of getting to orbit is closer than you think. Start computing it.

Data science portfolio projects that are not toy notebooks

I Want To Learn Programming — Sat, 13 Jun 2026 14:00:03 +0000

Most data science portfolios are a folder of notebooks that all look the same: load a clean dataset, call fit, print an accuracy number. Hiring managers have seen the Titanic notebook a thousand times, and it tells them nothing, because it skips every hard part of real data work. A portfolio project that stands out shows the skills that actually matter on the job.

Here is what those are.

1. Handling messy, real data

Real data is missing values, wrong types, duplicates, inconsistent labels, and outliers. A project that starts from a clean Kaggle CSV demonstrates none of this. Use a messy, real source and show your cleaning: what you found, what you decided, and why. The cleaning is the work; do not hide it.

2. Avoiding data leakage

This is the mistake that separates beginners from people who can be trusted with a model. Leakage is when information from the future, or from the test set, sneaks into training, giving an amazing score that collapses in production. Fitting your scaler on the whole dataset before splitting is leakage. Showing that you understand and prevent it is one of the strongest signals you can send.

3. Honest train/test splits and validation

Split before you do anything, hold out a real test set you only touch once, and use cross-validation to estimate performance. A single train/test accuracy is not enough. Reviewers look for whether you validated honestly, because a model that only works on the data it saw is worthless.

4. The right metrics

Accuracy is misleading on imbalanced data (99% accuracy by predicting "no" every time). Show that you chose metrics that fit the problem: precision and recall, a confusion matrix, ROC where it makes sense, and that you can explain the trade-off in plain language.

5. Reproducibility

Can someone run your project and get your results? Fixed random seeds, a clear environment, and an ordered pipeline. Reproducibility is a professional habit, and its absence is obvious.

6. A story, not just a model

The best projects answer a real question and tell the story: here was the question, here is what the data showed, here is what I would do about it. The model is a means to an insight, not the point. Communication is half the job.

Build projects that show this

The data science track builds machine learning from scratch on real, messy data, with the full pipeline (cleaning, splits, metrics, validation) done honestly, and graded in your browser. The work you do becomes exactly the kind of project worth putting in a portfolio. The first project is free.

A model is easy. A trustworthy result is what gets you hired.

The Python projects that actually teach you to code

I Want To Learn Programming — Fri, 12 Jun 2026 14:00:06 +0000

Search "beginner Python projects" and you get the same list: a calculator, a number-guessing game, a to-do app. They are not wrong, but copying them teaches you little, because they exercise one idea and then you move on. What actually builds a programmer is a sequence of projects where each one forces a new fundamental and builds on the last.

Here is the progression that works, and why each step matters.

1. Foundations: variables, expressions, and output

Before any "app," get fluent with values, types, arithmetic, and printing results. Build small programs that compute something real (unit conversions, a tip splitter, a simple statistics summary). The goal is that data types and expressions become second nature, because every later project assumes them.

2. Control flow: decisions and repetition

Now add if, for, and while. Projects that loop over input and branch on conditions (a grading script, a simple text menu, a prime checker) teach you to reason about what the program does step by step. This is also where you start hitting and fixing real bugs.

3. Collections: lists, dicts, sets

This is the jump from "scripts" to "programs." Counting things with a dict, de-duplicating with a set, and processing lists is the core of almost all real code. A word-frequency counter or a small inventory tracker teaches more than ten toy apps.

4. Files and JSON

Real programs read and write data. Reading a CSV, parsing JSON, and saving results to disk turns your programs into things that persist and interact with the outside world. This single step makes everything you build feel real.

5. Functions and organization

As projects grow, you learn to break them into functions, then modules. This is where you stop writing one long script and start designing. A small tool with several functions that call each other teaches composition, the skill behind all larger software.

6. Objects: modeling a domain

Finally, classes: bundling data and behavior to model a thing (a bank account, a deck of cards, a small simulation). Object thinking is what lets you build systems instead of scripts.

7. A capstone that combines everything

End with a project that needs all of it: input, control flow, collections, files, functions, and objects together. That integration is where it all consolidates into real ability.

Why the order matters

Each step is a prerequisite for the next, and skipping ahead is why people stall. You cannot model a domain with objects if dicts still confuse you. The compounding is the point.

A track built exactly this way

The general coding track is this exact progression, foundations through control flow, collections, files, functions, objects, and a capstone, with every level a real problem graded the moment you run it. The first project is free.

Skip the filler. Build the sequence that compounds.

Cybersecurity with Python, what beginners should actually build

I Want To Learn Programming — Fri, 12 Jun 2026 14:00:02 +0000

Most cybersecurity beginners get stuck downloading tools and memorizing acronyms. That teaches you to push buttons, not to understand security. The faster path is to build the primitives yourself in Python. Once you have implemented the building blocks, both attacks and defenses make sense, because you know what is happening underneath.

Here is what to build, and what each one teaches.

1. Encoding and decoding

Start with Base64 and hex by hand. It is not security, but it teaches you how data is represented and transmitted, which is the foundation of reading anything (payloads, tokens, captured traffic). The first "aha" is realizing how much of what looks scrambled is just encoded.

2. XOR and the idea of a key

Implement a XOR cipher. It is weak, but it teaches the core idea of symmetric encryption (combine data with a key, reversibly) and, importantly, why naive schemes break (key reuse, known plaintext). Breaking your own XOR cipher teaches more than reading about AES.

3. Hashing

Build a tamper check with SHA-256: hash a file, change one byte, watch the hash change completely. This teaches integrity, the property behind checksums, signatures, and password storage. Then learn why plain hashes are wrong for passwords (too fast) and what salting fixes.

4. HMAC and message authentication

Combine a hash with a secret key to prove a message came from who you think and was not altered. HMAC is everywhere (API signing, webhooks, tokens), and building one teaches the difference between "this is unchanged" and "this is unchanged and from a trusted source."

5. Log forensics

Parse a server log, count requests per IP, and flag suspicious patterns (a spike of failed logins, a scan across many paths). This is the defensive analyst's daily work, and it is just text processing plus pattern recognition.

6. Input validation and injection

Build a tiny vulnerable login, see how unsanitized input breaks it, then fix it with parameterized queries and validation. Understanding injection from the inside is the single most valuable defensive lesson, and you learn it safely on your own toy system.

Why build instead of download

Security is about understanding systems deeply enough to find where they break. Tools hide that understanding; building reveals it. When you have written a hash check, an HMAC, and a log parser, you can reason about real systems instead of running scripts you do not understand.

Build the toolkit

The cybersecurity track is built this way: encoding, classical and modern crypto, hashing, password cracking, log forensics, network analysis, web security, and a reverse-engineering finale, all built and run in your browser. The first project is free.

Understand it by building it. That is what makes a security mindset.

Learn robotics programming by simulating a robot first

I Want To Learn Programming — Thu, 11 Jun 2026 14:00:07 +0000

People who want to learn robotics usually think the first step is buying a kit. It is not. The expensive, frustrating part of hardware (wiring, motors, flaky sensors) teaches you very little about the part that actually makes a robot intelligent: the code that decides what it does. You can build all of that in simulation first, and it transfers directly to real robots.

What simulation lets you learn

The "brain" of a mobile robot is a stack of ideas that are pure software, and you can build every one of them without a single motor:

Pose: where the robot is and which way it faces, usually (x, y, theta). Everything else is updates to this.
Odometry: estimating the new pose from wheel motion. This is dead reckoning, and building it teaches you why errors accumulate over time.
Sensors: modeling a range sensor that reports distance to obstacles, so the robot can perceive its world.
Control: turning "I want to go there" into wheel commands, which is where PID control comes in.
Behaviors and state machines: wandering, following a wall, avoiding obstacles, and switching between them cleanly.
Mapping and planning: building an occupancy grid of what is free or blocked, then finding a path with A*.

A robot that can localize, sense, decide, and plan a path in simulation is running the same logic a real one would. The hardware just executes the commands your code already knows how to produce.

Why this order is better

When you start with hardware, a bug could be your code, a loose wire, a dying battery, or a miscalibrated sensor, and you waste hours not knowing which. In simulation, the only variable is your logic, so you learn the concepts cleanly and fast. Then, when you do move to hardware, you are debugging the physical layer alone, with a brain you already trust.

This is also how serious robotics is actually done: simulate first, then deploy. It is not a beginner shortcut; it is the professional workflow.

Build the robot's brain

The robotics track builds a complete mobile robot in C++ through simulation: the robot class and kinematics, odometry, sensors, PID control, line following, reactive behaviors and state machines, occupancy-grid mapping, and A* path planning, all graded in your browser. The first project is free.

Learn the part that makes a robot smart. The motors can wait.

Backpropagation explained by coding it

I Want To Learn Programming — Thu, 11 Jun 2026 14:00:02 +0000

Backpropagation is the algorithm that trains every neural network, and it has a reputation for being hard. It is not. It is the chain rule from calculus, applied backward through a chain of operations. The fastest way to understand it for good is to code a tiny version yourself.

The one idea

Training means adjusting weights to reduce a loss. To adjust a weight, you need to know how the loss changes when that weight changes, which is its gradient. Backprop is just an efficient way to compute every weight's gradient by working backward from the loss.

Forward pass: data flows in, predictions and loss come out. Backward pass: gradients flow back, from the loss to every parameter.

The chain rule, concretely

If loss depends on a, and a depends on w, then how much the loss changes with w is the product of the local changes:

d(loss)/d(w) = d(loss)/d(a) * d(a)/d(w)

That is the whole trick. Each operation knows its own local derivative; backprop multiplies them along the path from the loss back to each weight.

A tiny worked version

Take one neuron: z = w*x + b, then a = sigmoid(z), then a loss comparing a to the target y. The backward pass computes, in order:

# forward
z = w * x + b
a = 1 / (1 + math.exp(-z))
loss = (a - y) ** 2

# backward (chain rule, step by step)
dloss_da = 2 * (a - y)
da_dz    = a * (1 - a)        # derivative of sigmoid
dz_dw    = x
grad_w   = dloss_da * da_dz * dz_dw
grad_b   = dloss_da * da_dz   # dz/db = 1

Then you nudge the weights down their gradients (w -= lr * grad_w) and repeat. Scale this from one neuron to a layer to a network, and you have exactly what frameworks do, just with more bookkeeping.

Why coding it matters

Once you have written the backward pass by hand, a lot of deep learning stops being mysterious: why gradients can vanish (many small derivatives multiplied together), why activation choice matters (its derivative is a factor in every gradient), and what an optimizer is actually doing. You will read framework code and recognize the machinery instead of trusting it blindly.

Build the whole thing

The AI and Deep Learning track takes you from a single neuron through hand-coded backprop to training real networks, all built from scratch and graded in your browser, ending in a tiny GPT you backpropagate yourself. The first project is free.

Code the backward pass once, and neural networks will never look like magic again.

Code Challenge of the Day: Product of array except self (hard)

I Want To Learn Programming — Wed, 10 Jun 2026 15:34:51 +0000

Return a list where out[i] is the product of all elements except numsi.
Write product_except_self(nums).

Starter:

def product_except_self(nums):
    # TODO
    pass

Solve it interactively in your browser (no setup), check your answer instantly, and keep your daily streak going on IWTLP: https://iwtlp.com/challenge

SQL for data analysis, the 10 query patterns that matter

I Want To Learn Programming — Wed, 10 Jun 2026 15:34:49 +0000

You do not need to memorize hundreds of SQL functions to be a strong analyst. Real analytical work is a small set of patterns that come up again and again. Learn these ten and you can answer most questions a business will throw at you.

1. Filtering and aggregation

The foundation: WHERE to pick rows, GROUP BY with COUNT, SUM, AVG to summarize. Most reports are some version of "this metric, by this dimension."

SELECT region, COUNT(*) AS orders, SUM(amount) AS revenue
FROM orders GROUP BY region;

2. Joins

Combining tables is the heart of SQL. Know the difference between an inner join (only matches) and a left join (keep all rows on the left, fill nulls where there is no match). Most "where did my rows go" bugs are an inner join that should have been a left join.

3. Conditional aggregation

Counting subsets in one pass with CASE inside an aggregate. This replaces running several queries.

SELECT
  COUNT(*) AS total,
  COUNT(*) FILTER (WHERE status = 'paid') AS paid
FROM orders;

4. Window functions

The analyst's superpower: compute across a set of rows without collapsing them. Running totals, rankings, and "compared to the row before."

SELECT day, revenue,
  SUM(revenue) OVER (ORDER BY day) AS running_total
FROM daily;

5. Ranking and top-N-per-group

ROW_NUMBER() or RANK() partitioned by a group, to get "the top 3 products in each category."

6. CTEs for readable, layered queries

WITH lets you name a step and build on it, so a complex query reads top to bottom instead of as nested subqueries. Use them to keep analysis legible.

7. Cohorts

Group users by when they joined, then track each cohort over time. The pattern: derive a cohort key (signup month), then aggregate activity by cohort and period.

8. Funnels

Count how many users reached each step of a flow (viewed, added to cart, purchased), usually with conditional aggregation or joins between step events.

9. Retention

What fraction of a cohort comes back in week 1, 2, 3. A join of a cohort to its later activity, then a ratio. This is one of the most-asked analytics questions.

10. Null handling

Nulls break sums, comparisons, and joins in surprising ways. COALESCE to supply defaults, and remember that NULL = NULL is not true. Most subtle SQL bugs trace back to nulls.

Build the patterns, not flashcards

These click when you run them on real tables and see the rows change. The SQL track builds each of these patterns on real data, graded in your browser as you write the query. The first project is free.