A Free Programming Experiment for Thirty People: Results and Review

3 June 2017 Others (Translated by ChatGPT)

Background

Three months ago, I posted on PTT ([Sharing] Free Programming Tutorial (Front-end)) saying that I was willing to provide a series of free front-end programming tutorials. Anyone with a web foundation could sign up, and I welcomed everyone to write to me with a few answers to some questions. Finally, I would select 5-10 people for training.

The questions are as follows:

Self-introduction (such as background, how to learn programming, programming ability)
How long have you been learning programming, and why did you want to learn programming in the first place?
Are you currently working? If so, what is your job content?
The most difficult programming problem you have encountered recently
What kind of assistance do you hope I can provide?

The article was posted on March 2nd, and the deadline for registration was March 11th. I would send an email to the people I selected before March 15th.

First, let’s talk about why I wanted to offer this free programming tutorial! Actually, it was also mentioned in the original article, but I’ll explain it more clearly.

Before this, I had actually organized a similar event before, although it was also a programming tutorial, the people who came to me were all inexperienced beginners. I could only give them some general advice, such as introducing them to front-end and back-end, introducing several programming languages, and recommending suitable ones for beginners.

The last tutorial probably involved about ten people, but almost none of them “really wrote code,” and they only stayed at the stage of “wanting to learn programming but haven’t started yet.”

But that’s not what I want. What I want is to actually let the students write code and verify whether “my method” is really effective. As for what this method is, we’ll talk about it later. Therefore, this tutorial limited students to “having a front-end programming foundation,” which means I can teach them more in-depth things.

Exploding Inbox

The response on PTT after the article was posted was okay, with about 30 likes, which is quite a lot for a smaller board like the software job board. However, the number of people who signed up far exceeded my expectations.

By the deadline for registration, I received a total of 42 emails.

This is four to eight times the number of people I originally wanted to recruit (I only wanted to recruit 5-10 people), and many of them wrote very well. In fact, from these emails, you can see the personality of each person. Some people are lazy and just write three or four lines and send them over; some people are very serious, even providing resumes or carefully formatting them.

So what should I do? How do I screen the people I want from them?

Forget it, it’s too troublesome, just take them all!

Yes, that’s really what I thought. So after rejecting the four people who were really unsuitable, I finally recruited 38 people.

Below is the acceptance letter I sent to everyone:

Hi,

Receiving this email means you have been accepted.

But actually, I feel a bit strange saying “accepted,” because it’s not a formal event. The purpose of organizing this programming tutorial is purely because I hope that when I first came into contact with front-end and back-end web programming four or five years ago, someone could have taken me under their wing and given me some advice.

But that person never appeared, so after four or five years, I decided to jump down and be that person myself.

I have received a lot of help from my predecessors on the road of programming, and Google and Stackoverflow have also been very helpful to me. It’s because I have received help from so many people that I have always felt that “giving back” is something I must do.

The preface is almost over. This email is a unified reply to everyone, and I will introduce the direction of this event later.

The registration for this event was more active than I expected, with about 40 friends interested in this event. Although the article originally said that only 5-10 people would be accepted, after careful consideration, I found that everyone’s needs are different, and basically, the needs can be divided into two categories.

The first category is to practice front-end basics, hoping that I can give assignments or some guidance; the second category already has front-end programming ability and hopes to talk to me about work-related matters, such as how I came to work in Singapore, what level I need to achieve, and so on.

For these two types of needs, there will be two ways to proceed.

For the first category, there will be an assignment every week or every two weeks (or it may be changed to all assignments being prepared in advance, and everyone can have their own progress), and then at a fixed time, I will explain the knowledge points that you should be able to learn from this assignment, plus some of my own supplements.

For the second category, there is basically no problem with ability, and I have nothing to teach, so the main thing is to make an appointment with you and chat. It’s like attending a technical sharing meeting and chatting with the person next to you. There is no need to have too much pressure, and chatting may also reveal that your technical ability is stronger than mine.

Everyone has already sent me a simple self-introduction email, and now it’s my turn to introduce myself briefly.

My name is Hu Li, and I am currently a front-end engineer in Singapore, having been here for about five months.

