DEV Community: Yodit Weldegeorgise

LinkedIn Live with Venkat

Yodit Weldegeorgise — Thu, 11 Jun 2026 06:46:39 +0000

Yodit & Venkat

Yodit: Today I have Dr. Venkat with me, and I'll let him introduce himself before we start.

Venkat: Hey Yodit, it's really great to talk to you. Thanks for having me on this program. It's a pleasure.

What can I say? I get excited about programming. I enjoy coding. I talk about programming, I share what I know, and I learn from others. That's basically what I do.

Yodit: To give a little backstory, I got to know about you in December 2025 from the local Java User Group organizer, Eric.

He was like, "Oh, in January he's coming. One of my favorite speakers is coming to this event, and I'm so excited."

I was like, "Okay, one of your favorites out of everyone?"

He said, "Yes, you should come and listen."

The moment he put it on the calendar, I started researching what you do, the books you wrote, your award winning books, and everything else. I thought, "Okay, I should go to that event."

There was no way I was going to miss it.

So I came to the Java User Group event in January, and I actually won this notebook.

I still use it. One side is for AI notes and the other side is for data structures and algorithms.

I also got to know about Arc of AI. I won one of the free tickets, which was very generous.

It's been a pleasure getting to know everyone there. I had a really good time at the conference.

But I have a question.

What is the thought process behind having two successful conferences in one year? Both of them are demanding, and I don't know the objective of each separately, but why not combine them?

Venkat: First of all, Eric is awesome. He's been running the Dallas Java User Group for such a long time, so I definitely admire all the effort he and others have put into the community.

One of the things I was very interested in, as I've been speaking at conferences for about twenty plus years now, is that I travel around the world. I spend a lot of time in Europe speaking at conferences as well.

One of the thoughts I had in my mind was this:

As I travel to these conferences, especially the ones in Europe, there are amazing speakers from around the world who come and share their knowledge.

My question was:

What if we could bring those speakers in so we can learn from them here at home?

That's basically the idea.

I live in Colorado, so I decided to start the conference in Colorado back in 2020, which, as we know, was the infamous year of the pandemic.

Everything got derailed because of COVID.

But we were persistent. We stayed with it long enough, restarted the effort, and our first conference was in 2024 here in Denver, Colorado.

We've run the conference twice so far in the Denver area, and we've had speakers from the U.S., Europe, Asia, and literally all over the world.

Part of the objective for me to start the conference was twofold.

One was: What if developers here could learn from expertise from around the world?

The second was: What if we could give opportunities to new speakers who are extremely good but just haven't broken into the conference space yet?

In all honesty, one of the things I've really enjoyed over the past couple of years is getting to know speakers who are really, really good, but I never knew about them before we started.

That is one of the objectives.

Coming back to your other question about separate conferences, when we started Dev2Next, as the name kind of alludes to, it was about what's next for developers.

As we know, the world has changed quite drastically over the past few years.

When we first put the conference together, there wasn't much discussion around AI.

The question was: What do developers want to focus on as the next thing?

The focus of Dev2Next has been entirely on architecture, DevOps, current trends, agility, and programming languages.

But more important to me are two other tracks that we don't often have enough of at conferences.

One is leadership.

The other is what I like to call wealth and wellness.

People ask, "Did you mean health and wellness?"

No. Wealth and wellness.

I'm a firm believer that money doesn't bring happiness, but money gives you leverage.

As developers, we spend so much effort on our jobs that we sometimes forget where we're going.

That becomes an issue when we become sixty five or seventy years old.

A lot of things in life take a long time to build.

It's very difficult to wake up one day and say, "I want to be healthy tomorrow."

You don't get to decide that when you're seventy.

You need to start when you're twenty, thirty, or forty.

The same thing applies to wealth.

You can't wake up one morning and say, "I want to be rich tomorrow."

Money takes a long time legally to build.

That's one of the reasons I wanted to focus on wealth and wellness, because both of those things take a long time to build.

Along the way, we had this burst of excitement around AI.

We wanted to create a conference focused on AI, and that's basically what Arc of AI is now.

As we know, the software field is pretty broad today.

We still have concerns like:

How do you get good at architecture?

How do you get good at DevOps?

How do you keep track of current trends?

So Dev2Next continues to focus on those topics, while Arc of AI focuses on AI related topics.

That's basically the reason for having two separate conferences.

As you would expect, there's some overlap.

At Dev2Next, there are talks that involve AI, but they're not AI specific talks.

They focus on questions like:

How do we use AI for DevOps?

How do we create architecture with the help of AI?

At the same time, there are talks focused entirely on architecture, DevOps, and other topics that are not related to AI.

So Dev2Next stays focused on what's next for developers.

Arc of AI, on the other hand, goes deep into almost every aspect of AI.

From using AI for software development to using AI within product development and everything in between.

I think these two conferences will continue to grow with different areas of emphasis.

Yodit: That's really good.

So if it had to be only one, maybe Dev2Next would swallow Arc of AI?

Venkat: I don't think the goal is to have one or to have many.

The goal is to provide value to the community.

Where do we provide the best value? That's the question.

One of the things you don't want to do is walk around with size 10 shoes and ask, "What feet can fit these shoes?"

The question is:

"Here are my feet. What shoes fit them?"

That's the question you need to ask.

The angle I take is not from running a conference.

The angle I take is from understanding what the community actually needs and then deciding based on that.

At some point, if we decide one conference is enough and provides the value people need, then obviously we won't continue running another one.

The goal is not to merge them or keep them separate.

The goal is to provide the right value to the community.

Yodit: One of the best things I liked about the conference was how deep it was.

You could go very deep or stay at a higher level depending on the session.

And there were no vendors trying to grab your attention.

It was purely educational content.

I really liked that.

Venkat: That's one of the key things for us.

Sometimes people ask us, "Where are the large companies? Why aren't they involved?"

That's exactly the point.

I'm glad you noticed.

We want practitioners sharing the journey they've taken, where they've benefited, and what struggles they've faced.

We don't want vendors coming in and selling products.

One thing we've heard repeatedly from attendees is that many conferences become marketing pitches from beginning to end.

People have told me:

"I've been to several conferences, but one thing that disappoints me is that everything feels like a marketing presentation."

Whereas here, they feel like they're getting exposure to ideas they can take back to their company rather than listening to a vendor explain why they should buy a product.

To me, one of the most valuable things in the world is time.

You might be willing to give me ten dollars.

But once you spend ten minutes, you're never getting that time back.

I value people's time a lot.

If you're going to give me ten minutes of your time, I want to make sure I give you ten minutes of value.

To me, that's the deepest form of respect.

When people spend time away from work, away from home, and travel to another city to attend a conference, I respect that.

I want to make sure they're receiving what they need to receive.

That's very important to me.

Yodit: Another thing that I liked about the conference was the description for speakers.

