DEV Community: I Want To Learn Programming

Why project-based learning beats watching tutorials

I Want To Learn Programming — Tue, 09 Jun 2026 03:04:43 +0000

Almost everyone learning to code hits the same wall: you have watched dozens of hours of tutorials, you nod along to every line, and then you open a blank file and freeze. This is "tutorial hell," and it is not a discipline problem. It is a method problem.

Why watching feels like learning but is not

Watching a tutorial gives you the feeling of understanding because you are following someone else's decisions in real time. But following is not the same as generating. The hard part of programming is not understanding a line once it is written; it is deciding what to write on a blank page, and recovering when it breaks. Tutorials skip exactly that part, because the instructor already made every decision for you.

It is the difference between watching someone lift weights and lifting them yourself. Only one builds the muscle.

What building forces you to do

When you build something yourself, you are forced through the skills that actually matter:

Deciding what to write from a vague goal, which is most of real programming.
Hitting errors and reading them, forming a hypothesis, and finding the cause. Debugging is the core skill, and you only practice it when your own code fails.
Holding the whole problem in your head, not just the current line.
Recalling instead of recognizing. Recognizing a concept in a video is easy; recalling it from a blank page is the skill you are actually after.

This is why people who build a handful of real projects outpace people who finish ten courses.

How to escape tutorial hell

Build the thing, then look up only what you are stuck on. Reverse the order: start with the blank page, not the video.
Make it fail. Break your working code on purpose and fix it. Bugs are where learning concentrates.
Get immediate feedback. The longer the gap between writing code and finding out whether it works, the less you learn. Fast feedback is what keeps you in the loop.
Keep the projects real and small. Not a "calculator app" you copy, but a problem you actually have to think through.

This is the whole idea behind IWTLP

Every level here is a real problem you solve by writing working code, graded the instant you run it, so you are always building and always getting feedback, never just watching. Passing a project's assessment earns a verifiable certificate, so the proof is in what you built.

Browse the tracks and write your first real program. The first project of every discipline is free, no card needed. Close the tutorials and open a blank file. That is where it starts.

Pandas vs SQL, when to use each

I Want To Learn Programming — Tue, 09 Jun 2026 03:04:41 +0000

Pandas and SQL do a lot of the same things: filter rows, group, aggregate, join. So analysts reasonably ask which to learn and when to use which. The honest answer is that you want both, but they win in different situations. Here is the practical breakdown.

They are more alike than they look

Most core operations map almost one to one:

-- SQL
SELECT region, AVG(amount) AS avg_amount
FROM sales
WHERE amount > 0
GROUP BY region;

# pandas
(sales[sales.amount > 0]
 .groupby("region")["amount"].mean())

If you know one, the other is mostly a translation exercise. The interesting question is which fits the task.

When SQL wins

The data lives in a database. If it is already in Postgres or a warehouse, query it there. Pulling millions of rows into Python just to filter them is wasteful.
Scale. Databases are built to scan, index, and join large tables efficiently. Pandas holds everything in memory, so it hits a wall.
Shared, repeatable logic. A SQL view or query is easy to share and run on a schedule.
Joins across many tables. This is SQL's home turf.

When pandas wins

Exploration and iteration. Reshaping, plotting, and trying ideas quickly is smoother in a notebook.
Anything beyond querying. Cleaning messy data, feature engineering, applying a custom function row-wise, or feeding a machine learning model. SQL is not built for that.
Mixed-format data. JSON, CSVs, APIs, and odd files are easier to wrangle in Python.
Visualization. Pandas plugs straight into Matplotlib and friends.

The pattern most analysts settle on

Use SQL to do the heavy lifting close to the data (filter, join, aggregate, and reduce a huge table to the slice you care about), then pull that smaller result into pandas for cleaning, analysis, modeling, and charts. SQL narrows; pandas explores.