I started learning programming when I was in junior high school, and mostly self-taught along the way. I wrote VB when I was young, then moved on to C/C++ for programming competitions, and later became interested in mobile app development with Java and Android. In college, I finally embarked on the path of web development, learning PHP and front-end web development. During my internship, I realized that I was more interested in front-end development, so I started to focus more on front-end and Node.js back-end development.

For more detailed information, you can refer to my LinkedIn: https://www.linkedin.com/in/hulii. You don’t have to be too formal when communicating with me, just call me huli or Huli Li. If it’s too formal, I’ll feel a little strange. XD

Regarding this tutorial, there are a few things I want to explain:

You can “quit at any time” because you may have overestimated my abilities and found that I’m not as strong as you thought during the actual tutorial. If you feel that I can’t help you, you can tell me directly or come up with any excuse. Don’t worry, there’s no pressure.
Please give me feedback. Whether I teach well or poorly, please give me some feedback. I will create an anonymous Google form for everyone to fill out, and I would appreciate it if you could give me feedback after the tutorial.
Learning still depends on yourself. Although I may give you some direction and advice, ultimately it’s up to you to practice and improve.

There are two things I need your help with to get started:

Join Slack (if you haven’t used it before, you can Google a tutorial).
Fill out the basic information form on Google (this is super important, please fill it out).

Slack will be our main communication channel, so please turn on Slack notifications. If I don’t reply to you on Slack, you can try contacting me again or send me an email.

We have about three weeks until April, and during this time, I will try to chat with “everyone” as much as possible. If you are the second type, just want to chat with me, then our fate (?) will probably end after the chat, because I won’t have much else to offer. XD

If you are the first type and need tutoring, I will briefly chat with you based on your previous self-introduction, and we will also discuss your expectations for this tutorial and what specific help you need. The tutorial is expected to start in early April, and I will update everyone on the latest situation.

Below is the preliminary outline for the first type of tutorial. If you think you already know all of these, then there’s no need to listen to my tutorial, because that’s all I can teach. XD

I am more proficient in JS than CSS, so friends who expect to learn some amazing CSS skills may be disappointed. I’m not very good at layout design and RWD, so I can’t provide much help in that area.

Practice implementing Twitch game screen layout (knowledge points: basic HTML, CSS)
Make the screen more dynamic (knowledge points: CSS transition)
Use Less, Sass, or Stylus (knowledge points: using CSS preprocessors)
Connect to Twitch API to retrieve data (knowledge points: understanding API documentation, API integration, Ajax, CORS)
Optimization: add infinite scroll and placeholder (knowledge points: infinite scroll, placeholder)
Use vanilla JS (knowledge points: vanilla JS)
Add multilingual support (knowledge points: i18n, library)
Inline all CSS and JS into HTML (knowledge points: gulp, why we need gulp)
Why do we need Webpack? (knowledge points: Webpack)
Use React.js (knowledge points: React.js)
(Additional tutorials on Redux, React-router, etc. may be added depending on the situation, as the tutorial content may change and I haven’t planned that far ahead.)

To summarize the current situation:

Join Slack and fill out the Google form.
I will chat with everyone, but you can choose whether or not to participate in my programming course after the chat (meaning you can choose the first type).
Wait for me to contact you and chat online.
Wait for the notification to start the course.

Thank you for your cooperation,
Huli

In the first two weeks, I chatted one-on-one with about 20 classmates, about 70% using voice and 30% using text, to discuss each other’s situation, when we started learning programming, our level of proficiency, and our thoughts on the course outline.

The most important thing about this course is the course outline. Let’s take a closer look!

The meaning behind the course outline

The reason for creating this course outline is mainly due to two factors. First, the things taught in the course are all related to my recent work, so I will be more familiar with teaching them since I’m already working with these things.

The second reason is that when I encountered these things in my work, I didn’t know anything about them. I didn’t know what Webpack was doing, what Gulp was doing, or how to implement infinite scroll. But after spending some time understanding them, I realized why I found them so difficult at first.

Because I didn’t know where to use it, I didn’t know what it was for, or in other words, I didn’t know “why I should use it.” I searched a lot of tutorials on the internet, and each one was telling me “how to use it,” but there was little information that could tell me: “why to use it” and “what will happen if I don’t use it.”

After accumulating several teaching experiences, I found a teaching method that I think is more effective, and the principle is:

You have to experience pain before you can gain something.

What does this mean?