For example, if you're speaking, you may get paid or may not get paid depending on the outcome of the conference. It gives a sense of ownership as a speaker. It feels like everyone is working toward the success of the conference together.

I'm new to the conference world, but I hadn't seen that before.

That was another thing that really stood out to me.

Venkat: That was another thing that I really liked as we were thinking through this.

While there are a lot of nice conferences around the world, one of the challenges I hear from being on the other side, as a speaker, is that I get to sit down with speakers and listen to what they're saying.

A lot of times I hear speakers say:

"Hey, I'm spending money out of my own pocket to come and speak at this conference. My company is not paying for me to come. It's a huge burden on me to take time away from work, come speak, and still spend all this money."

The question for me was:

What can we do to support speakers who are not working for these large corporations?

People who are not being sent by their bosses to conferences, but who still have talent, knowledge, and expertise they want to share.

How can we support them?

In that regard, we decided to pay for travel for speakers who need travel support.

Now obviously, we don't have a bottomless budget. We can't spend money we don't have.

And in the United States especially, the conference market is extremely tight right now.

I'll be very honest about it.

Openness is something I really value.

We've been running the conference at a loss for the past several events.

Typically, we're losing about one hundred thousand dollars per conference.

But at the same time, we want to respect speakers who are not able to pay for themselves to come and speak.

So we're paying for speaker travel and accommodations for people whose companies cannot support them.

For those whose companies are able to support them, we're very thankful.

Again, the emphasis is that they're not coming to give a marketing talk.

One thing we've been very careful about is that the program committee has no visibility into which speakers are receiving travel support and which speakers have their companies paying for them.

They have no visibility into that.

The talks are selected entirely on their merit.

You'd be surprised how many talks we reject because they're marketing pitches.

We simply say:

"This is a marketing pitch. We're not going to accept it."

It doesn't matter if a company is willing to pay for the speaker.

We're not taking marketing talks into the conference.

Once the committee finishes selecting talks, then we look at the budget and ask:

How much money can we spend on travel?

Just to give you an idea, we're spending about twenty thousand dollars on travel expenses alone.

With twenty thousand dollars, we can bring a number of speakers, but we can't bring everyone.

If we have ten speakers from Europe who want to attend, that budget disappears very quickly.

So we have to balance things.

We look at the selected speakers and ask:

How many can we realistically support?

Maybe we bring a few speakers from different parts of the United States whose travel costs are relatively low.

Or maybe we bring one speaker from Europe.

Those are the kinds of tradeoffs we have to make.

If one speaker from overseas costs as much as four domestic speakers, we have to think carefully about how to balance that.

A lot goes into those decisions.

And then, of course, if we end up making a profit, and so far we haven't had that happen, we're not a money making machine.

We're here for the community.

If we make money, we want to put that value back into the community.

That's where profit sharing comes in.

We're doing this from the perspective of what value this brings to attendees, what value this brings to speakers, and what we can do to sustain the conference long term.

Right now we're not in a sustainable mode yet.

We're hoping the market improves and things get better.

But it's a journey.

Every opportunity is an opportunity to learn and improve.

We're here for the long haul.

We're here for the right reasons.

We're not here to make money in the short term and disappear.

That's not our goal.

This goes back to something I mentioned earlier.

Money doesn't bring happiness, but it gives you leverage.

The decisions we've made over the past few decades have given us enough leverage to weather these difficult periods and absorb these losses while building a really good conference.

From the outside, you see a good conference.

From the inside, it's been much harder than it may appear.

But we knew from the beginning that it wasn't going to be easy.

So the challenges aren't surprising.

If it's not challenging, anybody can do it.

Anybody can do it badly.

Our goal is not to do it badly.

Our goal is to do it really, really well.

And we're not going to be any less enthusiastic about delivering that value moving forward.

Yodit: I feel like if I were the organizer and I was trying to balance things while accommodating speakers, I might be tempted to accept vendors because that's where the money comes from.

But the fact that you have a strict boundary and say:

"No, we're not doing that."

and still try to make it work regardless is really impressive.

Venkat: That's the hard part.

It's easy to give in and do the wrong thing.

It's also important to keep costs affordable.

We don't want to charge an enormous amount of money.

At the end of the day, it's not just us making decisions.

There are employees who genuinely want to learn, get better in their careers, and bring value back to their companies.

They're often fighting internally to get approval to attend.

And I'll be absolutely honest.

There are attendees who pay for the conference themselves because their companies won't pay.

Sometimes they even take vacation time to attend.

Keeping costs affordable for them is very important to me.

If someone says:

"This conference will help my career. I'm going to take time off and pay for it myself."

then I want that cost to be within reach.

I don't want people feeling like attending will break the bank.

That's something we're very sensitive to.

We're balancing a lot of competing priorities.

If our goal were simply to make things easy on ourselves, there are a thousand routes we could take.

But the goal is not to be easy.

The goal is to be right.

And usually, the right thing is not the easy thing.

That's where the challenge really is.

Yodit: Speaking of AI conferences, what do you think is the most overhyped or underhyped thing about AI currently?

Venkat: The most overhyped right now is this illusion that somehow AI is going to take over everything and we don't need humans to do anything.

Especially within the programming world, the hype is that we don't need programmers anymore and AI is going to program everything.

I had somebody come to me and say, "You don't understand. I'm able to build software myself. We don't need programmers anymore."

It's a person I know fairly well, and I asked him a question.

I said, "I'm glad you're excited about it. That's great. But can you tell me what the cost of failure is for the software you're building?"

His answer was, "There's really no cost of failure because what I build does a few interesting things, but it doesn't have any impact on anybody's life."

If your software is not managing somebody's bank account, somebody's finances, somebody's insurance, a construction project, or flight tracking, then the cost of failure may be relatively small.

But if any of those systems fail, the cost is enormous.

Cost comes in two forms.

There's financial cost, and there's health or life related cost.

If software fails and prevents someone from getting to a hospital, or misguides them on the way to a hospital, you can imagine the consequences.

A bank making mistakes with transactions can affect people's ability to pay bills or buy groceries.

So when people say AI can generate code, my question is always:

Who is accountable when something goes wrong?

Organizations are still responsible for the systems they build.

They can't hand accountability to AI.

One of the examples I often think about comes from a trip I took in New Zealand.

We had just finished a wonderful day of sightseeing, and our driver said:

"We have two ways to get down."

"Option one will take about ninety minutes."

"Option two will take twenty seconds."

We all laughed.

Then he said, "I think you know which one I'm choosing."

"The ninety minute option."

"Because we'll still be alive to remember the trip."

To me, that's the whole point.

Your goal is not simply to go fast.

Your goal is to go safely.

Speed without discipline is not sustainable. :contentReference[oaicite:0]{index=0}

The biggest hype today is around the speed of AI.

People are excited because they can generate code quickly.

But sustainable software development is not about how fast you can write code.

It's about how quickly you can deliver value to customers while maintaining quality.

