Forem: Yodit Weldegeorgise

𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝗦𝘁𝗮𝗿𝘁𝗲𝗱 𝘄𝗶𝘁𝗵 𝗔𝗜 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴

Yodit Weldegeorgise — Wed, 01 Apr 2026 05:51:53 +0000

Recently, I got a recommendation for the book AI Engineering: Building Applications with Foundation Models by Chip Huyen, and I decided to give it a try.

I finished Chapter 1, and I really loved it. The examples, use cases, and overall flow make the concepts easy to understand.

To complement that, I also started preparing for the AWS AI Practitioner certification. My goal is to not only understand the concepts but also see how they apply in real world systems. I did not want to just read about AI, I wanted to connect it to how things are actually built and used.

𝗔 𝗠𝗼𝗿𝗲 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝗩𝗶𝗲𝘄 𝗼𝗳 𝗔𝗜 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴

One idea that stood out to me is how AI engineering is evolving in practice.

While traditional machine learning focuses heavily on model development and training, AI engineering today is increasingly centered around how we use and adapt existing foundation models in real world applications.

This shift moves the focus from building models to designing systems. It is less about training from scratch and more about how effectively we can guide models, provide the right context, and evaluate their outputs.

What I found particularly valuable is how this perspective aligns closely with software engineering principles. The emphasis is not just on the model itself, but on how it fits into a larger system and delivers value in a practical setting.

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗵𝗼𝘄 𝗺𝗼𝗱𝗲𝗹𝘀 𝗽𝗿𝗼𝗰𝗲𝘀𝘀 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲

One concept that stood out to me was how models process text.

Instead of reading full words the way we do, they break text into smaller pieces called tokens. For example, a word like “cooking” can be split into “cook” and “ing.” Even a completely new or made up word can still be interpreted because the model looks at its smaller components.

This approach allows models to capture meaning while remaining efficient, and it helps them handle words they have not explicitly seen before

It also explains why interactions with these models feel flexible and natural.

𝗛𝗼𝘄 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗲𝘀 𝗮𝗿𝗲 𝗴𝗲𝗻𝗲𝗿𝗮𝘁𝗲𝗱

Another important idea is how these models generate responses.

They do not reason in the same structured way humans do. Instead, they predict what comes next based on the sequence of tokens they have already seen. Each response is built incrementally, one step at a time, based on learned patterns.

When viewed this way, it becomes clearer why interactions feel conversational. The model is continuously predicting the next most likely piece of text in a sequence

𝗙𝗿𝗼𝗺 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗺𝗼𝗱𝗲𝗹𝘀 𝘁𝗼 𝗮𝗱𝗮𝗽𝘁𝗶𝗻𝗴 𝘁𝗵𝗲𝗺

A key takeaway for me is that building AI applications today does not always require training models from scratch.

Instead, much of the focus is on adapting existing models. This can be done by providing better instructions, supplying additional context through external data, or refining the model for specific use cases.

This shift lowers the barrier to entry and enables faster experimentation. It allows developers to focus more on solving problems and less on the complexity of model training

It feels great to understand the nuances behind what we use every day. I use LLMs on a daily basis, and getting to learn what is happening underneath has been fascinating so far.

From a software engineering perspective, this shift is particularly meaningful. It reinforces the importance of building, iterating, and integrating systems rather than waiting for complete theoretical understanding.

It also highlights that many core engineering skills remain relevant. Designing systems, thinking about user experience, and building reliable applications continue to be central, even as the tools evolve.

At this stage, I am continuing the book while also preparing for the AWS AI Practitioner certification. I want to build a solid foundation while staying grounded in practical application.

In parallel, I am exploring ways to apply these concepts in smaller projects. Even simple implementations can provide valuable insight into how these systems behave and how they can be improved.

This combination of learning and building feels like the most effective way to deepen my understanding.

AI is no longer just about models, it is about systems.

Understanding how to use, guide, and integrate those systems is what makes the difference.

What is vCon and Why Should We Care?

Yodit Weldegeorgise — Sun, 29 Mar 2026 04:52:47 +0000

This week, I came across something at Spring vCon 2026 that completely changed how I think about conversations in the digital world. It didn’t just stay theoretical for me: I actually experienced a version of this shift myself.

Recently, I went through two AI-driven interview sessions:

A 25-minute video interview
A 15-minute voice interview

At first, it felt unusual to speak to an AI in such a structured, recorded way. But over time, it started to feel normal, almost like a regular part of the hiring process. It even became fun when the AI asked for clarifications and follow-up questions.

Later, when I shared this experience in a tech Discord server, the conversation immediately shifted to a critical concern: 𝐏𝐞𝐫𝐬𝐨𝐧𝐚𝐥 𝐃𝐚𝐭𝐚.

"I’m not sure what their terms and conditions are. There is no disclaimer whatsoever, and I’m not sure if they are regulated or not."

That discussion made everything click. Because I had just lived through exactly what vCon is trying to solve.

𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬 𝐚𝐫𝐞 𝐛𝐞𝐜𝐨𝐦𝐢𝐧𝐠 𝐝𝐚𝐭𝐚

I’ve always thought of conversations as temporary, like calls, meetings, or chats that happen and then get stored somewhere as recordings or transcripts.

But between AI interviews and this discussion, I started seeing something different:

𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬 𝐚𝐫𝐞 𝐧𝐨𝐭 𝐣𝐮𝐬𝐭 𝐦𝐨𝐦𝐞𝐧𝐭𝐬. 𝐓𝐡𝐞𝐲 𝐚𝐫𝐞 𝐝𝐚𝐭𝐚 𝐚𝐬𝐬𝐞𝐭𝐬.

And we are generating more of them than we can properly organize or reuse.

𝐒𝐨 𝐰𝐡𝐚𝐭 𝐞𝐱𝐚𝐜𝐭𝐥𝐲 𝐢𝐬 𝐯𝐂𝐨𝐧?

𝐯𝐂𝐨𝐧 (𝐕𝐨𝐢𝐜𝐞 𝐚𝐧𝐝 𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧 𝐨𝐧 𝐭𝐡𝐞 𝐍𝐞𝐭) is an emerging open standard designed to represent conversations in a structured, machine-readable format.

At its core, vCon defines a way to package everything that makes up a conversation into one portable container. Think of it as a standardized 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫 𝐟𝐨𝐫𝐦𝐚𝐭 𝐟𝐨𝐫 𝐜𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬, similar to how PDF standardized documents or how MP4 standardized video.

Instead of scattered pieces, vCon brings it all together:

𝐌𝐞𝐝𝐢𝐚: Audio and video recordings
𝐀𝐧𝐚𝐥𝐲𝐬𝐢𝐬: Full transcripts and AI-generated summaries
𝐂𝐨𝐧𝐭𝐞𝐱𝐭: Participants, identities, and timestamps
𝐌𝐞𝐭𝐚𝐝𝐚𝐭𝐚: Action items, tags, and behavioral signals

𝐕𝐢𝐬𝐮𝐚𝐥𝐢𝐳𝐢𝐧𝐠 𝐭𝐡𝐞 𝐯𝐂𝐨𝐧 𝐞𝐜𝐨𝐬𝐲𝐬𝐭𝐞𝐦

Image taken from Jill Blankenship

To really understand how this works, it’s helpful to look at the flow of data. The "Trusted Source" model illustrates how these interactions move through a secure pipeline:

𝐓𝐡𝐞 𝐒𝐨𝐮𝐫𝐜𝐞 (𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 𝐈𝐧𝐭𝐞𝐫𝐚𝐜𝐭𝐢𝐨𝐧𝐬): On the left, we see the input phase where Voice Calls, Chat, Email, Messaging, and Video are captured.
𝐯𝐂𝐨𝐧: 𝐓𝐡𝐞 𝐓𝐫𝐮𝐬𝐭𝐞𝐝 𝐒𝐨𝐮𝐫𝐜𝐞 (𝐂𝐞𝐧𝐭𝐫𝐚𝐥 𝐁𝐥𝐨𝐜𝐤): This purple box in the middle is the vCon Container. It acts as the "Single source of truth" by ensuring every conversation is Complete & Accurate, recorded in a Standardized Format, and kept Secure & Governed.

𝐓𝐡𝐞 𝐂𝐨𝐧𝐬𝐮𝐦𝐞𝐫𝐬 (𝐔𝐬𝐞𝐝 & 𝐓𝐫𝐮𝐬𝐭𝐞𝐝 𝐁𝐲): On the right, the green arrows show how this trusted data flows into AI & Analytics, Automation, Quality & Compliance, Business Intelligence, and Customer Experience tools.

𝐓𝐡𝐞 𝐑𝐢𝐬𝐞 𝐨𝐟 𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐚𝐥 𝐈𝐧𝐟𝐫𝐚𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞

At Spring vCon 2026, one theme kept coming up repeatedly:
𝐖𝐞 𝐚𝐫𝐞 𝐠𝐞𝐧𝐞𝐫𝐚𝐭𝐢𝐧𝐠 𝐦𝐨𝐫𝐞 𝐜𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐚𝐥 𝐝𝐚𝐭𝐚 𝐭𝐡𝐚𝐧 𝐞𝐯𝐞𝐫 𝐛𝐞𝐟𝐨𝐫𝐞, 𝐛𝐮𝐭 𝐰𝐞 𝐜𝐚𝐧𝐧𝐨𝐭 𝐩𝐫𝐨𝐩𝐞𝐫𝐥𝐲 𝐮𝐬𝐞 𝐢𝐭.