For a while, I liked to read some architecture articles from big companies, which wrote about how they adjusted their machine architecture to be suitable for scaling, and how they encountered problems and solved bugs caused by large amounts of data.

At first, I felt that I gained a lot: “Wow, these things feel so powerful, I learned a lot.” But after a while, I realized that I didn’t learn anything. I forgot all those things after a week, as if I had never read the article.

Later, I forgot where I saw an article, but I remembered a passage that conveyed a message that was particularly profound (if someone has also read the same article, please leave a comment below, I would be very grateful). The article wrote that those were the “essences” that the experts of big companies had painfully experienced and tempered. How could you expect to have their ten years of experience after watching for ten minutes?

“Pain” is a very important thing.

Instead of teaching them how to write SCSS directly, it is better to let them write CSS first, and then keep asking them to change colors and change things. At this time, they can only keep searching and replacing with text editors, repeating this cycle. When you confirm that they are really in pain, then teach them SCSS.

At this time, they will have a feeling of “rebirth”, “Damn! I didn’t know there was such a thing. I don’t have to change it so hard anymore. I can use variables.” I think this way of learning will be much more effective than teaching directly.

Before teaching them the same thing, I will definitely find a way to let them know: “Why do I need this?” I think that when this question is understood and agreed upon, they will be more motivated to learn, and they will also know what they are learning and what they can do after learning.

There is another thing, which is that instead of doing different small assignments, it is better to do a “gradually strengthening assignment”. In this way, when doing assignments, students can constantly see their progress, constantly see the growth of the project, and finally make a complete project, instead of a bunch of fragmented, broken small projects.

Therefore, I planned these course outlines based on these concepts, and made some adjustments later:

Basic HTML/CSS practice: using Twitch as an example
Make the screen more dynamic: magical CSS transition
Essential tool for writing CSS: CSS preprocessor
From fake data to real data: Ajax and API integration
Make the webpage more complete: add placeholder and infinite scroll
Back to basics: vanilla js
Towards internationalization: i18n
When we are bundled together: Webpack
Extreme saving of requests: one for all, all for one
Change your bad habits: ESLint and standard

The tenth week was originally React.js, but I later removed it for two reasons. The first is that I think React is not suitable here, it is not yet the time to teach, and it is not related to the previous ones. The second is that I found that many people’s coding styles were not good when I changed the assignment, so I put this one in the tenth week, and the uglier the assignments in the previous nine weeks, the more time they will spend on fixing them, so that they can “suffer” a bit.

I must admit that this plan did not use the teaching principle of “pain before gain” very well, which is an area where I can do better and there is still a lot of room for improvement.

I think I have mastered the process of gradually optimizing from a small assignment. At the beginning, let them carve a static page, then change the CSS to SCSS, and then change the fake data to real data and integrate the API. Then add placeholder images and infinite scrolling to make the channel continuously scroll and load.

The purpose of the sixth week’s assignment is to abandon jQuery, save file size, and let them know that they can still write JavaScript without relying on jQuery. In the seventh week, change Chinese to bilingual, supporting two languages. In the eighth week, use webpack to implement modularization. In the ninth week, use gulp to let them know that many things can be automated. Finally, in the last week, correct their own coding style.

In this way, the process of gradually optimizing, they can directly follow up on the next assignment, and make a project more and more complete.

Problem Solving

As I have repeatedly emphasized, writing code is not the focus, the focus is on “problem solving,” and almost all the focus is on this.

Problem solving can be divided into the following points for thinking:

What problem do you want to solve?
What method do you use to solve it?
What are the advantages and disadvantages of this method?

I like a term called trade-off, which can be translated into Chinese as: trade-off, choice.

Especially in the field of programming, what you do is actually a trade-off. The most common example is trading time for space or space for time. There is no such good thing that you can have both space and time. Well, actually there is, but that’s what money is for.

In the instructions for each week’s assignment, I will mention what problems we encountered this week. What about the solution? The solution is of course what we will teach everyone this week. Let’s take a closer look at each week’s course, and ask and answer the above three questions (what problem to solve, how to solve it, advantages and disadvantages):

Basic HTML/CSS Practice: Using Twitch as an Example

Problem to solve: I want a page where I can watch Twitch channels.
Solution: Write my own webpage.
Pros: Customizable. Cons: Time-consuming.