Learning both is not redundant; it is the standard analyst toolkit. The database answers "what does the data say at scale," and pandas answers "what do I do with this slice."

Learn them by doing

The fastest way to feel where each one fits is to run the same analysis both ways. The SQL track builds query skills on real tables, and the data science track builds the pandas-and-beyond side, both graded in your browser. The first project of each is free.

Encoding vs encryption vs hashing, explained simply

I Want To Learn Programming — Mon, 08 Jun 2026 18:57:52 +0000

Encoding, encryption, and hashing get confused constantly, and the confusion causes real security bugs (like "encrypting" passwords, or trusting Base64 to hide a secret). They solve three different problems. Here is the clear version.

Encoding: for format, not secrecy

Encoding transforms data into another format so it can be stored or transmitted safely, for example Base64 to put binary into text. It is fully reversible by anyone, with no key. Base64 is not security; it is the digital equivalent of writing in a different alphabet.

import base64
base64.b64encode(b"hello")   # b'aGVsbG8='  -> anyone can decode this

Use it for: moving data through channels that expect text (data URLs, JSON, email). Never use it to protect anything secret.

Encryption: for secrecy

Encryption scrambles data with a key so that only someone with the right key can read it. It is reversible, but only if you have the key. This is what protects messages, files, and traffic.

plaintext + key -> ciphertext   (and back, with the key)

There are two families: symmetric (same key to encrypt and decrypt, fast, for data at rest) and asymmetric (a public key encrypts, a private key decrypts, the basis of HTTPS). The golden rule: do not invent your own; use a vetted library.

Use it for: anything that must stay secret but be recovered later.

Hashing: for integrity, one way

A hash function turns any input into a fixed-size fingerprint, and it is deliberately not reversible. The same input always gives the same hash; a tiny change gives a totally different one. You cannot get the original back from the hash.

import hashlib
hashlib.sha256(b"hello").hexdigest()   # a fixed 64-char fingerprint

Use it for: verifying a file has not changed, storing passwords (with a slow, salted hash like bcrypt or argon2, never plain SHA-256), and de-duplication.

The mistakes to avoid

"We encrypt passwords." No. Passwords should be hashed (slow + salted), never encrypted, because you never need to recover the original, only check a match.
"Base64 hides it." Encoding is not encryption. Base64 protects nothing.
Plain SHA-256 for passwords. Too fast, so it is brute-forceable. Use a purpose-built password hash.

A simple way to remember: encoding is for format, encryption is for secrecy, hashing is for integrity.

See it by building it

These ideas stick when you implement them: encode and decode Base64 by hand, build a hash-based tamper check, and store a password the right way. The cybersecurity track walks through encoding, hashing, classical and modern crypto, and password cracking, all built and run in your browser. The first project is free.

Why you should build your data structures from scratch once

I Want To Learn Programming — Mon, 08 Jun 2026 18:54:58 +0000

Most developers never implement a hash map, a heap, or a binary search tree. They reach for std::unordered_map, std::priority_queue, std::map, and move on. That is correct for shipping code.

But it leaves a gap. When you have only ever used a heap, "k-th largest in O(n log k)" is a magic phrase. When you have built one, it is obvious: a size-k heap, push, pop when it overflows, done.

The trick is to build each structure exactly once, with tests checking every step, and then go back to using the standard library forever. The point is not to reinvent the wheel in production. The point is that after you have built the wheel, you can see it turning inside everyone else's code.

A short list worth doing by hand at least once:

A dynamic array (grow, amortized push) so O(1) amortized stops being a phrase.
A hash map with collision handling so you trust the O(1) average.
A binary heap so top-K and Dijkstra stop being mysterious.
A binary search tree so "inorder is sorted" is something you have seen, not memorized.

Do it in a compiled language and let the compiler and a test harness be your reviewer. The friction is the lesson.

Build all of these by hand, in C++, with a compiler grading every step: https://iwtlp.com/track/dsa-cpp