According to industry research from 𝐆𝐚𝐫𝐭𝐧𝐞𝐫, over 80% 𝐨𝐟 𝐞𝐧𝐭𝐞𝐫𝐩𝐫𝐢𝐬𝐞 𝐝𝐚𝐭𝐚 𝐢𝐬 𝐮𝐧𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞𝐝, and conversations are the 𝐩𝐫𝐢𝐦𝐚𝐫𝐲 𝐬𝐨𝐮𝐫𝐜𝐞 of this information. Yet most of this data is:

Hard to search
Hard to reuse
Locked inside 𝐢𝐬𝐨𝐥𝐚𝐭𝐞𝐝 𝐬𝐲𝐬𝐭𝐞𝐦𝐬
Difficult to analyze consistently at scale

𝐏𝐫𝐢𝐯𝐚𝐜𝐲 𝐛𝐲 𝐃𝐞𝐬𝐢𝐠𝐧: 𝐏𝐫𝐨𝐭𝐞𝐜𝐭𝐢𝐧𝐠 𝐭𝐡𝐞 𝐏𝐞𝐫𝐬𝐨𝐧

When the discussion on Discord turned to privacy, it highlighted a major gap. 𝐒𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞 𝐰𝐢𝐭𝐡𝐨𝐮𝐭 𝐭𝐫𝐚𝐧𝐬𝐩𝐚𝐫𝐞𝐧𝐜𝐲 𝐢𝐬 𝐧𝐨𝐭 𝐞𝐧𝐨𝐮𝐠𝐡. By standardizing the format, we can also standardize the 𝐠𝐨𝐯𝐞𝐫𝐧𝐚𝐧𝐜𝐞.

This means that privacy controls and data retention policies are baked into the file itself. Crucially, a vCon container is designed to be 𝐬𝐭𝐨𝐫𝐞𝐝 𝐢𝐧 𝐚 𝐰𝐚𝐲 𝐭𝐡𝐚𝐭 𝐚𝐯𝐨𝐢𝐝𝐬 𝐞𝐱𝐩𝐨𝐬𝐢𝐧𝐠 𝐩𝐞𝐨𝐩𝐥𝐞'𝐬 𝐩𝐫𝐢𝐯𝐚𝐜𝐲. It allows systems to analyze the context of a conversation for business intelligence while keeping the identity of the person secure.

This architecture ensures that permissions travel with the data, rather than being 𝐥𝐨𝐬𝐭 𝐢𝐧 𝐭𝐡𝐞 𝐟𝐢𝐧𝐞 𝐩𝐫𝐢𝐧𝐭 𝐨𝐟 𝐚 𝐦𝐚𝐬𝐬𝐢𝐯𝐞 𝐥𝐞𝐠𝐚𝐥 𝐚𝐠𝐫𝐞𝐞𝐦𝐞𝐧𝐭.

𝐖𝐡𝐲 𝐭𝐡𝐢𝐬 𝐦𝐚𝐭𝐭𝐞𝐫𝐬

Right now, conversations are trapped. A sales call lives in a CRM, a support call lives in a contact center tool, and a meeting lives in a video platform. They don’t connect.

vCon introduces a shared language for all of this. It turns conversations into something you can:

Store consistently
Search intelligently
Analyze at scale
Move across platforms

We are moving from "𝐋𝐞𝐭'𝐬 𝐫𝐞𝐜𝐨𝐫𝐝 𝐜𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬" to "𝐋𝐞𝐭'𝐬 𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞 𝐜𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬 𝐬𝐨 𝐭𝐡𝐞𝐲 𝐜𝐚𝐧 𝐛𝐞 𝐫𝐞𝐮𝐬𝐞𝐝, 𝐚𝐧𝐚𝐥𝐲𝐳𝐞𝐝, 𝐚𝐧𝐝 𝐮𝐧𝐝𝐞𝐫𝐬𝐭𝐨𝐨𝐝." That shift is powerful because once conversations become structured data, they stop being temporary: they become infrastructure.

𝐑𝐞𝐬𝐞𝐚𝐫𝐜𝐡 & 𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐋𝐢𝐧𝐤𝐬

𝐆𝐚𝐫𝐭𝐧𝐞𝐫 𝐑𝐞𝐬𝐞𝐚𝐫𝐜𝐡 𝐨𝐧 𝐔𝐧𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞𝐝 𝐃𝐚𝐭𝐚: https://www.forcepoint.com/blog/insights/gartner-2024-world-class-security-unstructured-data-report

𝐎𝐟𝐟𝐢𝐜𝐢𝐚𝐥 𝐈𝐄𝐓𝐅 𝐯𝐂𝐨𝐧 𝐎𝐯𝐞𝐫𝐯𝐢𝐞𝐰: https://datatracker.ietf.org/doc/html/draft-ietf-vcon-overview-01

The Blank Page Effect in Problem Solving

Yodit Weldegeorgise — Mon, 16 Mar 2026 07:24:32 +0000

Have you ever stared at a problem and wondered where to start? This happens often in software development. You might have an idea for a feature, a system to design, or a problem to solve, but the starting point is not always clear.

A couple of weeks ago, in the middle of our cohort project, I noticed something interesting. The cohort environment made the development process much easier to navigate. We had structured discussions, defined tasks, and teammates to bounce ideas off. Because of that structure, it was easier to move from problem to solution.

That experience helped me realize what had been missing in some of my personal projects. When working alone, I often reached a moment where I was not sure where to begin or how to break a big idea into something manageable. Everything felt possible, but that also made it harder to take the first step.

During one of our team discussions, our lead shared something that was eye opening. He said that 𝗐𝗁𝖺𝗍𝖾𝗏𝖾𝗋 𝗐𝖾 𝗍𝗁𝗂𝗇𝗄 𝗍𝗁𝖾 𝖬𝖵𝖯 𝗂𝗌, 𝗐𝖾 𝗌𝗁𝗈𝗎𝗅𝖽 𝗉𝗋𝗈𝖻𝖺𝖻𝗅𝗒 𝖼𝗎𝗍 𝖺𝖻𝗈𝗎𝗍 𝟪𝟢 𝗉𝖾𝗋𝖼𝖾𝗇𝗍 𝗈𝖿 𝗂𝗍 𝖺𝗇𝖽 𝖿𝗈𝖼𝗎𝗌 𝗈𝗇 𝗍𝗁𝖾 𝗋𝖾𝗆𝖺𝗂𝗇𝗂𝗇𝗀 𝟤𝟢 𝗉𝖾𝗋𝖼𝖾𝗇𝗍. The goal is not to build everything at once, but to build the smallest version that actually solves the core problem.

At first, that sounded counterintuitive. When you have an idea, the natural instinct is to add more features and make the solution as complete as possible. But the more we talked about it, the more it made sense. By reducing the scope, the problem becomes clearer and easier to approach.

Around the same time, I learned that this experience is often described as the 𝗯𝗹𝗮𝗻𝗸 𝗽𝗮𝗴𝗲 𝗲𝗳𝗳𝗲𝗰𝘁. When people face an open-ended task with no clear starting point, the lack of structure can slow them down. Instead of helping creativity, too many possible directions can create hesitation.

One way to move past that moment is to reduce the problem to something smaller and more manageable. In software development, defining a minimum viable product can help create that structure. By focusing on the smallest useful solution, developers can create a clear starting point and allow the system to evolve through iteration.

For me, progress usually starts when a big idea is 𝗿𝗲𝗱𝘂𝗰𝗲𝗱 𝘁𝗼 𝗮 𝘀𝗺𝗮𝗹𝗹, 𝗮𝗰𝘁𝗶𝗼𝗻𝗮𝗯𝗹𝗲 𝘀𝘁𝗲𝗽. Once that starting point exists, the blank page is no longer empty. It becomes something you can improve, iterate on, and build over time.

Now I feel ready to 𝗍𝖺𝗄𝖾 𝗈𝗇 𝗆𝗈𝗋𝖾 𝗉𝗋𝗈𝖻𝗅𝖾𝗆𝗌 𝖺𝗇𝖽 𝗄𝖾𝖾𝗉 𝗅𝖾𝖺𝗋𝗇𝗂𝗇𝗀 𝖻𝗒 𝗍𝗎𝗋𝗇𝗂𝗇𝗀 𝗂𝖽𝖾𝖺𝗌 𝗂𝗇𝗍𝗈 𝗌𝗆𝖺𝗅𝗅, 𝖺𝖼𝗍𝗂𝗈𝗇𝖺𝖻𝗅𝖾 𝗉𝗋𝗈𝗃𝖾𝖼𝗍𝗌.

𝐅𝐞𝐞𝐝𝐛𝐚𝐜𝐤 𝐈𝐬 𝐚 𝐆𝐢𝐟𝐭: 𝐋𝐞𝐬𝐬𝐨𝐧𝐬 𝐅𝐫𝐨𝐦 𝐓𝐨𝐚𝐬𝐭𝐦𝐚𝐬𝐭𝐞𝐫𝐬

Yodit Weldegeorgise — Wed, 04 Mar 2026 08:35:56 +0000

Today I will be the evaluator for a prepared speech at Toastmasters. This is a meaningful milestone for me for two reasons.