The good news is that this isn't hopeless.

There are good engineering practices that allow you to use AI effectively.

You just won't get that uncontrolled speed people are talking about.

You don't want the twenty second ride down the mountain if the result is disastrous.

You want something in the middle.

You want sustainable speed.

I think over the next few years the industry is going to go through that learning process and realize how AI should really be used.

To me, the speed of programming isn't important.

Business agility is important.

How quickly can I deliver results for the business?

How quickly can I deliver value to customers?

Delivering value doesn't just involve writing code.

It involves writing code that is maintainable.

When changes happen, you need confidence that those changes didn't break what was already working.

All the feedback loops we talk about in agile development become even more important when using AI.

AI combined with sustainable engineering practices will give us better results.

Not AI alone, but AI combined with good engineering practices.

Yodit: That's really nice.

So that's the overhyped part.

What would you say is the underhyped aspect of AI?

Venkat: One of my biggest aha moments has been realizing that while AI is not super good at writing code, it's fantastic at identifying issues in existing code.

I call AI an awesome investigator.

That's my definition of AI.

AI is really good at analysis, much more than generation. :contentReference[oaicite:2]{index=2}

I truly think that's underhyped.

We've already seen examples where AI has found bugs that have been sitting in systems for years, sometimes even decades.

I think that's where companies are going to gain tremendous value.

If organizations use AI to analyze existing code, detect problems, and analyze operational data, they'll gain much more value than many people realize.

The analysis aspect of AI is something we're going to benefit from significantly.

I don't think people are talking about that nearly enough. :contentReference[oaicite:3]{index=3}

Yodit: Speaking of thirty years ago, I was watching one of your interviews. I don't know if you remember it, but you talked about your first speaking event in Phoenix.

Let's go back in time.

If you could do that speaking event again today with everything you've learned over the last thirty plus years, what would you do differently?

Venkat: Oh my gosh. A lot.

I know exactly what you're talking about.

That was back in 1993.

Venkat: I was working on my PhD at that time, and as part of my PhD, I had a paper accepted to speak at a conference that was being held in Phoenix.

The entire talk was twenty minutes long, and I cannot even tell you how much time I spent practicing for that talk over and over and over again.

What I realize today is that when you're nervous, you practice very differently than when you're an expert.

That has been one of the biggest aha moments for me.

As a novice, you're practicing the talk repeatedly. Sometimes you're even trying to memorize exactly what you're going to say.

Then everything gets derailed because once you get there, you're absolutely nervous.

You're like a deer in headlights.

You're not really able to think through how to present because you're overwhelmed by the opportunity to stand in front of people and give a talk.

As an expert, you prepare very differently.

Today, I still prepare for talks, but I prepare very differently than I did thirty years ago.

So what would I do differently?

That's actually a difficult question to answer because as a novice, you cannot behave like an expert.

And as an expert, you shouldn't behave like a novice.

Part of life is going through that journey.

Part of life is going through the experience, learning from it, succeeding, failing, and getting better.

If I were to rethink it, maybe I would tone down the amount of practice I was doing and instead focus more on the subject I wanted to deliver.

I would internalize the topic more than the exact words I planned to speak.

That's really my focus today.

I want to internalize the topic deeply and then be able to speak about it.

The words get generated on the fly.

I don't spend time memorizing what I'm going to say.

I spend time understanding what I want to say.

There's a huge difference between those two things.

Yodit: So the reason I ask is because I'm going to be giving a speaking event. I'm going to be speaking at a conference in September.

The distinction you gave and the specific interview that I mentioned was the difference between storytelling and a tale.

Do you have an example of how to approach it? This could be the storytelling version, but this would be the tale version, and we should avoid that one.

Do you have a story?

Venkat: Yeah, I always say, tell a story but not a tale.

Stories are very useful to ground ideas in people's minds. Stories are very important.

A tale, unfortunately, distracts the audience from the main point, and they will lose interest in it.

For example, I could say AI is great for finding issues.

As an example, I was working on a production system where the team was struggling for six months. They couldn't find the issue, but we unleashed AI on it, and within a matter of seconds, it was able to point us to areas that we didn't even consider.

Sure, the programmers had to investigate further, but it really gave us focus and areas of interest.

That's storytelling right there.

A tale would be:

"Oh, you know what? This was in Flagstaff, Arizona. There was this company. I had to take a flight. I got there. My flight got delayed. I ended up being late..."

Now you're doing a tale, and people are wondering where this person is going and how this is related to the topic.

A lot of times people get derailed into the story, and the focus becomes the story.

That's when it becomes a tale rather than keeping the story relevant to the topic.

You have to surface back to the topic.

That is the distinction between those two.

You want to make it lively.

One of the key things is when you read good books, what do good books do?

Good books don't lay out facts and walk away.

Laying out facts in a talk is like giving vegetables to children and saying, "Eat it."

No child likes eating vegetables because vegetables are bland.

A mild amount of spice adds to the taste.

Your stories are the spice you bring to the food, to the facts, to the data, to the topic.

You want to sprinkle anecdotes and metaphors into your talk. Then people get attached to it.

Otherwise, the facts become too bland and people get bored listening to your talk.

You really want to look at these as two extremes.

On one side, you're delivering a set of facts.

You walk in and say:

"Here are the things you should do. Write tests. Have continuous feedback loops."

You plow through concept after concept.

People are sitting there thinking:

"I would rather paint my toenails than listen to this person."

Then you go to the other extreme.

You walk in and start telling jokes and endless tales.

For the first few minutes people chuckle and think it's funny.

Then after a while they start asking:

"Why am I here?"

"If I wanted a comedy show, I would have gone somewhere else."

This goes back to what I mentioned earlier.

As a speaker, I have to value the time of the people sitting in front of me.

One thing I often talk about is information density.

Information density is how much value you're providing within a given amount of time.

If I spend too much time telling tales, I'm lowering the information density.

If I only deliver facts, the information density may be high, but it becomes difficult to consume.

You have to strike a balance.

That's where stories and metaphors come in.

Stories and metaphors become carriers for the facts.

Think of them as a capsule.

You take medicine inside a capsule because it makes it easier to consume.

It's like the famous Mary Poppins song.

A spoonful of sugar helps the medicine go down.

A little story helps the facts go down much better.

That's the balance we need to strike.

Yodit: I heard this was designed by your son. The logo, right?

Venkat: Yes, the logo. He's a graphic designer.

Yodit: Did he come up and say, "Okay, I want to design it," or did you say, "Okay..."

Venkat: Oh no. I am better than that.

I'll tell you the true story.

I am good at a few things in the world. I am terrible at a whole lot of other things.

I was on a ten hour flight from Europe to the US.

I got on the flight and designed a logo.

It took me about an hour and a half to two hours.

When I finished designing the logo, I sent it to my family and said:

"Here's the logo for this new conference we're going to start."

Within a few minutes, my son replied back saying:

