SQL Is the Best Skill Per Hour for Non-Programmers, and Your Phone Is the Place to Practice It
If you are an analyst, a marketer, a product manager, a founder, or anyone else who spends the day asking other people for numbers, there is one technical skill that pays back faster than every other: SQL. Not Python, not a dashboard tool, not a spreadsheet macro. SQL.
The reason is simple. The data you want already lives in a database. Someone in your company is currently writing a query to get it for you, and you are waiting in their queue. Learning to write that query yourself removes the queue. Twenty hours of practice is enough to answer most of the questions you would otherwise ask, and the value starts on hour five.
Why SQL is unusually well suited to phone practice
Most programming is awkward on a phone because programs are long and results are visual. SQL is the opposite on both counts.
A useful query is two to six lines. SELECT some columns, FROM a table, WHERE a condition, ORDER BY something. That fits on a phone screen with room to spare, and it is fast to type even on glass.
The result is a table of rows, and it is either right or it is not. There is no "does this look okay." Either you got the five customers who spent more than a hundred dollars, sorted by total, or you did not. That kind of exact, immediate feedback is exactly what makes short practice sessions stick.
And SQL is declarative. You are describing what you want, not the steps to compute it. That means there is much less to hold in your head at once compared to a loop-based language, which matters when your session is the length of a bus ride.
The part that usually stops people: setup
Historically the barrier to SQL practice was never the language. It was installing PostgreSQL, creating a database, finding some data to load into it, and then dealing with a client application. Most people bounce off before writing a single SELECT.
That is why an app with the database built in changes the equation. Codewise 1.2 adds a PostgreSQL module with an in-memory SQL engine that runs entirely on the device. Tables, rows, queries, results, all inside the app, no server and no connection. It covers CREATE TABLE, INSERT, SELECT, WHERE, ORDER BY, GROUP BY with aggregates, JOINs, UPDATE, and DELETE. Each challenge gives you a table or two to work with, asks for a specific result, and checks your output. Like the rest of Codewise, it is a one-time purchase with no account and no ads, and the same purchase runs on iPhone, iPad, and Mac.
A ten query starter path
Here is the order I would learn in. Each step is one idea, and each is a five minute session on a phone. Do each one until you can write it without looking, then move on.
- SELECT specific columns. Start with SELECT name, email FROM customers. Resist the star. Naming columns forces you to know what is in the table.
- WHERE with one condition. WHERE country = 'Canada'. Then a number: WHERE total > 100. Notice that text needs quotes and numbers do not.
- WHERE with AND and OR. Combine two conditions. Learn what parentheses do when you mix AND and OR, because this is where real reports go wrong.
- ORDER BY. Sort ascending, then descending. Sort by two columns. Add LIMIT to get the top five.
- COUNT. SELECT COUNT(*) FROM orders WHERE status = 'shipped'. Your first aggregate, and the one you will use most.
- SUM and AVG. Total revenue, average order value. Give the result a name with AS so the output reads like a report.
- GROUP BY. Revenue per country. Orders per customer. This is the step where SQL starts replacing pivot tables, and it is the one to spend the most time on.
- HAVING. Customers with more than three orders. The difference between WHERE and HAVING will confuse you once and then never again.
- INNER JOIN. Customer names next to their orders. Two tables, one key, one query. Once this clicks you can answer most questions a business asks.
- LEFT JOIN. Customers with zero orders. The rows that are missing are often the most interesting ones, and LEFT JOIN is how you find them.
After ten, add INSERT, UPDATE, and DELETE so you understand how data gets into the state you are querying. You will rarely run them at work as a non-engineer, but reading them makes you far better at understanding why a report looks the way it does.
How to structure the practice
Three short sessions a day beat one long one. The morning commute for a new concept, lunch to repeat it, and the evening to redo yesterday's query from a blank editor. Total time is under twenty minutes, and because the results are exact you always know whether you are done.
Keep a running list of real questions from your job: "which campaign brought the most signups last month," "how many accounts have not logged in for ninety days." Every time you learn a new clause, look at the list and see which question you can now answer. That is the moment the practice turns into leverage.
Why PostgreSQL specifically
SQL has dialects, and if you learn one you can read the others. But if you are going to pick one to learn on, PostgreSQL is the sensible choice. It is what a large share of modern products run on, its syntax is close to the standard, and what you practice will transfer almost unchanged to the analytics warehouses most companies use. Learning it on a phone with an engine that behaves like Postgres means the queries you write on the train are the queries you will write at your desk.
The honest limit
A phone will not teach you to design a schema for a production system, tune a slow query against a hundred million rows, or manage permissions. Those are database engineering skills and they need real infrastructure. But those are also not why you are learning SQL. You are learning it to stop waiting for someone else to answer your question. Ten queries get you there, and all ten fit in your pocket.