00:00:00
I was pretty excited to be here. I have an announcement to make. Does anyone know what it is? Okay, well, this is the Friday keynote. Happy Friday! So, the other day while I was on my flight here, I realized that the keynote was going to be on Friday. If you're new to the Ruby community, you might not know this, but there is a tradition that every Friday during the conference, we do one thing: it's Friday hug.
00:00:23
If you have not done this before, this is what we're going to do. Right now, you're going to stand up and move to the middle. Then, you can take a selfie! So, stand up, move toward the middle, and raise your arms just like they did in the picture. This is my first time doing it, so it might take a while, but we'll get through it together.
00:00:51
Okay, are you ready for this? Let's do it! Wait, it’s not working. Technology, I guess... okay, there we go. Happy Friday! Thank you for doing this with me. Unfortunately, that took a little longer than I expected because it was my first time, and I spent all my humor time on that selfie. The rest of the talk is going to be very serious. I apologize for that. So, with that out of the way, we can get down to serious business.
00:01:18
There is an old Chinese proverb that states, "Giving a person a fish is not as good as teaching a person to fish." If you prefer a more poetic version, it goes like this: "Give a person a fish, and you feed them for a day. Teach a person to fish, and you feed them for a lifetime." Let's take a moment to appreciate the beauty of the Chinese language here. This proverb is structured in a parallel comparative form, where one thing is compared to something else.
00:02:04
If you look closely, you'll realize the only difference in the two clauses is the last character. The former is 'yu', meaning a fish, and the latter is 'yu', which is a verb meaning 'to fish' or 'fishing.' What's interesting here is that these two characters sound the same but are written differently. This creates a poetic inside joke. If you haven't seen this written form before, you cannot understand it just by listening to the words.
00:02:47
Equally interesting is that if you look at the first character of the two clauses, they're exactly the same. However, in the first clause, the character means 'to give,' while in the second clause, it means 'to teach.' This character also has other meanings, like 'to grant' or 'to gift.' It's no coincidence that they all share the same character. Teaching is ultimately giving a gift in the form of a skill, and the best thing a teacher could teach is the meta-skill of self-learning, which would be a gift that benefits a person's intellect for a lifetime.
00:03:37
All these are pretty uncontroversial points if you talk to any teacher or educator. I think everyone would agree that ultimately, that's what they're trying to accomplish. However, a 21st-century economy makes things pretty difficult. Most of us are not farmers or fishermen anymore. So, in today's economy, what is the 'fish' and what is the skill of teaching? What does it actually mean to teach someone to fish?
00:04:14
In fact, the line is even more blurry. Let’s say we teach someone to build a Rails app today; is that teaching them a skill, or is it just giving out a fish that would perish in a few years? What about teaching programming? Many cities have announced plans to incorporate programming into regular school curricula. Does that count as teaching the skill of fishing? In our industry, what does it really mean to learn to fish?
00:05:08
You've probably heard this statement before: a job as a programmer or software engineer is to solve problems. In other words, the fishing skill we want to teach in our industry is called problem-solving skills. While this is a noble goal, it’s not particularly helpful as a definition because it’s so vague. This description applies to pretty much every discipline. For example, when a client with too much money walks into your office, your job as a financial advisor is to help them come up with an investment strategy that maximizes their wealth.
00:05:57
Sadly, this is not a problem I personally have, but that definitely sounds like problem-solving to me. While I would love to think of myself as a magical problem-solving oracle, that’s not really helping us here. The industry is in love with the idea of disruption lately. Startups like Uber and Airbnb have identified inefficiencies in existing markets and industries, and they developed fresh approaches involving technology that ignored old rules along the way. Basically, they changed the game entirely.
00:06:52
For the most part, this change is for the better. As a consumer, I love the products. When I arrived here at the airport in Tokyo, I took an Uber to my hotel. Later this week, I will be traveling around Taiwan and staying in a few Airbnb places along the way. Unfortunately, while a lot of these rules that create friction and inefficiencies in the market need to be discarded, there also exist many that were set in place for very good reasons.
00:07:40
As a society, we have invested decades of learning into these regulations. Throwing them all out and starting anew means we will have to painfully relearn those lessons along the way. Let’s take the taxi industry as an example. Many cities have set accessibility requirements to ensure that people traveling in wheelchairs can reliably get a ride. Likewise, the hotel industry has insurance and safety requirements to ensure everyone's safety.
00:08:22
Education, too, has similar problems. There are clear inefficiencies in our computer science education system. Programmers and software engineers are in very high demand these days. As you might know, a computer science degree typically takes four years to complete, and that duration is way too long and too expensive. Besides, CS programs often fail to produce many good programmers, and academia is frequently out of touch with industry needs.
00:09:04
What they teach in schools today isn't that useful in the real world, and a lot of CS graduates do not possess the skills that are actually in demand on the market. So, what do we do? Well, we disrupt the education system, of course! We've seen the emergence of new programs called code schools and boot camps that train new entrants specifically on what the industry needs right now.
00:09:42
The short answer is similar to Uber and Airbnb. I actually love this idea. My company recently hired a new employee who came from a code school background, and she’s an excellent fit for the role I'm hiring for. However, just like Uber and Airbnb, I can't help but feel that we might be throwing out the baby with the bathwater. Computer science as an academic discipline has existed for much longer than you might think.
00:10:25
While the traditional system is far from perfect, perhaps there are good reasons why it’s structured the way it is today. And maybe there are some reasons why the fundamental CS classes have retained more or less the same shape over the last decade or so. As Rexy mentioned, I came from a traditional CS background. I attended a Canadian school called Simon Fraser University for my CS degree and also spent some time at the National University of Singapore.
00:11:09
I am very grateful for my education. On the other hand, as a graduate, I can definitely understand a lot of the criticisms people have about CS programs. Like most of us working in web technology, I had to teach myself. My work involved writing Ruby on Rails, working with browsers, optimizing SQL queries, and scaling out applications. Indeed, I didn't learn any of that in school; I had to learn it all on my own.
00:11:55
To think about it, I didn’t even learn much about programming at school. There simply weren't that many programming assignments at all. I was mostly taught and tested on the conceptual and theoretical level. Two years ago, I had the occasion to create a talk at RailsConf, describing our occupation as software writers, emphasizing that a big part of our job is to write beautiful code with clarity.
00:12:32
By that standard, I am actually pretty terrible. I don't think my work was ever graded on the clarity of my code, nor did I receive feedback on code quality in my programming assignments. All I needed to do was submit programs that worked, and that was it. Concepts like 'refactor' and 'unit tests' never came up.
00:13:15
It’s as if not only did they not teach me to fish, but all we did was sit in a room all day and learn how to prove that one way of catching fish was more efficient than the other. As it turns out, computer science isn't even really about programming. In fact, it might not have much to do with it at all. There’s a famous quote by a computer scientist that states computer science is no more about computers than astronomy is about telescopes.
00:14:03
So, if CS isn't really about programming and it isn't really about computers, and I didn’t learn the work skills I needed from school, does that mean the critics were right and I wasted five years of my time? Well, I can’t speak for everyone, but personally, I’m really glad I did it. I happened to really enjoy learning about the subjects they taught in school and had a lot of fun along the way.
00:14:47
However, there’s probably more to it. I’m pretty sure I wouldn’t be able to work on the same stuff I do today without my CS background. At least, it would have taken me much longer to get here. It's not just about the knowledge either; like most people will tell you, I didn’t end up using most of the things I learned in my CS program. Even the things that were actually useful by the time I needed them, I had already forgotten.
00:15:38
There’s something magical about the experience I went through. It changed the way I think and learn in ways that helped me later in my career. I believe that during my time in school, I might have actually taught myself to fish. Now, I’m not suggesting that a four-year CS degree is the only way to acquire this magical skill of fishing. During my career in the industry, I’ve had the privilege to work with many smart people who didn't go through a traditional path, and yes, they have definitely practiced that skill.
00:16:26
On the other hand, this is far from a skill that you automatically pick up just by going through a four-year CS program. I’ve seen plenty of CS graduates who did not leave school with these skills, and they had to learn a lot when transitioning into industry work.
00:17:10
Nevertheless, my CS education seems to have helped me develop this magical skill of fishing. Maybe we should try to figure out what it is and which aspects of my CS education helped me get there. If we can identify this skill, then we can discuss it concretely and perhaps find ways to make it easier for others to acquire.
00:17:54
This brings us to the topic of cognitive science, which I minored in during school. For those who are unaware, cognitive science is the interdisciplinary study of the human mind, examining how humans think. It exists at the intersection of computer science and human-computer interaction, also known as user experience design.
00:18:36
To illustrate what this field is all about, let me share something interesting. My company recently bought a new trash can in the office, but it’s not just any trash can—it’s a smart one. It has buttons, which might be hard to see, but the one on the left is labeled 'close' and the one on the right says 'open.' Those two buttons are what you would expect, but there’s a problem. Sometimes the 'open' button doesn’t actually work.
00:19:20
Pressing it does nothing. At first, we thought maybe the trash can was broken, but there’s an indentation that lets you open the lid manually. That works, but it defeats the purpose of it being smart. Eventually, we realized something odd: there’s an LED light between the two buttons that sometimes turns green. Whenever this happens, the 'open' button stops working.
00:20:03
It turns out this smart trash can is a state machine. At any given moment, it believes the lid is in either the open or closed position. When the lid is open, the only option is to close it, and when closed, the only option is to open it. The problem arises when the internal state in the trash can goes out of sync with reality. For example, if someone uses the button to open the lid but slams it down manually, the trash can incorrectly believes it’s in the open state when the lid is physically closed.
00:20:55
This also relates to the LED, which is supposed to indicate this internal state. A green LED actually means it’s in the open state, while a blinking red light indicates it's closed. Yet, as it happens, all of this doesn’t really matter because you should not be using those buttons in the first place. Turns out there’s a sensor between the two buttons, so what you're really supposed to do is walk up to the trash can and wave your hand over it to make it open.
00:21:40
It will open for a few seconds so you can toss your garbage in, and then close itself automatically. Now I see why they call this a smart trash can. Surprisingly, even though this example does not involve any computers at all, it showcases all the important concepts of effective interaction design.
00:22:26
I won’t delve too deeply into this topic, but if you’re interested in learning how to design better trash cans or user interfaces, I strongly recommend reading a book by Don Norman called "The Design of Everyday Things." What interests me is the process of how people in the office learned to use this trash can.
00:23:14
There’s a concept from Norman known as the human action cycle, which is a loop comprising goal formation, execution, and evaluation. When you interact with a physical object or user interface, the first thing you do is form a goal.
00:24:00
In this case, your goal is to throw out garbage from your lunch into the trash can. You now have a goal, and the next step is to formulate a plan to achieve it and then execute that plan. In this instance, you might think, 'I should probably go up to the trash can, press the open button, put my garbage in, and be done.' The last step is the crucial part, the evaluation stage.
00:24:44
Here, after executing your plan, you need to observe the result and assess if it worked, measuring your expectations. If it did not, you need to return to the initial step and start over; this time integrating what you just learned from the previous cycle to adjust your goals and plans accordingly. Maybe you would try to open the lid manually.
00:25:31
What's happening is that humans have a mental model of how to interact with physical objects. As you go through this human action cycle, you keep learning and refining your mental model. Eventually, even with something as bizarre as a smart trash can in the office, you arrive at the correct mental model.
00:26:16
What distinguishes good design from bad design is that good design naturally guides the user in forming the correct mental model while steering them away from incorrect mental models. When a user's mental model doesn't match reality, it can have tangible consequences, as seen in our trash can example. This is sometimes summarized as the usability iceberg.
00:27:01
On the surface of the iceberg, you have the parts that are visible, such as graphical design, colors, and typography. These visible parts make up about 10% of the overall experience. People often complain about them, but in reality, they represent just a tiny fraction of the overall user experience. Beneath the surface lies the hidden aspects, which account for the bulk of the user experience.
00:27:56
The mental model includes how well the flow of the user interface matches user expectations and performs the functionality people expect. I mention this usability iceberg because I think there are many similarities between user experience and programming. After all, programming involves writing code to instruct a computer to accomplish tasks, and the source code you write acts as a form of user interface.
00:28:43
I think the iceberg analogy applies well to programming as much as it does to user experience. At the top of the iceberg, you have visible things like code style and formatting, while the interaction layer consists of whether your code feels like Ruby, adhering to its conventions, and effectively utilizing language features.
00:29:32
However, more importantly, it is the invisible part, the underwater portion, that shapes the programmer's experience. This is where the mental model comes in—does the code flow naturally? Does it do a good job of compartmentalizing different concepts into their own objects or methods, like a well-designed user interface? Factory code naturally guides the reader to form the right mental model.
00:30:25
Having good comments is important, as is using clear naming conventions. Naming things critically forces you to think about the concepts you're working with in your code. In fact, the Ruby community has long recognized this. We have a principle called the 'principle of least surprise,' which essentially states that if you lead your users to form the wrong mental model, they will be confused and dissatisfied.
00:31:15
Additionally, the concept of 'convention over configuration' is related to this. By adhering to common conventions, you can establish your mental model once and apply it across various codebases, even those that are unfamiliar to you. This is particularly true for Rails—if you learn Rails, you know exactly where to find things in a new Rails app.
00:31:53
Mental models are inherently linked to a programming concept known as abstractions. High-level abstractions like Rails are immensely valuable as they allow you to start building from a higher level, rather than starting from scratch. Generally, the higher you operate in the stack, the more value you deliver to your business and end users. This is why salaries for developers and engineers are higher than ever before today.
00:32:43
We're building on an extensive foundation of abstractions that enable us to provide tremendous value right from the beginning. Nonetheless, the tide is turning against abstractions somewhat. There's an understandable backlash due to many developers being burned by poor abstractions—when you experience a failure, the emotions are vivid, and it often leads to conclusions like 'Oh, abstractions are never reliable.'
00:33:36
However, we must remember that while all abstractions can leak, this is a common insight in both science and statistics. The saying goes that all models are wrong, but some are useful. A great example can be found in physics. If you studied physics in high school, you probably learned to ignore friction and air resistance in your calculations. Although this is a wrong model of reality, it’s useful as it provides high school students with a sufficiently good mental model to start understanding the world.
00:34:27
It's also important not to forget that, while Newtonian mechanics provides a simplified model, it can still be very effective for many practical applications. Just because relativity offers a more accurate representation doesn’t mean it's reasonable for someone designing a car to think about space-time fabric.
00:35:15
In academics, we explicitly teach students to build models. Everyone knows all models are flawed, but these simplified models are features, not bugs. In our field, abstractions serve a similar purpose; they act as guides, helping users and readers form the appropriate mental model. While acknowledging that all abstractions may leak, it’s crucial to recognize that some mental models, like all models, are wrong, but some are still useful.
00:36:08
In cognitive science, there's a 'magic number' seven—a human can only keep about seven distinct objects in working memory at one time. Understanding this limitation emphasizes the importance of building effective abstractions that group things into higher-level objects, allowing for the retention of more information simultaneously.
00:36:51
Good abstractions simplify mental models by hiding unnecessary details. However, 'unimportant' is highly contextual—for example, if you are designing a car, ignoring friction will lead to issues in the real world. Well-structured abstractions delineate clear boundaries and help compartmentalize complex things into their own manageable categories, reducing the cognitive load.
00:37:38
That being said, when abstractions break down or cease to behave as expected, we all know the answer: debugging! That's our job as developers. One way to fix problems is to experiment, throwing different code solutions at the situation until something works. I'd argue this works to some extent, but there’s something unsettling about relying on this strategy in our work.
00:38:31
Instead of mindlessly troubleshooting, one key question becomes: Why has my understanding of the system diverged from reality? When encountering this discrepancy, it's important to recognize that the issue might be due to erroneous assumptions in our mental model or perhaps due to a bug in the abstractions below the surface.
00:39:19
If you’re lucky, understanding the source can be as simple as reviewing the documentation. Ideally, the abstractions we work with will intuitively guide us toward the correct understanding of the system. However, the reality is that designs like the smart trashcan I mentioned earlier are prevalent and not always fixable. Having the capacity to identify these signs will empower you to build a more accurate mental model despite inefficiencies in the underlying abstractions.
00:40:11
Critical as it is, many times, figuring out where things have gone wrong involves peering deep into the abstraction layers you rely on. Joe Kahn coined the term 'leaky abstractions' to explain how programmers often need more than superficial knowledge to work effectively with the systems they encounter.
00:41:06
Traditionally, computer science education adopts a bottom-up approach. In most CS curriculums, students begin at the lowest layer of abstraction and gradually learn their way up the stack. For example, in the first year, you might study a mix of programming, computer architecture, discrete math, and calculus. Once those foundational layers are solidified, you ascend to subjects like data structures, algorithms, and statistics. In your later years, you learn about operating systems, databases, AI, and computer graphics.
00:41:59
The supposed benefit is that even while you delve deeply into the minutiae of each layer, your understanding builds upward one layer at a time until you can address problems effectively at any level, should challenges arise. The drawback is that there are so many topics to cover, making it difficult to build that high in just four years. Everyone in the real world is building from higher layers that don’t require such exhaustive bottom-up learning.
00:42:53
For example, if you want to build a JavaScript application in the browser, but your CS education only goes up to the information systems level, you’ll have a gap in your learning. You will need to fill in those gaps independently as you learn about frameworks like Rails or Ember. Or, if you're working on a gaming project but your coursework ended at the theoretical aspects of animation, you’ll have to bridge that knowledge gap yourself.
00:43:49
Due to our traditional approach of baby-step learning, many students struggle with leaps from the 20th floor to the 50th floor, often falling off the CS cliff along the way. Traditional schools recognize the hurdles in learning that many students face and understand we, as an industry, are adept at building abstractions today.
00:44:43
When you work with something like Rails, it's very rare that you need to dig all the way down to the operating systems level to troubleshoot an issue. Therefore, perhaps we can start students at higher levels of learning, bypassing the unnecessary in-depth study of every lower layer since they might not need that foundational understanding immediately.
00:45:38
This creates a different issue: what if you actually need to go down, maybe not all the way to the operating systems level, but just one layer beneath Rails? Hopefully, over time, you learn those concepts. It’s imperative to recognize the CS cliff but also the CS gap—most of the time, you won’t need to navigate those layers, but having that skill and capability is essential regardless.
00:46:32
Thus, we return to the human action cycle—you need to consistently refine your mental models as you face new learning challenges. You might start with a vague concept: 'This is Rails, it does magic for me,' but as soon as that magic fails to function correctly, you need to evaluate, 'Something in my understanding about this framework is incorrect.'
00:47:26
This brings me to a broader academic principle, known as the hermeneutic circle. It originally described how biblical scholars analyze scripture, positing that understanding the whole requires comprehension of the parts, while understanding the parts necessitates grasping the whole—the process is circular. In a similar way, traditional CS education often functions as a massive hermeneutic cycle.
00:48:22
Particularly, that entire cycle takes about four years, which can be too long for many minds. By the time students finally arrive at the end of the cycle, they may forget the original reason they started studying CS. On the other hand, code schools face the opposite problem, delivering a crash course often lasting just three months before students transition to actual work, but they may struggle to find the path back to continuous learning.
00:49:18
With the vast array of resources available today, from online courses to book clubs and meetups, motivation and determination play critical roles. However, as newcomers, it can be hard to discern what to learn next. Perhaps restructuring our programs around this cycle better will allow students to navigate their learning journey.
00:50:10
There is a saying that it takes a village to raise a child. My education certainly didn't end there. I participated in my school's co-op program, where I had to do internships every summer. Whoever hired me took a significant risk; what did I know as a first-year student, right? Many people invested in my growth along the way, and I wouldn’t be here without their trust and investment.
00:50:57
Five years ago, I was fortunate to receive the RailsConf Opportunity Scholarship in Texas, where I met many of my open-source mentors, who further invested their time in me. However, that isn’t where my story began; I actually self-taught programming in high school. By the time I entered most of my CS classes, it was my second or third iteration through the hermeneutic cycle.
00:51:56
My education in this space started when I met my computer science teacher in elementary school who dedicated time beyond the classroom to teach us website development. He gave me my first programming book called "Professional PHP," which became pivotal to my self-teaching journey. My curiosity even led me to accidentally delete essential system files on my computer, prompting my uncle to come help me reinstall Windows.
00:52:55
I wouldn’t have accomplished any of these things without support from my family, who encouraged me to explore my interests in a culture that prioritizes academics above all else. Without their backing, I might have relinquished my passion for computer science, especially if bullying or negative reinforcement had stifled my curiosity.
00:53:53
Computer science education is about more than simply imparting knowledge or skills; it involves standing against bullying, advocating for gender equity, and reforming educational systems to nurture children's interests. If it truly takes a village to raise a child, then it equally requires a collective endeavor to cultivate 21st-century fishermen.
00:54:39
You are all here, and you've all made it, but we need more fishermen. Each of you holds a unique contribution. I will close with this: please pay it forward.
