About This Article

To learn JavaScript, I had GPT-4 write me a concise introductory tutorial: JavaScript: From Novice to Nonsense - https://github.com/Kit086/javascript-from-novice-to-nonsense.

But why am I learning JavaScript? There are many reasons. I’ve repurposed the preface I wrote for this tutorial as the content of this blog post:

Preface - Critical Thinking and Flexible Application: Reflecting on Design Patterns in Software Development

At first, the trending popularity of programming languages and tools left me, a novice developer, brimming with excitement. I was once firmly convinced that backend development was the domain of Java, C# & .NET, and Golang, while frontend development was inseparable from React, Angular, and Vue. Wasn't development all about high performance, high concurrency, and elegant patterns? But as time went on, I realized that back then, I was like a foolish knight wielding a sword, believing I could solve every problem, only to repeatedly stumble over my own feet and end up in a complete mess.

file

This screenshot is from Twitter, showing a tweet posted by a user named Fredy R. Guibert, along with a humorous reply from another user, Manzur Alahi.

Fredy R. Guibert's tweet listed various software design patterns and methodologies, including:

  • Clean Architecture
  • Domain Driven Design
  • Test Driven Design
  • Outbox Pattern
  • Repository Pattern
  • CQRS Pattern
  • Mediator Pattern
  • Result Pattern

Manzur Alahi replied: "list of things to avoid?"

Behind this joke lies a deep reflection on the various design patterns and methodologies in current software development practices. It’s almost like saying: Hey, stop wasting time on these complex terms, buddy, and get back to basics!

The design patterns and methodologies listed by the author are very popular in software development and are often seen as the cure-all for complex problems. However, these patterns and methodologies can also lead to the following issues:

  • Over-complication: Have you ever gotten lost in your code, even questioning your existence? Applying too many design patterns can increase code complexity, making it difficult to maintain and understand, with maintenance feeling like defusing a bomb.
  • Blind application: Sometimes we act as if we are using patterns for the sake of patterns, like competing in a "Patterns Olympics," rather than choosing the right solution based on actual needs.
  • Learning curve: Mastering these patterns and methodologies requires a certain amount of time. For novice developers, it feels like climbing a mountain with no end.
  • Losing sight of the goal: Focusing on adhering to specific design patterns may cause you to forget the actual needs of the software and its ultimate objectives, only to find yourself solving problems that do not exist in the first place—like a chef who obsesses over plating presentation but forgets about the taste.

Manzur Alahi’s reply, “list of things to avoid?” (Are these all things to avoid?), though simple, reveals a truth: design patterns and methodologies are neutral tools in themselves. Their value lies in whether they effectively solve real-world problems. Design patterns and methodologies are not a panacea for software development. They should serve as tools for problem-solving, not as dogmas that must be followed. However, in practice, we often encounter developers whose “experience” is merely the accumulation of years on the job, without any genuine improvement in skills or thinking. They are like drivers who own a luxury sports car but don’t know how to shift gears, or drivers who only look at the map and not the road, ultimately getting lost in the complex routes they themselves have created. They believe they are seasoned veterans, but in reality, they are merely using confidence built on tenure to mask their laziness.

  1. Fixed Mindsets and Blind Confidence These developers’ fixed mindsets make it difficult for them to adapt to a rapidly changing technological environment. They may rely too heavily on their habitual practices, unwilling to accept new ideas and methods, much like an old circus monkey who considers himself the “elder ape” of the troupe and refuses to learn new tricks—the outcome is predictable. Moreover, blind confidence makes it hard for them to learn from mistakes and improve. They may believe they have already mastered all the necessary knowledge, neglecting the importance of continuous learning and self-improvement, as if they have already become “sages” in the tech world.

  2. Lack of Reflection and Resistance to New Technologies Under this fixed mindset, developers often overlook the value of reflection and feedback. When a project fails or encounters issues, they are more likely to blame external factors rather than examine their own shortcomings. Resistance to new technologies also causes them to miss numerous opportunities to enhance their skills and efficiency. When faced with new technologies and methods, they often exhibit suspicion and resistance, believing that existing practices are already good enough—as if they firmly believe the Earth is flat. They harbor a natural hostility toward new technologies, as if new tech is an enemy lurking in the shadows, ready to destroy their outdated arsenal at any moment.

  3. Cultivating Critical Thinking and Flexible Application The key to solving these problems lies in fostering an open and critical mindset, encouraging continuous learning and improvement. Design patterns and methodologies should be used as tools to help us solve problems, not as shackles or mandatory rules. Understanding their principles and applicable scenarios, and applying them flexibly according to specific circumstances, is the only way to truly improve software quality. After all, the tools in a toolbox are meant to solve problems, not to show off.

