Computer Science in High Schools


This year, I got an intern with a resume that did not mention my high school's CS project with a single word. Therefore, at this point, either success or failure in my high school CS career does not matter at all, so I can honestly reflect on it. I reviewed again all my computer science related records and writings to ensure the content in this article is as accurate as possible. I hope it still helps.

1. The Story

I came into my high school with a declared intention to major in computer science in college. Ironically, my computer science related activities only had a good start at the second semester in tenth grade. Before that, I was in a club called CCC that mainly produced some arcade games and computer animations that we only internally share. The club was probably dismantled when I was in the twelfth grade. I was also briefly in the student union's publicity department. I came in with a glorious plan to improve many of their workflows in a silicon valley way, but my advice was praised and ignored. Luckily, I wasn't assigned any time-consuming task in the period, so I didn't waste too much time. But there was one exception: they asked me to improve the official website for their charity event. I refreshed it with flat and responsive design with my best knowledge on CSS3, only to found that they didn't use the website at all. The incident prompted me to resign from the student union (although it's not the only reason). After all, if they didn't care about tech, which I knew a lot, why should I care about them?

The real reason was: I was invited to join Computerization, a computer programming club that I believed to have potential. This club tried to change the way we receive homework by creating an online platform to post homework. The existing members did not have a strong CS background, so they just used the Moodle software, hacked some configuration, and called it a day. Eventually, they ran out of the feature provided by the open source solution and they cannot code their own. They reached out to me when we were both on a trip to participate in Standard Math Tournament. I agreed, and the story formally began.

During the first meeting, they were still debating how to try harder to hack on the existing Moodle system. Already had 3 years of web-development experience by the time, I suggested creating a new one from scratch because I could do it. I kept the promise. I created a prototype in 4 weeks and it had more potential than the Moodle system that none of us truly understood. Initially, the codename of the project was Missile because I liked military technology. They probably knew SAM stands for surface-to-air missile, so they named the product SAM, System of Assignment Management. The initial product was almost unusable: uploading files did not quite work; the UI became trash in some edge cases; many convenient operations were not implemented, etc. We spent another few weeks to fix these urgent problems before we started a small beta release. When the feature set seemed to surpass the original Moodle system, we released it publicly and started to promote it.

Starting from the mid-semester towards the end, we were in a fast development and release cycle. Usually the problems raised at the weekly meeting would be fixed by me at midnight. According to popular demands from students and teachers, we added some time management features and eventually implemented the homework editing feature instead of relying on deletion and creation. The usage was rising: the system quickly covered many math and physics classes, because their teachers were usually more fond of technology. The future seemed so promising that I even considered the possibility to make the system more flexible so it can be promoted to other schools.

But there were frictions. The first friction came as a feature request. A teacher asked us to implement a feature to check whether students had seen the homework. This would imply tracking the scrollbar in our implementation. It seemed too troublesome to me because it sounds like telescreen, so I directly rejected the request. Since I was the only one who knew how to code in the club, there was no effective objection.

Besides that incident, we did handle some reasonable requests. Some teacher told us students added themselves to other physics classes to steal the already provided solution on the homework they were supposed to do independently. I quickly disable the feature on student side and made the adding student feature on teacher side and admin panel more powerful. Therefore, I would say things went smoothly in that semester in general, and we had a good start.

Now it was the junior year. The senior members retired from management of the club and I was passed the position of the club president. That was not the only implication. Junior year implied that college admission was only one year away, so I'd better produce some good statistics for this club. The most important number is, of course, usage statistics. Soon, I found that I was fighting a battle that I was so unfamiliar.

We continued to promote our product to teachers, but it seemed that 40% student coverage is a cap. The core user was still confined in math and physics classes, and other classes either did not have enough incentive or utterly had no interest in the usage of technology. We tried to improve our system's usage, so we added more features. We enabled score recording for teachers the club activity recording and promotion for students. None of them was warmly received. Managing existing members were also not easy. I tried to distribute some easy programming task to them, but they were never able to complete them with acceptable code quality. Some simply didn't run. It was the first time I realized that I was not good at dealing with these non-technical issues. On the technical side, I was able to quickly implement the material design overhaul in a weekend and improved review among current users. On the marketing and management side, it was a total mess.

Finally, failure in math modeling contest ended the semester. GPA-wise, it was better than ever. But everything else not related to school grades and pure computer science had spun out of control. It forced me to reflect. My reflection was that I was forced into this position that I didn't actually enjoy, and I wanted to step down. It was the time when I started to recall the days when I was only a regular member in nostalgia: I only needed to be responsible for and worry about implementation and bugs, and that was nice and easy. I wrote a short document indicating my willingness to step down as club president and only intended to maintain the technical leadership. I asked club members' approval and let them decide who would be the new president. However, no one wanted to. I didn't want Computerization to die so I must continue.

Before the start of the second semester in my junior, I received an email expressing the intention to join Computerization. I quickly accepted, because having more members was better than having less when the leader was lost. Nevertheless, I knew it was not because we did a good job; it was simply because we were the only computer programming club in the school. This kind of monopoly was not something I would be proud of.

At the beginning of the second semester, I became so disillusioned so I didn't develop more features on SAM. Instead, I tried to teach the existing and new members programming. It was another disaster because my teaching ability was close to zero. I would say it was at least not negative because I managed not to make people who know programming to be more confused. Near the middle of the semester, it seemed that the project and club had come to a dead end. People didn't seem to have motivations and I had lost my confidence.

Nonetheless, issues started to resolve themselves on my side. On March, my delayed SAT score finally arrived and I was finally set free from the most tedious standardized test. In the same month, various math awards started to arrive. In addition, the news that AlphaGo won mysteriously gave me the confidence to throw away the hell and got started again. I did. I found some prototype code I wrote in the winter on a feature to allow students to report their various scores and choices of colleges, and we rank them to give them a rough idea of their chances of getting in. I told the club members about the idea and many of them did like this feature and wanted to see it implemented. I quickly implemented this feature, released it on a Friday night, and the article describing the new feature circulated very fast.

Around the same time, a member brought up that a student assistant of the dean of students affairs mentioned that our club was not liked by the school's administrators. Now I would say they disliked us for good reasons. Of course, we didn't produce good statistics, and we didn't win contests to add up to school pride. More importantly, I constantly reject feature requests in a way they could not understand. I once rejected the request to merge our account system with the school's system used to store student scores. I refused because I didn't want our secure system to be infected by the school's system with a number of known unfixed security vulnerabilities. They could not understand because it seemed that I intentionally missed an opportunity to dramatically increase our system's student coverage. But I knew that there was something higher than those numbers in my mind. Now I knew it was about finding the right answer. For nerds like me, accepting an inferior solution for something else was unthinkable: it was just blatantly bad.

However, I was still angry and our members were still angry, especially because we knew that student had some known bad history of not doing things. On that night, I wrote a strongly opinionated response, proclaiming that Computerization was not a conventional club and we would not care about those comments about worldly success. Starting from that moment, I began to slowly understand what drove me forward even when everything was in a mess. It was never about producing some good numbers to be put on the Common App. It was about an ideal. It's an ideal that software engineers took for granted to build great software. It was about Google's line on its website: Google is not a conventional company; we never intend to be. It was about Facebook's motto: move fast and break things. It was about that software engineers who love to build things can build great things to make a change. Regulation and authority were never part of this story, because we place correctness of code before pleasing others.

On the club fest next week, instead of echoing the random theme the administrator happened to think of, we talked about our newly released CollegeChoice feature, about the freedom I gave to the developers, and about our belief that engineers rule. It didn't matter whether the administrator liked our style. What matters was that we found our purpose.

The final two months when I was the club president moved quite fast. We secured the cooperation with the school's college admission department based on our demo during club fest. We trained a workable machine learning model on the dataset provided by the department. I even started some plans to transform Computerization into a tech-company-like organization to provide advanced platforms and solutions. But now it was the real time to step down, as an honored battle-scarred service member.

2. Aftermath

In the first semester of my senior year, I helped the new president to recruit new members. We got over 20. It was a huge step compared to where I started. A year ago when I was doing recruitment as the club president, I had to put existing members' names on the recruited member spreadsheet to make things look less bad. Computerization did become prominent and computer science was no longer a negligible topic in the high school campus.

Given such a big influx, I became worried that we may need to become more bureaucratic to deal with so many members, a change none of us liked. However, it seemed that my worries were unnecessary because it was the exact opposite: chaos.

We tried to teach the new members programming. Again, it failed miserably. It seemed to be a repeating pattern that someone good at programming thought he could teach, and the assumption proved to be utterly wrong. On the development side, they pushed a UI refresh, but they never considered the edge case when text overflows, and it became really bad because many math and physics teachers who were still using our platform usually posted a long list of problem numbers that student needs to do. It was almost the same sequence of breakdown, although a different one in kind.

A few days before I graduated from my high school, I had a talk with the club president and asked why things went so wrong. He said it's because they didn't have enough time like I did. I didn't like the response, but it did explain a lot of things. The year when I was in charge was an exception rather than a norm. In my year, we could get things done not because I could effectively motivate and train the club members to do the job. It's just because I could always do it all alone when things got messed up. This pattern was nowhere close to the adjective sustainable, and the price was that I messed up almost all the other jobs related to club management, including training new members.

Six months later when I came back from Cornell to visit my high school again, I heard that the new leadership threw away my independent stance and just implemented whatever features the student union asked them to implement, in my opinion, like an outsourcing company. I didn't know what's happening right now, but whether they had fame or not, it was no longer the same club.

I once thought I may continue to contribute to the codebase after my graduation. I never did. Not even the README. In the summer, a year after my graduation, I was designing my own programming language. You can say it's some kind of PTSD. I completely stopped caring about usage statistics. Now I only care about the difficulty of the project. That's how first-class functions, basic type inference and generics got soundly added to my programming language even if I had never taken any formal PL class.

In this fall, I went to the career fair and practiced a lot of LeetCode algorithm problems and finally got an intern. In the winter, I was back again and was invited to the alumni sharing event hosted by my high school, and I'm in the subsection about computer science. It was not unexpected that there was a large crowd: mostly anxious parents. Most of them didn't really understand a lot about computer science. Of course, they know AI is now a buzz-word, but they probably also believe AlphaGo is going to destroy the human civilization due to its dangerous potential.

After my talk, many parents stayed to ask me tips about learning computer science. I can't really give any useful ones. My experience was so unique that it was not transferable at all. In addition, I don't really believe CS education before college had any real improvement recently, at least in the context of my high school. Feeling the same as the anxious parents, I want an answer. I want to know why life seems to be so hard for computer science students in high school.

3. Why Nerds are Unpopular

In the recent days I got ill, so I didn't have enough energy to do advance type inference in my programming language. But it gave an opportunity to reflect. I started to review many documents archived securely in my Google Drive. More importantly, I read again Paul Graham's long essay Why Nerds are Unpopular again. It was an essay that shaped my voice for my college admission essay.

"We sat at a D table, as low as you could get without looking physically different. We were not being especially candid to grade ourselves as D. It would have taken a deliberate lie to say otherwise. Everyone in the school knew exactly how popular everyone else was, including us."

Well, IQ and school grades definitely matter more than in the US, so I could give myself a C. It was the same grade I would give to assess the popularity of computer science in our high school.

It was very different from college. In Cornell, my project team received over 700 applications and we only admit less than 50. We had six to seven subteams, all with talented software engineers. In high school, the situation was like we begged others to join, and the best we can have is to get one or two qualified and a heap of completely unqualified students.

Computer science is hard because it's not just about writing programs that run without crashing, although that alone could weed out many people. One or two lectures from successful people or parents advice didn't change the fact much. However, computer science is also something that needs a critical mass to accelerate forward. In a small-sized high school, it was almost impossible.

"And that, I think, is the root of the problem. Nerds serve two masters. They want to be popular, certainly, but they want even more to be smart. And popularity is not something you can do in your spare time, not in the fiercely competitive environment of an American secondary school."

Computer science requires IQ, but not necessarily popularity. If you examine things more closely, you may find that success in computer science was almost orthogonal to success in college admission. You can probably get away if you write in your college admission essay that you want to use natural language processing to build better C compilers, but it's definitely not OK to write that you build an optimizing OCaml compiler that nobody uses and you don't care. College admission is a notorious example of a contest without well-defined criteria, and it somewhat already degenerates into a popularity contest. To make it worse, it heavily guides how high school works.

For a future computer science under this system, life was quite hard. You should first write good and correct programs to make yourselves happy, even if the admission officers don't understand and care nothing about your GitHub repos. In addition, the program you write would better be something that the admission officer can understand, so it almost immediately rules out some options like compilers, assembly optimizations, etc. Furthermore, you want to demonstrate your leadership and impact, so other students can use your product. In my summary, they probably expect some businessman who happens to know how to write a few lines of code, because that's probably what they could understand.

"The stated purpose of schools is to educate the kids. But there is no external pressure to do this well."

If you are unlucky, you may encounter administrators who want to replace a free, silicon-valley-like environment with a highly regulated one. They have their own agenda, and their understanding of what's needed for computer science ranges from uninformed to ignorant. The stated purpose is always to ensure clubs grow in a healthy and sustainable way, but there were no external forces to push them to ensure that all clubs are treated equally. Under the leadership of some stubborn nerds like me, it would be resisted to ensure that computer science clubs are actually doing things in a computer science and silicon valley way. In other situations, people give up and just get assimilated to the point where the club is no longer doing anything useful for the future CS career, and the activities degenerate into college admission preparation.

There are more.

4. Final Comments

My story is mostly about failure. You may think that at least the development is not a failure. No. Judging from my current standard, I would say the code I wrote at that time was complete trash, and it's one of many reasons why I never touched the codebase after graduation.

I said a lot of harsh things in this post, but really I want to send an optimistic message. The failure is related to code quality, but it's a thing you can truly understand after you go to the college and industry, so the high school experience actually matters nothing. The failure is related to principles that got dropped due to the harsh reality, but that only happened after my graduation when things are completely out of my control. The biggest failure was probably about the popularity of the platform that I tried so hard to obtain but never succeeded. I agree, but I no longer care and it no longer matters.

If you asked me at that time that whether I wanted my system to be popular, I would resolutely say YES. Nonetheless, I actually didn't, at least not enough. There was something else I wanted more: live as a proud software engineer. It's not just building a secure and correct system that I can be proud of. It's about engineering pride, which means that you will still write nice code even if nobody cares. It's about belief, the belief that we can move fast, break things, but eventually get things done in a great way. More importantly, sometimes it's just about computer science, because computer scientists love to build things, more than anything else.

You need failure to have a profound understanding of a lot of things in computer science. For example, you probably would hate those accepted verbose design patterns, before you messed up a project where you do whatever you want and the complexity explodes. Therefore, I'm quite happy now that this kind of failure happens in my high school CS career. It told me what I like and what I dislike. It prompted me to make decisions that further the failure but I would never regret. All the obstacles I encountered shaped my skills and my determination, especially when things went wrong. For instance, I would never fear that someone would threaten me not to do their fair share in a CS group project. OK. Then I'm on my own and I will do it fast and efficient, and still manage to get the highest score. The most important lesson is that these failures made me clearly aware that life as a young computer scientist was inherently hard. In some environment, it was even miserable. The fact that I led a club and made some non-negligible noise was already satisfying. I earned for myself the reputation to be an exception.

Maybe one day all the Computerization 'losers' would come back and visit the past victors with our six-figure salary in silicon valley. But it's not about money, it's about choice. I've made my choice regarding my career in computer science during high school, and I think you can, too.