"Dear God, no."

So all I did was create an absolutely terrible design.

His reply was:

"Dear God, no."

And I'm like:

"What do you not like about it?"

He said:

"Dad, just chill. I'll get back to you."

I made him so angry that the only thing he could do was create a logo.

So he created one and said:

"What do you think of this?"

I'm like:

"I love it."

He kind of had these elements in mind about what I wanted in there.

Maybe one day in a museum we'll have my original logo, which only three people have ever seen in this world, and nobody else should ever see it.

Of course, that's the logo he designed.

Not because I asked him, but because I created a terrible logo.

That absolutely made him angry, and he had to go create a really good logo.

Yodit: The reason I bring that up is because some companies are staying away from hiring junior and mid level developers.

What do you think the cost will be if that pipeline starts closing?

Because now, because of the trust you had in your son and the opportunity he was given, we're all enjoying this amazing design.

If nobody had given him opportunities earlier in his career, maybe we wouldn't have this.

What do you think happens when companies stop investing in junior developers?

Venkat: I wouldn't say he's a beginner in this specific case because he has quite a bit of experience already.

But he got where he is because companies gave him opportunities.

They hired him and said:

"Hey, we see potential in you."

And that's important.

To go back to your question, think about the pipeline.

Today's juniors are tomorrow's experts.

Ten years from now, who are the experts going to be?

The juniors we have today.

If we don't give them opportunities to practice, to make mistakes, and to learn from the experts around them, eventually our current experts are going to retire.

They won't be here forever.

Then all of a sudden we wake up and realize we have a huge gap in the pipeline.

You can't wake up one morning and say:

"I need experts tomorrow. Where can I find them?"

Well, we prevented those experts from ever being developed.

Where are they supposed to come from?

Now, there will always be people who work very hard despite having fewer opportunities.

Some of them will still become experts.

But there will be fewer experts overall.

And guess what's going to happen?

Large companies have large budgets.

When they have large budgets, they can hire whoever they want.

The companies that will suffer the most are small businesses and medium sized businesses.

When they need talent, they're going to struggle because larger companies can attract whatever talent remains.

To me, the biggest challenge is the gap in the pipeline.

When the pipeline breaks, it takes a long time to repair.

People need time to grow into that level of expertise.

I hope we recognize that and continue creating opportunities for the next generation of developers.

Yodit: That's very true.

You speak all over the world.

Recently I saw you in Kenya. Other times you're in Europe and different places around the world.

What are the pros and cons of nonstop travel while also teaching, writing books, organizing conferences, and doing everything else?

Venkat: I would say the biggest advantage is that you continue learning.

To me, that's one of the most exciting things.

You continue to learn.

You broaden your mind.

You come back with new energy and new ideas.

I can't tell you how many ideas I've gotten for books, articles, talks, products, and projects simply from being around people and learning from them.

That's one of the reasons I keep going to user groups, conferences, and events.

It's a great learning experience.

And honestly, you don't always have to travel far.

Sometimes your local user group is one of the best places to continue learning.

On the other hand, there are downsides.

Time away from family is a big one.

That's a sacrifice.

You have to coordinate things differently.

You have to plan much further ahead.

You can't just jump into a meeting whenever you want.

You can't always meet a friend or relative on short notice.

Travel also affects your health.

You have to be careful about what you eat and where you eat.

If you're not careful, you can gain weight and develop other health issues.

One of the things I run into is hotel gyms.

Sometimes a hotel says it has a gym.

Then you walk in and discover there are two dumbbells and a treadmill that doesn't work.

So you have to get creative.

Maybe you find a nearby gym.

Maybe you run outside.

You figure it out.

There are times when I go to the gym at two in the morning because I have to leave for the airport at three thirty.

You work out, take a quick shower, and head to the airport.

Those are the sacrifices that come with it.

If you're someone who likes predictable schedules, regular sleep, and everything planned perfectly, travel may not be for you.

There are advantages and disadvantages.

It's like two sides of the same coin.

You don't get one without the other.

Yodit: Have you ever worked in a corporate environment as an employee?

Because when someone looks at your LinkedIn, it feels like you've always been doing conferences, consulting, training, and writing books.

Venkat: Yes, I did.

A long time ago.

My last job was in 1999.

I did have what I call a real job.

I've been gainfully unemployed for about twenty six or twenty seven years now.

Yodit: What is your job at the moment?

Venkat: I do consulting, training, mentoring, conference organizing, and corporate work.

I also teach part time at the University of Houston.

But that's only a small part of what I do.

My primary work is corporate training, consulting, and mentoring.

Yodit: How do you manage your time?

You have conferences, training, travel, writing books, family responsibilities, and all these different commitments.

How do you allocate your time?

Venkat: That's one of the things I've learned over time.

I would say my superpower is my ability to focus.

I am extremely focused on what I do.

I compartmentalize things very clearly.

I'm very self motivated.

When I start my day, it literally begins with a piece of paper that contains the things I need to work on.

I write down what I need to do.

Then I pick a task.

Until that task is done, I don't do anything else.

I don't check email.

I don't respond to messages.

I'm not on Slack.

I'm not constantly being interrupted.

One thing people don't realize is that I have notifications turned off completely.

My computer doesn't ping me.

My phone is configured so it only rings when my wife calls.

That's it.

Nobody else can interrupt me with a phone call.

And my wife knows she only calls if it's important.

We built that discipline intentionally.

As a result, I can focus.

If I want to write a chapter, I can sit down and focus for ten hours.

If I need fifteen minutes, I can focus for fifteen minutes.

If I need thirty minutes, I can focus for thirty minutes.

I don't multitask.

I compartmentalize.

When I decide to work on something, that's all I work on for that period of time.

When I'm done, then I move on to the next thing.

Another thing I do differently is I don't ask:

"How much time will this take?"

Instead, I ask:

"What can I get done with the time I have available?"

Maybe I have ten minutes.

Okay, what can I accomplish in ten minutes?

That's a different way of thinking.

When I'm at the airport, for example, my flight may start boarding at 10:30.

The worst thing I can do is sit there wondering if I'm going to miss boarding.

So I set an alarm for 10:30.

Then I open my laptop and start working.

At 10:30 the alarm goes off.

I close what I'm doing and walk to the gate.

Having that ability to focus helps tremendously.

Yodit: Were you always like this?

Venkat: No.

Not at all.

These are things you learn over time.

Being successful is about learning what works and changing what doesn't.

You try things.

You keep what helps.

You get rid of what doesn't.

Take notifications, for example.

At first they seem useful.

Then you realize you're being interrupted every few minutes.

That interruption comes at a cost.

People often tell me:

"Venkat, you reply so quickly."

The reason is I follow a simple rule:

Tell me now or tell me when.

I actually wrote about this a few years ago.

If you send me an email, I'll either reply quickly with the answer or I'll reply and say:

"I got your message. I'll get back to you on Tuesday."