First, it will be the last item on my checklist to complete 𝐏𝐫𝐞𝐬𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 𝐌𝐚𝐬𝐭𝐞𝐫𝐲 𝐋𝐞𝐯𝐞𝐥 𝟏.

Second, completing this will help my club move closer to 𝐏𝐫𝐞𝐬𝐢𝐝𝐞𝐧𝐭’𝐬 𝐃𝐢𝐬𝐭𝐢𝐧𝐠𝐮𝐢𝐬𝐡𝐞𝐝 𝐂𝐥𝐮𝐛 status, the highest recognition in Toastmasters. One of the requirements is having at least one member complete Level 1 along with other club goals. Being able to contribute to that progress makes this moment even more special.

This will be my second time giving an evaluation, and I will try my absolute best to deliver encouraging feedback so the speaker feels motivated to continue showing up and growing.

Evaluating someone’s speech requires careful listening, thoughtful observation, and the ability to share feedback in a way that helps the speaker grow. It is not just about pointing out what could be improved. It is also about recognizing what worked well and reinforcing those strengths.

One of the biggest lessons I learned from the Toastmasters evaluation training is the importance of staying positive. The goal is not to criticize the speaker. The goal is to support their growth while also recognizing what they did well. Positive feedback builds confidence and encourages people to keep improving.

Another important concept is using “I” statements. Instead of sounding like we are judging the speaker, we share what we personally experienced as listeners. For example, saying “I really connected with the story you shared about your first experience with public speaking” feels more personal and supportive.

Evaluations also need to be specific. Instead of general comments, the evaluator highlights specific moments in the speech. This helps the speaker understand exactly what worked well and what they might improve next time.

A helpful structure we learned for evaluations is organizing feedback into three parts. Since the evaluation time is usually 2–3 minutes, many Toastmasters evaluators follow a simple balance: two to three strengths, one or two improvement points, and one challenge for continued growth. This keeps the evaluation positive, focused, and helpful.

𝐘𝐨𝐮 𝐞𝐱𝐜𝐞𝐥𝐥𝐞𝐝 𝐚𝐭:

This is where the evaluator highlights the strengths of the speech. It focuses on what the speaker did well, such as strong storytelling, clear structure, or effective pauses. The goal is to reinforce the behaviors that worked so the speaker knows what to continue doing in future speeches.

𝐘𝐨𝐮 𝐦𝐚𝐲 𝐰𝐚𝐧𝐭 𝐭𝐨 𝐰𝐨𝐫𝐤 𝐨𝐧:

This part focuses on areas for improvement. Instead of criticizing, the evaluator shares observations that can help the speaker grow. It might be about pacing, transitions between ideas, or vocal variety. The key is presenting these points respectfully so the speaker feels encouraged rather than discouraged.

𝐓𝐨 𝐜𝐡𝐚𝐥𝐥𝐞𝐧𝐠𝐞 𝐲𝐨𝐮𝐫𝐬𝐞𝐥𝐟:

This section invites the speaker to take their skills one step further. It might suggest experimenting with something new such as stronger gestures, more vocal variety, or a more memorable closing. The idea is not just improvement, but continued growth.

One thing my mentor shared that stayed with me is this:

“Feedback is like a gift. You can open it and say ‘this is exactly what I wanted,’ or you can say ‘I’m going to have to take this back, it’s not quite the right fit.’”

I really liked that perspective because it shows how personal feedback can be. As evaluators, our responsibility is to offer thoughtful and supportive observations that help the speaker reflect on their speech and continue growing.

For me, this experience is helping me grow in a different way. It is teaching me how to listen more carefully and how to give thoughtful feedback. These are valuable skills not only in public speaking but also in everyday communication.

This experience is reminding me that giving feedback is also a skill. The more we practice it with care and encouragement, the more we help each other grow.

𝐈 𝐒𝐚𝐢𝐝 𝐘𝐞𝐬 𝐭𝐨 𝐋𝐞𝐚𝐝𝐢𝐧𝐠 𝐚 𝐏𝐮𝐛𝐥𝐢𝐜 𝐒𝐩𝐞𝐚𝐤𝐢𝐧𝐠 𝐖𝐨𝐫𝐤𝐬𝐡𝐨𝐩

Yodit Weldegeorgise — Tue, 24 Feb 2026 07:26:16 +0000

Last month, I wrote about moderating a book club session for the first time. I haven’t attended every single book club or entrepreneur workshop session, but I’ve gone enough to feel familiar with the space and the people. It’s usually a small group, around ten people, and over time it started to feel comfortable.

Moderating that session wasn’t a huge dramatic milestone. It was simply me stepping a little outside my usual role. Instead of just sharing my thoughts, I had to guide the discussion, manage the flow, and make sure everyone had space to speak. It stretched me just enough to feel meaningful.

After that, I didn’t expect anything else.

But then the organizer of the book club and the entrepreneur workshop reached out and asked if I would be interested in leading a public speaking workshop.

He gave me two options: March 14 or April 11.

At the time, choosing March felt simple and natural, and I didn’t think too much about it. It felt like momentum. Later, I realized I also have a major cohort presentation that same week, and if I had known that earlier, I probably would have picked April. But by then, it was already confirmed.

And honestly, that’s life sometimes.

Opportunities don’t always arrive neatly spaced out. They overlap. They stretch you. They test your time management and your energy.

My first reaction to the invitation wasn’t fear. It was excitement. I genuinely felt happy about it. The audience is usually small, and I already recognize many of the faces. That makes it feel less like a performance and more like a conversation in a safe space.

Still, I said something almost immediately.

“I just want to make sure you know… I’m not an expert.”

I wanted to be transparent. I’m still learning public speaking. I still adjust my slides. I’m still improving little by little. I didn’t want to present myself as someone who has mastered something I’m actively practicing.

And then he said something simple: “You have courage. You’re not afraid to take action.”

That gave me a different perspective.

Because while I may not be an expert, I do show up.

I volunteer to speak even when it would be easier to stay quiet. I join Toastmasters meetings even on busy weeks. I take feedback seriously. I try again after speeches that didn’t go the way I imagined. I raise my hand when there’s an opportunity.

And that pattern matters more than I realized.

None of those moments felt big on their own. They were small decisions. Small acts of choosing growth instead of comfort. But over time, those small choices started building something. Not perfection. Not mastery. Just familiarity. Just progress.

That mindset is exactly why I chose the title, 𝐀 𝐁𝐞𝐠𝐢𝐧𝐧𝐞𝐫 𝐅𝐫𝐢𝐞𝐧𝐝𝐥𝐲 𝐖𝐨𝐫𝐤𝐬𝐡𝐨𝐩: 𝐇𝐨𝐰 𝐭𝐨 𝐒𝐩𝐞𝐚𝐤 𝐂𝐨𝐦𝐟𝐨𝐫𝐭𝐚𝐛𝐥𝐲 𝐢𝐧 𝐏𝐮𝐛𝐥𝐢𝐜.

Not how to be perfect.
Not how to eliminate nerves.
Not how to dominate a stage.

Just comfortably.

Because in my experience, comfort doesn’t come before you start speaking. It comes after repetition. It comes after doing it enough times that your body and mind slowly realize you’re safe. It comes after surviving the awkward pauses, the slightly shaky voice, and the moments where you lose your train of thought but still recover.

𝐂𝐨𝐦𝐟𝐨𝐫𝐭 𝐢𝐬 𝐛𝐮𝐢𝐥𝐭.

This workshop isn’t about me standing at the front of the room pretending I’ve figured everything out. It’s about creating a space where beginners can practice without feeling judged. It’s about saying out loud that nerves are normal, that growth is gradual, and that courage often comes before confidence.

It’s going to be a full week. The workshop and the cohort presentation will sit side by side on my calendar. It wasn’t planned that way, but here we are.

Instead of seeing it as bad timing, I’m choosing to see it as growth.

I used to think I needed to feel fully confident before stepping into opportunities like this. Now I see that it doesn’t work that way. You say yes first. You prepare seriously. You adjust when things overlap. And somewhere in that process, you grow.

I won’t walk into that room as a public speaking expert. I’ll walk in as someone who said yes, still learning and committed to creating a space where beginners can grow without pressure.

𝐓𝐡𝐚𝐭 𝐟𝐞𝐞𝐥𝐬 𝐥𝐢𝐤𝐞 𝐭𝐡𝐞 𝐫𝐢𝐠𝐡𝐭 𝐤𝐢𝐧𝐝 𝐨𝐟 𝐬𝐭𝐫𝐞𝐭𝐜𝐡.

Because sometimes the next step doesn’t require perfect timing.

𝐈𝐭 𝐣𝐮𝐬𝐭 𝐫𝐞𝐪𝐮𝐢𝐫𝐞𝐬 𝐚 𝐲𝐞𝐬.

𝐇𝐨𝐰 𝐭𝐨 𝐇𝐚𝐧𝐝𝐥𝐞 𝐑𝐞𝐣𝐞𝐜𝐭𝐢𝐨𝐧

Yodit Weldegeorgise — Tue, 17 Feb 2026 05:56:02 +0000

Rejection is a normal part of professional growth.

At some point, you will put time and effort into something and it will not move forward. An opportunity may not work out. A proposal may not get approved. A plan may not happen the way you expected.

In professional settings, rejection is usually simple and short. Sometimes you get a clear answer. Sometimes you do not get much feedback. Either way, it can slow you down and make you question what happened.

