> For the complete documentation index, see [llms.txt](https://guide.ivanzakutnii.com/the-hard-way-to-swe-excellence/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide.ivanzakutnii.com/the-hard-way-to-swe-excellence/learning-path/getting-basic-understanding-of-core-programming-technologies.md).

# Getting Basic Understanding of Core Programming Technologies

The next step is to become familiar with the concepts, methods, and tools that surround a program.

Study the following topics through documentation, books, courses, and small experiments. You do not need mastery yet, but you should be able to explain what each item is for and use its basic form:

* The main paradigms used in your language: functions, modules, composition, and object-oriented concepts where applicable
* Your compiler or interpreter from the command line, plus the language's package and dependency tools
* A Unix-like command line: navigation, files, processes, permissions, pipes, and environment variables
* Debugging with an IDE or command-line debugger, logs, assertions, and reproducible inputs
* Testing basics: unit, integration, and end-to-end tests, plus the basic idea behind TDD
* Files, directories, streams, and resource handling in code
* Common data formats such as JSON and CSV, plus basic work with documents, archives, and images
* Maps/dictionaries, sets, queues, and other standard-library collections
* Processes, memory, concurrency, and the difference between synchronous and asynchronous work
* Networking basics: IP, DNS, ports, HTTP, clients, servers, and APIs
* Errors and failure: validation, exceptions or result values, retries, timeouts, and useful error messages
* Relational databases and SQL at an introductory level
* Linters, formatters, static analysis, and documentation tools
* Basic security habits: input validation, dependency hygiene, secrets, permissions, and safe handling of untrusted data
* Issue trackers and code review: understand what tools such as Jira or GitHub Issues represent in a team workflow

The challenge is that each topic can become a profession of its own. Do not turn this block into an endless survey.

A mentor can help you choose the right depth. If you are learning alone, use thinking through writing and a tiny experiment for each topic.

For example, do not merely read that a timeout exists. Write a small client that times out, observe the failure, and explain what changed when you handled it. Apply the same pattern to processes, files, tests, SQL, and the other topics.

Move on when you can build and inspect a small multi-file program with dependencies, tests, file or network I/O, and useful diagnostics. You should be able to explain how it starts, where it can fail, and how you would investigate that failure.

You can learn this on your own if you keep the scope bounded and pass each topic through your own thinking. The goal is a connected mental map that you can deepen later, not shallow familiarity with every tool name.

There is often a good book for your language that covers many of these topics in one coherent sequence. Prefer that over assembling dozens of unrelated tutorials when you can.