Making the Page More Dynamic: The Magic of CSS Transition

Problem to solve: I want to add effects to make the page more refined.
Solution: Use the CSS transition property to create a gradient effect.
Pros: Has a gradient effect. Cons: May have performance issues.

Essential Tool for Writing CSS: CSS Preprocessor

Problem to solve: Writing CSS is too complicated. I want to use variables like in programming.
Solution: Use a CSS preprocessor.
Pros: Easy to maintain. Cons: Requires an extra step to compile.

From Fake Data to Real Data: Ajax and API Integration

Problem to solve: Current data is pre-written. I want real data.
Solution: Integrate with Twitch API.
Pros: Data becomes real. Cons: Slower loading speed.

Making the Webpage More Complete: Adding Placeholder and Infinite Scroll

Problem to solve: Loading 100 channels at once is too slow and causes layout issues.
Solution: Use the method of loading new channels only when scrolling to the bottom, and add placeholders to prevent layout issues.
Pros: Improves user experience and faster initial loading. Cons: Increases the number of requests.

Back to Basics: Vanilla JS

Problem to solve: jQuery file size is too large. I want to reduce request size.
Solution: Remove jQuery and do not rely on any library.
Pros: Reduces file size. Cons: Increases code complexity and requires handling cross-browser issues.

Going International: i18n

Problem to solve: I want to add a new language.
Solution: Put the language in a language file and pass it through the global variable “window”.
Pros: Can have multiple languages. Cons: Pollutes global variables.

When We Are Together: Webpack

Problem to solve: Solving the global variable pollution in the previous homework and wanting to use the “require” syntax.
Solution: Import Webpack.
Pros: Modular development. Cons: Requires an extra layer of packaging and increases file size.

The Ultimate Way to Save Requests: One for All, All for One

Problem to solve: Too many requests.
Solution: Inline all JavaScript and CSS into HTML.
Pros: Reduces requests. Cons: Slower page loading time.

Breaking Bad Habits: ESLint and Standard

Problem to solve: Bad coding habits that are not conducive to team development.
Solution: Introduce syntax checking tools.
Pros: Uniform code specifications. Cons: …seems to have no disadvantages.

Compared to an introduction like “Webpack is a packaging tool,” letting beginners know what Webpack is for, what problems it solves, and how to solve them is much more useful. Once again, emphasizing why is important, knowing why is also important. Knowing the reasons behind it, you can decide whether or not to use this solution.

When you use something, there must be a “good reason” behind it.

A: Let’s switch to TypeScript.
B: Why?
A: Because it’s trendy!

If the reason “trendy” is not convincing enough and A cannot come up with better reasons, then there is no need to switch to TypeScript.

There was a very popular article before called “What is it like to learn JavaScript in 2016?” I think there is a regrettable point, that is, some people’s feedback after reading it is only: “Ah, yeah! Front-end development is too complicated now!”

But I think what you should think about after reading this article is: “Do I really need to use those tools? Are the problems those tools want to solve really the problems I encounter?” This is the focus of this article.

For example, there is a paragraph that says:

Don’t use jQuery! Who still uses jQuery now? It’s 2016, you should definitely use React.

This reason is as weak as the one above, one word: trendy!

Of course, it may also mean something else, such as expressing that React is a recent trend, jQuery may be gradually phased out and no longer maintained, and there will be maintenance issues in the future. At this time, you can consider: Is this situation possible? If it really happens, what will be the impact? Which one has less damage, the complexity brought by using React or the maintainability of jQuery?

In short, the focus should be on “what problem you want to solve, which tools are best suited to assist,” rather than blindly thinking that front-end development is so complicated and there are so many things to learn.

Yes, there are a lot of things, but you may not need most of them!

If you insist on using React + Redux + Rx + Webpack for a one-page marketing landing page, then I am speechless.

Course Progress

The course progresses as follows: as mentioned above, there are a total of ten assignments, one per week. You must “complete the assignment first,” but it’s okay if you can’t. Every Tuesday, I will live stream and explain the previous week’s assignment and demonstrate how I would do it.

This is because “self-learning” is an important skill in any field. I want students to have a concept of what I am teaching, and even after completing the assignment, I will explain it again. I think only in this way can students become more familiar with what I am teaching.