The goal is not to avoid rejection. That is not realistic. The real goal is to respond in a way that protects your confidence and keeps you moving forward.

Handling rejection well is a skill. It takes awareness and discipline. Most importantly, it requires you to remember that one result does not define your entire career.

Here are a few simple ways I try to handle rejection.

𝐑𝐞𝐝𝐢𝐫𝐞𝐜𝐭 𝐘𝐨𝐮𝐫 𝐀𝐭𝐭𝐞𝐧𝐭𝐢𝐨𝐧

After a setback, it is easy to keep thinking about it.

You may replay conversations. You may rethink your decisions. You may wonder what you could have done differently. A short review is helpful. But thinking about it again and again does not usually help.

At some point, you have to shift your focus.

Instead of staying stuck on what happened, move your energy toward something productive. Improve a skill. Fix something that felt weak. Start a new task. Apply what you learned.

Shifting your focus helps you move forward. It stops one setback from turning into a long pause.

Progress in any area builds confidence.

𝐒𝐩𝐫𝐞𝐚𝐝 𝐎𝐮𝐭 𝐘𝐨𝐮𝐫 𝐒𝐨𝐮𝐫𝐜𝐞 𝐨𝐟 𝐕𝐚𝐥𝐢𝐝𝐚𝐭𝐢𝐨𝐧

Rejection can feel heavier when too much of your confidence comes from one place.

If your sense of success depends only on one opportunity or one result, then losing that opportunity feels like losing everything.

It helps to build confidence from different areas of your life. Learning new skills. Staying consistent. Building strong relationships. Keeping your discipline. Helping others. Finishing what you start.

When your confidence comes from many areas, one rejection does not shake you as much.

It becomes part of the journey, not a definition of who you are.

𝐋𝐞𝐚𝐧 𝐈𝐧𝐭𝐨 𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐭𝐲

Rejection can make you feel alone, even though it is very common.

Talking to trusted friends, mentors, or peers can help. Most professionals have faced rejection at some point. Hearing their stories often brings perspective.

Community reminds you that setbacks are normal. It also gives you support and helpful advice.

Asking for perspective is not weakness. It is a smart way to stay steady.

𝐓𝐚𝐤𝐞 𝐚 𝐁𝐫𝐞𝐚𝐤, 𝐓𝐡𝐞𝐧 𝐂𝐨𝐦𝐞 𝐁𝐚𝐜𝐤 𝐒𝐭𝐫𝐨𝐧𝐠𝐞𝐫

Sometimes you need a short break.

Rejection can affect your energy. It can make you feel tired or discouraged. Stepping away for a short time can help you reset.

Take a walk. Disconnect for a day. Clear your mind.

But make the break temporary. The goal is to recover, not to quit.

When you return, come back with a plan. Decide what you want to improve. Decide what your next step will be.

Coming back stronger does not mean becoming perfect. It means making small, clear improvements and continuing forward.

𝐓𝐡𝐞 𝐓𝐚𝐤𝐞𝐚𝐰𝐚𝐲

Rejection is not a sign that you should stop. It is a sign that you are trying.

In any career, not everything will work out. Not every idea will be accepted. Not every effort will bring immediate results.

What you can control is your response.

If you shift your focus, build confidence from different areas, lean on community, and reset when needed, rejection becomes part of your growth instead of something that blocks it.

You cannot remove rejection from your career.

But you can choose not to let it stop you.

And over time, that choice makes a difference.

Fail Fast, Fail Forward

Yodit Weldegeorgise — Tue, 10 Feb 2026 06:17:54 +0000

For a long time, I thought failing meant I had done something wrong.
Over time, I realized it usually meant I waited too long to test an idea, ask a question, or try a different approach.

Fail fast, fail forward is not about celebrating failure.
It is about 𝐫𝐞𝐝𝐮𝐜𝐢𝐧𝐠 𝐭𝐡𝐞 𝐜𝐨𝐬𝐭 𝐨𝐟 𝐥𝐞𝐚𝐫𝐧𝐢𝐧𝐠.

What fail fast actually means

Fail fast means 𝐠𝐞𝐭𝐭𝐢𝐧𝐠 𝐟𝐞𝐞𝐝𝐛𝐚𝐜𝐤 𝐞𝐚𝐫𝐥𝐲.

Instead of spending weeks polishing something in isolation, you put it in front of reality as soon as possible. Reality can be code running, a question asked in a meeting, or trying a new approach even if you are not fully confident yet.

The goal is not speed for the sake of speed.
The goal is 𝐜𝐥𝐚𝐫𝐢𝐭𝐲.

A technical example from data structures

This idea shows up very clearly in data structures.

In Java, HashMap is a good example of a 𝐟𝐚𝐢𝐥 𝐟𝐚𝐬𝐭 data structure.

When you iterate over a HashMap and modify it at the same time, Java throws an exception immediately. It does not try to recover or continue quietly. It stops execution so the problem is visible right away.

This behavior is intentional.

The goal is not to make the program crash randomly.
The goal is to 𝐬𝐮𝐫𝐟𝐚𝐜𝐞 𝐛𝐮𝐠𝐬 𝐞𝐚𝐫𝐥𝐲, while they are still easy to understand and fix.

Other data structures are designed to be 𝐟𝐚𝐢𝐥 𝐬𝐚𝐟𝐞.

For example, collections like CopyOnWriteArrayList work on a copy of the data. Modifications do not affect the current iteration, so the program continues running without throwing an error.

This feels safer, but it also means issues can go unnoticed longer.

Neither approach is wrong.
They solve different problems.

Fail fast structures prioritize 𝐞𝐚𝐫𝐥𝐲 𝐟𝐞𝐞𝐝𝐛𝐚𝐜𝐤 𝐚𝐧𝐝 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐧𝐞𝐬𝐬.
Fail safe structures prioritize 𝐬𝐭𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐚𝐧𝐝 𝐜𝐨𝐧𝐭𝐢𝐧𝐮𝐢𝐭𝐲.

Seeing this in code helped me understand the idea beyond theory.

A simple example from backend development

When I started building backend APIs, I would often overthink structure before even running the application. I wanted everything to be clean before seeing if it actually worked.

That usually backfired.

Now I run the application early, even if the code is incomplete. Errors show up quickly. Misunderstandings become obvious. I learn what the framework expects instead of guessing.

Failing fast here means I spend less time being stuck and more time 𝐚𝐝𝐣𝐮𝐬𝐭𝐢𝐧𝐠 𝐢𝐧 𝐭𝐡𝐞 𝐫𝐢𝐠𝐡𝐭 𝐝𝐢𝐫𝐞𝐜𝐭𝐢𝐨𝐧.

Applying this idea to public speaking

Public speaking did not become easier because I suddenly felt confident.
It became easier because I stopped waiting until I felt ready.

Early speeches were imperfect. Timing was off. Feedback was direct. None of that meant I was bad at speaking. It showed me what needed attention next.

Failing forward meant taking that feedback and applying 𝐨𝐧𝐞 𝐬𝐦𝐚𝐥𝐥 𝐢𝐦𝐩𝐫𝐨𝐯𝐞𝐦𝐞𝐧𝐭 𝐚𝐭 𝐚 𝐭𝐢𝐦𝐞, instead of trying to fix everything at once.

Why failing forward matters more than failing fast

Failing fast gives you information.
Failing forward means 𝐲𝐨𝐮 𝐮𝐬𝐞 𝐢𝐭.

Failing forward looks like:

Making 𝐨𝐧𝐞 𝐚𝐝𝐣𝐮𝐬𝐭𝐦𝐞𝐧𝐭 based on feedback

Asking a 𝐜𝐥𝐞𝐚𝐫𝐞𝐫 𝐪𝐮𝐞𝐬𝐭𝐢𝐨𝐧 next time

Trying again with 𝐬𝐥𝐢𝐠𝐡𝐭𝐥𝐲 𝐛𝐞𝐭𝐭𝐞𝐫 𝐮𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠

It is not dramatic. Most progress is 𝐢𝐧𝐜𝐫𝐞𝐦𝐞𝐧𝐭𝐚𝐥 𝐚𝐧𝐝 𝐪𝐮𝐢𝐞𝐭.

The model I follow

The model I follow is simple:

Try early
Observe what does not work
Adjust one thing
Try again

There is 𝐧𝐨 𝐩𝐞𝐫𝐟𝐞𝐜𝐭 𝐭𝐢𝐦𝐞 𝐭𝐨 𝐬𝐭𝐚𝐫𝐭.
There is 𝐧𝐨 𝐛𝐞𝐧𝐞𝐟𝐢𝐭 𝐢𝐧 𝐰𝐚𝐢𝐭𝐢𝐧𝐠

This is the same approach I use in tech, learning, and preparing workshops.

What I'm working on next

I am excited to share that I will be giving a workshop titled:

𝐀 𝐁𝐞𝐠𝐢𝐧𝐧𝐞𝐫-𝐅𝐫𝐢𝐞𝐧𝐝𝐥𝐲 𝐖𝐨𝐫𝐤𝐬𝐡𝐨𝐩: 𝐇𝐨𝐰 𝐭𝐨 𝐒𝐩𝐞𝐚𝐤 𝐂𝐨𝐦𝐟𝐨𝐫𝐭𝐚𝐛𝐥𝐲 𝐢𝐧 𝐏𝐮𝐛𝐥𝐢𝐜