Then it goes onto my calendar.

Now I know exactly when I'll handle it.

You know when I'll handle it.

Nobody has to keep following up.

I don't like having things hanging over my head.

If I don't respond for three days, people are going to email again and ask what happened.

Instead, I tell them when they'll hear back from me.

Being disciplined is also a way of respecting other people's time.

And when you respect other people's time, you're also respecting your own.

Those are lessons I learned over the years.

I wish I had learned them earlier.

But as they say, better late than never.

Yodit: Actually, when I reached out to you about doing this LinkedIn Live, I expected you to say:

"I'm traveling. I'm busy. I don't have time."

Instead, you gave me two options.

I picked the earliest one.

At the time, I didn't even know how to set up LinkedIn Live.

I had to go figure it out afterward.

So thank you.

I really appreciate it.

It means a lot.

Venkat: Thank you.

Honestly, I don't believe anybody is busy.

You'll never hear me say:

"I'm busy."

Nobody is busy.

We're just disorganized.

If we're organized, most things become manageable.

Yodit: You've written several books.

I might be off on the number, but is it fourteen or sixteen books so far?

Venkat: Something like that, yes.

Yodit: How does the writing process work for you?

When you're writing a book, do you stop your other commitments, for example speaking at conferences, events, training, and consulting?

Or do you still manage to work on everything in parallel?

Because that's a lot of books.

Even writing one book feels like a lot, dealing with publishers and everything else.

I was wondering how you manage to publish so many books.

Venkat: Most of the books I've written, I've written the first draft in one week or maybe one and a half weeks.

Usually I'll find a week like Thanksgiving.

That's a holiday week, which is great.

I lock myself in a room.

And I'm not saying that metaphorically.

I mean literally.

My family would pass food under the door.

For one week they don't see me.

I sit there and write the first draft.

I've done that for a few books.

For a few other books, I use travel time.

I go to Europe about twice a month.

That means I spend about eight to ten hours on a flight three or four times a month.

That's roughly forty hours right there.

Flights are great because nobody is calling you on the phone.

Nobody is pinging you.

Nobody is knocking on your door.

You get this moment of isolation that you normally don't get.

Typically, I get on a flight, open my laptop, and start writing.

I can often complete the first draft of a chapter during a flight.

If a book has eight chapters, that's eight flights back and forth to Europe and you've got a first draft.

The key is not being tempted to watch movies.

Instead, you sit down and write a chapter.

A lot of flights today have internet access, but years ago they didn't.

You got on a flight and there was no internet.

You either stared at the TV screen or stared at your laptop.

I preferred the laptop.

People often ask:

"Don't you need internet to write a chapter?"

Usually not.

By the time I'm writing, I've already done enough research on the topic.

There may be a few gaps I need to fill later, but I can leave placeholders and keep moving.

A lot of writing is really staring at the ceiling and trying to come up with a better example.

You ask yourself:

"Does this example work?"

"No."

"Maybe this example works better."

You're constantly refining your thinking.

On a ten hour flight, you can build a pretty good collection of examples and material for a chapter.

Yodit: Do you have a favorite book from all the books you've written?

Venkat: Every one of them is my favorite.

All of them.

Yodit: No hierarchy?

Venkat: No.

All of them.

To me, one of the reasons I write books is because I have a story to tell.

Usually I'm working on a topic, learning about it, or using it in practice.

Then I realize it's something interesting to write about.

I start seeing stories that would make the topic exciting and useful.

That's when I get excited about writing it.

Every one of the books came from that kind of experience.

So every book was my favorite while I was writing it.

Yodit: Should we expect a book on AI?

Because I feel like there are so many stories there.

Venkat: No.

I never plan books ahead of time.

I don't sit down and say:

"I want to write a book."

There is one book I want to write, but it's not technical at all.

And it's probably not going to get written anytime soon.

Other than that, I don't think about writing books in advance.

Usually a book idea comes to me minutes before I start writing.

I'll be on a walk or a hike and suddenly think:

"This would be a really good topic to write about."

Then I can't stop thinking about it.

I rush home and start writing.

That's usually how books happen.

I don't plan them ahead of time.

Yodit: Nice.

We covered a little about working with family.

I know you organize the conferences with your wife.

How is it working with family?

And by the way, the food was amazing.

I heard she's the one who created the buffet and organized everything.

The balance of healthy food, snacks, and everything else was really good.

Venkat: That's one of the things I've honestly enjoyed in this journey.

We've been married for more than thirty years now.

We're getting close to thirty five years.

But when she decided to work on the conference, I started seeing aspects of her that I didn't even know about.

You see somebody in a completely different role and with a different set of responsibilities.

It's been wonderful to watch her take on those responsibilities.

She'll suddenly send me a text or an email and say:

"We need to talk about this."

"I've got an idea."

Then she'll explain it and I'll think:

"Wow. I didn't even think about that."

That's amazing.

There's a lot of creativity that she brings to the table.

Raising a family is one thing.

But now that we're empty nesters, the question becomes:

"What are you going to do next?"

She's busier than ever.

She's running conferences and taking on so many responsibilities.

Honestly, I don't think I could do any of this without that kind of help.

It's been a great experience and I'm very thankful for it.

Yodit: Yeah, she was very welcoming.

I was really happy to get to know her as well.

I think there were around one hundred seventy five people at the conference.

It was amazing.

I got to do my first interview at the Utah Java User Group because of your recommendation.

That experience made me realize:

"Okay, I should do this more."

It's been a really fun journey so far.

Venkat: That's wonderful.

It's been great to see you take on these opportunities as well.

Thirty years from now, you're going to be on the other side talking about these same journeys.

Make sure you create good memories along the way.

Yodit: You're also a Java Champion, right?

I think we can close with that one.

How was your journey?

I know everyone's journey to becoming a Java Champion is different.

How was yours?

And if you have any message for developers who are just getting started, especially with AI and everything changing so quickly, you can wrap up with that as well.

Venkat: One of the things I often say is:

Get recognized for what you do, but don't do things to be recognized.

There's a very important difference there.

If you do things in order to be recognized, there are two problems.

The first is that you may not get recognized, and then you're going to be disappointed.

The second is that if you do get recognized, then you may feel like you've reached the finish line.

You might think:

"Okay, I got recognized. I don't need to do this anymore."

To me, that's the wrong reason.

I go out and do what I do because I genuinely enjoy it.

I enjoy being part of the community.

I enjoy sharing what I know.

I enjoy learning from others.

I help the community learn a little from me, and I learn a lot from them.

That's why I write books.

That's why I speak at conferences.

That's why I go to user groups.

That's why I continue showing up.

Today I probably speak at twenty five to thirty user groups every year.

If you look at my website, you'll see that I continue doing that consistently.

I didn't stop going to user groups because I became a Java Champion.

I continue doing it because that's something I've cared about for a very long time.

I go to events.

