As an intern for OpenBraille

 When I think about OpenBraille, I do not think of myself as a finished developer standing proudly inside the IT world. I think of myself as an intern in the widest and most metaphorical sense of the word. I was not hired by some famous company. I did not arrive with a polished résumé, years of coding experience, or a portfolio full of products. I had never worked in frontend, backend, DevOps, or any of the recognized lanes that people usually mention when they speak of careers in technology. I was a newcomer, someone standing at the edge of an unfamiliar continent, trying to learn the language while already walking among those who seemed more natural there.

That is why the OpenBraille project remains meaningful to me beyond its technical form. It was not only a project. It was a doorway.

When I first took part in the project as a member of the hardware team, I knew my limitations clearly. I was not joining as a seasoned engineer. I did not have professional development experience. I had no mastery over software architecture or product pipelines. If someone had asked me then to lead frontend development, design a backend API, build cloud infrastructure, or maintain DevOps workflows, I would have had little to offer. That truth made me anxious, but it also made the acceptance more meaningful.

The team leader, Changhoon Yoon, accepted me into the project. I have often wondered why. It certainly was not because I had overwhelming technical credentials. I suspect he thought positively of me for other reasons. Perhaps he liked the way I thought. Perhaps he respected my energy. Perhaps my classroom stories stayed in his mind. Perhaps he sensed that teams need more than narrow technical output alone. Or perhaps he simply gave me a chance before I had fully earned one.

That kind of chance matters in life.

Before ChatBraille evolved and departed into the next phase, Changhoon Yoon also took part in a book club called Five Books. That detail may sound small to outsiders, but it mattered to me because I come from a world where books, ideas, and discussion were serious things. During my years at Gyeong-In National University of Education, I managed a book club for years. I know the atmosphere of reading groups well: the subtle hierarchy of who thinks clearly, who speaks honestly, who can synthesize ideas, who merely repeats phrases, who can move discussion deeper, who cannot. In that world, I had confidence.

I am really good at commenting on books. I know how to draw meaning from texts, how to connect ideas to life, how to challenge shallow interpretations without killing the spirit of conversation. In a reading group, influence often belongs not to the loudest voice but to the one who can illuminate what others sensed but could not yet articulate. I had learned that skill over years.

So perhaps when technical credentials were thin, other forms of credibility mattered. In a team, intelligence does not always arrive wearing the same uniform. Some people bring code. Some bring discipline. Some bring imagination. Some bring communication. Some bring morale. Some bring the ability to interpret human meaning behind technical tasks. I like to think that even before I had much technical proof, I carried something useful into the room.

That may be why I was accepted as a member of the embedded team for OpenBraille.

Then reality began.

If I was going to participate honestly, I had to study Arduino. There was no escape through rhetoric. A project involving hardware, microcontrollers, sensors, and physical interaction does not care how eloquently someone speaks about books. Components either work or do not work. Connections are correct or incorrect. Signals arrive or fail. Circuits respond or remain silent.

That confrontation with reality was healthy for me.

The repository structure itself reveals the shape of the project. It centers on firmware and example code. Inside the firmware section are BLE modules: one advertiser, one scanner. That means the project uses Bluetooth Low Energy as a way for devices to discover and communicate with each other efficiently. One ESP32 device broadcasts identity. Another scans for that identity and measures signal strength. From the README, the system uses RSSI values to estimate proximity. In simple terms, the device can sense nearness.

That is a beautiful idea when linked to accessibility.

For a blind user, proximity awareness matters. Space is not abstract. Distance is practical reality. If a system can help detect what is near, identify devices, or provide spatial cues, it can reduce uncertainty. The project also includes ultrasonic sensing through HC-SR04 hardware. That means environmental obstacles can be detected through distance measurement. The repository describes real-time feedback and one-second measurement cycles.

When I read this, I do not merely see electronics. I see a philosophy: technology should give perception where perception is limited.

There is also an IoT door system in the example code. That suggests remote access control, connected environments, and the possibility that accessibility tools can extend into everyday infrastructure. A blind person’s challenge is not only reading text. It includes navigating spaces, controlling environments, interacting with doors, devices, and systems that others often take for granted. OpenBraille appears to understand that accessibility is ecological, not narrow.

The architecture listed in the repository uses ESP32 microcontrollers and WeMos D1 Mini boards. Those choices make sense. They are affordable, flexible, common in maker culture, and suitable for experimentation. That alone says something important. This was not a vanity project built on expensive exclusive hardware. It was grounded in practical boards that students and independent builders can learn from.

I admire that spirit.

The development plan in the repository mentions future goals: braille encoding and decoding algorithms, multi-device communication protocols, mobile app integration, and enhanced spatial mapping. That means the project was not limited to one demo. It imagined growth into a fuller platform.