The ideas around failing fast and failing forward are a core part of how I approach public speaking, especially for beginners who feel pressure to be confident before they start.

I will write more about the process, lessons, and practical exercises from this workshop in future blog posts.

𝗗𝗼 𝗜𝘁 𝗦𝗰𝗮𝗿𝗲𝗱: 𝗪𝗵𝗮𝘁 𝗮 𝟭𝟮𝟬 𝗕𝗣𝗠 𝗛𝗲𝗮𝗿𝘁𝗯𝗲𝗮𝘁 𝗧𝗮𝘂𝗴𝗵𝘁 𝗠𝗲

Yodit Weldegeorgise — Mon, 02 Feb 2026 21:00:04 +0000

There is a book called Do It Scared, and I read Do It Scared a few months ago. Its message is simple but challenging: you do not wait until fear disappears before you act, you move forward while fear is still there.

𝗪𝗵𝗲𝗻 𝗳𝗲𝗮𝗿 𝘀𝗵𝗼𝘄𝗲𝗱 𝘂𝗽

Last Wednesday night, right before I presented a speech at Toastmasters, my watch sent me a notification telling me that my heart rate had risen above 𝟭𝟮𝟬 𝗕𝗣𝗠 even though I was inactive. I was not running or moving around. I was simply standing there, waiting for my turn to speak, and that was enough for fear to show up physically.

I was nervous, and part of that nervousness came from an honest awareness that my preparation was not where I wanted it to be. I had limited time, I knew I could have practiced more, and that awareness made the moment feel heavier than usual.

I was most nervous before I started. Once I began speaking, it got easier. As I talked, my body settled, my thoughts slowed down, and I could finally focus on what I wanted to say instead of how fast my heart was beating.

When my evaluator mentioned that I looked calm and relaxed, I was genuinely surprised, because not long before that moment my heart had been racing. On the outside, I appeared steady, even though internally I had been working through fear.

𝗙𝗼𝘂𝗿 𝗱𝗮𝘆𝘀 𝗹𝗮𝘁𝗲𝗿

I stepped into another first.

I showed up to the contest expecting to serve as a timer, but with encouragement from our club leader, Yujun, I found myself stepping in as a contestant instead. With just 𝗳𝗼𝘂𝗿 𝗱𝗮𝘆𝘀’ 𝗻𝗼𝘁𝗶𝗰𝗲, I decided to compete in my first Evaluation Contest in front of district judges, knowing there was no long preparation window and no chance to feel completely ready.

Again, part of the fear came from the same place. I was stepping in before everything felt polished, and every instinct told me to wait, give myself more time, and stay comfortable. Instead, I chose to step forward.

When the contest ended and I heard my name called for 𝘁𝗵𝗶𝗿𝗱 𝗽𝗹𝗮𝗰𝗲, what stayed with me most was something simpler. It was my first time evaluating, and the fact that I had stepped into that role at all surprised me.

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗳𝗲𝗮𝗿 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆

One idea from Do It Scared that helped me see fear differently is that fear does not show up the same way for everyone.
The book describes seven fear archetypes:

The Procrastinator, who waits for the perfect moment
The People Pleaser, who fears disappointing others
The Rule Follower, who is afraid of doing things wrong
The Outcast, who fears standing out
The Self-Doubter, who questions their ability
The Excuse Maker, who always finds a reason not to act
The Pessimist, who expects the worst outcome

Reading about these made me realize that fear is personal and adaptive. That week, I recognized myself in more than one of these patterns. I noticed the self-doubter questioning readiness, the rule follower wanting everything to be right, and the procrastinator suggesting maybe later. Even with all of that, I chose to act.

𝗪𝗵𝗮𝘁 𝗱𝗼𝗶𝗻𝗴 𝗶𝘁 𝘀𝗰𝗮𝗿𝗲𝗱 𝗿𝗲𝗮𝗹𝗹𝘆 𝗺𝗲𝗮𝗻𝘀

Doing it scared does not mean being careless. It means moving forward even when preparation is imperfect and conditions are not ideal. Fear did not mean I was failing. It meant I cared enough to want to do well, and confidence did not come before action but slowly built because I acted anyway.

So the next time your heart races, do not take it as a warning.
Take it as a signal.

A signal that you care.
A signal that you are stepping into something that matters.
A signal that growth is happening in real time.

That 𝟭𝟮𝟬 𝗕𝗣𝗠 was not telling me to stop. It was telling me to begin. I spoke anyway, I competed anyway, and I learned that courage does not require fear to disappear.

𝗗𝗼 𝗶𝘁 𝘀𝗰𝗮𝗿𝗲𝗱.

The Java switch nuance that gave me an "oh wow" moment

Yodit Weldegeorgise — Mon, 26 Jan 2026 07:47:18 +0000

While preparing for the OCA 808 exam (the Java SE 8 certification exam), I have been revisiting Java fundamentals. Not just the syntax I use daily, but the rules that define how the language actually behaves. Along the way, a switch workshop on pattern matching by Venkat Subramaniam made the topic even more engaging.

One detail that stood out early on is that Java’s switch statement only supports a limited set of data types.

Integer primitives: byte, short, char, int
enum
String

That limitation alone hints that switch behaves very differently from something like if-else.

As I looked more closely at the language rules, I ran into a subtle nuance that rarely shows up in everyday code.

In most real-world examples, default appears at the end of a switch and is paired with a break. Because we see it written this way so consistently, it is easy to internalize default as a simple fallback, almost like an else. Over time, it can even start to feel like something that always runs, similar to finally.

That assumption turns out to be wrong.

A closer look at default in Java switch

In Java, default is a reserved keyword, but that does not give it special control-flow behavior inside a switch. What causes confusion is not how the language works, but how we usually write our code.

Inside a switch, default is just a label. It marks a possible entry point. If no other case matches, execution may begin there. Once execution starts, the rules are exactly the same as for any other case.

Here is a simple example.

int x = 10;

switch (x) {
    default:
        System.out.println("Default");
    case 1:
        System.out.println("One");
}

When this code runs, the output is:

Default
One

Because there is no break, execution begins at default and then falls through into case 1.

The important detail here is that default does not control execution.
It only controls where execution starts.

It does not stop execution.
It does not have to appear last.
It does not guarantee that it will run.

Why this feels counterintuitive

The confusion comes from mixing mental models.

With if-else, conditions are evaluated top to bottom.
With finally, execution is guaranteed.
A switch works differently.

A switch does not execute cases in order. It decides where to start, then executes code forward from that point.

Once I stopped thinking of switch as a sequence and started thinking of it as a jump, things clicked.

A note about common explanations

Many explanations describe switch as working sequentially by evaluating cases from top to bottom until a match is found. This model is very common, especially in beginner-friendly resources and search results.

That explanation is useful for predicting behavior, but it is not describing how Java implements switch at runtime.

At the source-code level, switch reads as if cases are checked in order. At the JVM level, however, selection is implemented as a direct jump. The JVM does not compare the switch value against each case one by one.

Both descriptions explain the same observable behavior, but they operate at different levels of abstraction.

If switch were implemented by evaluating cases sequentially, placing default at the top would cause a serious problem. Since default is the widest match, execution would always begin there, and more specific cases would never be reached. In that model, default would almost certainly need to appear last.

Thankfully, that is not how Java works.

During the selection phase, Java does not evaluate default as a condition at all. Instead, the JVM first determines whether any specific case matches the switch value. If a match is found, execution jumps directly to that case, even if default appears earlier in the source code. Only when no case matches does the JVM select default as the entry point, regardless of its position.

Once execution begins at the selected label, normal fall-through rules apply. If there is no break or return, execution continues into subsequent cases. To prevent fall-through, break is commonly used, but return is also a valid alternative when exiting the method is the desired behavior.

This behavior only makes sense when switch selection is treated as a jump decision rather than a sequential check.

Selection and execution

A switch has two distinct phases.

Selection phase

The switch expression is evaluated once.
Java decides which label to jump to.
This will be either a matching case or default.
No code runs during this phase.
Source order does not matter.

Execution phase

Java jumps to the selected label.
Statements execute top to bottom.
Output is produced.
Fall-through can happen.
Execution continues until a break, return, or the end of the switch.

Selection decides where execution starts.

Execution decides what actually runs.

Here is an example that makes this distinction clear.

int x = 1;

switch (x) {
    case 1:
        System.out.println("One");
    case 2:
        System.out.println("Two");
        break;
    default:
        System.out.println("Default");
}

The output is:

One
Two

Only one entry point was selected, but multiple lines were executed.

Placing default at the top

To make this even clearer, consider default placed at the top.

int x = 1;

switch (x) {
    default:
        System.out.println("Default");
    case 1:
        System.out.println("One");
        break;
    case 2:
        System.out.println("Two");
        break;
}

The output is:

One

Even though default appears first, execution does not start there. Selection chooses case 1, and execution begins at that label.

Now remove the break.

int x = 3;

switch (x) {
    default:
        System.out.println("Default");
    case 1:
        System.out.println("One");
    case 2:
        System.out.println("Two");
}

The output is:

Default
One
Two

This shows that default behaves exactly like any other case once execution begins.

How Java selects a case internally

Under the hood, Java does not check cases one by one at runtime. The compiler transforms a switch into a structure that allows the JVM to jump directly to the correct label.