This echoes what I mentioned earlier, “you have to suffer first before you can gain.” Many students have responded that they found some things difficult during their pre-class preparation, and they couldn’t understand them no matter how they looked at them. But after watching my live teaching, they had a feeling of enlightenment: “Wow! It’s so simple.”

What if it were the other way around? If I taught first, they would only think, “Oh, that’s how you write it,” and then just copy my solution when doing the assignment. What did they learn? They learned to imitate my code, and then forget about it completely after a week. Why? Because they didn’t suffer, so they didn’t think.

Again, I emphasize that you must think when you write code! Think! Think! Only things that have been deeply thought about are truly yours, and you will remember them.

Course Effectiveness

After discussing the design concept of the course outline and the core ideas I want to convey in this course, let’s talk about the effectiveness of this course.

As mentioned earlier, 38 people received acceptance letters, but only 36 people filled out their basic information, and two people disappeared.

Among these 36 people, only 26 completed the first assignment, meaning that 10 people didn’t even do the assignment, and 28% of the people disappeared. Therefore, I will adjust the number of people participating in this course to 26 in the future data.

Only 8 out of 10 people were able to complete the assignments, which is about 30%. The graph below shows the number of people who completed each assignment.

It can be seen that the most significant drop was from hw2 to hw3, where the essential tool for writing CSS, CSS preprocessors, was introduced, and many people dropped out for some reason.

After the course, the feedback questionnaire revealed that the reasons for not completing the assignments were: inability to allocate time, high difficulty, laziness, other things to do, and lack of interest.

One of the questions in the questionnaire was: “Which assignment do you think was the most challenging?” Most people answered hw5 (Making the webpage more complete: adding placeholders and infinite scrolling) and hw6 (Back to basics: vanilla js) because they had never written anything similar before.

If there is a need for improvement in the future, hw5 can be divided into several units instead of completing these two items at once, and the same method can be applied to hw6. This way, the difficulty will not jump so much for students, and it will gradually become more challenging.

Student Feedback

After the course, everyone was asked to fill out a feedback form, and fortunately, everyone had a lot to say. I originally wanted to post the entire original text, but it would be too long and hinder reading, so I only selected some parts and deleted some repetitive content.

What are the advantages of the teacher’s explanation or assignment modification?

(The following are feedback original texts, and I only made some formatting changes.)

The use of Youtube live streaming for lectures can allow students to flexibly arrange their time to listen to the lectures. The content of the lectures has a significant advantage that Huli uses very straightforward examples and concepts to introduce them, making it easy for students to understand. After spending one or two days on an assignment, I sometimes feel that “Wow, it’s not as difficult as I thought” after listening to the lecture. The arrangement of each lecture is organized and easy to take notes. Regarding the modification of assignments, Huli will carefully look at the troubleshooting I have listed and provide useful suggestions. When doing well, he will also give full encouragement, which is excellent guidance for beginners.
When explaining, Huli talked about many things that I was prepared to ask, and the way of explanation is easy to understand. Because the reasons are explained, it is easy to accept. Just like arranging the course, each chapter is progressive, so it is easy to understand and accept why to use these things and the usefulness of these things.
Although I only submitted the first few assignments, I can see that he was attentive in reviewing them. Regarding the lectures, I think they are excellent and there are no awkward moments. The lectures are also very clear!
The complete program live coding process is broadcasted, including executing commands using the terminal, which makes me, a terminal novice, no longer afraid to use the terminal and become more familiar with it. The process of explaining the program makes people feel that writing programs can be so clear and simple. The explanation process seems easy but has a structure. When classmates don’t understand, he will explain from many different angles, such as real-life examples or various related links, to deepen students’ understanding and impression of the program!

What are the shortcomings of the teacher when explaining or grading assignments?

There are not many shortcomings, but if there is room for improvement, the IDE color theme could have stronger contrast between the font and background to enhance the user experience. However, overall it is not a big issue.
If possible, the teacher could prepare a text file with the key points to be discussed that day and use them as headings.
When the course content, such as webpack and gulp, is completely unfamiliar to me and I have not touched node.js, I feel that the explanation speed is too fast. Especially during live classes, when the teacher says that the webpack and gulp assignments are easy, it can be frustrating for beginners like me. I hope to develop the ability to quickly learn new things.
This is not a shortcoming, just a suggestion. To save time during live classes, the teacher could prepare the websites that may be needed in advance. However, the benefit of searching directly during the live class is that we can know what keywords you used to search later.

