Working as a teaching assistant for Application of Advanced Programming Language, Section 011300 at Sejong University gave me a completely different view of programming education.
As a student, I usually think about my own assignments, my own grades, and my own understanding. As a teaching assistant, I had to think about the whole class: how students receive assignments, how they submit code, what mistakes they commonly make, how technical problems block them, and how course staff can make the workflow more organized.
This experience taught me that programming education is not only about writing code. It is also about communication, structure, tooling, documentation, and support.
My Role
My TA work focused on supporting the programming-course workflow. A major part of that work involved GitHub Classroom, student repositories, assignment submissions, and technical troubleshooting.
The role included:
- helping manage assignment workflows;
- supporting students with Git and GitHub issues;
- helping students understand repository submission rules;
- checking whether submissions followed the expected structure;
- assisting with course communication;
- working with the professor to support class operations.
This was not only a technical role. It required responsibility and careful communication because students depended on the workflow to submit their assignments properly.
GitHub Classroom and Assignment Workflow
One of the biggest parts of the experience was GitHub Classroom. GitHub Classroom is useful because it gives each student their own repository and makes assignment submission more trackable. However, for many students, GitHub itself can become a problem.
Some students struggle with:
- accepting the assignment link;
- cloning the repository;
- pushing to the correct branch;
- understanding repository structure;
- fixing empty repositories;
- dealing with authentication or permission issues;
- knowing whether their submission was actually uploaded.
This showed me that a tool can be powerful but still difficult if students do not understand the workflow. A good system is not only technically correct; it must also be understandable for the users.
What Students Actually Struggle With
Before working as a TA, I thought most programming problems came from logic or syntax. Those are still common, but I realized that many problems are workflow problems.
Students may know some programming but still fail to submit correctly because they do not understand Git, branches, repositories, or file structure. Others may complete the code but forget to push it. Some students may upload the wrong file or work outside the required template.
That taught me an important lesson:
“In real technical work, the system around the code matters almost as much as the code itself.”
Programming education needs clear instructions, repeatable workflows, and simple rules. Otherwise, students waste time fighting the process instead of learning the actual topic.
Working with the Professor
Working directly with the course professor helped me understand the responsibility behind course support. A professor has to think about the learning goals, assignment design, fairness, deadlines, grading, and class-level organization. A TA helps connect that plan with the students’ practical experience.
That means the TA role is not just answering random questions. It is part of the course system.
A good TA needs to be:
- technically accurate;
- clear in communication;
- patient with repeated questions;
- careful with student data;
- organized with assignment information;
- consistent with course rules.
This experience made me more aware of how much invisible work exists behind a programming course.
Technical Lessons
This role also improved my own technical mindset. Supporting students forced me to explain things clearly. If I could not explain a GitHub issue simply, then I probably did not understand it deeply enough.
I also became more aware of practical development habits:
- repository structure should be clear;
- submission instructions should be specific;
- code should run before submission;
- commit and push behavior should be checked;
- documentation reduces repeated confusion;
- screenshots and error messages make debugging faster.
These are basic habits, but they matter. They are the difference between messy work and organized engineering.
Communication Lessons
One of the most important lessons was communication. Technical knowledge alone is not enough. If students misunderstand the instruction, the workflow fails. If the announcement is vague, students ask the same question repeatedly. If the submission rule is unclear, many students make the same mistake.
Good communication in a programming course should be:
- direct;
- specific;
- short enough to follow;
- strict about important rules;
- clear about what students must submit;
- clear about what happens if something goes wrong.
This is also true in software engineering. A good system needs good documentation and communication, not only good code.
How This Changed My Perspective
This experience changed how I think about teaching, tools, and software systems.
I learned that technical systems are used by people with different levels of skill. A workflow that feels obvious to one person may be confusing to another. If many users make the same mistake, the problem may not only be the users. The system or instruction may also be unclear.
That lesson applies directly to my own projects. When I build platforms like SejongPulse, I need to think about how real users will interact with the system. If users get confused, the product is not finished, even if the code works.
Key Takeaways
- programming education needs structure, not only lectures;
- GitHub Classroom is powerful but requires clear guidance;
- many student problems are workflow problems, not only coding problems;
- technical communication must be precise;
- documentation saves time;
- supporting others improves your own understanding;
- real systems must be designed for real users, not only for developers.
Final Reflection
My teaching assistant experience for Application of Advanced Programming Language, Section 011300 was one of the most practical parts of my university life. It helped me understand programming from both sides: as a student learning the material and as a TA supporting others through the process.
It also made me more serious about building organized systems. Whether it is a course workflow, a GitHub Classroom setup, or a full-stack platform, the same principle applies:
“Good technical work is not only about making something work. It is about making it understandable, usable, and reliable for other people.”
That is the biggest lesson I took from this experience.