I volunteer my time.

I offer whatever help I can.

Then one day someone says:

"We've decided to recognize you as a Java Champion."

And my reaction is:

"Thank you."

But I'm not doing it because I want recognition.

And I'm not going to stop doing it because I received recognition.

To me, the idea is simple:

Be recognized for what you do, but don't do things to be recognized.

When you think that way, your focus stays in the right place.

You're working on things because you care about them.

The recognition becomes a bonus.

It's the cherry on top.

But it shouldn't be the reason you're doing the work.

Yodit: And what advice would you give developers?

Venkat: Help and be helped.

That would be my advice.

Help others.

Everybody benefits from helping.

But also be willing to receive help.

Don't be stubborn and think:

"I shouldn't ask for help."

There are people all around you who are willing to help if you simply ask.

I'm often surprised.

I'll go to a group and say:

"I'm here. If you need help, ask."

And very few people actually ask for help.

Even when they could benefit from it.

So don't hesitate to ask.

Help others and be helped by others.

That's one of the most valuable things you can learn.

Yodit: Amazing.

Thank you so much.

I know I booked one hour, but we're way past that.

Thank you so much.

Hopefully we'll get to do this again.

And hopefully we'll get to meet again at a conference or at a Java User Group here in Dallas.

Thank you again.

Venkat: Sounds good.

Thank you very much for having me.

And best wishes for all the things ahead for you as well.

Yodit: Thank you.

Have a good one.

Venkat: You too.

Bye bye.

Yodit: Bye.

𝐓𝐡𝐞 𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐒𝐭𝐲𝐥𝐞 𝐂𝐫𝐢𝐬𝐢𝐬

Yodit Weldegeorgise — Thu, 21 May 2026 19:22:32 +0000

𝐇𝐚𝐯𝐞 𝐲𝐨𝐮 𝐞𝐯𝐞𝐫 𝐭𝐚𝐤𝐞𝐧 𝐚 𝐩𝐞𝐫𝐬𝐨𝐧𝐚𝐥𝐢𝐭𝐲 𝐭𝐞𝐬𝐭 𝐚𝐧𝐝 𝐬𝐨𝐦𝐞𝐡𝐨𝐰 𝐞𝐧𝐝𝐞𝐝 𝐮𝐩 𝐪𝐮𝐞𝐬𝐭𝐢𝐨𝐧𝐢𝐧𝐠 𝐲𝐨𝐮𝐫 𝐞𝐧𝐭𝐢𝐫𝐞 𝐢𝐝𝐞𝐧𝐭𝐢𝐭𝐲?

𝐁𝐞𝐜𝐚𝐮𝐬𝐞 𝐭𝐡𝐚𝐭 𝐢𝐬 𝐞𝐱𝐚𝐜𝐭𝐥𝐲 𝐰𝐡𝐚𝐭 𝐡𝐚𝐩𝐩𝐞𝐧𝐞𝐝 𝐭𝐨 𝐦𝐞.

When I first opened the communication style assessment, I thought it would be simple. I thought I would answer a few questions, get my results, and quickly write my speech.

Instead, I ended up taking the assessment three different times.

That probably should have been my first clue about my communication style.

The assessment was difficult because it was not one of those personality quizzes where you simply select “strongly agree” or “strongly disagree.” For every question, I had to choose one word that described me the most, and that gave me cognitive overload.

The more I looked at the questions, the more I realized my communication style has evolved over the years. Different situations bring out different versions of me, so trying to reduce myself to one word felt almost impossible.

One of the first questions asked how others would describe me: gentle, fun-loving, results-oriented, or disciplined.

I stared at the screen for a long time because all of them felt true.

If you meet me while I’m traveling, making videos, attending conferences, or laughing with friends at a meetup, you would probably describe me as fun-loving. I genuinely enjoy experiences, meeting people from different backgrounds, and collecting memories through conversations and adventures.

But another side of me is very disciplined. That is the version of me that studies late at night for certifications, balances Toastmasters leadership with work and networking events, and joins intensive cohort programs while managing everything else happening in life.

Then there is the results-oriented side of me. Years ago, I made the decision to leave everything familiar behind and move thousands of miles across continents to pursue a completely different future. At the time, I had no idea how things would turn out. There was no guarantee of success, just hope, uncertainty, and the willingness to take a chance on myself.

As I continued through the assessment, the questions became even harder.

Another question asked how I like my appearance to be: formal, casual, stylish, or business-like.

Again, I struggled to choose one answer because my style changes depending on the environment. I enjoy dressing professionally at networking events and conferences, but I also enjoy creativity and fashion. I participated in a nonprofit fashion show, modeled, and even appeared in a magazine.

At one point I remember thinking, “Which version of me is this assessment asking about?”

Then came the question about support:
Do I want support for my goals, ideas, feelings, or thoughts?

I wanted to choose all of them.

Because as human beings, we want people to believe in our goals, understand our ideas, respect our feelings, and value our thoughts.

By the second time I took the assessment, I was still struggling enough that I ended up completing it with my mentor, Jen.

Looking back, that became one of the most meaningful parts of this experience.

As we went through the questions together, she helped me stop overanalyzing every word and instead focus on patterns in my behavior. She helped me think less about who I am in one moment and more about who I consistently become across different situations.

Then we reached the question asking how others may perceive me negatively.

The choices included indecisive, perfectionist, impulsive, and strong-willed.

I immediately laughed because I could relate to more than one.

I can absolutely be a perfectionist, especially in software engineering. I like clarity, structure, and understanding requirements before starting work.

Unfortunately, technology rarely works that way.

Requirements change. Information is incomplete. Sometimes you have to move forward before everything is fully figured out.

At the same time, I can also be indecisive in everyday life. Shopping is probably the best example. I can spend so much time comparing options that eventually I get tired and leave without buying anything at all.

When I took the assessment the third time, the results finally felt more balanced.

𝐒𝐮𝐩𝐩𝐨𝐫𝐭𝐢𝐯𝐞 was my highest score with a 5.
𝐈𝐧𝐢𝐭𝐢𝐚𝐭𝐢𝐧𝐠 came next with a 4.
𝐃𝐢𝐫𝐞𝐜𝐭 was 2.
And 𝐀𝐧𝐚𝐥𝐲𝐭𝐢𝐜𝐚𝐥 was 1.

But I still felt like my analytical side was higher than the results showed.

Because one of my favorite questions to ask is:

𝐖𝐡𝐲?

I naturally want to understand the deeper reason behind things. I like understanding root causes instead of only fixing surface problems.

While reflecting on my results, I realized something else too.

𝐈 𝐰𝐚𝐧𝐭 𝐭𝐨 𝐛𝐞𝐜𝐨𝐦𝐞 𝐦𝐨𝐫𝐞 𝐝𝐢𝐫𝐞𝐜𝐭 𝐚𝐧𝐝 𝐚𝐬𝐬𝐞𝐫𝐭𝐢𝐯𝐞.

