owc blog 3

 Blog Post 3: When I Don’t Understand Something


Last semester, I was working on a group project and we had to use Git. I was already familiar with Git, but to be honest, I didn’t really understand how it worked. Everyone around me seemed to be so uptight about Git push, Git pull, and rebase. I was nervous; they would think I didn’t belong there if I asked a question.


So I kept quiet. I copied what everyone else was doing and hoped nothing would go wrong.


Of course, something did.


After I tried to rebase something, my commits disappeared. I panicked. That night, I said to myself, “Okay, I need to learn what I’m doing.” I created a test folder and started running simple Git commands, reading what each one did. I watched videos, read a few blog posts, and even asked questions like “What does rebase actually do?” on ChatGPT.


Slowly, things started to make sense. I learned that Git is like a big snapshot timeline, and rebasing essentially rewrites the timeline.  I also learned about Git Reflog, which allowed me to revert incomplete commits. It felt like magic.


But more important than learning Git was this lesson: Pretending not to know doesn’t work. When I started asking questions, I realized that others don’t know everything either. Some of my colleagues even said, “Wow, I was just guessing that command.”


Now, I feel more comfortable saying, “I don’t know,” or “Can you show me?” It’s really refreshing. And it helps me really understand things, instead of just copying the steps.


This experience reminded me that being an engineer isn’t about knowing everything. It’s about staying curious, asking questions, and learning step by step.


Thoughts on AI


What prompts have you used regarding AI?

I asked ChatGPT to help me rewrite my blog post in a simpler, more human tone. I also asked for help making the structure more fluid and personal.


What part of the AI ​​results clarified or inspired your blog post?

 ChatGPT helped me tell my Git story better: I started with the problem, showed my feelings, and explained how I learned. It also reminded me to focus on honesty rather than technical details.


What did you change or remove from the AI’s suggestions?

I removed parts that sounded too formal or robotic. I wanted the text to sound like me, not like a textbook. I also added more information about how I felt about the situation.


How much of your story is entirely your own?

The Git rebase error, my panic, how I experimented with a test folder, and what I learned from it all came from my own experiences.

Yorumlar

Yorum Gönder

Bu blogdaki popüler yayınlar

owc blog

 Last summer, while working in the US with the Work and Travel program, I sent my shift change request to my manager via Slack: “Can I start my shift a little later tomorrow due to a personal situation?” Although the message seemed polite and explanatory to me, the short and distant “Noted” response I received bothered me. When we spoke face to face the next day, my manager said that the message was perceived as an order, not a request. At that moment, I deeply understood McLuhan’s words, “The medium is the message,” because if the same message were delivered face to face or on a different platform like email, my tone and intention would have been much clearer. A similar situation occurred during a misunderstanding I experienced on Instagram: The sentence I shared, “It’s been a crazy trip,” was a nostalgic and humorous farewell, but some of my friends thought I was sending a depressing message. However, the same content could have made a much more accurate impression if it were sup...
Devamı

owc blog 2

 hat Code Review Changed Me During my senior year of college, I decided to contribute to an open source project. I picked a small “problem” and submitted my solution as a pull request (PR) on GitHub. My code worked, passed the tests, and honestly, I thought I did a good job. But the first comment that came gave me pause: “Your function is great, but it’s a bit too much work. Can you consider reducing it to a single responsibility?” This comment seemed simple, but I realized at that moment: It’s not enough for code to just work. It also needs to be readable, maintainable, and understandable to others. Later comments pointed out that variable names were vague, I was skipping some test cases, and I lacked modularity. The comments were not destructive, but they were clear. The criticisms were open-ended questions: “Why was this part done this way?” “Have you considered this approach as an alternative?” I was initially discouraged, but when I went back and reviewed my code again, I agre...
Devamı