https://www.hitmymanager.com/

The story starts with a sad, overworked employee being bullied by a terrible boss. But one day… he finally decides he’s done. This little worker is ready to stand up for himself.

This is the first time I fully poured my heart into making a game, and wow — it took me hella time. Here are some things I learned along the way, especially about using AI to design.

1. AI can create something impressive fast — but consistency is a beast

AI is great at generating those eye-catching first drafts. But getting consistent characters, consistent styles, consistent sprites? Not easy. Not even close.
It kept giving me designs that didn’t match the theme, or characters that mutated every few frames. I spent so much time fixing weird eyes, weird faces, and weird randomness.

2. Prompting is a real skill (and I don’t speak “designer”)

My designer friends know all the magic words, “chip,” “composition,” and a bunch of terms I’ve never used in my life. They speak the language that helps AI stay consistent and intentional with its design.

I… absolutely do not.

So when I prompt, AI just freestyles. And the freestyle is almost never what I want. Learning to talk to AI like a designer is basically learning a whole new dialect.

What’s funny is: in programming, it’s the opposite. I can fix a bug instantly by talking to AI in engineering language, while my designer friends get stuck because they don’t know how to “speak code” to AI. It made me realize prompting isn’t universal, it’s domain-specific.

3. Simple ideas are not simple when you try to make them good

“Just make a game where you hit a manager.” Sounds easy!

But it’s quite the opposite.

Initially, we made the game because we want improve this current physic engine about gravity.

We originally wanted people to scan real objects and learn physics by playing with them. It sounded exciting — scan a cup, toss it in the game, and watch real-world physics come to life.

But it’s actually very hard to do it well. Building accurate physics engines takes a long time, and once we finally got gravity “right,” the gameplay wasn’t fun. Objects stayed in the air for so long that everything felt slow and boring. Real physics ≠ good game design.

So we pivoted toward a storyline everyone can instantly resonate with: hitting someone. Simple, emotional, universally understood.

But to actually make this idea work, we had to

• build a clear storyline

• test the mechanics with real users (some found it too easy, others too hard, so I spent forever tuning tiny details),

• iterate until the gameplay made intuitive sense

And that’s just the creative side. There’s also all the invisible work behind the scenes:Most players are on mobile → so now I have to redesign the entire experience for mobile. API costs are too high → so I need to rethink the architecture and optimize everything.

A “simple idea” becomes complex the moment you try to make it good.

4. AI shines when you use it as a debugging with imaginations

One big problem I had was detecting collision using x/y positions. I was confused for hours. Then I asked AI to visualize the collision area with a green box. Instantly the issue became obvious. Sometimes, AI isn’t a good designer, but it’s an amazing assistant when you need clarity.

5. Storytelling still matters in game design

Good gameplay needs to feel connected to the narrative. Even a simple arcade game needs progression that makes sense.

For example:

• Level 1: the manager is just standing

• Level 2: the manager starts walking around

The story advances, and the difficulty increases naturally. Designing these transitions required more creativity than I expected.

6. Boring ideas aren’t always boring

We originally planned to make a very basic throwing game. In the first hour of the hackathon, we were already bored of it. But my designer friend refused to give up. We kept pushing, refining, adjusting, and the game slowly transformed into what it is today.

That process taught me how to collaborate with both AI and human designers. People love to say you can just “vibe code” your way through things, but as a programmer I learned the opposite: polishing a game takes way more time, thought, and obsessiveness than I ever imagined.

I started this project because I interviewed with Brilliant and learned interactive programming with p5.js for the interview challenge. I didn’t get the job, but that interview somehow grew into something much bigger.

Now I’m excited to take these lessons into future projects, maybe even building more interactive learning experiences like the ones Brilliant creates.

Who knows? This might just be the start of something cool.

What if, I imagine myself learning like a students preparing for an exam again?

• Before: I self study ML in my free time, but I often want to stop when things get hard, or I ignored what I didn’t understand.

• With the new attitude: I don’t just take notes for important concepts. I take complete notes to the level that I can read it without supporting documents (aka I also need to handwrite codes). Yet, slowing things done greatly improve my understanding and attention to important details.

When I’m bored doing similar work, what if I imagine I’m a student practicing problem set?

• Before: I get annoyed that there is bug here and bug there.

• Now: I wrote now all the problems and time it.

  • Problem set 1: The bar doesn’t show….. Problem solving time: x min

  • Problem set 2: …

It greatly reduced my personal boredom, but also allow me to monitor my progress.

As a engineer, of course, we rarely do handwritten notes, and we think build build build will help us improve. Yet, can we do better by applying different learning methods?

Inspired by my law student friend’s bar test studying style, and another friend who used flashcard app to study leetocde.

So she created this blog so people can learn through playing!

• Blog post: https://byte-pairing.vercel.app/

• Github: https://github.com/esther119/build-tokenization-from-scratch

Since Medium doesn’t allow interactive elements, I put my blog post teaser here. I’m looking for more animation and interactive ideas to improve this blog post!

Where does even the idea of a computer come from? Imagine a mathematician with a pen and paper.

There are already some basic raw forms of computers, such as punch cards, but most of them are perceived as an engine with specific usage. The initial idea of the computer is from Turing’s imagination. He imagined a computer is like a mathematician with pen and paper. The hands, eyes, and pencils are replaced as a scanning device that can move forward on the tape, representing the read and write of the machine. And an internal search pad to record “the state” (The current intermediate steps of computation) of a machine.

Let’s replace the two-dimensional sheet of paper with an infinitely long tape divided into squares, like a roll of postage stamps. Each square will either be blank or have a symbol written on it. (The symbols could be anything—numbers, letters, colors, pictures, whatever—so long as there was just one per square.)

Next, said Turing, let’s replace the mathematician’s hand, eye, and pencil with a scanning device that can move backward and forward along the tape one square at a time, reading and writing symbols as it goes. (A modern analogy would be the read/write head of a tape recorder or a VCR.) Let’s also replace the mathematician’s “state of mind,” his minute-to-minute sense of what’s going on in the calculation, with a kind of internal scratch pad that records the current “state” of the machine. (Example: “I am currently in the process of carrying a 4 to the next column of addition.”) Each different state can also be labeled by a symbol.

How does a machine know what operation to do next? Inspiration of cellular automata.

Before computers were programmable, they were operator-supervised, meaning that machines could only perform based on the instruction of the operator. They do not know the state they are in, so they cannot make their own decision. For instance, the decision is based on some conditions “If variable X = 0, then do operation Y, else do operation Z.”

The start of understanding the states of machines is the famous automata. If you know cellular automata, you will probably say “Ah ha!” When we learn it in our CS class, we are given some initial rules, such as:

At any given time and in any given cell, the automata could be in only one of a finite number of states, which could be thought of as red, white, blue, green, and yellow, or 1, 2, 3, and 4, or living and dead, or whatever. At each tick of the clock, the automata would make a transition to a new state, which would be determined by its own current state and that of its neighbors.

If you have learned this in school, you will probably know that the teacher will ask you the formula of state transition, the equilibrium, to the evolution of states.

Things start to click all of a sudden.

How does a computer become a general-purpose tool? Von Neuman’s “First Draft”: we fetch execute and return.

To describe why computers are general purpose today, I will need to use an analogy to describe software and hardware. You can imagine software is music and hardware is the instrument. You can play all kinds of music on a piano, is like you can use a computer for anything from writing a novel to flying jets. On the other hand, the same music can be played on different instruments like tubas and pipe organs. It is like you can run Google Sheets on both Windows and Mac.

Before Turing and Von Neuman’s “First Draft,” we think that a computer is just a fancier adding machine. This is how Von Neuman imagined the computer,

Finally, said von Neumann, the central control unit would be the heart of the computer, the part that decided what to do next. (Today this is usually known as the central processing unit, or CPU.) Its decisions would in turn be governed by a program stored in the memory unit.

How was the central control unit supposed to go about executing those programs? Von Neumann had quite a bit of leeway in his answer, thanks to Alan Turing. As he was undoubtedly well aware, his abstract architecture was logically equivalent to a Turing machine, with the memory, input, and output units collectively corresponding to the tape, and the central arithmetic and central control units collectively corresponding to the read/write head.

The fundamental basis of how a machine operates is: fetch execute and return. It feels similar to the language we use in javascript, we fetch the data, execute some functions, and return the results. This is the underlying of how machines operate our codes.

He envisioned the central controller as going through an endless cycle: fetch the next chunk of instructions or data from the memory unit, execute the appropriate operation, and then send the results back for storage in memory. Fetch, execute, return. Fetch, execute, return.

Before this, we can either ask a machine to do one set of operations or use an operator to make modifications. Back at this time, it’s not good enough because it goes through everything step by step. It’s like trying to make a dinner salad the hard way: go out and buy the lettuce, bring it home, and chop it up. Go out and buy the carrots, bring them home, and chop them up. But at least, they can perform many different kinds of things based on the instruction in the memory address.

Where does RAM come from? To speed up the computation by not waiting for the correct address.

I always find it weird to call RAM (random access memory). Why does it need to be random? Why is RAM faster than hard disk?

Since now you understand that the machine’s operation process is fetch, execute, and return, they need to know the memory address the fetch the next instruction they need to do, but that’s slow.

Among many other things, the 1946 report pointed out how much more efficient a computer would be if it could get access to each memory address at "random"-that is, instantaneously, without having to wait until the correct address came around on a circulating tape or a mercury delay line. Naturally, such a storage scheme became known as Random-Access Memory, or RAM. (Of course, the report also concluded that the memory unit should store the data as charged spots on the face of a cathode-ray tube —a cutting-edge technology in 1946, but now so thoroughly obsolete that almost no one remembers it.)

Hence, the term “random access” means that the CPU can access any memory cell directly, without having to go through all the preceding cells. This contrasts with sequential access, where data must be accessed in a predetermined order.

Where does a function come from? Subroutine in Lisp, a reusable and modular function.

We already have some idea of subroutines in Von Newman’s first draft, but the real application of it is from Lisp, a programming language from the 1950s by John McCarthy.

The use of software building blocks was hardly a new concept even then, of course. Starting in the 1940s, long before Lisp, or Fortran, or any of the other languages appeared, programmers had learned that they could save themselves a lot of time and confusion by breaking up programs into subroutines-reusable, self-contained procedures that could each do one specific task. One subroutine might calculate the cube root of any given number, for instance, while another might sort any given list of names alphabetically. These procedures could in turn be broken up into still simpler subroutines, and so on, all the way down to the level of individual commands, if need be. Indeed, as programmers tackled tougher and tougher challenges in the 1950s — the SAGE project, for example-this kind of decomposition had become increasingly critical.* Even today, under the rubric of "structured programming."

Before the idea of a subroutine, our code is just a big chunk of things together. Super hard to debug when it gets bigger. But in Lisp, the programmer can finally start with some basic functions and create their own. It makes so much sense why everyone is saying that writing modular code is good. Logically, it makes sense, but it’s indeed an evolution of thoughts.

Where does the idea of multitasking come from? Time-sharing, the computer switches tasks fast enough without humans noticing it.

Project Mac from the 1960s is the first machine that allows time sharing. Time-sharing is a computing technique that allows multiple users to share a single computer system simultaneously. Before time sharing, we are only using batch processing. In batch processing systems, users submit their jobs or programs to a computer operator, who then compiles and executes them one after another sequentially. Is there a better way to allocate computer resources?

So, McCarthy wondered, why not let the CPU skip from one user's memory area to the next user's in sequence, executing a few steps of each task as it went? If that cycle was repeated rapidly enough, the users would never notice the gaps (think of a kindergarten teacher holding simultaneous conversations with a dozen insistent five-year-olds). Each of them would perceive his or her program to be executing continuously. And more to the point, each would be able to create and modify and execute programs interactively, as if he or she had sole control of the computer. Since the users would be sharing the computer's processing time as well as its storage space, McCarthy took to calling his scheme time-sharing.