That was probably the hardest part of the assessment for me because I naturally lean toward being supportive and understanding. I care about harmony, relationships, and how people feel.

But in the field I work in, being direct matters.

There are moments where clarity matters more than comfort. Moments where decisions need to be made confidently. Moments where communication needs to be assertive, especially in leadership and problem-solving situations.

That is when this speech stopped being just about a communication style assessment.

𝐈𝐭 𝐛𝐞𝐜𝐚𝐦𝐞 𝐚 𝐫𝐞𝐟𝐥𝐞𝐜𝐭𝐢𝐨𝐧 𝐨𝐧 𝐠𝐫𝐨𝐰𝐭𝐡.

The assessment helped me recognize both my strengths and the areas where I still want to improve.

At the end of all three assessments, one thing stayed consistent: my supportive side.

That result made sense to me because I value relationships deeply. I care about people, I enjoy encouraging others, and I try to contribute wherever I can.

So here I am, giving a speech about communication styles while still learning how to fully define my own.

𝐌𝐚𝐲𝐛𝐞 𝐭𝐡𝐞 𝐜𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐬𝐭𝐲𝐥𝐞 𝐜𝐫𝐢𝐬𝐢𝐬 𝐢𝐬 𝐧𝐨𝐭 𝐜𝐨𝐧𝐟𝐮𝐬𝐢𝐨𝐧.

𝐌𝐚𝐲𝐛𝐞 𝐢𝐭 𝐢𝐬 𝐬𝐞𝐥𝐟 𝐚𝐰𝐚𝐫𝐞𝐧𝐞𝐬𝐬 𝐡𝐚𝐩𝐩𝐞𝐧𝐢𝐧𝐠 𝐢𝐧 𝐫𝐞𝐚𝐥 𝐭𝐢𝐦𝐞.

Because once you truly understand yourself, you also begin to see where you still want to grow.

And for me, that growth starts with becoming more direct, more confident, and more willing to speak with clarity.

From Leading Myself to Leading and Guiding Others

Yodit Weldegeorgise — Thu, 30 Apr 2026 05:48:53 +0000

For a long time, I didn’t really see myself in leadership roles and never imagined I would be the person taking on that kind of responsibility.

Leadership felt like something for people who were more experienced or just naturally good at it, so I kept my focus on myself and what I could control.

I spent my time working on staying consistent, trying to get a little better every day, and showing up even on days when I didn’t feel like it, while setting goals, learning new skills, and slowly improving step by step.

There was no audience and no team depending on me, which gave me the space to focus on myself and really build a strong foundation.

Looking back now, I realize that phase helped me more than I expected because I learned how to stay consistent even when I didn’t feel motivated, how to manage my time while balancing work and learning, and how to get comfortable doing things that felt uncomfortable, like going to meetups alone or speaking up in rooms where I didn’t feel fully comfortable yet.

At the time, I didn’t think of any of this as leadership, but now I can see that I was actually learning how to lead myself.

Then I got nominated

When I joined Toastmasters International, my plan wasn’t very clear at the beginning, because I was still exploring what I needed and what would work best for me.

At first, I was actually looking for an in-person club since I thought that would be easier for me to connect and practice speaking, but while I was figuring that out, a leader, now my mentor, suggested that I join the Texas Tech Talk Toastmasters meeting for the time being so I could at least get started instead of waiting.

Since most of my career so far has been in an online setup, I realized that communicating clearly in that kind of environment is something I really need to get better at, and instead of avoiding it, I thought I might as well work on navigating it more intentionally.

I started paying closer attention to how people spoke, how meetings were structured, and how different roles contributed to the overall experience, and instead of just attending, I stayed a little longer after meetings, talked to more people, and tried to understand what was happening behind the scenes.

Then there was the District 50 Fall Conference, and for Texas Tech Talk members, it was free to attend, which made me think that since I was already planning to become a member at some point, I might as well join now, attend the conference, and get more involved.

At the same time, I still had it in mind that I would eventually find an in-person club and join that one later.

But that “later” never really came… yet.

I stayed, got more involved, and within two months, before I fully realized it, I was nominated to be Vice President of Membership.

I said no at first because I didn’t feel ready, I wasn’t sure what I would be doing, and I thought there were other people who would be better for the role.

But after talking it through and having a few discussions, I decided to give it a try.

As I started settling into the role, I paid closer attention to things I hadn’t noticed before, like how a guest feels when they join the meeting for the first time, how well they understand what is going on, and how comfortable they feel about coming back.

I realized that even small actions like following up after a meeting, acknowledging them when they join, and making sure they feel included in the conversation can shape how someone experiences the space.

I’m learning to navigate how to make guests feel welcome and, if they decide to become members, how to make the process smooth while encouraging them to stay involved.

Since I’ve learned how to lead myself, the transition into leading others, or even just helping guide them as they work toward their goals, has been really rewarding.

After stepping into that role, I was also nominated twice to be an Area Director, which I honestly didn’t expect, but at that point I already had a lot on my plate.

I also wanted to participate in the International Speech and Evaluation Contest, and according to Toastmasters rules, you can’t compete in those contests if you are serving as an Area Director, so I knew I wouldn’t be able to do both at the same time.

Because of that, I decided to decline and told myself that maybe I could take on that opportunity in the future.

After that, instead of moving to another club like I originally planned, I ended up renewing my membership again in March.

I’m still figuring things out as I go, and with the help of my mentors and fellow Toastmasters, I’m growing into the responsibility that comes with leadership.

𝗪𝗵𝗮𝘁 𝗜 𝗟𝗲𝗮𝗿𝗻𝗲𝗱 𝗳𝗿𝗼𝗺 𝗖𝗵𝗮𝗽𝘁𝗲𝗿 𝟮 𝗼𝗳 𝗔𝗜 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴: 𝗪𝗵𝘆 𝗦𝗮𝗺𝗽𝗹𝗶𝗻𝗴 𝗖𝗵𝗮𝗻𝗴𝗲𝘀 𝗘𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴

Yodit Weldegeorgise — Mon, 13 Apr 2026 04:42:09 +0000

When people talk about AI models, the focus is usually on training, such as how much data was used, how big the model is, or what architecture it uses.

That’s where most of the attention goes.

But Chapter 2 of AI Engineering made me focus on something that has a direct impact on how models behave in practice: 𝗦𝗮𝗺𝗽𝗹𝗶𝗻𝗴.

Sampling is how a model selects one output from many possible options. It might seem like a small detail, but it explains a lot of what we see in real-world usage, especially inconsistency and hallucinations.

𝗧𝗿𝗮𝗶𝗻𝗶𝗻𝗴 𝗜𝘀𝗻’𝘁 𝗝𝘂𝘀𝘁 𝗔𝗯𝗼𝘂𝘁 𝗠𝗼𝗿𝗲 𝗗𝗮𝘁𝗮

