Code without hands
Creative voice coding solution with students
Problem
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,
Flask app with render_template in HTML.
Langcorn and my own LLM customization in Python with the display on Vercel
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!