Focus on Learning Languages Over Frameworks and Writing Minimal, Modular Code

Learning Languages Instead of Frameworks

I like PHP, Python, and JavaScript and enjoy using them, but I am not a Symfony, Django, or jQuery developer.

I think there is a big difference. One can become a jQuery programmer rather than a JavaScript programmer, or a Django programmer instead of a Python programmer. In practice, many valuable and practical tools and frameworks exist, but if you only know how to use a framework, using only suitable tools can limit tasks; you should examine the tools and frameworks you use. In my experience, some complex full‑stack frameworks are not the best choice, especially regarding flexibility and performance.

Focusing on mastering a language makes a programmer more flexible. Full‑stack complex frameworks can help build a product quickly, but when a solution falls outside the framework’s scope, it becomes a hindrance. I often adopt a “plug‑and‑pray” approach: when I find a library or plugin that meets a need, I apply it to the product. This can speed up delivery but may leave many obstacles later.

Moreover, learning a full‑stack framework is as complex as learning a new language. They usually have intricate architectures and terminology, and some parts do not apply to other frameworks or tools. Frameworks have many benefits, but only if you first understand the language itself; then you can grasp the framework’s true workings. Therefore, I prefer to spend time learning the language itself and applying those skills to other languages or libraries.

Building Small Modules

Small, self‑contained code units are popular among programmers because the smaller they are, the easier they are to understand and the harder they are to become messy, so limiting overly long or complex code is essential.

Thus, purposefully building small modules—as close as possible to the required goal—makes sense. They should be independent blocks that solve a specific problem, but when combined they can address large, complex issues.

Simple module code also makes bug fixing very easy. Because these isolated blocks are straightforward, their purpose is immediately clear. If a module is self‑contained, testing becomes simpler as well.

Less Code Is Better

As Biggie Smalls said: “The more code, the more problems.”

Everyone likes to manage less code. Most of us have experienced that when reviewing a feature module, a large, messy codebase gives a bad first impression, whereas concise, clear code is pleasant. In plain terms, more code means harder management: longer search times, slower navigation, and more difficult execution tracing.

You may have noticed that code reviews and many tools aim to reduce code volume. Massive libraries and long code can overflow our mental buffers. When I trace a long source file or jump across several files, I become frustrated. That’s why I appreciate syntax‑highlighting editors and consistent spacing.

Beyond preferring less code, I support developers simplifying code as much as possible. Programmers are responsible not only for the code they write but for every line in the application, including third‑party code, meaning they must also own bugs or security vulnerabilities that appear.

Would you use code you don’t understand? That doesn’t mean I never use others’ code—there are many excellent programmers—but you must understand any code you incorporate because every line matters. When coding, never forget to think, “Writing the least code should be accompanied by thoughtful consideration, so you avoid unnecessary trouble.”

Write Simple, Useful, Readable Code

Write code that is easy to understand; code less, think more, and you’ll complete features faster, boosting productivity.

Of course, I also want code to be verifiable. I have always believed that simple, modular code is easier to test.

Another essential characteristic of code is readability. Code should be concise and semantically clear. When writing, I consider how long it will take another programmer to understand it at first glance, or whether I will still understand it months later. As the well‑known programming proverb says: “Any fool can write code that a machine can understand; only good programmers can write code that humans can understand.” The less time you spend discovering how something works, the more you can accomplish.

However, few people stick to these rules. Sometimes I’m lazy or time‑pressed and write complex, hard‑to‑understand code or use unchecked libraries to achieve a function. Writing simple, clear code in the short term is difficult—it requires discipline and continuous technical evaluation, especially for time‑sensitive projects.

Nevertheless, when you invest time and effort, you’ll find that the effort pays off—not only for yourself but also for other team members.

Disclaimer: The content of this account is sourced from the Internet and other public channels; we remain neutral on the viewpoints expressed and provide them for reference and discussion only. Copyright of reproduced articles belongs to the original authors or institutions; please contact us for removal if infringement occurs.