It’s easy to assume that more data leads to better performance, but that assumption breaks down quickly.

A model trained on a smaller amount of high-quality data can outperform a larger model trained on low-quality data.

What matters is finding the right balance between quantity, quality, and diversity. The model needs enough exposure to learn patterns, the data needs to be reliable, and it needs enough variety to generalize well.

This aligns closely with how we think about data in backend systems. Clean and well-structured inputs tend to produce more reliable outputs.

𝗖𝗼𝗺𝗽𝘂𝘁𝗲 𝗙𝗼𝗿𝗰𝗲𝘀 𝗧𝗿𝗮𝗱𝗲𝗼𝗳𝗳𝘀

AI systems don’t scale in isolation. They scale within constraints.

Larger models and datasets require more compute, and compute directly translates to cost.

In practice, teams don’t start with the biggest possible model. They start with a budget and design within that limit.

This is where the 𝗖𝗵𝗶𝗻𝗰𝗵𝗶𝗹𝗹𝗮 𝘀𝗰𝗮𝗹𝗶𝗻𝗴 𝗹𝗮𝘄 becomes useful.

Before jumping into large numbers, it helps to understand one term:

A 𝗽𝗮𝗿𝗮𝗺𝗲𝘁𝗲𝗿 is a learned value inside the model that helps it make decisions. More parameters mean the model can learn more patterns, but it also needs more data to train properly.

Now, think of the scaling rule like this:

1 parameter → ~20 tokens

Then scale it up:

1B parameters → ~20B tokens
3B parameters → ~60B tokens

The pattern stays consistent. As the model grows, the data needs to grow with it. Otherwise, you end up with a larger model that isn’t fully trained and doesn’t use compute efficiently.

This matters because it directly affects how we make decisions when working with AI systems.

In practice, we are constantly choosing between models, deciding whether to fine-tune, and balancing cost with performance. This concept gives a way to reason about those choices.

For example, a larger model isn’t automatically better if it wasn’t trained with enough data. That explains why smaller, well-trained models can sometimes outperform larger ones.

It also applies when fine-tuning. Adding complexity or expecting better results won’t help unless there is enough high-quality data to support it.

Even when using APIs, this changes the mindset. Instead of defaulting to the biggest model, the focus shifts to whether the model was trained efficiently and whether it fits the use case.

So this is not just a scaling rule. It becomes a way to guide model selection, fine-tuning decisions, and cost vs performance tradeoffs.

𝗙𝗿𝗼𝗺 𝗣𝗿𝗲-𝗧𝗿𝗮𝗶𝗻𝗲𝗱 𝗠𝗼𝗱𝗲𝗹𝘀 𝘁𝗼 𝗥𝗲𝗮𝗹 𝗦𝘆𝘀𝘁𝗲𝗺𝘀

A pre-trained model is not ready for production use.

It is optimized for predicting the next token, not for producing useful, safe, or aligned responses.

That’s where post-training comes in.

𝗦𝘂𝗽𝗲𝗿𝘃𝗶𝘀𝗲𝗱 𝗳𝗶𝗻𝗲-𝘁𝘂𝗻𝗶𝗻𝗴 teaches the model how to respond using structured examples. However, that alone is not enough.

𝗥𝗟𝗛𝗙 (𝗥𝗲𝗶𝗻𝗳𝗼𝗿𝗰𝗲𝗺𝗲𝗻𝘁 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗳𝗿𝗼𝗺 𝗛𝘂𝗺𝗮𝗻 𝗙𝗲𝗲𝗱𝗯𝗮𝗰𝗸) introduces a feedback loop that improves alignment.

A 𝗿𝗲𝘄𝗮𝗿𝗱 𝗺𝗼𝗱𝗲𝗹 is trained to evaluate how good a response is. Instead of relying on absolute scoring, models often learn from comparing multiple responses, which helps reduce inconsistency.

Then RLHF uses that feedback process. The model generates responses, the reward model scores them, and the model is updated to favor better responses over time.

This process helps align models with human expectations, not just in correctness but also in tone, safety, and usefulness.

𝗔 𝗛𝗶𝗱𝗱𝗲𝗻 𝗥𝗶𝘀𝗸: 𝗧𝗵𝗲 𝗤𝘂𝗮𝗹𝗶𝘁𝘆 𝗼𝗳 𝘁𝗵𝗲 𝗜𝗻𝘁𝗲𝗿𝗻𝗲𝘁 𝗜𝘁𝘀𝗲𝗹𝗳

Models are trained on internet-scale data. That means whatever exists online, whether accurate or misleading, can influence how models behave.

As more AI-generated content is published, there is a growing risk that future models will be trained on synthetic or incorrect information.

It is also possible for bad actors to intentionally introduce misleading content into the internet so that future models learn from it.

This turns into a data integrity problem, not just a modeling problem.

As engineers, this means we need to be more mindful. Not all data sources are equally reliable, and blindly trusting model outputs becomes riskier over time.

𝗪𝗵𝘆 𝗔𝗜 𝗙𝗲𝗲𝗹𝘀 𝗜𝗻𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝘁

One of the most important ideas in this chapter is that AI models are 𝗽𝗿𝗼𝗯𝗮𝗯𝗶𝗹𝗶𝘀𝘁𝗶𝗰 𝘀𝘆𝘀𝘁𝗲𝗺𝘀.

That means the same input can produce different outputs, and even a small change in input can lead to a noticeably different response.

This behavior is driven by 𝗦𝗮𝗺𝗽𝗹𝗶𝗻𝗴.

It also explains 𝗵𝗮𝗹𝗹𝘂𝗰𝗶𝗻𝗮𝘁𝗶𝗼𝗻𝘀, where the model generates responses that sound correct but are not grounded in fact.

𝗗𝗲𝘀𝗶𝗴𝗻𝗶𝗻𝗴 𝗔𝗿𝗼𝘂𝗻𝗱 𝗣𝗿𝗼𝗯𝗮𝗯𝗶𝗹𝗶𝘀𝘁𝗶𝗰 𝗦𝘆𝘀𝘁𝗲𝗺𝘀

This chapter didn’t introduce completely new ideas to me, but it helped connect things more clearly.

In backend systems, I’m used to building deterministic workflows where the same input leads to the same output. This chapter reinforced that AI systems don’t behave that way.

Instead, AI systems need to be designed with their probabilistic nature in mind.

That shows up in practice. Outputs need validation instead of blind trust. Prompting and constraints act as control mechanisms. Fine-tuning becomes a tool for consistency, not just improvement.

AI systems are shaped by the data they are trained on, the compute used during training, the post-training process, and the sampling strategy that generates outputs.

Sampling is what makes models flexible and useful, but it is also what introduces variability.

Understanding that tradeoff is what makes AI engineering more practical.

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

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.

𝗗𝗼 𝗶𝘁 𝘀𝗰𝗮𝗿𝗲𝗱.