Course Feedback

Due to the length of the feedback questionnaire, it is not suitable to post it here. Therefore, I will only post two articles that I wrote on my own blog.

Self-reflection

First, let’s talk about the shortcomings. Actually, compared to the strengths, I would like to hear more about the shortcomings. Knowing where the shortcomings are is the only way to continue to improve. However, I don’t know if it’s because the performance was too good this time or the students were too shy, but there was less feedback on the shortcomings.

As a teacher who constantly strives for improvement, even if the students don’t speak up, I should be able to detect some shortcomings myself.

1. Sometimes grading assignments is careless.

Although the students said that the teacher graded the assignments carefully, sometimes when facing a pile of more than ten assignments, many things are just quickly glanced over. After all, teachers can also be lazy… This is an area where I can improve in the future.

2. The course planning is not “painful” enough.

As I mentioned earlier, you have to experience pain before you can understand. I think the assignments can be broken down into smaller parts to make the students feel more “pain”. For example, in the part of cultivating coding style, you can first set a rule for everyone: “Variable names can only use one English word, such as a, e, y, etc. If it is not enough, add a number to become a0, etc.” After completing the assignment, let everyone look at the program they wrote last week after two weeks. They should find that they can’t understand what they wrote.

At this point, they will know the importance of variable naming.

Now let’s talk about the strengths. I mentioned earlier that this was a “30-person teaching experiment”, and the goal of the experiment was to verify whether the teaching concepts I mentioned above (you have to experience pain, understand the purpose, and know why) can really help students learn.

From the feedback from the students, I think it can, which also confirms the direction of my future course planning.

Regarding the strengths, I will directly post some feedback from the students! From these feedbacks, you can see that they can really receive the message I want to convey.

When explaining, the teacher talked about many things that I originally prepared to ask, and the way of explanation is easy to understand because the reasons are explained, so it is easy to accept. Just like arranging the course, each chapter is gradually progressive, so it is easy to understand and accept why to use these things and the benefits of these things.
Explaining the program makes people feel that writing code can be so clear and simple. The explanation process seems easy but has a structure. When classmates don’t understand, the teacher will explain from many different angles, such as using examples from daily life or various related links to deepen classmates’ understanding and impression of the program!
I really like that the teacher lets the students write first and then publish the answers. This allows students to have the opportunity to try various possible solutions that they think of or find first. When it comes to live classes, the teacher’s approach can provide opportunities for mutual exchange and discussion, and it won’t make students go to class with an empty head. Because they have already completed the assignments, they can absorb and integrate more easily in class, and they can quickly understand which solution is suitable for which situation and can immediately see where they were stuck before because they have already been stuck.
In this programming course, I also found that thinking about writing code is not as complicated as I imagined. Maybe it’s because the teacher’s outline is clear and clean, and the explanation is based on “requirements”. Some beginners, like me, often spend a lot of time in the development process, always writing code that they don’t understand what they are doing or why they are writing it. Thinking about writing code is the precious harvest I learned in this programming course.

Conclusion

First of all, I would like to thank my students for accompanying me through ten weeks of courses and being willing to give feedback after the course.

I have always felt that programming education should have better methods to help students learn faster and understand faster. This course has verified that my current direction is correct, and I will continue to move in this direction in the future.

If you are interested in this course, you can go to the Github page to view the course content, or go to Youtube to watch the videos directly.

You can also register for the course on my recently launched online course platform: Lidemy Lithium Academy, which is completely free! I have uploaded the homework content and videos there. (However, since the course has ended, no one will help you with your homework.)

I believe that the value of this course lies in the teaching mode of “doing homework first and then explaining”. Therefore, I don’t intend to profit from releasing the teaching videos like the one above. All resources are completely free and open for everyone to use, because the core value of this course has been lost, so there is no need to charge for it.

I hope that my course can be open and transparent in all aspects. Therefore, if you are interested in the feedback form submitted by students after the course, here is a complete backup of the student feedback (with some personal information deleted).

Finally, thank you for taking the time to read this lengthy article. If you are interested in my future teaching experiments or courses, please follow the Lidemy Lithium Academy fan page, where all future updates will be announced.

Thank you.

#Story