❓ Honest FAQ

Straight answers to the questions people are sometimes embarrassed to ask.

“Am I too old for this?”

No. This is the most common fear and the least justified one. People successfully learn this material in their 40s, 50s, 60s and beyond. Adults actually have advantages: discipline, real-world context, and domain knowledge (a nurse who understands software understands hospital software better than any new graduate). What matters is consistent hours, not your birth year.

“Do I need to be good at math?”

No. Day-to-day software engineering uses roughly the math of running a household budget: arithmetic, a bit of logic, occasionally percentages. A few specialties (graphics, machine learning research, cryptography) go deeper — but you can have a whole career without them. This course contains no equations.

“Do I need an expensive computer?”

No. Every lab in this course runs in a web browser — a phone works, and any laptop made in the last decade is plenty. Professional programming is comfortable on a modest laptop.

“How long until I understand this stuff?”

Working through this course at one module a day takes about a month; at a relaxed pace, about three months. By the end you’ll genuinely understand how software works and have built real things.

“How long until I could get a job?”

Honest answer: for most people studying part-time and self-taught, 12–24 months from zero to first tech job — less for adjacent roles (QA, support, data analysis, project coordination), which are excellent, underrated entry points. Anyone promising “job-ready in 8 weeks” is selling something. Module 19 covers realistic paths in detail.

“Is it too late? Won’t AI write all the code anyway?”

AI is genuinely changing how code gets written — engineers now review and direct a lot of machine-generated code. But that raises the value of exactly what this course teaches: understanding what to build, whether it’s correct, and how the whole system fits together. The judgment is the job; typing was never the hard part. Module 16 gives you an honest picture.

“I read a page and didn’t understand it. Am I not cut out for this?”

You’re describing the normal daily experience of every professional engineer. Re-reading, looking things up, and feeling lost before it clicks is the process — not a sign you’re failing at it. Also: if a page in this course lost you, that’s officially a bug in the course. Report it.

“Which programming language should I learn first?”

For understanding and versatility: Python (what this course uses — reads almost like English). If you specifically want to make websites: JavaScript next. The secret nobody tells beginners: languages are ~80% the same ideas with different spelling. Learn one well and the second takes a fraction of the time.

“Do real programmers memorize all this?”

No. Professionals look up syntax, error messages, and definitions every single day. What they carry in their heads is the map — how things connect — which is exactly what this course builds. Nobody is checking whether you memorized anything.

“What’s the difference between computer science and software engineering?”

Computer science is the study of what computation can do (the science of recipes). Software engineering is the craft of reliably building useful software with a team over time (running an actual restaurant). This course teaches both, with the emphasis on the restaurant.

“Can I really learn this for free?”

Yes — completely. This course is free, and every resource it links to is free (we mark the rare optional paid book clearly). The main cost is your time. Paid bootcamps buy structure and pressure, not secret knowledge.

“I’m not planning to change careers. Is this still for me?”

Absolutely. Most learners here don’t want to become engineers — they want to stop feeling locked out: managers who work with developers, founders hiring their first technical person, marketers, lawyers, teachers, parents, and the curious. Understanding software is becoming basic literacy, like reading a map or a contract.

“What if I get stuck?”

Use the getting-unstuck ladder: (1) re-read the previous section slowly, (2) check the Glossary, (3) search the exact error message in quotes, (4) explain the problem out loud to anyone or anything (Module 09 explains why this weirdly works), (5) ask in a community (Module 19 lists friendly ones). Being stuck is not the exception in software — it’s the texture of the work, and getting unstuck is the skill.