One of the most fascinating things about time sharing is not only sharing computer resources, it also allows information sharing because they are accessing the same system. Hence, the system became the repository of the knowledge of the community, and people started to discuss whether should we have passwords or we should just share all the resources together.

Where do TCP/IP come from? The invention of a network.

ARPA community is trying to build a network so different computers can talk to each other. They are facing some challenges. The two main challenges are:

1. How to send the information from one computer to another?

2. How can computers know where to send the information?

To send the information, first, they need to break the information chunks into smaller chunks, which is called a packet.

A second conclusion was a bit more esoteric, said Roberts, but less of a surprise: digital messages could not be sent through the network as a continuous stream of bits. Instead, they would have to be broken into segments, with some fixed number of bits in each one (think of a long letter written on a series of postcards).

The farther a message traveled, the greater the chances that one or more bits would be garbled by static and distortion on the line. And in the digital world, one erroneous bit might easily spell disaster. Thus the digital postcards, or "packets," in modern parlance.

Second, they need the computer to read the digital address (destination address, return address…) on the packet, so they know where to send it, which is the routing.

the clerks in each telegraph office had to write down messages as they arrived, then key them in again to send them farther down the line.) The idea was to keep the complex, highway-map structure of the network, with lines running every which way and an ARPA site sitting at each intersection. But the individual sites would share routing responsibilities equally. That is, the computer at each site would first read the digital address on each packet as it came in. (The packets would actually carry the digital equivalent of an entire bill of lading, with destination address, return address, error-checking codes, message identifiers, and so forth.)

That’s good, but what if there are many packets being sent? It will become a congestion! So they come up with the idea of having small computers as designated points for entry and exit of packets like limited access highways.

Clark remembers saying. "So my idea was simply to define the network to be something self-contained." That is, make the ARPA network into the digital equivalent of a limited-access highway, with an "interchange" located just outside each town. Each of these digital interchanges would actually be a small computer, of course, separate from the main computer. But like its asphalt counterpart, the digital interchange would handle all the routing chores. It would provide an on-ramp to the network for new packets coming out of the main computer; an off-ramp for incoming packets addressed to the main computer; and traffic directions for packets passing through on their way to other computers.

So now, they need to have small computers to handle the routings. They are called independent routing computers.

Now, said Clark, the beauty of this scheme was that it would simplify life for everybody. ARPA could take responsibility for designing and implementing the network proper-meaning the information highways and the digital interchanges-without having to worry that some contractor somewhere would mess up his site's programming and thereby bollix up the whole system. And the contractors, for their part, could focus on one comparatively simple task-establishing a link from their central computer to the routing computer— without having to worry about all the ins and outs of all the other computers on the network. So, said Clark, that was the idea: small, independent routing computers.

We just learned the history of network protocols. That’s why we talk about IP (internet protocol) packets and TCP (Transmission Control Protocol). The IP address is like the phone number assigned to your smartphone. TCP is all the technology that makes the phone ring, and that enables you to talk to someone on another phone.

And then those scientists spent lots of time convincing, fighting, and discussing how to set a protocol that everyone uses nowadays. That’s why we are using so many protocols e.g. Hypertext Transfer Protocol (HTTP), following the same rules.

Closing notes

When reading the history of computer science, I found it really funny that our ancestors were mind-blown by things that I find so stupid today, like copy and paste.

This quote from Steve Jobs resonates with me after reading the book.

All these complicated concepts that we have struggled with in school are evolutions of thoughts for decades. But it starts pretty simple, such as Turning’s imagination of a computer as a mathematician with a pencil and paper. Learning history demystifies a lot of fear we have when we start learning computer science, gives us an understanding of why we need to do things like this today, and a glimpse of how our ancestors imagined the future of computers. In contrast to just learning how to code, I believe learning the why of all inventions emerge will bring our joy of learning and depth of understanding to the next level.

最近聽了Jeremy 學習深度學習的分享，他說他當時天天熱切地打開深度學習的教科書，學到做夢也會夢到梯度下降法（Gradient descent）。我聽到的時候，心想，怎麼會這麼不公平，為什麼他的腦袋可以夢到梯度下降法，我的腦袋閒暇時間只會自動生成炮仔聲這種肥皂劇呢？為什麼它不會無聊時告訴我，我們來複習一下泰勒級數的公式（Taylor Series）吧！

於是我開始遐想，如何讓工程不單單只是知識或是技術，而成為我的一部份。因此，我就在閒暇時間問我的腦袋，我們來想想剛剛學到了什麼工程知識吧！沒想到腦袋想了兩秒，就說「太累了！」，然後自動進入睡眠模式。在觀察之後，我發現兩件事：

1. 我的腦袋只有在問題解不開的時候才願意思考，通常是有 bug 的時候。

2. 我的腦袋是懶惰的，只想做簡單的事情。因為編故事容易、思考難，所以閒暇時間當然只編故事。

那我有沒有可能擴展我對工程的既定印象，讓他不只是演算法與技術問題，融合更多的故事和想像力呢？

舉個例子來說，當我在學 CORS 的時候，這是一個網路的解釋版本：

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

Cross-Origin Resource Sharing、server、mechanism 是公殺毀，難怪我的腦袋閒暇的時候不願意想這件事情。那讓我把這個概念編成一個故事給你聽。

你想像 CORS 是一個許可通行證。想像你和小明住在兩個不同的房子，然後你想去找小明聊天。如果你到他家的時候，就直接打開他家的家門，那也太沒有禮貌了吧！你總是得先知道小明有沒有空，想不想和你說話。於是，你該做的事情有兩件：

1. 敲敲小明的家門，看看人家現在能不能和你說話

2. 如果小明說好，那再把你心中的話告訴他

以工程語言的角度來看，你和小明都是網站。如果你想和小明要一些資料，你就開先有禮貌地敲敲他家的家門，這就叫做 CORS 中的 preflight request。

通常，他們家還會有個看門的，叫做 OPTIONS，告訴你你是不是允許和小明說話（看看你有沒有符合訪客規定！）如果你有拿到許可，你就可以和小明要你想要的資訊，或是把你心中的話告訴他。

如果以更詳細的方式解釋，看門的還可以決定小明的訪客規範。

• 訪客需要先登記嗎？Access-Control-Allow-Origin: Specifies which origin(s) are allowed.

• 什麼要的談話方式是被允許的？你只能聽小明說還是你也可以傳話給小明？

  Access-Control-Allow-Methods: Lists the HTTP methods that are allowed.

• 怎麼樣的談話資訊格式是核可的？Access-Control-Allow-Headers: Indicates which headers can be used in the actual request. (JSON, plain text …)

雖然如果單純只看這些程式句法，確實陌生又可怕，但若仔細深究，就會發現他們的命名是有道理的。Access-Control-Allow-Origin 代表允許的資訊來源，Access-Control-Allow-Methods 代表交流的方式，而 Access-Control-Allow-Headers （較不直覺）表示可以傳送的額外資訊。

當然，要我的腦袋想和小明聊天的故事，比想 CORS 等技術名詞容易多了！

在學會學習工程不應該只想程式函數與寫作句法，應該更廣泛的學習一門科技的設計理念和問題背景後，我開始重新想像工程的學習，不應該只侷限於演算法、邏輯、與問題解決的方式，更應該廣闊的接納它蜘蛛網絲般環環相扣的故事與人類設計的精巧手藝，它可是一個老祖宗精心設計的思考方式和語言呢！

譬如說，我們被迫接納電腦的運作方式就是 0 和 1 ，這不是很奇怪嗎？誰會這麼想呢？但如果你閱讀 The Dream Machine，了解資訊理論的創始人 Shannon 的創作背景，就會不禁啞然失笑。他當時是個沒沒無問得研究生，只是發現電流的開開關關，好像邏輯系統裡的 0 和 1，覺得好玩，於是就用他寫了一篇論文 A Symbolic Analysis of Relay and Switching Circuits，大家剛看到這篇論文時，也沒想太多，覺得他真有創意，當他當時拿這電路板進辦公室玩的時候，同事們都覺得他在玩玩具！但這個想法卻拓展人類的想像，成為電腦運作方式的開端。

我注意到身邊有些工程師因為他們擁有的知識而有特別的優越感。有人告訴我：「我哪來的美國時間和新人花三十分鐘解釋 OLTP 和 OLAP 的差別！」這些技術名詞聽來可怕，但如果願意稍微花點時間研究一下，就會發現他談的只是資料庫隨著時代需求的演進罷了，和其他知識沒有太大的差別，就也是一門學問。我想，我們社會給工程很多既定印象，像是「工程是個神秘的，聰明人才能學的領域」或者是「工程師都有社交障礙」等，都是有礙學習的，畢竟這些印象，也只是社會訴說的一個故事，我們可以自主地去決定要不要相信它。

對於哪個要用軟體的激辯，應該要像是辯論哪間麵包店出爐的可頌更好吃，學習工程的想像也不應該侷限於一個穿著帽 T ，把自己鎖在陰暗的地下室前面，盯著一堆電腦螢幕的黑客，對於工程學習的想像，應該要是個創作的過程、藝術的想像、和日常生活的細碎變化。

有時，我會在工程裡會遇見沒看過的新單字，聽不懂那些外國人到底在饒舌些什麼；

有時，學工程是寫一首七言絕句，我得鑽研如何寫出平仄相對的格律；

有時，學工程像是練習投籃，要不斷複習怎麼從不同角度都可以進洞；

有時，學工程像是拼拼圖，我得找到下一個最符合色調的方塊；

有時，學工程像是看一個犯罪現場，我是個辦案的偵探；

有時，學工程像是聽一則上古時代的傳說，我聆聽先人的缺失與智慧；

我始終相信，唯有我們能夠屏棄社會不斷告訴我們的故事，我們才能以重新創造我們對工程的想像與理解，讓工程成為我們的方言，成為我們呼吸心跳的一部分。

原文：Engineering as a language of mine

As I’m working toward it, I quickly notice two things:

1. My mind only thinks about engineering problems when it’s uncomfortable, e.g., when I cannot figure out some bugs.

2. My mind doesn’t talk about the Taylor series during its free time because it’s lazy.

I tried to recall lots of engineering problems during my free time, and I realized my mind wanted to shut down if there weren’t any problems I hadn’t resolved yet. It much rather thinks about narratives, aka some easy telenovelas, that are convenient to come up with. This makes sense because our mind is wired with lots of stories we choose to believe in.

Then how do I make engineering a language of mine? After being inspired by the story of engineering, I wonder if it might be possible to make engineering a mixture of problem-solving and storytelling.

For instance, when I think about CORS (Cross-Origin Resource Sharing), you will get the definition of it:

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

Goddam it! No wonder my mind doesn’t want to think about it when it has free time. However, let me remake this as a story for you.

CORS is like a permission slip when two friends living in different houses want to talk to each other. If you just go straight to their house and open their door, that’s completely disrespectful! You should ask if they are willing to talk first. To have great communication, you need to do two things:

1. You knock on the door and ask if they want to have a conversation atm

2. If they say yes, you tell them what is on your mind

In engineering terms, you and your friend are websites. If you want to ask something from them, your respectful knock on the door is called the “preflight request.”

Usually, there will be a doorman, called OPTIONS, telling you if they want to talk to you (e.g. comply with the rules as a guest). If you are permitted, you can talk to your friend and get and give whatever you want!

To put it into even more detail, the doorman can specify rules on who can talk to your friends.

• Does the guest need to be registered? Access-Control-Allow-Origin: Specifies which origin(s) are allowed.

• What kind of conversation is allowed? Are you allowed to give or take the information? Access-Control-Allow-Methods: Lists the HTTP methods that are allowed.

• What type of information you can give or take? Access-Control-Allow-Headers: Indicates which headers can be used in the actual request. (JSON, plain text …)