When case values are close together, the compiler uses a jump table.

Example values: 1, 2, 3, 4
The switch value is converted into an index.
The JVM jumps directly to the corresponding label.
This runs in constant time.

When case values are sparse, the compiler uses a lookup table.

Example values: 1, 100, 10000
Values are mapped to jump targets.
This avoids wasting space.
Lookup is optimized and effectively constant time for typical switches.

In both cases:

Selection happens before execution.
default is just a fallback jump target.
Source order does not affect selection.

Observing selection using the command line

You cannot step through switch selection logic in a normal debugger, because that decision happens before any Java statements execute. To see it clearly, you need to inspect the compiled bytecode.

I compiled the code from the command line and inspected it using javap.

javac -d . SwitchStatement.java
javap -c -classpath . org.example.test.oca.SwitchStatement

A simplified snippet from the output looks like this:

lookupswitch {
  1: 36
  2: 44
  default: 28
}

The numbers 36, 44, and 28 are bytecode instruction offsets. They mark the exact instruction where execution begins for each case.

If the value is 1, execution jumps to offset 36
If the value is 2, execution jumps to offset 44
If no case matches, execution jumps to 28, the start of default

Reading the bytecode like an insider

While reading the javap output, I kept seeing instructions like getstatic, ldc, and invokevirtual. At first glance, these look cryptic, but they map very directly to familiar Java statements.

For example:

28: getstatic
31: ldc "Default"
33: invokevirtual println

This corresponds to:

System.out.println("Default");

Under the hood:

getstatic retrieves the System.out reference
ldc loads a constant value from the constant pool
invokevirtual calls the println method

The instruction that caught my attention was ldc. It is easy to misread it as “idc” (I don’t care), but it actually means load constant. String literals and other constants live in the class’s constant pool, and ldc pushes the correct value onto the operand stack so the next instruction can use it.

Once you understand this, the bytecode stops feeling mysterious. It becomes a very explicit, step-by-step description of how the JVM executes the code you wrote.

A brief note on modern switch features

Switch expressions first appeared as a preview in Java 12, were refined in Java 13, and became official in Java 14. Later, switch was extended with pattern matching, allowing switches to match on object types rather than only constant values.

Classic value-based switch:

String input = "hello";

switch (input) {
    case "hello":
        System.out.println("Greeting");
        break;
    default:
        System.out.println("Unknown");
}

Output:

Greeting

Pattern matching switch:

Object obj = 42;

switch (obj) {
    case Integer i -> System.out.println("Integer: " + i);
    case String s  -> System.out.println("String: " + s);
    default        -> System.out.println("Something else");
}

Output:

Integer: 42

Best practices around switch, such as placing default at the end and using break, are still the right approach in production code. What helped me was understanding what the language is doing underneath those conventions. Seeing the clear separation between selection and execution made those best practices feel intentional rather than arbitrary.

If you have had a similar moment where understanding a small internal detail reshaped how you think about a familiar construct, I would love to hear it.

The First 90 Days: Navigating Career Transitions with Intention

Yodit Weldegeorgise — Mon, 19 Jan 2026 07:51:16 +0000

There are some books you read and think, this is helpful.

And then there are books you read and think, I wish I had discovered this book years ago.

That is exactly how I felt reading 𝗧𝗵𝗲 𝗙𝗶𝗿𝘀𝘁 𝟵𝟬 𝗗𝗮𝘆𝘀.

I genuinely believe this book should be taught in school, or at least introduced before anyone steps into their first corporate role. Not because it teaches technical skills, but because it focuses on something we are rarely prepared for early on: 𝗵𝗼𝘄 𝘁𝗼 𝗻𝗮𝘃𝗶𝗴𝗮𝘁𝗲 𝘁𝗿𝗮𝗻𝘀𝗶𝘁𝗶𝗼𝗻𝘀 𝘄𝗶𝘁𝗵 𝗶𝗻𝘁𝗲𝗻𝘁𝗶𝗼𝗻.

The book is structured around 𝟭𝟬 𝗰𝗵𝗮𝗽𝘁𝗲𝗿𝘀, each focused on a specific aspect of navigating the early days of a new role. Together, they break down what those first 90 days are really about: 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗳𝗮𝘀𝘁, 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗰𝗼𝗻𝘁𝗲𝘅𝘁, 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗿𝗲𝗹𝗮𝘁𝗶𝗼𝗻𝘀𝗵𝗶𝗽𝘀, 𝗮𝗻𝗱 𝗰𝗿𝗲𝗮𝘁𝗶𝗻𝗴 𝗲𝗮𝗿𝗹𝘆 𝗺𝗼𝗺𝗲𝗻𝘁𝘂𝗺. These ideas apply whether you are starting your first job, joining a new team, or stepping into a new responsibility.

𝗛𝗼𝘄 𝗜 𝗙𝗼𝘂𝗻𝗱 𝘁𝗵𝗲 𝗕𝗼𝗼𝗸

I first learned about this book during a Toastmasters meeting. Later, when my local business book club announced the books we would be reading throughout the year and invited members to moderate discussions, I immediately knew which book I wanted to choose.

I selected this book back in November, and this will be my first time moderating a discussion. I will be moderating the conversation on Saturday, January 24. For me, moderating felt like the best way to truly absorb the material. Reading with the responsibility of guiding a conversation encourages 𝗱𝗲𝗲𝗽𝗲𝗿 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗮𝗻𝗱 𝗺𝗼𝗿𝗲 𝘁𝗵𝗼𝘂𝗴𝗵𝘁𝗳𝘂𝗹 𝗿𝗲𝗳𝗹𝗲𝗰𝘁𝗶𝗼𝗻.

That approach fits naturally with the ideas in the book. 𝗧𝗿𝗮𝗻𝘀𝗶𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗮𝗰𝘁𝗶𝘃𝗲 𝗺𝗼𝗺𝗲𝗻𝘁𝘀, and learning happens best when you engage with intention rather than passively.

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀

One of the most important ideas in the book is that 𝘁𝗿𝗮𝗻𝘀𝗶𝘁𝗶𝗼𝗻𝘀 𝗱𝗼 𝗻𝗼𝘁 𝗳𝗮𝗶𝗹 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝗽𝗲𝗼𝗽𝗹𝗲 𝗮𝗿𝗲 𝗶𝗻𝗰𝗮𝗽𝗮𝗯𝗹𝗲. They fail when there is a mismatch between the situation and how someone approaches it.

New roles come with both opportunity and risk. What worked in a previous role may not work in the next one. 𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗱𝘂𝗿𝗶𝗻𝗴 𝘁𝗿𝗮𝗻𝘀𝗶𝘁𝗶𝗼𝗻𝘀 𝗶𝘀 𝗹𝗲𝘀𝘀 𝗮𝗯𝗼𝘂𝘁 𝘄𝗼𝗿𝗸𝗶𝗻𝗴 𝗵𝗮𝗿𝗱𝗲𝗿 𝗮𝗻𝗱 𝗺𝗼𝗿𝗲 𝗮𝗯𝗼𝘂𝘁 𝘄𝗼𝗿𝗸𝗶𝗻𝗴 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆.

The good news is that transitions are not random. There are clear principles that can significantly improve your chances of success if you apply them early.

Below are the ideas that stood out to me most.

1. 𝗣𝗿𝗲𝗽𝗮𝗿𝗲 𝗬𝗼𝘂𝗿𝘀𝗲𝗹𝗳 (𝗔𝗻𝘆 𝗥𝗼𝗹𝗲, 𝗔𝗻𝘆 𝗟𝗲𝘃𝗲𝗹)

Transitions affect everyone, not just managers.

At any level, one of the first things to accept is that 𝘄𝗵𝗮𝘁 𝘄𝗼𝗿𝗸𝗲𝗱 𝗯𝗲𝗳𝗼𝗿𝗲 𝗺𝗮𝘆 𝗻𝗼𝘁 𝗼𝗿𝗸 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝘄𝗮𝘆 𝗻𝗼𝘄. A new role comes with different expectations, even if the title or skills feel familiar. Preparing yourself means staying open to learning instead of relying on past habits.

One of my favorite metaphors from the book compares joining a new company to 𝗮𝗻 𝗼𝗿𝗴𝗮𝗻 𝘁𝗿𝗮𝗻𝘀𝗽𝗹𝗮𝗻𝘁. You are the new organ entering a living system. If you do not take time to adapt, the system may reject you, even with good intentions.

Every organization has its own culture, rhythm, and way of working. Observing first and learning how things actually operate helps you integrate and build trust.

Another idea that stood out is the comparison between recruiting and employment. 𝗥𝗲𝗰𝗿𝘂𝗶𝘁𝗶𝗻𝗴 𝗼𝗳𝘁𝗲𝗻 𝗳𝗲𝗲𝗹𝘀 𝗹𝗶𝗸𝗲 𝗿𝗼𝗺𝗮𝗻𝗰𝗲. 𝗘𝗺𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗳𝗲𝗲𝗹𝘀 𝗺𝗼𝗿𝗲 𝗹𝗶𝗸𝗲 𝗺𝗮𝗿𝗿𝗶𝗮𝗴𝗲. The shift is subtle but important, especially early on.

That is why clarifying expectations matters. What you thought the role would be may look very different once you are inside the organization.