And that is where the meaning of “OpenBraille” becomes richer.

OpenBraille is not merely “braille plus electronics.” It is an attempt to rethink braille systems in a multilingual, connected, AI-influenced era. If language can be translated intelligently, then braille interaction need not remain trapped in one linguistic environment. If mobile integration develops, the system can connect to broader digital life. If spatial mapping improves, it can become part of navigation. If devices communicate together, it becomes an ecosystem rather than a gadget.

That is ambitious thinking.

As for me, I entered this world not as an engineer who had everything to teach, but as an intern who had much to learn.

I had to learn what embedded systems really mean. In ordinary life, software can feel abstract: windows on screens, websites, apps, code running somewhere unseen. Embedded systems are different. They live inside objects. They touch sensors, pins, power limits, signals, boards, timing constraints. They remind you that intelligence ultimately meets matter.

This was humbling.

When a person with a humanities and education background enters such a world, he quickly learns that concepts alone are not enough. Precision matters. Practical patience matters. Troubleshooting matters. Reading documentation matters. Learning from people who know more matters.

Yet I also learned that technical spaces are still human spaces.

A project is never only components and repositories. It is trust, motivation, leadership, temperament, generosity, and shared purpose. Someone decides to include a newcomer. Someone explains things without contempt. Someone keeps morale alive when progress is slow. Someone imagines a meaningful mission large enough to gather people together.

OpenBraille had that human dimension.

The mission itself helped me endure my insecurity. If I had joined a random project with no moral center, anxiety might have overwhelmed me. But accessibility changes the emotional structure of work. When the aim is to help blind people communicate, navigate, and live more independently, even small contributions feel dignified.

I think that is one reason I stayed engaged despite my lack of experience. I was not merely trying to impress a recruiter or decorate a résumé. I was participating in something humane.

Still, the insecurity remained real.

I knew I lacked what many others in IT consider basic identity markers. No development job experience. No long GitHub history. No famous stack expertise. No obvious specialization. Sometimes I felt like an accidental guest at a table where everyone else belonged more naturally.

But then I would remember something important: every expert was once a beginner whose ignorance was still visible.

The difference between the permanent outsider and the future insider is often not talent alone, but whether the person stays in the room long enough to transform.

OpenBraille gave me a room to stay in.

It also taught me something about independence. I often dream of becoming more independent through technology—less dependent on rigid institutions, more able to create value through skill and systems. But independence is not romantic freedom floating in the air. It is built from competence, trustworthiness, and accumulated capability.

An embedded project teaches that brutally. If you cannot learn, adapt, and contribute, slogans about freedom mean nothing. If you can learn steadily, then even small projects become bricks in a future foundation.

In that sense, I really was an intern for OpenBraille.

Not an intern by contract, but by posture.

I arrived to learn.

I arrived aware of my weakness.

I arrived hoping that contribution might someday catch up with aspiration.

I arrived carrying strange assets from another life: book club leadership, teaching experience, classroom-state imagination, rhetorical confidence, social reading of people, and stubbornness.

Those things do not replace code. But they are not worthless either.

In fact, I suspect the modern technical world increasingly needs hybrid people—those who can connect engineering with education, systems with society, tools with meaning. Pure specialists matter greatly, but teams also need people who understand users, communication, narrative, motivation, and the moral stakes of what is being built.

Perhaps that is where I belong.

When I think of Changhoon Yoon accepting me, I feel gratitude. Sometimes one person’s willingness to include an unproven newcomer changes the course of another person’s self-understanding. He may have simply chosen a team member. But from my side, it felt like recognition that I might still have a place in this new world.

And when I think of the book club connection, I smile. Life is rarely linear. A person may imagine that literature and embedded hardware belong to separate universes. Yet human networks do not obey neat categories. A serious discussion about books may someday open a door into a technical project. A teacher’s ability to comment insightfully on texts may help establish trust among builders. Civilization is more intertwined than official résumés suggest.

That gives me hope.

Because I am still unfinished.

I am still not a veteran of the IT field. I am still learning fundamentals many others learned earlier. I still have anxieties about portfolio, employability, and legitimacy. I still sometimes feel like a traveler crossing into a country where my accent is obvious.

But OpenBraille proved something to me.

I can enter the room.

I can join builders.

I can learn hardware after coming from books.

I can participate in work that touches real human need.

I can be more than a spectator of technological change.

The repository may look modest to outsiders: one commit history, BLE modules, sensor examples, a README, future plans. But to me it contains biography. It records a season when I stopped treating technology as distant spectacle and began touching its working surfaces.

Perhaps one day I will have broader experience—frontend, backend, DevOps, products, deployments, teams, systems at scale. Perhaps one day I will look back and smile at how inexperienced I was.

But even if that day comes, I think I will still value this phase most tenderly.