Even though merely looking at the codes looks daunting, if you give the language a closer look, you will realize the naming makes a lot of sense with the story. Access-Control-Allow-Origin is talking about where the source comes from, Access-Control-Allow-Methods is about the methods to communicate, and Access-Control-Allow-Headers (less intuitive) is about some additional information that is being sent.

Asking my mind to recall this story is so much easier than thinking of CORS, server, mechanism, bla bla bla…

Combining the philosophical level, thinking of problem context and design philosophy to learn about engineering, I started to think maybe I should expand my perception of engineering from algorithms and problem-solving process to a web of stories and an intricate design of human ideas, and a language our ancestors created.

I find lots of engineers have a superiority complex for the knowledge they have. This is tied with the social perception of “engineering is a difficult mysterious discipline that is only for smart people” or “engineering is for socially awkward nerds who are as cold as machines.” When they talk about it, they sound scarily smart in the beginning. However, if it doesn’t deter me from learning deeply about it, it is just another piece of knowledge, another kind of information. The prominent social perception essentially is just another story that we can choose to believe or not to believe.

Debating about which engineering technology to use should be similar to debating which bakery sells the best croissant. The image of learning engineering shouldn’t be imagining yourself as a hacker wearing a hoodie in a basement, sitting humpbackedly in front of computers. The image of learning should be a creative process, an imagination, a daily encounter.

Sometimes, you encounter new vocabulary that you don’t know what the locals are talking about.

Sometimes, engineering is like practicing a serve in ping pong that you try to master.

Sometimes, it’s like a crime scene where you try to find the murderer.

Sometimes, engineering is seeing many different living room designs that you try to pick for your house. Sometimes, it’s a recipe you try to follow.

Sometimes, engineering is a puzzle that you try to find the next piece.

Sometimes, engineering is an ancient fairytale that a grandpa is telling you.

I believe only when we are able to let go of the social narrative of engineering, we are free to recreate engineering as a language of ours.

Step 1: Download sam cli (command line for aws)

Step 2: Add credentials

• I recommend using “root user” rather than setting up the IAM role in the beginning. Permission problems can be annoying when while root user has all the permission.

• To add root users, go to security credentials, and add an access key.

Step 3: Start with a simple sample template from aws

• Run sam init on your terminal

• Build your function and test if it is correct

  • Build: sam build

  • Test your lint: cfn-lint template.yaml This command is very helpful because we usually want to modify our template.yaml file, and it gives us the exact line on our error.

  • Test your function: sam validate

• Try to run it locally

  • sam local invoke: You can invoke your local function. To specify a function when you have multiple functions, use sam local invoke {{your_function_name}}

  • sam local start-api: You will receive an output API that you can test on.

• Deploy on aws

  • sam deploy: You will be able to see your function on cloud formation.

Step 4: Add your own functions

Python: Flask

Basic folder structure

├── README.md
├── __init__.py
├── events
│   └── event.json
├── hello_world
│   ├── __init__.py
│   ├── app.py
│   └── requirements.txt
├── samconfig.toml
├── template.yaml
└── tests
    ├── __init__.py
    ├── integration
    │   ├── __init__.py
    │   └── test_api_gateway.py
    ├── requirements.txt
    └── unit
        ├── __init__.py
        └── test_handler.py

The only thing we need to modify is the app.py file to add flask, and template.yaml to configure aws lambda.

My app.py

from flask import Flask
import json
app = Flask(__name__)

@app.route('/')
def hello(event, context):
         return {
            "statusCode": 200,
            "body": json.dumps({
                "message": "Success"
            })
        }

if __name__ == '__main__':
    app.run(debug=True)

Corresponding template.yaml file

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31

Resources:
  FlaskAppLambda:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world/
      Handler: app.hello
      Runtime: python3.9
      Events:
        FlaskAppApi:
          Type: Api
          Properties:
            Path: /
            Method: get

Node: Express

While I was using zip as a package type of Python deployment, when you use Node, the aws template is naturally tied with the Docker container, but you can also choose to not use it.

Basic folder structure

.
├── README.md
├── events
├── hello-world
│   ├── Dockerfile
│   ├── app.mjs
│   ├── handler.mjs
│   ├── index.mjs
│   ├── node_modules
│   ├── package-lock.json
│   ├── package.json
│   └── tests
├── samconfig.toml
└── template.yaml

Some useful command lines to see if your container is correctly connected with your Node.

• To see all containers: docker ps -a

• To see only the running ones: docker ps

• To run a specific container: docker run --platform linux/amd64 -it helloworldfunction:nodejs18.x-v1

Here, you will need to modify several files: index.mjs, template.yaml. I bolded all the code that I added apart from the template.

The aws template comes with app.mjs

/**
 *
 * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
 * @param {Object} event - API Gateway Lambda Proxy Input Format
 *
 * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html
 * @param {Object} context
 *
 * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
 * @returns {Object} object - API Gateway Lambda Proxy Output Format
 *
 */

export const lambdaHandler = async (event, context) => {
  try {
    // Check if the HTTP method is POST
    if (event.httpMethod !== "POST") {
      return {
        statusCode: 405, // Method Not Allowed
        body: JSON.stringify({
          error: "Method not allowed. Use POST method.",
        }),
      };
    }

    // Parse the incoming request body
    const requestBody = JSON.parse(event.body);

    // Your POST request handling logic here

    return {
      statusCode: 200,
      body: JSON.stringify({
        message: "hello world",
      }),
    };
  } catch (err) {
    console.log(err);
    return {
      statusCode: 500,
      body: JSON.stringify({
        error: "Internal Server Error",
      }),
    };
  }
};

Create a new file: index.mjs

import express from "express";

const app_test = express();

app_test.get("/myfunction/get", (req, res) => {
  console.log("Received a GET request to /myfunction");
  res.json({ message: "Hello, World!" });
});

// Handler for POST requests to /hello
app_test.post("/myfunction/post", (req, res) => {
  console.log("Received a POST request to /myfunction/hell");
  res.json({ message: "Received a POST request to /myfunction/hell" });
});

const port = 3002;
app_test.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});

export default app_test;

Modify template.yaml

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: >
  sam-node-template

  Sample SAM Template for sam-node-template

# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
  Function:
    Timeout: 3

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      PackageType: Image
      Architectures:
        - x86_64
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /
            Method: post
    Metadata:
      DockerTag: nodejs18.x-v1
      DockerContext: ./hello-world
      Dockerfile: Dockerfile
  # Define the functions section here
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/ #path to the function code
      Handler: handler.hello
      Runtime: nodejs18.x
      Events:
        MyGetFunction:
          Type: Api
          Properties:
            Path: /myfunction/get
            Method: GET
        MyPostFunction:
          Type: Api
          Properties:
            Path: /myfunction/post
            Method: POST

Outputs:
  # ServerlessRestApi is an implicit API created out of Events key under Serverless::Function
  # Find out more about other implicit resources you can reference within SAM
  # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api

  HelloWorldApi:
    Description: "API Gateway endpoint URL for Prod stage for Hello World function"
    Value: !Sub "https://${HelloWorldFunction}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
  HelloWorldFunction:
    Description: "Hello World Lambda Function ARN"
    Value: !GetAtt HelloWorldFunction.Arn
  HelloWorldFunctionIamRole:
    Description: "Implicit IAM Role created for Hello World function"
    Value: !GetAtt HelloWorldFunctionRole.Arn
  MyFunctionArn:
    Description: "ARN of MyFunction"
    Value: !GetAtt MyFunction.Arn
  MyFunctionApi:
    Description: "API of MyFunction"
    Value: !Sub "https://${MyFunction}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
  MyFunctionIamRole:
    Description: "Implicit IAM Role created for My function"
    Value: !GetAtt MyFunctionRole.Arn

Learning Strategies

1. Always remember to run it locally first.

   1. Run without lambda: You can run with your Python through python3 app.py or node index.js.

   2. Run with lambda locally: You can build with sam build, test with sam validate, and test your local API through sam local start-api.

   3. Run lambda deployment: After sam deploy, look around your aws cloud console to gain bug reports. You can also directly add an API test on the console to prevent authentication or other potential problems.

2. Test the deployment environment first before integrating it with your code: This is the biggest learning I gained. Usually, I rush to integrate the deployment code with my existing codebase, but the bug becomes very complex because of too many moving parts involved. This time, I played around the code with Python and Node first to make sure I understood how to tweak it. I only integrate my Nodejs deployment code with my codebase when I’m confident that my get and post request both work on my deployment testing code.

Working templates on my Github

• Node template: here

• Node template with express: here

• Python template: here

• Python Flask template: here

Most people associate programming with generating lots of codes.

And many current AI solutions emphasize alleviating the burden on humans to write code. However, the actual process of programming is heavily tied to various skill sets, including solving engineering problems, project management, and the ability to self-learn—especially when building projects as a way to progress. Here, I want to explore how we might rethink the self-learning journey for junior engineers as they attempt to learn through building projects.

What programming actually is in a project

When a junior engineer attempts to solve a problem or implement new ideas, they need to begin with technical planning, research various technologies to address the issue, compare different solutions, formulate hypotheses, and validate these hypotheses through testing. However, each step requires different abilities:

1. Planning: Ability to plan out solutions within the desired difficulty level.

2. Research: Ability to differentiate between good and useful resources (evaluation) and those that are not, and identify important learning spots.

3. Hypothesis Formulation: Ability to detect incorrect assumptions they may have when setting up hypotheses.

4. Hypothesis Validation: Ability to proof of concepts that can be transferred to the actual project.

5. Implementation: Ability to implement the solutions and unblock when encountering problems.

They might need multiple iterations. For instance, to host a full-stack image gallery app, they might consider different technologies including Node.js, Vercel, and Next.js. If they want to decide which technology will be best to quickly load the images, they will need to test different solutions through research and hypothesis testing for each technology.

3 Problems in self-learning for a junior engineer

Research: The superficial learning problem

If you are familiar with Bayesian inference, you probably know that our minds constantly update when new information comes in. However, the difference between a junior and senior engineer lies in experience, indicating the ability to assign correct weight to prioritize important concepts or problems for deeper exploration. Since junior engineers don’t have much prior experience, they are more likely to treat all information with equal weight, feeling puzzled by potential directions, and unable to delve deep into essential concepts.

For instance, even in React, one might simply see `props.name` and believe they understand `props` without comprehending the relationships between child and parent components, the concept of single-direction data flow, and the idea of lifting state — concepts strongly connected to the initial design of props.

More often than not, important concepts are overlooked by simply copying and pasting without a deep understanding of the underlying principles. This results in an inability to grasp more complicated concepts in the future.

Hypothesis testing: The wrong assumption problem

Whenever we try to implement an idea or resolve a problem, we will have a "bug hypothesis." These hypotheses are formed based on evidence and assumptions. If we set our assumptions incorrectly, we can never formulate a good hypothesis to address our problems at hand.

For instance, I spent the entire afternoon working on the integration from text to speech, wondering why the generated speech couldn’t be played. It was only later that I discovered the issue— the QuickTime Player on Mac doesn't support MP3 as a file format!

However, operating under my implicit assumption that my QuickTime Player could definitely play my MP3 file, I spent time working on the wrong hypothesis until a senior engineer friend pointed it out.

Validate hypothesis & Implementation: The give-up problem

The process of validating hypotheses can consume a significant amount of time and energy, often representing a common period when individuals abandon their projects.

When building projects, I constantly face decision-making challenges. Questions such as "Which technology is best suited to solve this problem?" and "How much time should I invest in a particular testing?" consistently arise. At times, the need to learn a new technology to test a hypothesis adds complexity. This process can be both painful and time-consuming, ultimately proving fruitless for the current project due to underestimation of difficulty or limitations in available learning resources.

For example, my roommate rebuilt her entire language learning app without using Unity because she hypothesized that she could achieve her desired features without it. This hypothesis was based on extensive online research and initial proof-of-concept building. However, she ended up resetting her entire GitHub repository painfully and relearning Unity when she realized her hypothesis was falsified.