When onboarding or transition support exists, it is worth using. Even when it does not, early conversations with your manager or HR about priorities, expectations, and a simple 90 day plan can help. Asking who the key stakeholders are or who understands the culture well can also make the adjustment smoother.

Preparing yourself is not about proving value quickly. It is about adjusting your mindset, understanding the environment, and setting yourself up to succeed.

2. 𝗔𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗲 𝗬𝗼𝘂𝗿 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴

Starting a new role can feel like 𝗱𝗿𝗶𝗻𝗸𝗶𝗻𝗴 𝗳𝗿𝗼𝗺 𝗮 𝗳𝗶𝗿𝗲𝗵𝗼𝘀𝗲. Information is everywhere, opinions are everywhere, and there is pressure to catch up fast.

This chapter helped me realize that learning quickly is not about consuming more. 𝗜𝘁 𝗶𝘀 𝗮𝗯𝗼𝘂𝘁 𝗰𝗵𝗼𝗼𝘀𝗶𝗻𝗴 𝗯𝗲𝘁𝘁𝗲𝗿 𝗶𝗻𝗽𝘂𝘁𝘀.

Early on, it is tempting to stay close to your immediate team and assume that gives you the full picture. It rarely does. Some of the most useful insights come from people closest to the work. Those interacting with customers, running operations, or supporting day to day execution often see problems before they show up in reports.

It also made me more aware of how easily early impressions stick. The first few conversations you have can quietly shape how you understand the organization. If those conversations are unstructured, you may end up reacting to strong opinions instead of real signals.

A better approach is to slow down just enough to learn with intention. Asking similar questions across different conversations helps patterns surface. When the same themes show up repeatedly, you start to see what truly matters versus what is just noise.

For me, accelerating learning is not about speed. It is about clarity.

3. 𝗠𝗮𝘁𝗰𝗵 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 𝘁𝗼 𝘁𝗵𝗲 𝗦𝗶𝘁𝘂𝗮𝘁𝗶𝗼𝗻

Success in a new role depends on how well your approach fits the situation.

The same behavior can lead to very different outcomes depending on context. Acting aggressively may be right in a crisis, but harmful in a stable environment that needs refinement rather than disruption.

The book introduces the 𝗦𝗧𝗔𝗥𝗦 𝗺𝗼𝗱𝗲𝗹, which describes five common transition situations: Start-up, Turnaround, Accelerated Growth, Realignment, and Sustaining Success. Each requires a different focus, pace, and strategy.

Misreading the situation is easy. Not every problem is a crisis, and not every opportunity requires dramatic change. Applying the wrong strategy often creates resistance, even with good intentions.

The more accurately you diagnose the situation, the easier it becomes to decide how to act and where to focus your energy.

4. 𝗡𝗲𝗴𝗼𝘁𝗶𝗮𝘁𝗲 𝗦𝘂𝗰𝗰𝗲𝘀𝘀

Success in a new role is not just about doing good work. It is about building alignment with your manager early.

One important part of that is educating your manager when expectations do not match reality. Your manager may have assumptions about where problems exist or how fast change can happen. When that occurs, your role is to share what you are seeing, backed by context and facts, and help reset expectations thoughtfully.

Another practical principle is to 𝘂𝗻𝗱𝗲𝗿𝗽𝗿𝗼𝗺𝗶𝘀𝗲 𝗮𝗻𝗱 𝗼𝘃𝗲𝗿𝗱𝗲𝗹𝗶𝘃𝗲𝗿. It is tempting to say yes to everything early on, but credibility is built by being realistic. Promising less and delivering more builds trust. Promising too much and missing it does the opposite.

Clarity matters. Even when expectations seem clear, keep checking. Ask questions. Confirm priorities. Ambiguity around goals and success criteria creates problems later. It is better to slow down early than to move fast in the wrong direction.

Negotiating success is about shared understanding.

5. 𝗦𝗲𝗰𝘂𝗿𝗲 𝗘𝗮𝗿𝗹𝘆 𝗪𝗶𝗻𝘀

Early wins matter because they build trust before you need it.

When you step into a new role, people are still forming opinions. Small, visible progress helps others see that things are moving in the right direction. These wins do not need to be dramatic. They need to be relevant, real, and aligned with what matters to the team.

Early wins create momentum. They buy you time. Once people see results, they are more open to ideas, more patient with learning curves, and more willing to support larger changes later.

The key is choosing wisely. Focus on problems that matter and can be solved in the short term. One or two well chosen wins are far more effective than trying to fix everything at once.

6. 𝗔𝗰𝗵𝗶𝗲𝘃𝗲 𝗔𝗹𝗶𝗴𝗻𝗺𝗲𝗻𝘁

One of the easiest ways to struggle in a new role is to work hard on the wrong things.

Alignment starts with understanding where the organization truly stands. A simple SWOT mindset helps. Strengths, weaknesses, opportunities, and threats provide a clearer picture of reality.

You do not need a formal analysis. Listening, observing, and asking thoughtful questions will tell you what matters. Notice what gets repeated in meetings, what decisions move quickly, and which problems keep resurfacing.

Alignment also means understanding your manager’s priorities within that context. Priorities shift, so checking in and adjusting your focus helps you move with the organization rather than against it.

7. 𝗕𝘂𝗶𝗹𝗱 𝗬𝗼𝘂𝗿 𝗧𝗲𝗮𝗺

No transition happens alone. Even in individual roles, success depends on the people around you.

Building your team starts with understanding how people work. Learn how they communicate, what they own, and what they care about. Listening early matters more than trying to change things.

Clarity around roles and expectations prevents confusion later. Trust is built through consistency, follow through, and respect for others’ time.

Investing in relationships early makes every transition smoother.

8. 𝗖𝗿𝗲𝗮𝘁𝗲 𝗔𝗹𝗹𝗶𝗮𝗻𝗰𝗲𝘀

It is easy to stay in your lane when you start something new, but work rarely happens in isolation.

Creating alliances means understanding how other people’s work connects to yours. These relationships often become your best source of context, support, and momentum.

Alliances grow through everyday interactions. Showing curiosity. Listening without rushing to respond. Being dependable in small moments.

Over time, trust forms. When trust exists, collaboration feels easier and progress feels lighter.

9. 𝗠𝗮𝗻𝗮𝗴𝗲 𝗬𝗼𝘂𝗿𝘀𝗲𝗹𝗳

Transitions are not just about learning a new role. They are also about managing your energy, emotions, and expectations.

Early on, everything can feel urgent. Pressure to prove yourself can lead to rushed decisions or burnout before momentum even builds.

Managing yourself means slowing down enough to stay grounded. Paying attention to how you respond under stress. Being honest about limits. Choosing where to focus instead of trying to do everything at once.

How you manage yourself shapes how others experience working with you. Calm and steady presence builds confidence. Thoughtful responses build trust.

10. 𝗔𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗲 𝗘𝘃𝗲𝗿𝘆𝗼𝗻𝗲

It is easy to focus only on your own ramp up. But progress rarely depends on one person alone.

This chapter reframed acceleration for me. It is not just about how fast you learn. It is about how quickly the people around you can move with you.

Accelerating everyone means sharing context, reducing confusion, and helping others understand direction and purpose. You do not need authority to do this. Small actions matter. Clarifying goals. Connecting dots. Making work easier for others.

When learning and momentum are shared, progress becomes more sustainable.

Although 𝗧𝗵𝗲 𝗙𝗶𝗿𝘀𝘁 𝟵𝟬 𝗗𝗮𝘆𝘀 was written with managers in mind, its lessons go far beyond leadership titles.

At its core, this book is about how people step into something new. How they learn, adapt, build relationships, and create momentum in unfamiliar environments. Those challenges show up for every new employee, at every stage of a career.

If you are curious about how the corporate world really works, and how to navigate change with more clarity and confidence, this book offers a thoughtful starting point. Not as a checklist, but as a mindset.

The first 90 days will come again and again throughout a career. 𝗛𝗼𝘄 𝘆𝗼𝘂 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵 𝘁𝗵𝗲𝗺 𝗰𝗮𝗻 𝗺𝗮𝗸𝗲 𝗮𝗹𝗹 𝘁𝗵𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲.

OOP vs DOP: Rethinking Design, Complexity, and Trade-offs

Yodit Weldegeorgise — Fri, 16 Jan 2026 06:28:38 +0000

On Wednesday, I attended an 𝗢𝗢𝗣 𝘃𝘀 𝗗𝗢𝗣 discussion that challenged the way I think about software design, complexity, and trade-offs.

𝗤𝘂𝗶𝗰𝗸 𝗴𝗿𝗼𝘂𝗻𝗱𝗶𝗻𝗴 𝗯𝗲𝗳𝗼𝗿𝗲 𝗱𝗶𝘃𝗶𝗻𝗴 𝗶𝗻

𝗢𝗯𝗷𝗲𝗰𝘁-𝗢𝗿𝗶𝗲𝗻𝘁𝗲𝗱 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 (𝗢𝗢𝗣) organizes software around objects that bundle data and behavior together. It relies on abstraction, encapsulation, inheritance, and polymorphism.

𝗗𝗮𝘁𝗮-𝗢𝗿𝗶𝗲𝗻𝘁𝗲𝗱 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 (𝗗𝗢𝗣) focuses on modeling data first and driving behavior from that data. It often favors simplicity, immutability, and pattern matching over deep object hierarchies.

