My first large project after entering Informatics
Kicau was our major project for Algorithms and Data Structures, completed in my third semester. At ITB, the first two semesters are a common foundation filled with mathematics, physics, chemistry, and general engineering. This was my first semester inside the Informatics major and my first large program written entirely in C.
It became my first taste of advanced data structure programming. Stacks, linked lists, queues, graphs, trees, and dynamic arrays were no longer separate exercises. They all had to coexist inside one working social network.
The course assistants specified almost every feature, from posts and drafts to friendships, replies, threads, and persistence. What they did not give us was the correct structure for each one.
Our job was to translate product behavior into data structure decisions. Draft history naturally suggested a stack. Relationships became a graph. Pending requests needed a queue. Nested replies required a tree. The project taught me that selecting a structure is part of designing the feature itself.
Kicau, BurBir, and a terminal Twitter
Kicau was our team name and referred to the sound of a tweet. Inside the application, we called the social network BurBir, short for burung biru, after Twitter’s old blue bird identity.
The result was a complete Twitter-like experience inside a terminal. Users could manage profiles, form friendships, publish posts, save drafts, create threads, write nested replies, and restore the network from files.
My clearest feature ownership was the draft stack, but my role grew far beyond one module. I helped manage what the team needed to do, debugged across features, integrated other people’s work, and built much of the save and load mechanism.
Persistence forced me to understand how every structure represented its state. I could not save a reply tree, friendship graph, thread list, or draft stack correctly without understanding how it worked in memory and how it needed to be reconstructed later. The repository history also confirms my work across draft loading, users, posts, replies, integration, and the final Makefile.
Building without the conveniences we knew
The assignment required us to work through primitive character and word machines instead of relying on convenient input and parsing functions. That made saving and loading considerably harder.
I also created the Makefile while barely understanding what a Makefile was. At the time, even teaching the compiler how to assemble dozens of C modules felt like its own project. It gave me an early lesson that build tooling becomes part of the engineering once a codebase grows beyond a few files.
The reply tree was the hardest structure to integrate. Stacks and queues already have everyday metaphors, but trees were unfamiliar to most of us. Nested replies had to be inserted, searched, and printed at the correct indentation while pointers connected every branch.
When the indentation finally appeared correctly, it was deeply satisfying. Then the program crashed with a segmentation fault because we had missed a null-pointer check somewhere in the traversal. That sequence captures the project well: a visible breakthrough immediately followed by C reminding us that one invalid pointer could undo everything.
Integration was painful and worth it
Combining independently developed abstract data types was, honestly, a pain. We encountered more segmentation faults than I could count, and save/load made every mismatch between modules visible.
But it was also challenging in a satisfying way. Our team worked well together, and once the complete application could load its state, execute its features, print nested replies, and save everything again, the individual structures finally felt like one system.
After submitting the project, we went out for nasi goreng. It was a simple celebration after weeks of pointers, integration, parsing, and debugging.
The lasting lesson was that these “advanced” data structures have real use cases. A stack, tree, graph, or queue is not advanced because it is complicated. It becomes useful when its behavior matches the problem naturally. Kicau was the project that allowed me to see those matches inside one complete application.
What stayed with me
- The feature often tells you which data structure it needs.
- Persistence forces you to understand the whole system.
- A missing null check can humble an entire reply tree.
- Some submissions deserve nasi goreng.
Run it locally
Clone the source repository or download the project ZIP, then run these commands from the project folder.
Explore the complete project
Download the source, assets, and included documentation as a ZIP archive.
Build and run
$ make clean
$ make
$ ./start.exe
# committed object files are Windows builds, so make clean first
Use it
# every input ends with a semicolon. Try:
# Configs; MASUK; Agil; passAgil; KICAUAN;
# BALAS 57 -1; then BALASAN 57; to see the reply tree
# DAFTAR_TEMAN Agil; BUAT_DRAF; UTAS 57;