While the initial hypothesis may seem promising, unexpected complexities or limitations can emerge during the testing and implementation phases, and the flood of overwhelming negative emotions becomes a reason for learners to give up on their projects.

How might we ease the pain?

I want to temporarily disregard online coding boot camps and paid classes as solutions due to the monetary constraints that most junior engineers face, being either poor students or recent graduates.

Current personal solutions

The simplest way to observe what learners do is by working on safe projects (e.g. working on projects with existing working code on YouTube or replicating code from others' GitHub repositories)

However, this strategy introduces a conflict between creativity and safety when undertaking new projects. Some of my friends build numerous projects but only by following the successful and existing work of others because they lack confidence in their ability to gauge the scope and difficulty of constructing their own. In fact, they simply don't know how to start.

This safety-first approach not only diminishes the enjoyment of building but also lacks an assessment of applying the concepts learned. How can we de-risk the building process and provide learners with more freedom to imagine what they want to realize?

Community Solutions: Buildspace

I've come across another existing solution that is well-known in Silicon Valley: Buildspace. This event invites learners to submit their weekly projects and share comments on Twitter as part of an accountability system. However, it primarily addresses motivation issues and does not alleviate the other challenges associated with learning engineering through building passion projects.

How can I pick up full-stack development in a few months?

Reflecting on my personal learning experience, I realize that the reason I was able to grasp full-stack development in a short time is not solely due to my hard work. Many learners also put in a lot of effort to learn engineering. However, the key factor contributing to my success was the abundance of resources in San Francisco. In this environment, I am constantly exposed to best practices in coding and easy-to-use, up-to-date technology. Participating in hackathons exposes me to what's possible, and I frequently encounter people who are happy to teach me the entire mental models for new technology, eliminating the need to slowly piece together various bits of information.

For example, in an effort to reduce my give-up rate and address my poor intuition in problem-solving, I force myself to use a well-structured template when building side projects. I break down projects into multiple versions of MVP, build proof of concepts before adopting new technology, time-box my exploration of new solutions, and iteratively reflect and improve during my learning process. Yet, I found that these practices were still not quite enough, and I wonder how we can do better than this.

Our idea: The development of a painkiller

We aim to address the three problems in self-learning for juniors:

• Detecting hidden assumptions by asking guided questions.

• Encouraging in-depth learning through following up on new concepts.

• Auto-generating code for proof of concepts to validate hypotheses.

What we are essentially imagining is having a senior engineer sitting next to you, with intelligence-guided questions to uncover your assumptions and lead you to the right problems with confident evidence of proof of concepts.

This is the procedure that my friend and I have built for this first-generation tool:

1. Track the problems you are attempting to work on during research.

2. Provide suggested questions to address hidden assumptions and problems.

3. Generate explanations for you.

4. Offer follow-up questions to encourage learning beyond the superficial, guiding you down the rabbit hole.

5. Provide sample code so you can "see" the concept and easily test hypotheses.

For instance, when I attempted to learn about information theory, the AI gave me Huffman code to understand how information is compressed. Similarly, when exploring the difference between runtime and build time, the tool generated a timer with simulation for runtime and build time so I can see the difference.

Based on our interviews with learners, most people find the most value in the sample code generation. The "Ah-ha" moment from seeing sample codes allows people to learn through an immediate connection between their hypotheses and the real output. While the guided questions are useful to re-center learners on better questions, we haven't been able to observe the in-depth dive of learnings from more follow-up questions.

If von Neumann’s First Draft has already transformed our understanding of machines from a fancier specialized adding machine to a general-purpose tool, I cannot see why the self-learning journey of a junior engineer cannot imagine whatever ideas they want to build in their minds. If hardware is our instrument, software should be the music that allows us complete freedom to play and experiment with different notes Hence, the self-learning journey should allow as much creativity and fun as possible, steering away from the grinding and emotionally traumatizing process learners usually describe and fear. The purpose of self-learning software should be to play, not to cause pain.

All in all, I love this entire building process because I can observe different learners and see how they solve their problems in their heads, all while rethinking how to improve my own learning process. This idea is very preliminary, but the point is to throw out bricks to attract jade ideas from people (拋磚引玉).

In short, our idea is about: We want to help junior engineers to learn deeper. Deep enough for them not only to understand how a piece of code works, but learn how to apply it and potentially provide problem context and design philosophy so they don’t only know how to do it, but why and when to use a concept.

Because the problem is, as a beginner for learning a new tool or new concept, we always stop at a surface level of learning, because we assume that we roughly know it. Or, we are distracted by so many external resources that we see, and overwhelmed by the amount of information. Can we build a tool that allows engineers to really drill down into some important concepts and learn them by heart?

To do that, my design research focuses on 3 main dimensions: Highlighting tools, coding assistants, and chat-based tools to see how existing solutions look like.

• Highlighting tools: These range from just highlighting the website to highlighting and creating a dictionary for keywords, and even making all the highlights a knowledge card so the learning can connect to each other.

• Coding assistant: Coding assistant usually has a side panel at VS code, where they highlight the code and generate how to modify it.

• Chat-based tools: Chat with websites or co-pilot with all the websites you are currently browsing

Highlighting tools

Highlighty

• function: highlight

Feedly

• Highlight + search for keywords

Sentelo

• function: Highlight + summarize + explain + give an example

Recall

• function: highlight + knowledge card + connect knowledge + question practices

Coding assistant

Codeium

• function: Generate code explanation and code at their sidebar

Chat

ChatWebpage

• function: Chat with websites

Sider

function: chat + explain + summarize + translate + write + OCR + grammar check (basically whatever interaction that you might need with the browser)

Many tools look really cool. However, most of the highlighting tools are limited to learning a keyword, not an entire concept. Even with the tool that won the Chrome extension award, Sider, acts more like an assistant for the web, but not for learning purposes.

Is there an opportunity that I can make a tool, that engineers can learn from a piece of code → to a concept → to the problem context or design philosophy to apply the concept? For example, can we look at props.name in react, but learn how the sharing state between components (Lifting State Up), to the single direction design philosophy in react?

To constrain the scope of MVP, we decided to only implement one idea: whenever there is a highlight, you will keep drilling down on that highlight. In contrast to asking one question on every different webpage, we are imagining a situation where you highlight something that you are curious or confused about, and AI will give you more explanation on it, and then you keep drilling down from the explanation that AI provides you.

Well…for sure I’m not only imagining this. I would love to have coding examples to practice the new concepts, want to have AI to know where my exact blockage on this learning is, what to learn next, and how can I apply this concept to my project…….

However, we decided just to focus on the nested highlighting idea for our first user testing round. We aren’t sure if this is a good idea yet!

Feeling Note: I was initially feeling quite discouraged because I was that those top Chrome extension products cover even more functions! Even though our ideas have a 10% difference, 90% is the same. So…maybe I shouldn’t even try? But several friends told me, that the first version of ideas will always be similar and a product is great isn’t only because it’s a brand new idea, there are so many other things that matter. So I decided to give this idea a shot!

Prerequisite for this post: You will need to know some React to understand this post.

If you have read The Key to Learning Deeply in Programming, my friend and I start to wonder: Is there any way AI can uplift the stress of building side projects and help junior engineers learn better?

Today, I spent some time breaking down problems and ideating potential solutions, and I want to use React statement management as an example to demonstrate how might we learn deeply through AI.

How might we help first-time React learners to learn better?

I ask AI to generate some important concepts to learn for a React beginner and choose state & props as an example to dive deeper. This is the thread of conversation I have with AI. Feel free to skip or just read the highlight because it’s quite long.

• Explain in simple terms: props & state

• Demo code for explanation

• Q: Applying in a novel scenario

• A: Applying in a novel scenario

• A: Explain the novel scenario

• A: Explain the novel scenario with visualization

• Problem context and design philosophy

Explain in simple terms

AI, can you explain props and state for me?

1. Props: This is information that a parent component passes down to its child components. Think of it like a teacher giving books to their students. Each student gets a book (props) from the teacher (parent component). They can read, use, and learn from it, but they cannot alter the content of the book.

2. State: This is information that a component maintains and can change over time. It's like a note you write to yourself that you can add to, erase, and modify as you need. In terms of components, this is data that can change after the component is loaded.

Demo code for explanation

AI, generate a code example to explain.

Example 1: props

Here, we'll create a Greeting component that receives a name via props and displays a greeting message.

function Greeting(props) {

return <h1>Hello, {props.name}!</h1>;

}

function App() {

return <Greeting name="Alice" />;

}

In this example:

• The Greeting component accepts props.

• props.name is used to dynamically display the name.

• In App, we use the Greeting component and pass a name prop with the value "Alice".

Example 2: Using State

Now, let's create a Counter component that uses state to keep track of a count value.

import React, { useState } from 'react';

function Counter() {

const [count, setCount] = useState(0);

return (

<div>

<p>You clicked {count} times</p>

<button onClick={() => setCount(count + 1)}>Click me</button>

</div>

);

}

function App() {

return <Counter />;

}

In this example:

• The Counter component uses the useState hook to create a count state variable.

• count stores the current count, and setCount is the function to update it.

• When the button is clicked, setCount is called to increment the count.

• The Counter component keeps track of and displays its own count state.

Example 3: Combining Props and State

Finally, let's combine both concepts in a more interactive example.

function User(props) {

const [loggedIn, setLoggedIn] = useState(false);

return (

<div>

<p>Welcome, {props.name}! {loggedIn ? "You are logged in." : "You are not logged in."}</p>

<button onClick={() => setLoggedIn(!loggedIn)}>

{loggedIn ? "Log out" : "Log in"}

</button>

</div>

);

}

function App() {

return <User name="Bob" />;

}

How do you feel about the response? I think this is not enough to learn the core idea of state and props. However, this is also the same thing I get when I was learning through youtube.

Q: Applying in a novel scenario

AI, give me a novel scenario to practice this concept.

Let's say you want to develop a simple weather application using React that displays the current weather condition of a city. The application should have two components:

1. CityInput: A form input field that allows users to type in the name of the city. This will be a "controlled component", meaning that the input value should be controlled by the component's state.

2. WeatherDisplay: A component that takes the city name as a prop and displays the current weather condition of the city. Note: We'll not tackle the actual weather data fetching here, you might use an external API for that in an actual application.

How would you structure your components in terms of state and props? Could you write a simple skeleton of these components?

Hint: What information changes over time? Where does information flow?

Remember, the key thing here is to think about the state (what changes over time) and the props (how the information flows from parent to child).

It becomes interesting right? So I responed:
- What information changes over time? weather
- How the information flow from parent to child: parent - city, children - city weather

A: Applying in a novel scenario

That's correct!

In this scenario, the weather and the city, both can change over time so they should be kept in state. The city's state would be in CityInput, whereas WeatherDisplay's state would be the weather.

The information flow from the parent to child would be the selected city that's passed from CityInput (parent) to WeatherDisplay (child). When the city state in CityInput changes, it will trigger a re-render, passing the new city prop to WeatherDisplay.

Here's a simple skeleton code for the two components:

import React, { useState } from "react";

// CityInput component
function CityInput( { onUpdateCity } ) {
  const [city, setCity] = useState("");

  const handleChange = event => {
    setCity(event.target.value);
    // Notify parent component about city update
    onUpdateCity(event.target.value);
  };

    return (
      <input type="text" value={city} onChange={handleChange} placeholder="Enter city name" />
    );
}

// WeatherDisplay component
function WeatherDisplay( { city } ) {
  const [weather, setWeather] = useState("");

  // Assume we have a fetchWeather function to get weather data
  // useEffect(() => {
  //   fetchWeather(city).then(data => setWeather(data));
  // }, [city]);
 
  return (
    <h2>The current weather in {city} is {weather}</h2>
  );
}

// Parent component, here just an example
// It handles city updates from CityInput
function WeatherApp() {
  const [city, setCity] = useState("");
    
  const handleUpdateCity = (updatedCity) => {
    setCity(updatedCity);
  };

  return (
    <>
      <CityInput onUpdateCity={handleUpdateCity} />
      <WeatherDisplay city={city} />
    </>
  );
}

Please note that you'd need a real API call in WeatherDisplay to fetch weather data - it's commented out because it's not the focus of the question. In CityInput, we also introduced an onUpdateCity prop which allows CityInput to notify its parent (WeatherApp) about changes. This is a key pattern in React: "lifting state up", when the state is managed by a parent component or even higher.

A: Explain the novel scenario

It starts to get into the important part of it, so I follow up: I don't understand onUpdateCity and handleUpdateCity.

I apologize for any confusion. Let's dive a little deeper to understand onUpdateCity and handleUpdateCity.

Here's their purpose:

• onUpdateCity is basically a function that's passed as a prop from the WeatherApp component to the CityInput component. When we say onUpdateCity={handleUpdateCity} inside WeatherApp, we're saying "Hey, CityInput, here's a function that you should call when the city changes."

• Inside the CityInput component, it calls this passed function in its handleChange function. So, any time the city value changes due to a user typing in the input field, it not only updates its own state 'city' but also informs the parent component (in this case WeatherApp) about this change by calling onUpdateCity(event.target.value).

• handleUpdateCity is that function in the WeatherApp component that gets called. When this happens, it receives the updated city and uses it to update the state of the WeatherApp component.

The reason we do this roundabout thing is because the WeatherDisplay component, which is also a child of WeatherApp, needs to know when the city changes. But CityInput and WeatherDisplay are siblings -- they don't have a direct way to communicate. So we use their common parent WeatherApp as a conduit for that communication.

This is a common pattern in React called "lifting state up". Instead of trying to sync states across multiple components (which gets complex and error-prone very quickly), we "lift the state up" to a common ancestor and then distribute it down as props. This keeps our state logic in one place and our components more predictable and easier to understand.

A: Explain the novel scenario with visualization

Good job! AI starts to teach me in depth, using the parent/child information! Well, but since I still don’t understand, I ask: Can you visualize who is calling who. that's confusing.

Absolutely, we can look at the process as a model of communication between three individuals:

1. CityInput (a child who observes and reports)

1. WeatherApp (a parent who listens and informs)

1. WeatherDisplay (another child who receives updates)

Let's represent each component with these individuals and see how they interact:

• The CityInput (the observing child) is like a child playing outdoors. When the child observes a change (e.g., it starts to rain), they run inside to tell the parent, using the method the parent has told them to (onUpdateCity).

• WeatherApp (the parent) is the decision-maker of the house. They are listening for updates from CityInput (the observing child) via the handleUpdateCity function. Upon hearing about the rainfall, the parent then updates their knowledge (state), which in turn informs their other child - WeatherDisplay.

• The WeatherDisplay (the child receiving updates) then takes this new information (the weather condition) that it gets from the parent as a prop and acts on it. It may respond to this update by putting on a raincoat or grabbing an umbrella.

This represents the flow of information.

Here's it visually:

CityInput - (observes an event and tells parent) -> WeatherApp - (updates state and informs WeatherDisplay) -> WeatherDisplay

It's two communication lanes that form a cycle:

1. CityInput -> WeatherApp: via onUpdateCity prop (aka the parent's instruction).

1. WeatherApp -> WeatherDisplay: via city prop (aka the parent's update to its other child).

Hope this clarifies how the communication is happening between the components!

Problem context and design philosophy

Wow! This become so clear and finally understand more about props and state instead of pretending props.name is the world! So I AI about the problem context and philosophy for this design.

In GUI applications, the state of the application and the interface needs to change often due to user interactions (clicks, keystrokes, etc), and these changes need to be accurately reflected on the screen in real-time.

In traditional, procedural programming, this can lead to difficult-to-track bugs and inefficient code, as different parts of the application may need precise knowledge about others in order to function. React's model abstracts away this complexity through a single-direction data flow, and a diffing algorithm that efficiently updates only the parts of the interface that need changing.

…

• Bidirectional data binding (the method before react): This means that if you have two pieces of data, like a textbox and a model (an object that holds data), they are linked or "bound" together. So, if you change the data in the model, the textbox will automatically show this new data. It also means if someone types into the textbox, the data in the model will be updated to reflect that.

This seems convenient, right? But imagine if you have lots of these data bindings in a complex app. If an error pops up, it becomes difficult to trace which change caused it. Plus, with multiple components manipulating the data, it can lead to unexpected results.

• Unidirectional data flow (React's approach): React took a different approach, called "unidirectional data flow". Remember the LEGO analogy? With React, data moves in one direction, from top (parent component) to bottom (child component), just like building up a LEGO structure from base to top.

This means a child component can't directly update something in a parent component. If a change is needed, it must ask the parent component to do it. This helps keep things organized and makes code easier to understand, as you always know where the change is coming from. It also reduces the likelihood of bugs because you are controlling exactly where and how changes are made.

So, while bidirectional data binding is like a busy roundabout with traffic coming from all directions, React's unidirectional flow can be seen more like a one-way street, which can make managing complex applications much simpler and cleaner.

Kudos to you if you actually read it till here, but look! I also learn so many new things from the conversation with AI! To summarise the learning.

1. I learn how to apply props & state through the novel scenario

2. I learn why props & state as a design philosophy. React is designed as a unidirectional data flow to contrast with the messy bidirectional data binding approach in the old days. Hence, the parent-child relationship makes so much more sense now!

If you look back at my thread with AI, you will realize the most important parts are missing in our learning journey when we learn it for the first time ourselves.

My thread

• Explain in simple terms

• Demo code for explanation

• Q: Applying in a novel scenario (missing)

• A: Applying in a novel scenario (missing)

• A: Explain the novel scenario (missing)

• A: Explain the novel scenario with visualization (missing)

• Problem context and design philosophy (missing)

That’s why I always feel like I’m just sort of know state management but not really. However, after going through the in-depth application and problem context, it makes so much sense now. so here is the idea:

So far, it seems that the chat interface is bad, and it requires us to prompt it. But is there a way to integrate it with learners’ lives so beginners can pay attention to important but new learning concepts?

Me and my friend will be ideating on this tomorrow.

Most programming education tools suck. They teach you how to do things, like a user manual, but don't tell you where they come from and why they are needed. What can we do about it?

The Importance of Design Philosophy & Problem Context

The moment my friend explained the philosophy and historical context behind a technology's development, everything clicked, and I learned the tool so much more easily. For instance, he taught me about the development of the app router in Next.js. He said, "Because the app gets very complicated over time, we need a better abstraction so that the team can work hand in hand without knowing what other people are doing."

Okay, I understand what it means, but how does this philosophy show in the design of the tool? He pulled out the app he built and showed me the code with all the child components. "Look at the layout of my onboard page. There are so many tabs, but the onboard bar will stay the same no matter how the children inside change." When I saw the code, I immediately understood why Next.js forced us to use "layout.tsx" as a name everywhere and how another engineer developing the children inside no longer needs to see any code related to the onboard bar.

After our talks, I learned that I can separate my programming learning into several layers.

• Implementation level: How to debug my current problem right now?

  • This is what I did in the beginning and still do (when I'm lazy). I just copy and paste the error message and the code into ChatGPT or Stack Overflow. I try to run the code and see if it works.

• Functional level: How does this function work?

  • This is what I'm gradually learning through having a technical learning template and forcing myself to stop and learn.

• Philosophy level: How does this language work, and how is it designed? What problem is it trying to solve?

  • This is the part he taught me. With his experience, he gave me a conceptual view at the philosophical level and demonstrated it through his code template on a functional level.

Why do all these levels matter? It's about patterns. Most engineers I meet don't think about patterns or only have a "sense" but not an in-depth understanding of them. They just try to piece information together from their experience. In my previous work, when I asked a question, my ex-boss would just answer the exact question I asked but wouldn't tell me what motivated this question and what the mental models I was lacking were. Over time, I wrote lots of code, memorized everything, and tried to apply it in similar cases, but I never truly understood it. Though My senior engineer tried to explain things to me, which I kind of got, it wasn't as holistic and clear as when my friend explained things across three levels to me.

Another example is when I asked a front-end developer about React. I was in all the bugs and asked him how to fix them. Beyond debugging and thinking through the code, he taught me, "There is a difference between declarative vs. imperative language. Imperative language is what you know. You ask the computer to do step 1, step 2, and step 3, while declarative language, like React, is that you only want to know the beginning and the end and ask the code to show it when it happens." All of a sudden, all these weird state management things in React started to make sense to me.

The last example he taught me was about the server component in the app router. Before, I thought it was cool, and more convenient than the way we did things before (something on the client side), but I never knew exactly why. And then he taught me the dream of Next.js. Rather than separating the front end and back end, what if we have one thing that can somehow remix them together, so we will never need to worry about connecting both of them anymore? I still don't fully understand it, but I think it's starting to give me a sense of why I might want to use it and an interest in starting my exploration. Because I thought the people who designed this were so confusing and stupid.

What’s the difference between a senior engineer and a junior engineer?

Asking the right question.

It may sound super easy, but it's hard to apply it. For instance, the last time when my audio file didn't play, we debugged it for two hours, and he said, "Wait, it's because QuickTime Player doesn't support MP3!" For me, why is it possible for an audio player not to support mp3? Isn't supporting MP3 the most basic thing for an audio player on this planet? However, without challenging the assumption that "My audio player might not support the current audio format," I don't think I would ever figure out this problem even if you give me a century.

Another example is the getstaticprops the function I tried to learn in Next.js. I was annoyed by why this function disappeared in their new version, App Router. I thought, "This is so stupid, is it because this tool is so new that they haven't built it?" He immediately caught this assumption and asked, "Why is it not there? What might be the reason behind it?" And then we learned why App Router exists.

Today, we spent three hours together just talking through the project I worked on yesterday. What were my assumptions when solving the problems, deciding the tools to use, and how do form all my decisions?

In essence, when he keeps asking, "What do you assume about it and why?" it helps me catch the wrong assumptions and accumulate a better understanding to ask the right questions. However, how to ask good questions then?

How to ask good questions?

From him, I learned these two questions helped me a lot with the process of actually understanding it.

• Why? Why doesn’t it work? What is my hypothesis when I see my audio files don’t work? When I exclude some possibilities, what’s my assumption behind it?

• How? How do you utilize the concept you just learned in the code you have now? For example, how do you pass information in the event handler without having it in your component?

• So what? What will happen if we introduce this new function and tool? What kind of difference will be made? For instance, if the server component is implemented, what will it look like for the user?

Throughout our conversation, I finally learned what it means to delve deep into something. People often say that to become proficient in one thing, you should keep asking why and focus on learning one thing deeply. I know this, and I think everyone knows this, but none of us knows how to apply it when we are new to something. I used to make lots of mistakes by looking into irrelevant code because I was trying to go deep and felt frustrated wondering why I was just getting more confused. I'm super grateful that today he showed me a pathway on how to do it effectively and became my free tutor along the way.

As I have enough knowledge on implementation and functional level, the next step I will take is to learn all the design philosophies and problem contexts of new technologies. I believe it will give me better intuition into asking the right questions as a junior engineer.

However, as I was trying to make my own manually today, I realized there were many important elements that are missing.

Here are my problems

1. The image generation process takes a long time. Dalle is super slow. In fact, all the AI image generators are slow. I was really annoyed waiting for 30 seconds to generate an image that might be good and representative.

   1. I need a translation from Spanish to English first and add an extra image generation prompt.

   2. Even if everything is good, I might still be unsatisfied, I need to find a way to cancel and tweak my inputs.

   3. I do not care if the image is pretty, but it needs to give me a really strong association with words.

2. I need a place to store my images. I fill it in a big folder already as I have 25 images. What if I want to remember several hundred words?

3. I want sound!!! Looking at the image is really boring. How can I generate and pronounce sounds?

4. I want side notes! Looking at the word is hard to remember. I want to have the context from Harry Potter so I can know how and when to use it. But also, writing those notes is quite annoying. I want an easy way to match the notes with the word.

5. I don’t want to stare at my laptop all the time! I love circling words in my Harry Potter Spanish book. I want to have as little time on my laptop as possible.

After 1 hr of testing and with only 20 useful images out, I was annoyed. I realized I imagined it as a programming problem but not as a learning problem. So I underestimated how customized I needed my tool to be. I finally realize why lots of programmers that build lots of fancy but useless products. As a person really trying to learn Spanish, I don’t care how many features my flashcard app has, but I want to have something that can actually make me engage more in learning, and less in operational work.

Hence, I decided to throw away all my imagination of productionizing this tool. I just want to selfishly make this flashcard thing as helpful as it can be for me. I don’t mind dragging all the files to wherever. Using my hand to generate images is fine as long as it’s quick and simple.

I noticed the discrepancy between the builder and the user in the development of any tool. The real needs that a builder or a programmer imagines can be really different from the user, due to the lack of experience of the own tool they make. A builder can imagine, “Yes an AI auto flashcard generator will be so simple and easy to build!” Yet, they might not fully grasp the subtleties and specific requirements, like how an image should strongly and accurately trigger associations for the word being learned. The absence of this firsthand experience can lead to a mismatch between the basic structure of the tool and its intended purpose. While builders focus on crafting a visually appealing and functional tool, learners are more concerned with enhancing their learning experience. The nuanced difference between possessing exceptional craftsmanship and addressing immediate problems is the gap between the builder’s mindset and the user’s mindset. (highlight to remind my future self)

Yes, yes. My builder mindset is debating with my user’s mindset today.

My old method

Yes, I did the image method before for Spanish clothing. Images are so much more fun than looking at boring translation words, but…

Creating all these images took so much time, and lazy Esther ended up doing the translation method.

Nowadays, since AI can do lots of artwork, I started to imagine, can lazy Esther just ask AI to create the drawing part for her?

My idea

This is my idea sketch. There are three simple ideas that come up to my mind.

1. Memory gallery: Whenever I input new vocab, AI will generate an image and store it in a flashcard library.

2. Matching Game: I can play a drag-and-drop matching game for the vocabulary in the memory gallery to review. (Note: But the most powerful memorizing method is still “recall” aka you look at the image and actively think of the word from your brain)

3. Practice with AI: I look like the photo, and try to describe the image with the vocabulary that I learn.

Today, I tested with Dalle3 to see if this idea is possible. I asked it to draw whatever word I learned from Harry Potter recently.

• draw manzana (apple in Spanish):

• draw fracasar (fail/break down in Spanish):

draw obtener (get/obtain in Spanish)

I was sooooo amazed by AI! I thought they wouldn’t understand how to describe abstract words, such as fail or obtain, but they do it so well that I don’t think I will ever forget these three words in my mind!

Prototype

After seeing the possibility, I built a quick prototype for the memory gallery I was imagining.

How convenient it be if AI could handle the drawing labor work for me?

Next question

“Learn a word” for me means that I can easily apply it verbally in the sentence. Now, I can recognize the word, but how can I get to that application stage? What are the traditional methods that are effective? Can I use AI to practice with me?

Appendix

Where I’m stuck at: If you have read The Bottleneck in Learning a New Language, you will also know that I struggle a lot with applying the past tense. It takes me 30 seconds to think and say it out loud. I was thinking of talking to an AI to practice, but I don’t think that’s enough “stretch” to practice different verbs. Incubating more ideas!

We got some drawings from an artist, and then we just created more art!

Artist’s work:

Our work:

We played with it for 3 hours on a cloud GPU called RunPod, and my friend taught me Comfy UI, we used Control Net, VAE, and Lora to make it! (Yes, I have no idea what I’m talking about either because I’m just throwing words at you) We figured so many problems out today and I’m so so so happy hehe.

Out of curiosity, I put my drawing inside and see what it would look like. Let me show you my proudest baby!

I think AI really knows me by heart ❤️

Appendix

AI also created this and this, but I’m not a long-haired white woman 😤

And we made this funny slide and went back home without demoing. The next day, we noticed that we got the third price on twitter haha

Read more

I have been working on an AI learning company for two months that provides interesting knowledge and images whenever you have questions in your mind. For example, if you want to ask about 3D printing, the AI can generate information on that topic. This is one example that AI generates.

As an LLM Engineer, a significant portion of my work involves ensuring the quality of content and images. I evaluate whether the content provides meaningful information or is just a collection of meaningless words. I also check whether the images are relevant to the content. If you work on AI-generated images, you are likely familiar with the issues that AI faces. For example, people may appear distorted in the images, and the AI may generate lots of meaningless text.

Here are some of the things I have learned in my first two months on the job.

Simple instruction for LLM is usually better.

Before I joined, the old pipeline our company used had one prompt and asked AI to fit in 100 requirements. They asked AI to provide something interesting, be fun and engaging, avoid filler words, and not do certain things. They also asked AI to format some texts in style A, some in style B, and some in style C, D, E, F, G. When they asked AI to do so many things, AI became overwhelmed and the results were very poor.

However, if we understand that LLM/transformer is a series of predictions for the next word with some emphasis window (self-attention mechanism), we probably want to make sure AI can understand the one important goal and bias toward it rather than trying to achieve many goals at the same time. That’s why it’s usually better to do a chain if we have multiple objectives, but the trade-off will be latency. That’s why based on my experience the simpler the instruction, the better the performance.

Note: In addition, we also want to be aware of the initial dataset that it was trained on. Is our questioning format the same as the format that it was trained on? We should align our format with those.

Only Problems That Form a Pattern Are Worth Solving.

However, team members without a technical background may not understand it, and I often receive complaints such as “This image is off” or “That content is horrible”.

To be fair, I can make sure to resolve one specific content they complain about by specifying instructions. But is it worth the cost of the other 100 pieces of content that are good? So whenever my team members complain about content or image quality, the first question I ask myself is usually:

Is it a corner case or a pattern?

If it isn’t a pattern, it probably isn’t worth solving.

Keen Observations are the Key to Resolving LLM Problems.

One week, our founder kept saying “Our image AI is on LSD!” because the images the AI-generated were often rainbow-colored, crystal-like complicated patterns, and had a mix of colors in the background. To them, it seemed like the world was collapsing because everything was scary. However, when I looked into the problem, I noticed that all the “LSD images” were because the content was introducing abstract topics such as social justice and equality. The AI didn’t know how to draw them, so they got creative.

After giving them prompts to generate more concrete objects, many images became significantly better.

“Great work, Esther!” My founder beamed. Little did he know that it only took me less than an hour to figure this out and resolve this issue that seemed to be so large in scale. When this technology is so new, a scientific mindset such as observation, hypothesis, and experimentation is my toolkit.

The trade-off in LLM

The Trade-off Between Depth and Length, and Tone

When my team expressed dissatisfaction with the content quality, saying things such as “the texts are too long,” “the content isn’t informative,” and “there is no personality in the text,” I provided several examples to illustrate how content often represents a trade-off between various factors.

The following are three examples of writing about Giffen Goods:

As you can see,

• Example 1 (Top): It has the most personality with an analogy to assist understanding. However, it has filler words, such as “Ever heard of Giffen goods?”

• Example 2 (Middle): It still has some personality, and we successfully solved the problem of long texts. However, it suffers from some information loss.

• Example 3 (Bottom): It has adequate information with an acceptable length, but now it looks like a boring textbook!

Beyond the trade-off of tone, length, and depth, a trade-off exists in all prompt engineering practices because when AI is biased toward achieving one goal, some other things get sacrificed. If we are not trying to train a better, bigger model but building an LLM application in production, we have to lean toward whatever is more aligned with our business goals and user needs.

The Trade-Off Between Latency and Content Quality

Users feel frustrated if they have to wait more than a minute for the output after inputting their request. While it’s possible to train small models on specific tasks to reduce latency, these models will perform poorly if we ask them to handle tasks outside their domain. As I develop a general-purpose learning app, I’m hesitant to sacrifice content quality for speed.

You might ask, “Why not just stream the output?” However, the challenge I face in production involves a complicated chain of data validation and product requirements before sending the content to the users. Would users prefer waiting a minute to see the complete content or waiting 10 seconds to flip through every page?

I believe that as more AI tools with easy usage become available in the future, we might find a way to resolve this trade-off. For now, I’m trying to balance the competing demands of latency and content quality.

Prompt Engineering is Underestimated.

Most engineers think that prompt engineering isn’t “real” engineering. My engineer friend likes to say, “It’s just a GPT API wrapper.” But if I can soon create better prompts to replace coding, is it still stupid?

As an engineer, I used to find prompt engineering to be unimportant. Training on clusters and thinking about gradients seemed to be much cooler. However, from a business perspective, prompt engineering usually provides the biggest value at the lowest cost for content generation tasks.

Although there are already many prompt engineering cookbooks, it still requires lots of imagination and creativity to get the most out of this new technology. I hypothesize that we haven’t exhausted the potential of prompt engineering due to the indeterminate output and lack of an assistive evaluation tool in LLM.

Building a content evaluation tool is difficult, even through fine-tuning AI evaluation. But systematic exploration of prompts already exists. My friend built Baserun for prompt testing and evaluating output, which is a first step towards systemizing this process.

Using Temperature as a Simple Design for Fall-Back Systems and Data Validation.

Currently, I use datatype checking to ensure that AI output is in the desired format. When it is not, I change the temperature to create variation and ask the AI to rerun. Langchain has an output parser tool for this purpose, but from my testing, their parser tool is not reliable, so I prefer to test on my own. Guardrail AI also has its own testing system, but while its design philosophy makes sense, the implementation is not intuitive, so I have not yet tried it.

Overall, rerunning is not ideal as it takes up more time. Additionally, data validation requires returning the entire AI output, which takes away the advantage of streaming. I would love to learn more about solutions for these aspects.

It’s super important to communicate the possibilities and limitations of LLM to your team.

In a team where most people don’t really know how LLM works, I gradually realized the importance of communicating the information gap. There are two main points that I keep communicating with my team:

1. Improvement isn’t linear, and my timeline differs from people’s expectations. My team seems to expect that the content will gradually improve day by day, but that’s a misunderstanding. I will need to build the infrastructure, validate the output, examine the latency, and experiment with different prompts and combinations of chains. But when I’m done with it, it will be a totally new version of output. Conversely, sometimes I can simply change the prompt in 5 minutes and fix some significant problems. My team might think I worked a lot to make this great progress, but it’s actually much simpler and quicker than they expected. Overall, the timeline I’m working on isn’t as linear as they think, so I need to provide them with more context on how AI works.

2. Generating content that balances our expectations (users’ needs in the future) matters more than satisfying everyone. In the “Trade-Offs Between One, Depth, and Length” section, I showed that people want content that is fun, with in-depth knowledge, and a comfortable length. However, I’ve started to communicate with them that there is a trade-off or balance we can achieve rather than satisfying everyone’s needs. I’m not discounting that with better models, we might find a happy balance. But it requires clear and measurable “amazing content” that needs much more user feedback data and iterations, rather than personal judgments. As an LLM engineer, I’m learning how to communicate with my team to implement future practices that allow for scaling and acknowledge current constraints and trade-offs.

Here is what I have learned so far, but every day I still feel like I don’t know shit about LLM. Please let me know if you have any additional ideas for improving LLM engineering practices!

Throughout my job-hunting process, I found following up on emails very painful for outreach and recruiting. You need to be respectful but not pushy. Following up in 1 day looks desperate, but following up in 5 days is too late. The thought of it gives me a BIG headache and I end up procrastinating a lot. When I finally feel ready, the position has already been filled due to the competitive US job market.

Following up with people, especially recruiters, is so painful! You need to be respectful, not pushy, but also hit the point). Thinking of it gives me a headache and I procrastinate so much. When I was finally ready to send, the position is already filled In the crazy US job market. So I use LLM to directly follow up for me if people don’t respond in three days!

Solution

I built an auto-email follow-up solution with Eugene Chan. If an email you sent to recruiters or outreach hasn’t been responded to for three days, GPT will generate a follow-up draft for you.

Features

1. An Email label to filter recruiters vs non-recruiters

2. For labeled emails that haven’t been replied to for three days, a GPT draft a follow-email based on your prior conversation.

3. The draft sends it to your inbox to remind you to follow up, and you can customize it yourself before sending it.

How we did do it?

The flowchart below describes our entire process. It can be divided into the following three parts.

1. Python as the main logic flow

2. AWS lambda as backend flow

3. Zapier for Google Authentication and Daily Event Triggering

First, we use Python to create the main logic flow, ensuring that we can send the email from our local machine and that the output draft from GPT is correct. Second, we use AWS Lambda to wrap this Python script as our backend. When an event is triggered, AWS Lambda executes the Python process. Lastly, we use Zapier to handle Gmail authentication and set 9 am as the event trigger time for our AWS Lambda function.

Feel free to review our github to learn more about it.

Python as the main logic flow

Step 1: Import libraries

from googleapiclient.discovery import build
import json
import base64
# from lxml import etree
from datetime import datetime, timedelta
import json
import pandas as pd
import openai
import re
import os
from googleapiclient.errors import HttpError
from email.mime.text import MIMEText
from base64 import urlsafe_b64encode
from dotenv import load_dotenv

# FOR AWS
openai.api_key = os.environ['OPENAI_KEY']

Step 2: Fetch all emails and find those with the “Follow-up” label

To test the application locally, you will need to fetch the Gmail API and connect it as a service. This process is included in our app.py code for authentication with Zapier and execution with AWS Lambda. Therefore, we have not included it in this logical flow. However, for local testing, you can follow this tutorial to set up the Gmail API.

def find_all_messages(service, follow_up_label_id):
    # request a list of all the messages
    # We can also pass maxResults to get any number of emails. Like this:
    result = service.users().messages().list(
        userId='me', labelIds=['SENT', follow_up_label_id]).execute()
    messages = result.get('messages')
    return messages

# find the follow up labels
def find_follow_up_label(service):
    try:
        labels_results = service.users().labels().list(userId='me').execute()
        labels = labels_results.get('labels', [])
        print('labels', labels)        # #store all ids with follow-up label
        follow_up_label_id = None
        for label in labels:
            if label['name'] == 'Follow-up':
                follow_up_label_id = label['id']
        return follow_up_label_id
    except Exception as e:
        print(e)
        return None

Step 3: Check if you are the sender of the last thread

Here, we can view all the threads along with their IDs and determine if we are the sender of the most recent thread.

def get_thread_and_id(service, target_text):
    # find the thread for this email
    thread_id = target_text['threadId']
    thread = service.users().threads().get(userId='me', id=thread_id).execute()
    return thread, thread_id

def check_sender_of_last_thread(thread):
    if 'messages' in thread:
        last_message = thread['messages'][-1]
    if 'payload' in last_message:
        payload = last_message['payload']
        headers = payload['headers']
        for header in headers:
            if header['name'] == 'From':
                sender = header['value']
                return sender
    return None

Step 4: Check if the email has not been responded to for 3+ days.

We are only computing the date at this point. After we gather all the necessary information for the next step, we will update the filter in 3 days.

def get_subject_sender_receiver_date(headers, target_text):

    for d in headers:
        if d['name'] == 'Subject':
            subject = d['value']
        if d['name'] == 'From':
            sender = d['value']
        if d['name'] == 'To' or d['name'] == 'Delivered-To':
            receiver = d['value']    internal_date = target_text['internalDate']
    sent_time = datetime.fromtimestamp(
        int(internal_date) / 1000).strftime('%Y-%m-%d %H:%M:%S')
    return subject, sender, receiver, sent_time

Step 5: Gather all the information of those emails you want to follow up

The get_body function decodes encrypted emails to text. The not_replied_emails function gathers all the necessary information for follow-up, including the message ID, subject, thread ID, receiver, sent time, and body.

def get_body(payload):
		'''Find Email body'''
    # The Body of the message is in Encrypted format. So, we have to decode it.
    # Get the data and decode it with base 64 decoder.

    parts = payload.get('parts')[0]
    # non pure text
    if 'multipart' in parts['mimeType']:
        for part in parts['parts']:
            if part['mimeType'] == 'text/plain':
                data = part['body']['data']
    # pure text
    else:
        data = parts['body']['data']    data = data.replace("-", "+").replace("_", "/")
    body = base64.b64decode(data).decode('utf-8')
    return bodydef not_replied_emails(service, follow_up_label_id):
		'''Collect the email that we want to follow up in a data frame'''    messages = find_all_messages(service, follow_up_label_id)
    if (messages is None):
        return None
    # output data storage
    df = pd.DataFrame(columns=['msgId', 'subject', 'thread_id',
                      'sender', 'receiver', 'sent_time', 'body'])
    # iterate through all the messages
    thread_ids = set()    for msg in messages:
        # Get the message from its id
        txt = service.users().messages().get(
            userId='me', id=msg['id']).execute()
        # print("txt['labelIds']", txt['labelIds'])
        target_text = txt
        thread, thread_id = get_thread_and_id(service, target_text)
        last_sender = check_sender_of_last_thread(thread)        # Use try-except to avoid any Errors
        try:
            # Get value of 'payload' from dictionary 'target_text'
            payload = target_text['payload']
            headers = payload['headers']            subject, sender, receiver, sent_time = get_subject_sender_receiver_date(
                headers, target_text)            # check if the email is responded or not by seeing the last sender
            # and we haven't checked this thread yet
            if (last_sender == sender) and (thread_id not in thread_ids):
                thread_ids.add(thread_id)
                body = get_body(payload)                new_row = {'msgId': msg['id'], 'subject': subject, 'thread_id': thread_id, 'sender': sender,
                            'receiver': receiver, 'sent_time': sent_time, 'body': body}
                df.loc[len(df)] = new_row        except Exception as e:
            print('Error Occured: ', e)
            pass    # save as a json data
    df_dict = df.to_dict(orient='records')
    df['sent_time'] = df['sent_time'].astype(str)
    json_data = json.dumps(df_dict)    return json_data

Step 6: Draft a follow-up with GPT using Openai API

We perform data cleaning and generate responses using the Openai API.

def data_cleaning(json_str):
    # Convert the string to a DataFrame
    df = pd.read_json(json_str, orient='records')

    # filter dataframe that has been three days since the email was sent
    df['sent_time'] = pd.to_datetime(df['sent_time'])    # Calculate threshold date (current date - 3 days)
    threshold_date = datetime.now().date() - timedelta(days=3)    # Filter the dataframe based on the condition
    df = df[df['sent_time'].dt.date <= threshold_date]    # Apply the function on the 'email_string' column
    df['receiver'] = df['receiver'].apply(extract_email)    # %%
    # add an empty column to the dataframe
    df['reply'] = ''    return dfdef extract_email(string):
    # Define the regex pattern
    pattern = r'[\\w\\.-]+@[\\w\\.-]+'
    matches = re.findall(pattern, string)
    if matches:
        return matches[0]
    else:
        return ""def openai_prompt_response(clean_body, receiver, subject):    try: 
        prompt = "I wrote this email: " + clean_body + "\\n" + \\
            "Can you write a follow-up email for this email I wrote? I don't need a subject, and the email should be less than 100 words, and every sentence should be complete. The email should include the phrase, follow up, in the email body."
        model = "text-davinci-003"
        response = openai.Completion.create(
            engine=model, prompt=prompt, max_tokens=100)        generated_text = response.choices[0].text
        
        generated_formatted = "This is a reminder to send a follow-up email to " + receiver + ".\\n" "The email you wrote previously has the subject of: " + subject + "\\n\\nHere is the drafted follow up for you 😉\\n"+ generated_text        return generated_formatted
    except Exception as e:
        print('Error Occured: ', e)
        return Nonedef delete_old_thread(input_text):
    pattern = r'On [\\w\\s,]+ at [\\d:\\s]+[APM]+ [\\w\\s]+ <[\\w.-]+@[\\w.-]+>'
    match = re.search(pattern, input_text, re.IGNORECASE)
    if match:
        return input_text[:match.start()]
    else:
        return input_textdef generate_reply(json_str):
    df = data_cleaning(json_str)
    for index, row in df.iterrows():
        msgId = row['msgId']
        subject = row['subject']
        sender = row['sender']
        receiver = row['receiver']
        sent_time = row['sent_time']
        body = row['body']        clean_body = delete_old_thread(body)        response = openai_prompt_response(body, receiver, subject)        df.loc[index, 'reply'] = response
    df['sent_time'] = df['sent_time'].astype(str)
    df_dict = df.to_dict(orient='records')
    openai_json = json.dumps(df_dict)    return openai_json

Step 7: Send the draft email to yourself

We look through all the emails, sending them one by one.

def send_one_email(service, sender, receiver, subject, message):
    # Create an email message
    email = MIMEText(message)
    email['to'] = receiver
    email['from'] = sender
    email['subject'] = subject

    # Encode the email content
    raw_email = urlsafe_b64encode(email.as_bytes()).decode('utf-8')    # Send the email
    try:
        message = service.users().messages().send(
            userId='me', body={'raw': raw_email}).execute()
        print('One email sent successfully!')
        return message
    except HttpError as error:
        print('An error occurred while sending the email:', error)
        return None# -- Main Function for Sending Email -- #
def send_email_to_all(service, openai_json, email_address):
    df = pd.read_json(openai_json, orient='records')
    email_list = []    for i in range(len(df)):
        sender = email_address  
        real_receiver = df['receiver'][i]
        receiver = email_address        subject = '-- Follow up reminder -- ' + \\
            df['subject'][i] + ' -- For ' + real_receiver + ' ---'
        print(subject)
        message = df['reply'][i]
        message = send_one_email(service, sender, receiver, subject, message)
        email_list.append({'id': df['msgId'][i], 'message': message})    return email_list

AWS lambda as backend flow

Auto Follow-up consists of two components: a Zapier custom integration that serves as the interface for authentication and cron job orchestration, and a serverless function that handles the follow-up draft generation and sends reminders.

Our Python logic flow is administered through AWS Lambda. The code we execute on Lambda is referred to as a “Lambda function.” Lambda can automatically trigger functions (such as sending emails) when a specified event occurs (for example, Zapier’s daily checking time). If you are unfamiliar with AWS Lambda, you can check out an introduction here.

Building a serverless API with AWS

AWS offers a serverless application model (SAM) that simplifies the deployment of serverless code as Lambda functions and enables it to be served through APIs with the Amazon API Gateway. AWS’s serverless architecture includes a tool called SAM-CLI, which automates the compilation and deployment of serverless functions to an AWS cluster.

Our script for fetching all email threads that need a reply, generating a follow-up draft, and sending reminders to the user’s email lives in a single Python script that is wrapped as a Lambda function.

The AWS Serverless Application Model helps us create an API endpoint that receives requests and sends responses on behalf of the Lambda function. It ensures that our Lambda function receives the payload from the API request and sends the response back to the user through the API.

All the integration between the Lambda function and API Gateway is specified in the template.yaml file for the AWS Serverless Application Model.

GenerateFollowUpFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.generate_follow_up_handler
      Runtime: python3.9
      Architectures:
        - x86_64
      Events:
        GenerateFollowUp:
          Type: Api # specify function as API will create an API endpoint with
										# AWS API Gateway
          Properties:
            Path: /generate-follow-up
            Method: post

Once the function is set up as an API, an endpoint will be created. This is done when the Serverless Application is deployed with SAM-CLI. All request payloads can be retrieved in the Lambda function using the event['body'] object.

The challenging part is passing the response from the Lambda function through the API Gateway and back to the Zapier custom integration. The API Gateway has a specific request format that needs to be followed. If the format is not followed, the API Gateway will not pass the response back to the client, which in our case is the Zapier custom integration.

{
  "isBase64Encoded": false,
  "statusCode": [[status code]],
  "body": [[string body]],
  "headers": {
    "content-type": "application/json"
  }
}

Zapier for Google Authentication and Daily Event Triggering

Scheduling the reminder every day

To automatically check and generate follow-up reminders every day, we initially built a cron job worker. However, we ended up using Zapier’s custom integration platform. Zapier is a no-code workflow tool that allows people to integrate apps and chain them into automatic workflows with an “If-this-then-that” structure.

While a cron job worker may seem like the most obvious choice, we ultimately chose to build our generation on Zapier for the following reasons:

1. We needed to instantiate and orchestrate a cron job worker for each user (specifically, each Gmail account).

2. We needed to create a UI for users to authenticate with their Gmail account and grant us access to their sent emails.

3. We also needed to store the Gmail tokens for each user and handle token refresh, as users would not log in with Google every day when the cron job runs.

Zapier turned out to be the best solution for running cron jobs for multiple users. It handles authentication and refreshing of Gmail credentials, has a scheduler that runs the cron job for us, and provides an intuitive UI for users to set it up.

How did it work?

To connect these two components, we expose an API from the serverless function to the Zapier custom integration. When the Zapier integration is triggered (e.g. daily, weekly), it calls the API to check for emails that need follow-up. Then, it sends a reminder and a drafted follow-up message from GPT back to the user’s email.

Although this appears to be a normal API flow, there are several challenges in connecting Zapier to the serverless API function (i.e., an AWS Lambda function):

1. Zapier has a hard cap of 30 seconds for timeouts. However, depending on the follow-up items that need to be drafted and reminded, this often exceeds 30 seconds.

2. The AWS Lambda function does not automatically expose itself as an API. It needs to be wrapped in an API gateway to handle all the REST API requests and responses.

Working within Zapier’s hard timeout

Zapier provides an “escape hatch” for custom integrations that may take more than 30 seconds to give a proper response. This method is called performResume. It allows Zapier integration to call an external API server and parse a callback URL for the external server to use to callback once the long operation is completed.

While Zapier is waiting, the workflow remains in a pending state (similar to Promise in JavaScript). When the external server calls back the callback URL, Zapier triggers the performResume function defined for the custom integration to complete the workflow.

In our case, since generating and sending follow-up reminders may take more than 30 seconds, when Zapier first calls our generate follow-up reminder API server, along with other required payload, it generates and passes a callback URL.

Once the generation and sending of reminders are complete, our backend posts a request to the callback URL that Zapier provided and triggers the performResume function, which returns the email reminder sent by our backend

Results

I shared this tool on LinkedIn, helping out 50+ friends and connections! 🎉

When starting a new project, there are usually two directions to choose from: following a tutorial completely or using the tutorial to build what you want. While completely following a tutorial ensures success, building what you want sparks interest. Each direction has a very different learning strategy.

For my first website project, X, I used resources to build my chicken website because the system is simpler, and having fun motivates me for longer. However, for my first React App, since I don’t know much about the system structure, I decided to completely follow a trustworthy resource to understand the basics.

Personal Awareness

Timeline: I decided to finish it in only one day. Most people like to listen and follow the lesson one by one, and hence, most of them give up in the process because it’s dragging. Hence, I set a one-day maximum to do it myself because I know I will lose interest if I take longer.

Learning Resources

To ensure success in one day, I need to have very promising learning resources. Usually, paid online classes are the most promising, but they are boring, and I don’t want to pay. Here are my resource suggestions:

• Main resource: MDN web docs React

• Secondary resource: ReactJS Tutorial for Beginners YouTube

• Additional resource: ChatGPT

I have tried MDN web doc for my first website building, so I know the quality is high. However, reading lots of text is tiring, and I don’t have many concepts about the reaction (components, state, etc.) yet, so I supplement with YouTube as a second resource. The ReactJS Tutorial is better than “spending x hours to finish your first app video” because it chunks concepts, allowing me to grasp concepts quickly and feel motivated to finish watching. The additional resource, ChatGPT, provides more specific terms and coding examples because I don’t know where to put the example code and what they mean as a beginner!

Strategy in the Learning Process

Motivation: Let’s Do One More Section

I usually get quite frustrated or bored when trying to understand a big chunk of information when learning something new. Whenever I feel bored, I tell myself, “Let’s do one more section,” and then take a break or chat. After a certain point when things start to click, I immediately speed up.

Learning Strategy: Follow the Main Resource and Supplement with YouTube for High-Level Concepts. Use GPT to Dig into Specific Details

I will roughly browse through the code examples from the main resource, but the moment I feel tired of reading a concept I don’t understand immediately, I watch several relevant YouTube videos to supplement it and then go back. Usually, in this case, I can roughly understand what is going on at a higher level.

To understand specific implementations in the main resource, I put them into GPT and ask it to explain, so I can connect my high-level concepts with the code examples from my main resource.

Debug: Test and Ask

I use my high-level understanding to generate some hypotheses about bugs. However, I encounter a more complicated one that I don’t know how to handle. My roommate is a front-end engineer, so I ask him about the final bug, and explain the missing concept to me.

My Final Project Output:

View the web app: here

Slay!

From this post, Free LLM/GPT tutorial from Esther, you know that I overwork myself too much, so I cannot type anymore. However, I know creative problem-solving. I still have my eyes and brain, so I came up with a solution: Why not ask people to code for me while I offer an LLM tutorial?

Another practice I want to gain from this experience is “technical planning”. To teach others, I need to make sure everything will work in the end, or else my students will feel terrible. Hence, it will push me to design an “extremely promising technical plan” rather than jumping to the first appealing solution for me, so I can practice being better at project scoping and technical planning.

Initial Setup

• Collaboration time: 3 hours. I set it as 3 hours to test if my idea will work.

• Idea: I decided to try out the simplest idea possible, using our own front end to display GPT.

• Planning: The day before, I spent around 1.5 hours scoping out the project. Some ideas I have including,

1. Flask app with render_template in HTML.

2. Langcorn and my own LLM customization in Python with the display on Vercel

3. Fetch API route -> Display on HTML.

I know option 3 looks easy and intuitive, but it takes me time to get there. I realized that options 1 and 2 might look cooler but with higher risks because the solution isn’t end-to-end. In this process, I keep pushing myself asking, “Can this be easier and more promising?” With my friend as my student in mind, I really push myself to the simplest.

The tutorial

We spent three hours together and another 40 minutes debugging to produce this simple output. Not bad, I would say.

Time Distribution

• 2 hours: Setting up, getting API, and generating output

• 1 hour 40 minutes: Trying streaming code

Advantages & Disadvantages

Here are some advantages and disadvantages of doing this voice control coding.

Advantages:

• Avoid random debugging: Since I cannot touch the code, I need to talk through the instructions out loud and be strategic and targeted when debugging.

• Two people = bigger brain: Even though my partner is not an expert, they still provide great debugging ideas that help us make progress.

• Work distribution: Sometimes, my partner factors the code and I look for solutions. This allows me to focus on the bigger picture rather than getting bogged down in details.

Disadvantages:

• Higher communication cost: Sharing screens and code requires me to point out specific tabs and lines of code, which can be tiring. Students may move to other tabs or do other debugging that might not be right. To mitigate this, I ask him to push to GitHub and explain the code clearly to him. And the processing of exampling code helps me with debugging too.

• Difficulty in tab management: Switching between tabs in the IDE, browser, and other applications can be confusing, and I often need to use voice controls to navigate.

• It’s hard to debug when I’m unsure: Being unable to touch the code makes it slightly difficult to perform more tests while using voice control. That’s why I spent an additional 40 minutes debugging the streaming output on my own.

You might ask: Will it be faster if I just code myself?

I might use the word “maybe”. Without this promising technical plan, I would still be struggling to piece together complex methods. As for debugging, it depends on the situation. Collaborating remotely increases the time it takes to debug due to the high communication cost, but it also reduces the time spent trying out random debugging ideas.

All in all, I find it pretty fun and want to experiment with different styles of pair programming in the future!

Points of failure

1. Sagemaker is way too expensive. I spent $44 for using it for three days, and I cannot afford it.

2. The AI-generated image produced by Sagemaker is of poor quality. Despite using their stable AI model, the output looks terrible.

3. The technical difficulty is quite high. I got stuck generating my images on the endpoints for 2 days because images are very large outputs when represented as RGB numbers. I couldn’t find any tutorial on how to automatically upload them to S3 data storage and send them to the front end as a link.

What do I learn from my failure?

1. Gaining more information at the early stage may be more important than completing a single subproblem. I spent a lot of time working on the (3) endpoint technical difficulty, which caused me to overlook other important aspects, such as (2) the output quality. I was overly excited about trying AWS and had too much trust in their models. However, I should have first tested the AI image generation output. While software engineering involves breaking down problems into subproblems, starting with tracer bullets (proofs that the architecture, prototype, and outputs are compatible and feasible) should still be the primary focus.

2. Deploying machine learning models requires much more attention than just deploying the models themselves. I encountered many extra tasks beyond the deployment process. First, my computer would easily crash while running. Second, I needed to constantly monitor billing. Third, there were many new things to learn about setting up the system, such as dealing with permission problems when requesting quota increases. In order to design an effective system, I need to feel comfortable navigating AWS and understanding its potential constraints.

3. Gain an overall understanding of the system before following the setup steps. Rather than treating AWS like a user manual and following the setup steps step-by-step, like assembling a bike, I should approach it like reading a research paper and browsing through everything to gain an overall understanding of each part. This will help me avoid the fear of the unknown and allow me to more easily unblock myself when issues arise.

4. When I wake up in the morning, I should spend 10 minutes asking myself:

“Am I solving the right problem?”

I usually wake up and start thinking about problems like a teenage boy in a messy love affair. But is that the right problem to pursue at this stage, or should I focus on fixing other parts first? What are the most important problems related to feasibility that I need to address now? I shouldn’t shy away from scary bottleneck problems and potentially call the project quits if it doesn’t pass feasibility and usability tests.

5. Time boxing when trying something new. When experimenting with new technology, there are always unexpected bottlenecks. Timing each task is the best way to determine where I get stuck and how much time I spend on each task. Although this week’s failure is disappointing, I can still see that Tuesday and Wednesday were quite productive, and the bottleneck was the same problem as last Thursday and Friday.

6. Put more effort into technical planning during the initial stages and create hypothesis-driven documentation throughout the process. Although documentation and technical planning may seem like a waste of time, I have learned that they provide significant value in ensuring that you are on the right track. To improve my documentation process, I started using a new system that clearly lays out different MVP versions, proof of concepts, and technical planning. Additionally, I documented all the encountered problems along with their potential problem hypotheses during the development process.

This methodology is helpful when dealing with complex problems because it allows you time to reflect and readjust before pursuing every new idea that comes your way. A simple way to implement this is to imagine that you are reporting your progress to your manager.

7. Remember to take a break. Last week, I overworked myself while thinking about a problem. As a result, my wrist and fingers hurt this week, making it difficult to do anything.

8. Unblocking Your Emotions: I’ve learned that unblocking my emotions is a prerequisite to unblocking problems in the project. For instance, I was demotivated when I learned how expensive SageMaker was after trying it out on the first day. Should I stop the project because it’s not feasible?

To unblock my motivation issue, I created a brainstorming page called

I am only willing to tackle the technical challenges in my path when I can unblock my emotions. Although I may give up on this project for now, I am confident that I will resolve it at some point in my life

Although it was a disappointing week, I didn’t let it defeat me. Instead, it encouraged me to learn about the entire machine-learning production process. To do so, I started reading “Designing Machine Learning Systems: An Iterative Process for Production-Ready Applications” by Chip Huyen. Without this pain, I wouldn’t have picked up a technical book, and without this experience, I wouldn’t understand all the terms and related to the processes in the book either.