An open mindset and critical thinking are the foundation of a developer's growth. We must continuously challenge the boundaries of our own cognition, embrace new ideas and methods, and validate and refine our approaches through practice. Only in this way can we truly grow into experienced, insightful developers rather than dogmatists who merely recite the "Design Patterns Bible."

Returning to the conversation on Twitter, Manzur Alahi's response reminds us that design patterns and methodologies are not panaceas. We need to maintain critical thinking and flexibility when applying these patterns, avoiding blind reliance and over-complication. Through continuous learning and reflection, we can continually enhance our skills and mindset, becoming developers who truly possess programming thinking.

In this rapidly evolving technological landscape, only by constantly learning and adapting can we firmly establish ourselves and meet future challenges. Design patterns and methodologies are our tools, not our shackles. Let us apply these tools with an open and critical attitude, creating more efficient and high-quality software.

Back to the main topic. My perspective has shifted somewhat since I first entered the industry. I believe we should not be constrained by narrow-mindedness. We should focus on the essence of the problem and choose the right tools and methods based on actual needs, rather than blindly chasing so-called "best practices." For instance, when refactoring a high-concurrency legacy system, we might choose technologies like Java, C# & .NET, Golang, or Rust. However, when rapidly developing a small-scale application, JavaScript—particularly with frameworks like Next.js and SvelteKit—is often the ideal choice. This does not mean that Java, C# & .NET, or Golang are unsuitable for rapid development, nor does it mean that Python or JavaScript are ill-suited for high concurrency. Rather, we should select the most appropriate tools and methods based on actual requirements and the team's technical proficiency.

Therefore, I believe that JavaScript is a solid choice for both frontend and backend development. JavaScript is a flexible and powerful language that can be used to develop various types of applications, including web pages, mobile apps, and server-side applications. It offers rich built-in features and libraries, enabling developers to quickly build complex applications and interactive interfaces. Furthermore, JavaScript's ecosystem is vast, with many excellent frameworks and tools available. Thus, I believe learning JavaScript is highly valuable for software engineers, which is precisely why this book came to be.

Below is an introduction to this concise tutorial:

About this Tutorial

Welcome to JavaScript: From Beginner to Off the Rails—a concise tutorial designed specifically for software engineers who have spent years rolling around in other programming languages. Yes, you heard that right. The goal of this book is to help you navigate the ocean of JavaScript not as a drowning child, but with the confidence to paddle your little boat—and occasionally even pull off a stylish 360-degree spin.

In this book, we will comprehensively explore every aspect of JavaScript. You will learn about variables, operators, control flow, objects, arrays, functions, modules, and that love-hate relationship with asynchronous programming. Each section presents tutorial content and practical examples concisely, aiming to ensure that understanding JavaScript doesn't lead to premature hair loss.

The term "Off the Rails" in the title is a somewhat self-deprecating joke, hinting at those moments during your learning journey that are both maddening and amusing. Yes, we all know that coding can sometimes feel like navigating a maze, especially when you realize you've ended up back where you started. This lighthearted banter is intended to help you keep a smile on your face amidst the confusion, while reminding you that even the smartest programmers can lose their minds sometimes.

Although my main profession is .NET development, I have always firmly believed that Python and JavaScript will be the dominant languages of the future. To be honest, I have never systematically studied JavaScript. So one evening, on a whim, I opened freeCodeCamp, ready to find a video to self-study JavaScript. That's when I discovered these two tutorials:

Although these videos only total a few hours in length, my "get-it-done-quick" instinct made me unwilling to spend even that amount of time. Moreover, I knew all too well that I would constantly rewind and rewatch the obscure parts, resulting in a truly poor learning experience. Then, a lightbulb moment struck: why not convert these tutorials into text format? So, I sent the titles of these tutorials to GPT-4, and the result is the book you are holding in your hands right now. You might notice some very obvious traces of GPT's introductory remarks and summaries in this book, such as 希望这个教程能够帮助你的学员快速掌握 JavaScript 的基本和高级特性。如果需要进一步深入某个主题或有其他章节需要制作，请告诉我！, simply because I was too lazy to delete them.

Despite knowing nothing about JavaScript, I hope this book helps you quickly grasp the relevant knowledge and improve your programming skills. However, since I cannot guarantee the accuracy of the content, please make sure to file an issue if you find any errors—after all, fixing bugs together is the daily routine of programmers, isn't it?