𝗟𝗲𝘁 𝗺𝗲 𝘀𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝘀𝘁𝗼𝗿𝘆𝘁𝗲𝗹𝗹𝗶𝗻𝗴

The way Dr. Venkat Subramaniam teaches is refreshing.

A three-hour workshop felt like a thirty-minute conversation.

No slides.
Just live typing in Notepad, thinking out loud, and building ideas step by step.

As a visual learner, this style really worked for me. It was easy to follow and very different from the usual conference-style presentations.

𝗡𝗼𝘄 𝘁𝗼 𝘁𝗵𝗲 𝗰𝗼𝗻𝘁𝗲𝗻𝘁

Java has been centered around Object-Oriented Programming for more than thirty years, and as a community, we are deeply attached to its principles. But one question set the tone for the entire session:

👉 𝗜𝗳 𝘄𝗲 𝗳𝗼𝗹𝗹𝗼𝘄 𝗱𝗲𝘀𝗶𝗴𝗻 𝗽𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 𝗯𝗹𝗶𝗻𝗱𝗹𝘆, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗱𝗲𝘀𝗶𝗴𝗻 𝗶𝘀 𝘀𝘁𝗶𝗹𝗹 𝗯𝗮𝗱, 𝗮𝗿𝗲 𝘄𝗲 𝗿𝗲𝗮𝗹𝗹𝘆 𝘀𝗲𝗿𝘃𝗶𝗻𝗴 𝘁𝗵𝗲 𝗽𝘂𝗿𝗽𝗼𝘀𝗲?

That’s where the discussion got interesting.

𝗥𝗲𝘃𝗶𝘀𝗶𝘁𝗶𝗻𝗴 𝘁𝗵𝗲 𝗳𝗼𝘂𝗿 𝗽𝗶𝗹𝗹𝗮𝗿𝘀 𝗼𝗳 𝗢𝗢𝗣

𝗔𝗯𝘀𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻
Changing behavior without directly changing code, and how humans stay sane when dealing with complexity by focusing on what instead of how.

𝗘𝗻𝗰𝗮𝗽𝘀𝘂𝗹𝗮𝘁𝗶𝗼𝗻
Implementation hiding, or the separation of what from how. This applies at many levels, from functions and files to classes, components, subsystems, and entire systems.

𝗜𝗻𝗵𝗲𝗿𝗶𝘁𝗮𝗻𝗰𝗲
Often one of the weakest links of OOP when overused. Instead of defaulting to inheritance, the focus shifted to design by contract and design by capability.

𝗣𝗼𝗹𝘆𝗺𝗼𝗿𝗽𝗵𝗶𝘀𝗺
Behavior chosen at runtime, not compile time. It often appears with inheritance, but it does not require it and can also be achieved through interfaces, composition, or pattern matching.

This framing made the principles feel less like rigid rules and more like design tools with real trade-offs.

𝗗𝗲𝘀𝗶𝗴𝗻 𝗽𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 𝗶𝗻 𝗮𝗰𝘁𝗶𝗼𝗻

We explored the Open-Closed Principle and Dependency Inversion Principle.

A simple design evolved from:

OrderProcess -> CreditCard

to:

OrderProcess -> PaymentMethod <- CreditCard

Here, OrderProcess depends only on the abstraction, while CreditCard implements that abstraction, keeping high-level logic decoupled from concrete implementations.

𝗕𝘂𝘁 𝘁𝗵𝗲𝗻 𝗰𝗮𝗺𝗲 𝘁𝗵𝗲 𝗰𝗼𝘀𝘁

DRY was violated
Parallel class hierarchies appeared
Code size increased
Complexity grew quickly
Runtime errors became easier to introduce
Exception handling became painful

At some point, it felt like we were managing complexity by naming it.

That led to an important question:

When does the cost of complexity outweigh the benefits?

𝗟𝗼𝗼𝗸𝗶𝗻𝗴 𝗮𝘁 𝗗𝗢𝗣

With DOP, the Open-Closed Principle is violated, and Dependency Inversion is not used.

But in return:

Much less code
No parallel hierarchies
DRY preserved
Simpler logic
Easier exception handling
Compile-time errors when new types are introduced

The contrast was clear.

OOP relies on polymorphism.
DOP relies on pattern matching.

𝗠𝗼𝗱𝗲𝗿𝗻 𝗝𝗮𝘃𝗮 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀

Records encourage immutability.
Sealed classes give compile-time guarantees by defining a closed set of allowed subtypes.
Switch becomes a powerful pattern-matching tool, not just a control-flow tool.

𝗠𝘆 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆

Both in life and in programming, trade-offs are unavoidable.

I felt this personally. To attend this session, I had to choose between a Toastmasters meeting and the JavaMUG meetup. I could not be in two places at the same time.

Another insight that really stayed with me was Dr. Venkat’s perspective beyond any single language. He works with more than 15 programming languages, and his students often share that thinking beyond a fixed-language mindset helps them solve problems more effectively.

Focusing on thinking, not just syntax, was a powerful reminder.

No paradigm is perfect. What matters most is knowing when and why to use each one.

𝗖𝘂𝗿𝗶𝗼𝘂𝘀 𝘁𝗼 𝗵𝗲𝗮𝗿 𝘆𝗼𝘂𝗿 𝘁𝗵𝗼𝘂𝗴𝗵𝘁𝘀
Are you experimenting with DOP in Java yet, or are you still mostly in the OOP world?

How Not to Self-Reject Before You Even Try

Yodit Weldegeorgise — Mon, 12 Jan 2026 07:27:04 +0000

Hesitating before going after something new is extremely common. That pause can show up at work and after hours, often during quieter moments when people finally have time to reflect on their next steps and consider whether to apply, reach out, or move forward. It usually comes from self-doubt, fear of failure, low confidence, or imposter feelings. This is not a personal flaw. Research in psychology and workplace behavior consistently shows this pattern.

Leadership psychology research suggests that nearly 85% of people experience self-doubt at some point, even though most believe confidence is critical for success. This helps explain why people hesitate not only to apply for jobs or promotions but also to share their work publicly, reach out to mentors, enroll in new programs, or pursue opportunities outside their comfort zone.

Fear of failure plays an equally important role. Workplace studies show that over 40% of people say fear of making mistakes negatively affects how they perform. This fear does not stop when the workday ends. It shows up when people overthink resumes, delay applications, hesitate to send follow-up emails, or avoid networking opportunities because they worry about saying the wrong thing.

Imposter feelings add another layer. Peer-reviewed research shows that imposter syndrome is widespread across professions and experience levels. People experiencing it often doubt their accomplishments and fear being exposed as unqualified, even when their background clearly supports them. This frequently leads to avoiding interviews, declining visible opportunities, or staying silent in rooms where their voice belongs.

Taken together, these findings point to a clear pattern. Many people self-reject opportunities not because they lack ability, but because fear and self-doubt quietly push them into avoidance. Instead of taking a chance, they postpone applying for roles, talk themselves out of promotions, delay reaching out, or convince themselves they need more time.

This kind of rejection happens internally, long before anyone else is involved.

1. Self-rejection often hides behind “being responsible”

Self-rejection rarely looks dramatic. It usually looks like waiting.

One more certification before applying.

One more project before sharing work publicly.

One more year before asking for more responsibility.

What feels like being responsible is often fear reframed as caution. Many opportunities are designed for people who are still learning, not people who feel perfectly ready.

2. No one has actually said no yet

In many cases, no external rejection ever happens.

The application stays in drafts.

The email to a recruiter is never sent.

The promotion conversation keeps getting postponed.

Instead of hearing no from someone else, people decide the outcome themselves. The opportunity ends quietly, without feedback, clarity, or growth.

3. Confidence usually comes after action, not before

Behavioral psychology research consistently shows that confidence is built through exposure and repetition, not waiting.

People who seem confident did not start that way. They applied before they felt ready, spoke up before they felt certain, and learned that discomfort was survivable. Waiting to feel confident first keeps people stuck.

Action is what builds confidence.

4. Avoidance feels safer, but it limits growth

Avoidance reduces short-term discomfort. There is no rejection, no awkward moment, no disappointment.

But there is also no progress. Applying for jobs, interviewing, learning new skills, or putting yourself out there rarely locks you into a permanent decision. Trying and not getting selected still provides information. Avoiding keeps uncertainty alive.

5. Let the outcome live outside of you

Research on leadership and performance often emphasizes separating effort from outcome.

You can prepare.

You can show up.

You cannot control the result.

When people stop rejecting themselves on behalf of others, something shifts. A no becomes feedback, not a verdict. A yes becomes possible.

Self-rejection is quiet and often feels justified. Over time, though, it narrows what feels possible, professionally and personally.

You do not need certainty to move forward.

You just need to stop saying no before anyone else has the chance to answer.

Trying is not a promise that it will work.

It is simply a matter of choosing to stay in the process.

Sources (for readers who want to explore more)

Lara Morgan, leadership psychology research on self-doubt and confidence

https://www.linkedin.com/pulse/healthy-dose-self-doubt-lara-morgan/
Workplace Insight, Fear of Failure Holds People Back at Work

https://workplaceinsight.net/fear-of-failure-holds-people-back-at-work/
Bravata et al., Prevalence, Predictors, and Treatment of Impostor Syndrome,

Journal of General Internal Medicine

https://link.springer.com/article/10.1007/s11606-019-05364-1