DEV Community: Yodit Weldegeorgise

Community, Careers, and the Courage to Show Up

Yodit Weldegeorgise — Mon, 28 Sep 2026 04:04:22 +0000

After taking a little break from LinkedIn Live because of conference preparation, I came back with Taylor Desseyn, Vice President of Global Community at Torc. We first met at CYC 2025, and after seeing everything Taylor and the Torc community have been doing, I knew there was a lot we could talk about.

We planned for about 30 minutes.

We ended up talking for almost an hour.

We didn’t exactly have a smooth start to the LinkedIn Live. A few minutes in, my connection dropped and Taylor suddenly found himself hosting my Live by himself. He kept the Live going and continued talking while I worked my way back in.

You should definitely watch the video for that part because the written version won’t do it justice.

Once I rejoined, we got into what we were actually there to talk about: community, career growth, AI, content creation, DevRel, speaking, and the importance of showing up.

Community, CYC and Torc

Yodit: We can start with introducing yourself.

Taylor: Sure. I’ve been helping engineers really get to work for the last 15 years. I’ve spent nine years of my career really focused as a heads down recruiter. I’ve probably placed, at this point, over 5,000 engineers in new jobs.

Lately, I’ve moved into this community building role. What I tell people is that what I do now is I’m still a recruiter, but I’m not a one to one recruiter. I help people at scale.

So, get people connected through in person events, help provide high value content to navigate your career and job search through virtual events, and various other things as well.

Basically, 15 years in the engineering industry recruiting engineers, and again, excited to be here.

Yodit: That’s amazing. First, I have a question. Where do you get your energy?

Because we just wrapped up CYC 2026, and I’m still recovering. I saw you already online yesterday. When I messaged you, like, “How do you feel about our LinkedIn Live?” I was expecting you to say, “You know what? I’m tired. Let’s reschedule for next week.”

Taylor: I’m gonna be honest. It’s a little performative based. I kind of view myself as an actor. I know it’s weird to say.

The reality of it is, if you really wanna see who I am, ask my wife, because I’m definitely not as charismatic all the time.

But the reality is I get excited to help people. I’ve been in the industry for 15 years.

People ask me, “Where do you get your energy? How do you continually show up?”

Because I’m an introvert.

Yodit: I wouldn’t have guessed that!

Taylor: Everyone’s like, “I don’t know how you’re an introvert.”

But the reality is that I have learned over the course of years how to conserve my energy and when to exert my energy.

People joke with me. I don’t stay out for networking events. When I go to a conference, I’m usually in bed by 9:00. If it’s a dinner, I go right home. I don’t go to drinks after.

I’m pretty regimented in my time.

But I do that because I wanna be able to give as much energy to people as I feasibly can.

Yodit: That’s amazing.

I remember when we met at CYC 2025, you had a booth for Torc, and I was asking, “This is too good to be true. What is the catch?”

Taylor: There’s no catch.

I think what we’re doing at Randstad Digital and Torc, the way I tell people is, think of Microsoft as Randstad Digital and think of LinkedIn as Torc.

We’ve built our own internal version of LinkedIn that helps people get jobs. We really created an inner circle.

I think one of the biggest issues with the job search right now is all the applicants.

This is actually my second livestream today. I had Guidance Counselor 2.0 earlier today, and we talked about the thousands of applicants.

What we’ve done with Torc is built a platform where, if you sign up, you can specifically get access to jobs that other people don’t have access to.

However, we have layered that with the community approach, which is basically DevRel.

Instead of putting out documentation on the latest APIs or our latest framework, we actually help provide value through your career and job search.

It’s the resume reviews. It’s the LinkedIn reviews. It’s the Q&A fireside chats we bring into the community. It’s the upskilling. It’s the in person events.

My mom said the same thing.

My mom was like, “So how much do you charge for this stuff?”

And I was like, “Nothing. It’s free.”

She was like, “You’re kidding me?”

I think we have a good thing going. We can always be better. We’re always pivoting. We’re actively looking at our feedback from our events through Luma and pivoting.

But I truly think we’ve built a foundation to really help people navigate their careers.

Yodit: That’s amazing. I feel like that’s one of the reasons you really sync well with the CYC community. They also have that same community driven approach.

This was my second time at CYC. For you, comparing the previous one with this one, do you see any change?

Taylor: There are a lot of storylines with Commit Your Code for me.

Danny and I met during COVID virtually. He started to really get into the streaming tech world, and he was looking for people to come on and review LinkedIns.

I just slid into his DMs. I was like, “Hey, let’s do it. You seem like a cool guy.”

He and I hit it off.

Actually, our stream together has 91,000 views on YouTube, which is crazy.

I still get people coming up to me. They’re like, “I’ve watched that religiously for years.”

That’s a storyline for me.

The other storyline is that Commit Your Code was kind of our first official conference.

We showed up in the States as a community team for Torc in 2024. The 2024 one, I believe, was in September, and I started in August, so that was kind of our first one.

It has been really cool to see Danny’s evolution and what he’s built.

It has also been really cool to see our evolution because the very first Commit Your Code, I threw a little informal hangout. About five people showed up for lunch.

The next year, we threw a dinner. About 30 people showed up.

Then we threw our in person event at Commit Your Code this time, and we had about 75 people show up.

It has been really cool to see the evolution of not only what Danny has built but also what we’ve built.

It’s those storylines converging.

There’s a lot of overlap. Danny is really passionate about helping people get to work. So am I.

I always love showing up and supporting.

Yodit: I was actually at the after party this time at Hideaway. It was really good, and a lot of people showed up. I was surprised.

The community is growing very fast. I remember it was, how many thousand was it?

Taylor: We’re over 5,000 in Discord.

I actually found out we’re over 10,000 in our Luma community too. And that’s not even sharing the actual deep numbers. I don’t wanna share specifics.

But we’ve grown our North American user base 320% this year.

There are different levels to this thing.

We’ve been able to not only grow the brand from a public perspective but also grow the community as it relates to Randstad Digital and helping people get jobs.

Yodit: I remember I told you this when we met in person. I thought you were the founder of Torc.

Taylor: I get that a lot!

Mike Morris, if you watch this, I’m not the founder.

Mike Morris and Dave Messenger are, but they’ve trusted me to be the very vocal voice of it, so I’m very grateful for that.

Content, Community and Showing Up

Yodit: Obviously, you’re doing amazing.

I also see you post YouTube videos. I remember seeing the vlog you did for Arizona. It was almost, I believe, 17 minutes, and I watched it in one go. It was so good.

I was wondering, do you overthink?

For example, for me, I started one community driven YouTube channel. I have my personal YouTube too, but sometimes I feel like I’m supposed to be consistent, and now it’s holding me back.

How do you keep consistent, be genuinely energetic in the videos, and keep showing up?

Taylor: It’s exhausting.

The Phoenix vlog, the Raleigh vlog, and now we’re working on the Commit Your Code vlog. All of those I’ve shot myself.

I shoot all that myself, and then I have a few editors I work with that are great.

But it’s hard.

There are some conferences where I would love to just show up and not take one photo and one video.

But the reality is that the way marketing and branding work, you have to always be upfront and center.

And I wanna document the ride.

The reality is that you can go back now and watch all of the Commit Your Code vlogs, and you’ll see a change.

I’m really passionate about helping people, but I’m also really passionate about storytelling and bringing people along for the ride.

I pull a lot from run clubs or CrossFit or Hyrox, all these brands, fashion brands that build in public and bring people along for the ride.

I talk about it all the time. You have these kids that start a T shirt company and they go viral.

And it’s like, we’re out here helping people land jobs.

So what could I do and what could we accomplish if I mimicked what these companies are doing but brought it to the corporate world?

That’s why a lot of our stuff doesn’t feel overly corporate.

I really like to have more of an organic, natural approach to it.

I think it’s worked.

Yodit: It’s actually working. People are getting jobs, and the community is growing.

I like the fact that there are so many different things. There’s the Laid Off Lounge and also the Friday one. What was the Friday one?

Taylor: Yappy Hour is our networking hour.

Then we have our Laid Off Lounge.

The Laid Off Lounge is kind of a more intimate version of Guidance Counselor 2.0.

It’s basically where we bring in people who have been through the job search or hiring managers who can help answer questions.

It’s very informal.

We do that because we realized people are more willing to ask questions and be engaged in Discord than in public streams.

We’re actively trying to pivot and figure out how to gain more engagement.

When it comes to Yappy Hour, that’s our weekly networking session.

Then Roxy has her podcast, She Ships, highlighting women in tech.

Obviously, I have my podcast, Guidance Counselor 2.0.

Then we also have our career audit sessions, where we review resumes, Torc profiles, and LinkedIn.

We do a lot.

Yodit: I remember you saying it’s hard for you to keep up with the Discord messages.

There are different communities providing different values.

For someone also trying to job search and attend all these amazing sessions, how do you get the best out of it if you can’t be present for all the content?

Taylor: This is something I actively think about because the reality is I can’t get into Discord all day. I’m in meetings all day.

I’m constantly thinking about how we engage with the Gen Zs out there. The Gen Zs are in Discord, but then you also have the boomers who aren’t gonna get in Discord.

For us, if you wanna be engaged with what we do, show up to a stream.

Show up to an event. We do a lot of in person events.

I think that’s a great start.

There was a decision I made to go with Discord instead of Slack.

But there have been more conversations about, as we grow in 2027, we’re in 2027 planning now, should we spin up a Slack?

Should we have a Slack just for people who want to use Slack?

The whole point of community is meeting people where they’re at.

If we’re making people use Discord and they don’t wanna use Discord, that is not meeting people where they’re at.

The reality is we’re such a lean team. We just have to pick where we wanna go right now.

I found out the other day there are other communities within Randstad Digital on Microsoft Teams.

So it’s like, do we need to be on Teams?

These are all the things.

Community building is a very hard and vague thing. You kind of just have to know how to do it.

The Discord has grown from a few hundred members when we started in 2024, when there were almost no messages being sent, to now over 5,000 members and about 16,000 messages in a month.

Yodit: Wow. That’s amazing.

Mentorship and Career Growth

Yodit: What is the rewarding part?

For example, is it people getting a job or even the fact that they just show up after a long week on Friday and feel refreshed?

How do you summarize that?

Taylor: We have a mentor mentee program.

We took a break because we’ve been traveling so much. We’re gonna spin it up again in October.

One of our mentees got matched to a mentor and found a job because of the relationship with the mentor, not even through us.

Yodit: Wow.

Taylor: That’s kind of the whole thing.

There’s no silver bullet when it comes to your job search.

Do I wish we could place every single person within Torc and Randstad Digital?

Of course I do.

But the reality is we probably can’t.

So for us, it’s providing all this other value.

It’s the resume reviews. It’s all the things we’ve talked about.

I had a guy come up to me at All Things Open AI in March when I spoke in Raleigh.

He came up to me and goes, “Hey, you don’t know me, but I just wanna let you know I hopped into your resume reviews in Discord. Jason reviewed my resume, and because of the changes he made me do, I got an internship, and I’m moving out to California.”

All of these conversations.

We literally have a Slack channel of feedback that I screenshot.

There was one today. Somebody messaged around CYC.

They said, “I caught up with Roxy at the Friday event. I started following advice available from Danny Thompson and watching some of the reviews on the Torc Discord. I then got my resume reviewed and LinkedIn reviewed by the Torc Discord.”

After updating from the reviews, their LinkedIn profile views from recruiters went from something like 50 ish in 90 days to nearly 600 in the past 90 days.

They said, “I would say I average about three recruiters per day in my DMs, sometimes as many as 10.”

Yodit: Wow.

Taylor: The reality is that we’re here to help you find a job, whether it’s through us or not.

Yodit: You mentioned the mentor mentee relationship at Torc. How can someone be part of it?

Taylor: Sign up for the newsletter.

That’s kind of our faucet of information.

We send it out once a week. It literally comes from my team. We write it every week.

The mentor mentee program will obviously go pretty hard on social when we announce it, and we’ll send it through email.

We’ll probably open up sign ups in October.

The way we’ve done it in the past is anywhere from five to 10 mentors in a specific skill set and anywhere from 25 to 50 mentees.

We pair them up based on what they wanna do.

Is it a technical side?

Is it more of a career side?

We’re going to Argentina in two weeks for a conference. Once we’re back, we’re gonna turn on the faucet and start our mentor mentee program sign ups.

We’re gonna redo it.

If I’m gonna be honest with you, if you work for me, Brianna, Roxy, Jason, and Amanda can all attest to this.

I’m like, “Burn it down. Let’s rebuild it.”

We’re gonna burn down the mentor program again and rebuild it.

We don’t know if it’s gonna be super organized with tasks or if it’s more just on the person. More to come there.

But we’ll have sign ups.

We’ll also be opening up ambassador sign ups.

Our ambassador team is, in my opinion, top notch.

We’ll be opening ambassador sign ups in November.

If everything goes to plan, the awards and rewards our ambassadors will get will be more than they’ve ever been.

If you just wanna help people and be an advocate for what we’re building, we’ll have sign ups in November.

Yodit: I didn’t know there was a reward.

I was actually about to ask about Jeff because he’s everywhere in Discord. Is he part of the team?

Taylor: The way I treat the ambassador team is very similar to the way Bandit Running treats their influencer program.

I really view the ambassadors as an extension of our team.

We have a really lean team just because of budget.

We have an ambassador only chat in Discord.

We constantly get feedback from them.

I have a few of them on a text message basis where they have direct access to my phone.

If they need me, if there’s anything broken, if there’s anything we need improved, I tell them to do it.

Jeff has been massive in helping us run Discord with Roxy.

We’ve had a bunch of other ambassadors who help us with posting and gaining visibility for what we’re doing.

Shout out to Pat Clark.

I actually don’t know if Pat Clark is technically even an ambassador, but he’s a VP of Engineering in Raleigh Durham.

He went to our meetup for All Things Open that we were sponsoring last night and presented on behalf of us.

That has been really, really cool.

I appreciate Jeff and everybody who has helped us.

Yodit: When people register for the mentoring program, does it end after six weeks? Is it ongoing until someone gets a job?

Taylor: I don’t know.

Again, this is kind of the whole “burn it down, rebuild it.”

We did have a curriculum.

I don’t think it was necessarily well received.

I think people really want to be able to go at their own pace and have their own questions.

If I’m just pontificating here, I think what we’re gonna do is have a technical track and a job search track.

That is something we’ve kind of done in the past, but not really.

Again, taking a book out of Danny and Commit Your Code.

Our technical track will probably be very focused around AI literacy.

Maybe we’ll do a Java track because we’re in a lot of enterprise shops.

Then we’ll have a job search track or career track where you can hop on and go over how to write a LinkedIn, how to write a resume, and all that stuff.

More to come there.

But that’s kind of high level what I want our next mentor program to be: a technical track and a job search or career track.

Then we’ll probably cap it at three months.

I’ve done mentor programs before through the University of South Carolina.

Sometimes you just run out of things to talk about.

I don’t wanna have a six month program and string people along.

So we’ll probably keep it super short, super concise, three months.

Then if you wanna continue with your mentor afterward, you can.

Yodit: When you put a deadline toward something, people will put more into it.

Taylor: People want deadlines as much as they don’t want deadlines. They do want deadlines.

Yodit: And separating the career and technical tracks is good because not everyone has the same goal.

Taylor: Exactly.

We’re starting 2027 planning now with me and Brianna, and I think we’re gonna have much more incentives for our ambassadors next year.

But again, I appreciate all the ambassadors now who have taken a chance on us and have just done it for the love of the game.

We appreciate it.

Yodit: We kind of started talking about layoffs. Have you ever been laid off?

Taylor: Technically, I chose to move on with all of my opportunities.

But the reality is, if I did not choose to move on, I would have been laid off.

There was kind of writing on the wall.

So yes, I have left two jobs now at this point in my career.

Yodit: Was the transition easier for you? Did it take longer?

Taylor: I’ve been doing what I do for a long time.

I have a very deep network of folks, which is why I continue to preach: do these streams, show up, do a podcast, do something, get connected with people.

My job searches both times took less than a month, which I was very fortunate about.

If it happened again, I don’t know. I think it would take me a little longer.

When I left Vaco, I documented my job search.

I talked about what I was doing each day and all this stuff.

Everything I preach is everything I do.

Yodit: Yes, I’m a witness.

DevRel and the Changing Job Market

Yodit: We have a question in the chat about transitioning into DevRel and insights into the job market.

Taylor: I saw an interesting post the other day by Hank Taylor.

Shout out to Hank. He’s great.

He was formerly at Vercel, and he was recently at Laravel. He’s more of a technical marketer.

He has a podcast called Developer Marketing or something. I listen to it. I promise, Hank, I just forgot the title.

He and his friend Gonto were talking about how DevRel is kind of splitting.

There is developer experience, the documentation and things like that, which can increasingly be done with AI.

Then there is the public facing stuff: the streams, the events, the personality.

While I am not traditional DevRel, everything I tell my team to do has helped people get jobs.

Jason Torres got promoted out. Our community manager got promoted out and went to JetBrains.

Amanda Cruz, who was our Latin community manager, did the steps on my team and then she got promoted out.

I love Roxy to death, but the reality is I know somebody’s gonna pick her off within two years because she’s a gem, even though I don’t want them to.

You have to stream.

You have to be comfortable streaming and developing educational videos.

Josh Cirre at Laravel, I think, is one of the masters at it.

Even Aaron Francis, I know he’s VP of Marketing and Community now at Laravel, but he has been great at video.

You have to understand videos, how to create videos, how to run a booth, and understand the developer ecosystem.

Do you write?

Does your stuff get engagement?

It’s all of those things.

AI is taking over more of the operational work, which makes it even more important for Developer Relations people to be front and center and comfortable streaming, executing events, etc.

Which is everything we do with my team. We just aren’t a SaaS company.

Yodit: Speaking of Aaron, being more active on LinkedIn, starting my blog, and doing all these videos actually started from listening to his keynote speech at CYC 2025.

I tagged him, but I don’t know if he read it or not.

That’s where I got the inspiration to be this active on LinkedIn.

Taylor: Aaron’s great.

Aaron and I had coffee in Dallas last week.

We caught up and exchanged notes on how I’m running my team and how he’s running his team.

There’s a lot of overlap, which was cool.

I highly recommend checking him out.

Yodit: I didn’t even know he was in Dallas.

AI, Work and Careers

Yodit: Speaking of AI, I saw your post this morning.

It said 72% of employers say they cannot fill their roles, yet there are so many people out there job searching.

It’s kind of funny to navigate.

What was that post about?

Taylor: You need to pivot.

I think the problem is people aren’t pivoting.

I talked about this morning on my Guidance Counselor 2.0 stream.

People are like, “I’m just a frontend React guy or gal. That’s all I’m gonna do.”

But the reality is that you have to start integrating AI.

These companies want AI first developers, but people don’t use it, so the jobs stay open.

If I did what most developers are doing right now in my role, I wouldn’t do half the stuff I’m doing.

But the reality is I’m leveraging AI in so many aspects that I’m fully AI native at this point.

I have bots running.

I have Claude for writing.

I have automations set to trigger.

I’m fully orchestrating everything through AI.

The reason I do that is because I have aspirations of taking on more of a marketing role, branding, community, kind of the whole thing.

What I’ve seen is companies now want marketers who can do the whole thing by themselves.

Aaron Francis posted it yesterday. He goes, “Every role now is a technical role.”

Every role.

And that is using AI.

My thing is, the jobs are still open because you have Java developers not using any AI.

They are still writing hard lines of code, which is fine.

But that’s what backs up that stat.

People aren’t pivoting.

People are sticking their heads in the sand thinking this is a fad.

This is not a fad.

It’s only gonna get better or worse depending on how you look at it.

If you stick your head in the sand for another year, I don’t know if you’re gonna be able to find a job.

That’s my hot take.

I have people in my DMs now who are not pivoting and who can’t find jobs.

It’s already happening.

Yodit: There’s an interesting distinction there.

Everyone uses AI now, but are you building something? Are you really integrating it?

Taylor: There’s a difference between using the chat feature on ChatGPT and using Grok bot to manage your entire content process.

There’s a difference between asking Claude to write a post and setting up sessions in Claude to monitor your social media analytics or email response rates.

They’re different.

Most people think, “I’m gonna use AI,” and it’s just like my mom asking ChatGPT something.

That’s not using AI.

You need to be able to fully orchestrate your entire day job using AI.

Right now, in this moment, Grok bot is pinging me because it is working in the background.

I have Muse that I’m trying out now. It’s going in the background right now.

I have other tools running right now on various other tests.

So I have three or four different AIs running these orchestration processes to help me do my job.

This is a hot take, but if you are not interested in AI, that is a signal that you’re not interested in learning and changing, which most companies act as a red flag.

If you’re just like, “I’m not gonna use it,” to me that’s like, “Well, then you’re not flexible to work with. So why am I gonna hire you?”

Yodit: Someone in the chat said they just added AI to their roadmap and are working on positioning soon. Do you think they should go all in?

Taylor: Yes.

If I were looking for a job, I’d be like, “I’m an AI first growth community marketer.”

And I can specifically pinpoint all of these orchestrations I have going now.

I will say Grok bot gets heavy on usage because I have a lot of things going with Grok bot right now, and it eats the usage.

But it is what it is.

Yodit: Do you think companies are willing to train people who want to go in that direction?

Taylor: No.

You know why?

Because you don’t need a company to train you using AI.

The reason I say that is because I am the pure definition of a nontechnical person who is fully AI native at this point.

You don’t need to pay for AI training.

You just do it. Figure it out.

Every task I do, every micro task, I ask myself, “Can this be automated with AI?”

Every task.

You can go on YouTube and train yourself.

You know what’s great about AI?

You can just ask it.

If you want someone to train you on using AI, you’ve missed the entire point.

AI can train you how to use AI.

This whole corporate training of, “We need to train people how to use AI.”

No.

You just need to be interested in using AI.

The first thing I do with any of these AI tools I use is say, “Hey, what can you do? How can you help me?”

I start there.

Yodit: But aren’t all these tools expensive?

Taylor: It depends.

What do you wanna do?

They are expensive.

My wife has had a conversation with me.

She goes, “You need to stop spending so much money on AI bots.”

I said, “I understand.”

So I cut them.

If there’s not immediate value, I cut it.

But how much money do you spend eating out a month?

How much money do you spend getting cold brew, like myself?

How much money do you spend on gaming?

The reality of the situation is we all have money we can put toward AI.

It’s how valuable you think AI is for your career.

I would say they’re not all expensive.

The tier above free for Claude is $20 a month.

I don’t think that’s expensive.

Some people may think it’s expensive, but the reality is that $20 a month could help you land your next job.

Yodit: What kind of things are you using AI for?

Taylor: I created a job search tracker on Claude.

That would have been within the $20 a month plan.

I have Grok bot going through all my YouTube videos, cutting them up for me at a super high level and creating a thumbnail.

I stream a lot, so I’m trying to condense everything.

Grok bot is doing all that.

I have another set of bots as my chief of staff internally.

I have one bot that’s project managing our whole team right now within Torc.

Yodit: Wow.

I actually don’t have X, but after seeing some of the CYC 2027 sponsors and everything around the corner, I was thinking, okay, maybe I should create X.

I see there’s a lot of technical stuff there too.

Taylor: Listen, I know people have thoughts on X.

I get it.

But I will tell you this: if you are not consuming X and seeing where the market is heading, you’re gonna get lost.

I don’t see that type of chatter on Bluesky.

I just don’t.

The reality is X is where a lot of the trends and things are heading.

I’ve learned a lot there.

I would pay $100 a month for X if it were subscription based.

Yodit: For me, it’s not about whether I like this or that.

It’s just that I don’t wanna add another platform where I’m scrolling.

I already have LinkedIn, and it might be good enough for something like that.

But I see it could also be useful to get more technical stuff, which I would like to.

Taylor: I think the technical trends are massive.

Yodit: My chat has never been this active. I love it. This is amazing.

Another thing I wanted us to cover is taking a break.

When you had paternity leave, you had to be away for, I don’t remember, was it three months?

How was coming back after a break?

Was it an easy decision to take the break in the first place?

Taylor: It wasn’t three months. It was about two months.

It was eight weeks.

I’m super grateful for Randstad Digital having an actual paternity leave and being able to help my wife.

It was good for me to reset.

The reality is I’m always on.

We’re going on a beach trip in October, and I’m gonna put it on the record: I’m gonna put my phone away.

I’m always answering emails, always answering chats, always answering texts.

Being able to unplug and focus on the baby, my wife, and our other two kids, we have three, was very beneficial.

Yodit: That’s amazing.

I think we have a question from the chat.

“I feel that, yes, bots are doing things for you and you’re moving fast, but what’s the point?”

Taylor: That’s the whole point.

You’re asking, “What’s the point?”

That is the whole point.

That’s what companies want.

Companies don’t want you to do manual labor anymore if it can be automated.

If you are not leveraging AI to be a 10x developer, whatever term you wanna use, that’s the whole point.

The whole point is to move faster.

The velocity at which we ship on my team is insane, and we have a very small team.

The reason for that is because I’m fully AI, Brianna’s fully AI, Roxy’s fully AI.

We do more.

We have contractors, but in terms of core full time people, there are only about five of us.

The reality is our output is like 15 people.

I’ve been told that on the record by multiple people.

It’s because of AI.

Get Over Yourself and Start Putting Yourself Out There

Yodit: You mentioned being more visible, streaming, and engaging with your followers or people who see you.

But what if someone is really stuck in analysis paralysis?

For example, I have something I want to do around data structures and algorithms.

I want to solve questions and put them on YouTube.

But it holds you a lot.

You’re like, “Okay, let me do this,” and then you postpone it.

Especially if you’re not used to being on camera, it can be hard to take that step.

I’m used to being on camera now because of LinkedIn Live, and if I’m having that issue, imagine people who have never done it before.

It would be a lot harder to take that step.

What do you recommend?

Taylor: I’m gonna say something that may ruffle some feathers.

Get over yourself.

My boss said this a while ago.

He said, and I quote, “You’re not that important.”

What he meant by that is nobody cares.

The reality of the situation is you’re like, “I don’t wanna post.”

But that’s one of the ways to really get anywhere these days.

People are like, “That’s not fair. It shouldn’t be that way. What about introverts?”

Why do you think I post so much?

Because I’m an introvert, and I leverage content.

You realize I very rarely walk into a room now where I don’t know people because of content.

The content opens doors.

The content is the thing that gets you warm conversations.

This whole argument that I have with people sometimes where it’s like, “Well, I’m an introvert. It shouldn’t be this way.”

It is.

I would always recommend putting yourself out there.

Build, build, build.

Good things will happen.

Yodit: Is that specifically for people who are interested in DevRel?

Taylor: No.

Anybody.

If I had time, I’d probably create content around this whole “dumb guy learning AI” situation.

You can be whoever and post whatever, and you can become known for that thing.

There are multiple people in our Torc community who aren’t senior, but they post about one thing over and over again.

In my mind, they’re known as that person now.

I’ve been encouraging my mom.

She’s in her 60s.

I told her, “You need to start a Substack and just talk about what you like.”

My mom loves AI agents too.

I got my dad using AI, which is crazy. My dad loves it.

You just talk about this stuff and become known for it.

I was known as a recruiter for a bit.

Now I’m known as a community person.

Now I’m trying to be known as the guy who tries all these AI bots.

It’s not for one person.

It’s not for one skill set.

You just need to put yourself out there.

Yodit: Another thing I want us to cover is the speaking engagements you have.

I know we scheduled for half an hour, but we can end with this one.

How was your speaking journey?

What was the first time you did it?

Because I did my first conference talk at CYC, and it was terrifying.

Taylor: I started speaking back in 2013.

That’s when I started getting involved in meetups.

I started going to the .NET meetup in Raleigh, which was very active at the time.

I started getting to know the guys and girls.

Finally, I became kind of the trusted confidant of the .NET group as this recruiter who actually cares and knows what he’s talking about.

So I got invited to speak at a code camp.

There are different levels to this thing.

Code camps were kind of your introduction.

I don’t see a lot of code camps anymore. I don’t know if they’re still going strong.

But back in 2013 and 2014, there were a lot of code camps.

It was usually a free event at a community college, usually on Saturdays.

My very first talk was totally Q&A.

There were no slides or anything.

I had the hour leading up to lunch.

We got to lunchtime, and I said, “Alright, guys, y’all can leave. It’s lunchtime.”

Nobody left.

Yodit: Wow.

Taylor: People went to get their lunches and came back in.

So I went for two hours on my very first talk.

Then I kind of got hooked after that.

I’ve iterated.

I’ve come up with talks.

I’ve been rejected a ton.

There are still a lot of conferences I would love to speak at that I’ve never spoken at.

It has been this evolution.

I used to be really big on no slides.

Now I use slides.

At All Things Open in October, I’m giving a three hour workshop, which is crazy.

The only other workshop I’ve given was at Commit Your Code two years ago, which I still have people talk about as probably one of my best talks.

I’m giving a three hour talk on how to use AI in your job search and career in October in Raleigh.

It has just been an evolution.

Like I said, I’ve been rejected a ton.

For the most part, all my talks have gone well.

I’ve had some that maybe didn’t go as well.

I’ve presented sick before.

It has definitely been a journey.

But I would highly recommend everybody start speaking.

Meetups are just gone, by the way.

One of the biggest pieces of feedback we get for Torc is, “Oh my gosh, I’m so glad you’re doing this. Nobody’s doing meetups.”

It has been really awesome to bring meetups back to cities through Torc.

Yodit: What is your favorite talk ever?

Taylor: I think there are a few that stand out.

Obviously, my very first talk ever at Raleigh Code Camp in 2013 was the Q&A talk about how to use recruiters.

I answered every single question.

I didn’t shy away from anything.

I think the Commit Your Code talk was still one of my best talks.

It was about how to write your resume, how to write your LinkedIn, and really how to get started on your job search.

Then I would say probably the other talk that really stands out, I mean, there have been a lot of talks that stand out, but I spoke in Barcelona at Spring I/O, which is one of the larger Java conferences in Europe.

It was a completely packed room at a Java conference.

I had 250 people in the room.

It was insane.

I’m very, very grateful for that.

Yodit: Wow, congratulations with all this.

Taylor: Yeah, and someone in the chat asked about the topic for CYC.

I don’t know if it was recorded. I think it was recorded. If you go through the archives, maybe ask Danny.

But that one was before all the AI hype.

So I was like, open up your resume, how to create your resume, how to create your LinkedIn, all that stuff.

Yodit: Yeah, and those LinkedIn Live sessions for LinkedIn and resume review, they’re really helpful.

They helped me a lot.

Oh my God, it’s almost one hour.

Thank you, thank you, thank you so much.

Thank you everyone for showing up in the chat also.

We actually should do this again, like after three months or something.

Taylor: Yeah, let me know.

Yodit: Thank you. Thank you for coming.

Taylor: Absolutely. See you guys. Have a good one.

Your API Is Someone Else’s Dependency

Yodit Weldegeorgise — Mon, 21 Sep 2026 17:10:06 +0000

When I was preparing for my Commit Your Code conference talk on common mistakes developers make when building Application Programming Interfaces, commonly called APIs, I started by looking back at a Java project I had worked on during a six-week cohort that was part of Commit Your Code.

While we were building that project, I had already started paying closer attention to some of the decisions we were making around the API, especially how we named our endpoints, how we handled errors, where validation was happening, and what we were returning to the client. The application worked, and we built a lot together in six weeks, but there were also things I felt we could revisit and improve.

I think that is true for almost anything we build, in software and in life in general. There is almost always room for improvement when we come back to something with more experience, more context, or simply a different perspective.

Then the Call for Papers (CFP) for the Commit Your Code conference opened. I was one of the early people to submit, and part of that was intentional because I did not want to self-reject. I knew that if I gave myself too much time to think about whether I was ready to speak at a conference, I could easily start finding reasons to wait, prepare more, or apply another year, so I applied before I had enough time to change my mind.

Another reason the topic felt right was because of what I had already noticed while working on the cohort project. There were API decisions I wanted to understand better, and there were areas I thought we could revisit. Not because the project was bad, but because that is part of building software. We make decisions based on the time, knowledge, and experience we have, and later we often see things we would do differently.

That became the foundation of my talk. As I started researching those technical topics more deeply, I became curious about how the same ideas showed up outside of our project. I did not want to talk only about naming conventions, validation, status codes, Data Transfer Objects, versioning, and error handling as technical best practices. I wanted real examples that would make those ideas easier to understand and remember.

So I started looking at real-world cases. That research led me to Apollo and Reddit, DoorDash, Facebook and Cambridge Analytica, Square, and several other incidents. The situations were very different, but I started noticing something they had in common: your API is someone else’s dependency. Once another developer, application, or business builds on top of an API, decisions made on one side can affect much more than the team making that decision.

Eight Years of Building, Then the Rules Changed

One of the examples I found very interesting was Apollo, a popular third-party Reddit application created by developer Christian Selig. Over the years, it grew from an application he was building into his full-time work, and by the time Reddit announced changes to its API pricing in 2023, Apollo had been developed for roughly eight years.

When the pricing was announced, Selig calculated what it would mean based on Apollo’s existing usage. Apollo had made around seven billion API requests in the previous month, and at Reddit’s announced price, he estimated that continuing to operate at that level could cost almost $2 million per month, or more than $20 million per year.

That made me look at API changes differently because from the platform side, the decision could be described as changing API pricing, while from Apollo’s side, the same decision affected whether a product that had been built and improved for years could continue operating.

The timeline was another important part of the story. Selig said developers had about 30 days between learning the pricing and when the new charges would begin, which meant he would have needed to rethink Apollo’s payment model, transition existing users, test changes, and get an updated application through review within that period. He ultimately announced that Apollo would shut down on June 30, 2023.

Before researching this, API versioning was mostly something I thought about from the technical side. We talk about keeping version one available while introducing version two, providing documentation, announcing when an older version will be retired, and giving developers enough time to migrate, but the Apollo example made the other side easier to see.

There may be years of someone else’s work sitting on the other side of that API contract. A change that takes one internal team a few hours to implement can create weeks of work for developers consuming it. A new pricing model can determine whether another product is still financially possible, and a short migration period can force another team to make decisions much faster than they expected.

This does not mean an API should never change. Technology changes, security needs change, products evolve, and businesses make new decisions. For me, the lesson was that how we introduce change matters just as much as the change itself. If people depend on what we have built, communication, documentation, migration time, and backward compatibility matter too because someone else may have built something important on top of what we created.

When Retrying Makes an Outage Bigger

DoorDash gave me a completely different example. This was not about intentionally changing an API. It showed how one struggling part of a system can create problems across many other parts of the product.

During a DoorDash outage on June 19, 2021, latency began increasing in internal payment APIs while resource usage also increased. Services used by Dashers started showing errors, and the system began experiencing cascading failures.

Retrying a failed request normally sounds reasonable because network problems happen and services temporarily become unavailable. Trying again can sometimes solve the issue without the user even noticing anything went wrong, but it looks very different when thousands of requests start failing at the same time.

Services depending on DoorDash's payment infrastructure continued sending requests after failures. Each retry added more traffic to systems that were already struggling, and DoorDash reported that calls to its payment systems eventually reached around five times the normal volume. The logic that was supposed to help recover from a failure was now adding more pressure.

What made this useful for me was seeing how something happening inside one part of the system reached people far outside that API. Dashers were affected, customers had difficulty placing orders, and DoorDash eventually stopped accepting new consumer orders while engineers worked to stabilize the system.

From the engineering side, there were several services, dependencies, resource limits, and retry behaviors involved. From the customer side, it was much simpler because they could not order food. For a Dasher, it could mean they could not accept work, while for a restaurant, food might already be prepared and waiting.

That is one thing we can easily forget when we spend a lot of time looking at architecture diagrams. Users do not experience our architecture. They experience the outcome. They do not know which service is unavailable, which database query became slow, or which internal API started returning errors. They know whether they were able to do what they came to do.

This also changed how I think about error handling because an error response does not end when the server sends it. Something on the other side has to decide whether to retry, wait, stop, inform the user, or use another option, which means the way we handle failures is also part of the experience we create for systems depending on our API.

The API Was Doing What It Was Allowed to Do

The Facebook and Cambridge Analytica example made me think more about how much data an API should expose and how far that access can extend.

Aleksandr Kogan created a Facebook application that collected information from people who used it. Under Facebook's platform permissions at the time, the application could also collect profile information connected to those users' Facebook friends, even though those friends had not interacted with the application themselves.

According to the Federal Trade Commission, the application collected Facebook data from approximately 250,000 to 270,000 people who directly interacted with it, as well as data associated with roughly 50 million to 65 million Facebook friends in their social networks.

A much smaller group of people directly interacted with the application, but because of the way the platform permissions were designed, the reach of the data collection expanded to tens of millions of people. That connected directly to another topic I was researching for my conference talk: returning database entities directly through an API.

Imagine an entity contains twelve fields, but the client only needs four. Returning all twelve may feel easier because we do not have to create another class, map fields, or write additional code, but now we have exposed more information than the client actually needs.

Maybe today those extra fields seem harmless. Later, one of them could contain sensitive information, another developer might start depending on a field we never intended to support publicly, or our database structure might change and suddenly the API response changes with it. The convenience is on our side, but the consequences can reach the people depending on the API.

A Data Transfer Object (DTO) gives us a way to decide intentionally what information leaves the application instead of exposing everything available in the database. In this context, it is not only about adding another layer to the code. It gives us more control over the contract we expose to another system.

Sometimes Nothing Is Down and the Experience Still Feels Broken

Apollo, DoorDash, and Facebook are big examples, but for my conference talk I also wanted something that almost anyone who has applied for a job could relate to. That is where an Applicant Tracking System (ATS) came into the conversation.

An Applicant Tracking System is software companies use to manage job applications, résumés, candidates, and different stages of the hiring process. If you have applied for several jobs online, you have probably interacted with more than one Applicant Tracking System even if you never thought about the software behind the application.

You find a job you want, start the application, create an account, upload your résumé, fill in your work history and education, and answer several questions. Then somewhere in the process, the application does not let you continue because maybe one field is missing, something is in the wrong format, or the page tells you there is an error without clearly showing where the error is or what needs to change.

I used a screenshot of an Applicant Tracking System experience in my conference slide because it made validation easy to relate to. From the engineering side, the system may actually be working correctly because the backend receives the request, the validation logic catches incorrect input, the database is running, and the server is healthy. Nothing has technically crashed, but the person filling out the application may still feel stuck because they cannot figure out what needs to be fixed.

That is why validation and error handling became more than coding topics for me. A useful error response is part of the user experience. If an API receives invalid input and only returns a generic message saying something went wrong, we have rejected the request but we have not helped much. If the response clearly identifies which field is incorrect and what is expected, the next step becomes much easier because the goal should not only be to reject bad input but also to help the person or system understand what to do next.

The Mistakes Started Looking Different

By the time I finished researching my Commit Your Code talk, I was looking at the API decisions from our six-week project differently. Inconsistent naming was no longer only about code style because inconsistency can make working with an API unnecessarily confusing and stressful for another developer.

Validation was no longer simply about where a Java annotation belonged because it affected whether the client could understand what was wrong and how to correct it. Error handling was no longer simply about choosing between Hypertext Transfer Protocol (HTTP) response status codes such as 400 Bad Request, 404 Not Found, or 500 Internal Server Error, because the response could influence what the system on the other side does next.

Returning database entities directly was no longer only an architecture discussion. It connected to privacy, coupling, and deciding exactly what another system should receive. Versioning was also no longer simply about putting version one or version two in a Uniform Resource Locator (URL), the web address used to identify a resource, because Apollo showed how much another developer may have built on top of the contract we are changing.

The API Has Users Too

When we design a user interface, we naturally think about the person interacting with it. We ask whether they can understand what they are looking at, recover after making a mistake, understand what changed, avoid seeing information they should not see, and complete a task without unnecessary frustration.

I think APIs deserve the same level of thinking. The person using the API may not be clicking a button and may instead be another developer building an application on top of our service, but they are still a user and they also want a clear, consistent, and as stress-free as possible experience.

We should think about whether they can understand the responses they receive, whether errors help them understand what needs to be fixed, whether they have enough time to adapt when we introduce a breaking change, and whether they receive only the information they actually need. We should also think about how changes or failures in our API can affect the systems and people depending on it, because developer experience eventually becomes part of someone else's product experience.

Your API Is Part of Someone Else’s Experience

The closer we are to a codebase, the easier it becomes to assume other people understand what we understand. We know why a field has a strange name, why one endpoint behaves differently from another, which exception creates which response, and which internal service depends on another service somewhere else.

The developer consuming the API does not know all of that, and they should not have to. They experience the contract we give them, which is why consistency, useful validation, clear error responses, careful data exposure, versioning, documentation, and migration time all matter.

After going through all of this research, one idea summarized it well for me: your API is someone else’s dependency. For Apollo, that dependency was connected to a product that had been built over roughly eight years. For DoorDash, problems inside interconnected services eventually affected Dashers, merchants, and customers. For Facebook, the way data access was designed allowed information connected to people who had never interacted with the application themselves to be collected.

For someone filling out a job application through an Applicant Tracking System, the result may simply be frustration because an error message does not clearly explain what needs to be corrected. The scale is very different, but the idea is similar because the API is not the end of the story. Someone is using it to accomplish something else.

That is why, after doing this research, I think one of the most useful questions we can ask when building an API is not only “Does the API work?” but also “Can the person or system depending on it succeed?” Your API may look like one endpoint inside your codebase, but to someone else, it may be an important part of what they are building.

References

Reddit / Apollo
Christian Selig. Apollo will close down on June 30th: Reddit’s recent decisions and actions have unfortunately made it impossible for Apollo to continue. Reddit, June 8, 2023.
Apollo shutdown and Reddit API pricing announcement

Square
Square Developer. Incident Summary: 2017-03-16. This was one of the additional retry-related incidents I reviewed while researching the talk. The incident describes retry behavior that allowed up to 500 attempts without backoff and contributed to pressure across Square services.
Square incident summary

DoorDash
DoorDash Engineering. Our June 19th Outage Explained. The postmortem describes payment API latency, cascading retries, traffic reaching roughly five times normal levels, and the effect on Dashers and consumer orders.
DoorDash engineering outage postmortem

Facebook / Cambridge Analytica
Federal Trade Commission. FTC Sues Cambridge Analytica, Settles with Former CEO and App Developer. July 24, 2019.
Federal Trade Commission Cambridge Analytica case release

Federal Trade Commission. FTC sues Cambridge Analytica for deceptive claims about consumers’ personal information. July 24, 2019.
Federal Trade Commission Cambridge Analytica case details

Applicant Tracking System example
The Applicant Tracking System example comes from the screenshot and personal experience I used in my Commit Your Code presentation rather than an external case study.

𝗕𝗼𝗼𝗸 𝗥𝗲𝘃𝗶𝗲𝘄: 𝗙𝗼𝘂𝗿 𝗧𝗵𝗼𝘂𝘀𝗮𝗻𝗱 𝗪𝗲𝗲𝗸𝘀

Yodit Weldegeorgise — Sun, 30 Aug 2026 04:06:25 +0000

Last Saturday, August 22, marked the 𝘀𝗲𝗰𝗼𝗻𝗱 𝗮𝗻𝗻𝗶𝘃𝗲𝗿𝘀𝗮𝗿𝘆 𝗼𝗳 𝗮 𝗹𝗼𝗰𝗮𝗹 𝗯𝗼𝗼𝗸 𝗰𝗹𝘂𝗯 𝗜 𝗮𝗰𝘁𝗶𝘃𝗲𝗹𝘆 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗲 𝗶𝗻, and our discussion was on Four Thousand Weeks: Time Management for Mortals by Oliver Burkeman.

The title of the book comes from a very simple idea. If someone lives to around 80 years old, that is 𝗮𝗽𝗽𝗿𝗼𝘅𝗶𝗺𝗮𝘁𝗲𝗹𝘆 𝟰,𝟬𝟬𝟬 𝘄𝗲𝗲𝗸𝘀 𝗶𝗻 𝗮𝗻 𝗲𝗻𝘁𝗶𝗿𝗲 𝗹𝗶𝗳𝗲𝘁𝗶𝗺𝗲. When we think about life in years, 80 can sound like a long time, but when you convert it into weeks, 4,000 suddenly feels much more limited.

Here are seven ideas from the book and our discussion.

𝟭. 𝗧𝗶𝗺𝗲 𝗼𝗻 𝗮 𝗰𝗼𝗻𝘃𝗲𝘆𝗼𝗿 𝗯𝗲𝗹𝘁

The book describes the idea of treating time like a 𝗰𝗼𝗻𝘃𝗲𝘆𝗼𝗿 𝗯𝗲𝗹𝘁, where another hour arrives and we feel pressure to fill it productively before the next one comes. We finish one task, move to another, and keep trying to clear everything, even though there will always be more things waiting for our attention.

The book also gives a relatable example with email: 𝘁𝗵𝗲 𝗺𝗼𝗿𝗲 𝗲𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁𝗹𝘆 𝘆𝗼𝘂 𝗿𝗲𝗽𝗹𝘆 𝘁𝗼 𝗲𝗺𝗮𝗶𝗹𝘀, 𝘁𝗵𝗲 𝗺𝗼𝗿𝗲 𝗲𝗺𝗮𝗶𝗹𝘀 𝘁𝗲𝗻𝗱 𝘁𝗼 𝗮𝗿𝗿𝗶𝘃𝗲 𝗶𝗻 𝘆𝗼𝘂𝗿 𝗶𝗻𝗯𝗼𝘅. Becoming faster does not always create more free time, because sometimes it simply creates more capacity for additional work.

That led us into a conversation about 𝗲𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝗰𝘆 𝘃𝗲𝗿𝘀𝘂𝘀 𝗲𝗳𝗳𝗲𝗰𝘁𝗶𝘃𝗲𝗻𝗲𝘀𝘀. Becoming faster at doing something can be useful, but it is also important to ask whether that thing needs to be done in the first place. Sometimes efficiency should mean reducing unnecessary work instead of simply finding a faster way to do more, especially because every decision has an opportunity cost and the time we give to one thing is time we cannot give to something else.

𝟮. 𝗔𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻

𝗔𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻 𝗶𝘀 𝘁𝗵𝗲 𝗯𝗲𝗴𝗶𝗻𝗻𝗶𝗻𝗴 𝗼𝗳 𝗱𝗲𝘃𝗼𝘁𝗶𝗼𝗻.

Having time for something and actually giving it our attention are two different things, and that made me think about how we practice and work toward our goals. The number of hours we put into something matters, but so does the 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗼𝗳 𝘁𝗵𝗲 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲, 𝗼𝘂𝗿 𝘀𝗲𝗻𝘀𝗲 𝗼𝗳 𝗱𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻, 𝗮𝗻𝗱 𝗵𝗼𝘄 𝗶𝗻𝘁𝗲𝗻𝘁𝗶𝗼𝗻𝗮𝗹 𝘄𝗲 𝗮𝗿𝗲 𝘄𝗵𝗶𝗹𝗲 𝗱𝗼𝗶𝗻𝗴 𝗶𝘁, because simply spending more time on something does not automatically mean we are making better progress.

𝟯. 𝗧𝗵𝗲 𝘄𝗮𝘁𝗲𝗿𝗺𝗲𝗹𝗼𝗻 𝗽𝗿𝗼𝗯𝗹𝗲𝗺

The book uses an example involving a watermelon to show 𝗵𝗼𝘄 𝗲𝗮𝘀𝗶𝗹𝘆 𝗼𝘂𝗿 𝗮𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻 𝗰𝗮𝗻 𝗯𝗲 𝗰𝗮𝗽𝘁𝘂𝗿𝗲𝗱 𝗯𝘆 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝘄𝗲 𝗻𝗲𝘃𝗲𝗿 𝗶𝗻𝘁𝗲𝗻𝘁𝗶𝗼𝗻𝗮𝗹𝗹𝘆 𝗱𝗲𝗰𝗶𝗱𝗲𝗱 𝘄𝗮𝘀 𝘄𝗼𝗿𝘁𝗵 𝗼𝘂𝗿 𝘁𝗶𝗺𝗲.

The point is not really about the watermelon itself, but about how quickly curiosity, entertainment, or distraction can pull our attention in a direction we did not consciously choose. It is worth occasionally asking whether something actually deserves our focus, because when our time is limited, our attention is limited too.

A useful question to ask is: 𝗗𝗶𝗱 𝗜 𝗰𝗵𝗼𝗼𝘀𝗲 𝘁𝗼 𝗴𝗶𝘃𝗲 𝗺𝘆 𝗮𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻 𝘁𝗼 𝘁𝗵𝗶𝘀, 𝗼𝗿 𝗱𝗶𝗱 𝗶𝘁 𝘀𝗶𝗺𝗽𝗹𝘆 𝗽𝘂𝗹𝗹 𝗺𝗲 𝗶𝗻?

𝟰. 𝗕𝗲 𝗮 𝗯𝗲𝘁𝘁𝗲𝗿 𝗽𝗿𝗼𝗰𝗿𝗮𝘀𝘁𝗶𝗻𝗮𝘁𝗼𝗿

We often assume that the goal is to stop procrastinating completely, but when our time is limited, we are always going to postpone something because we simply cannot do everything at the same time.

That means the better question may not be how to eliminate procrastination, but 𝘄𝗵𝗮𝘁 𝘀𝗵𝗼𝘂𝗹𝗱 𝗜 𝗽𝗿𝗼𝗰𝗿𝗮𝘀𝘁𝗶𝗻𝗮𝘁𝗲 𝗼𝗻? Some things may still be worth doing, but that does not mean they need to be done right now, so learning what to postpone can be just as important as deciding what to prioritize.

𝟱. 𝗗𝗼𝗶𝗻𝗴 𝗻𝗼𝘁𝗵𝗶𝗻𝗴

Learning to 𝗱𝗼 𝗻𝗼𝘁𝗵𝗶𝗻𝗴 sounds simple, but it can be uncomfortable when we are used to thinking that time should always be productive, useful, or measurable.

The book challenges that idea by asking us to become more comfortable with moments when we are not trying to optimize, improve, or accomplish something. 𝗡𝗼𝘁 𝗲𝘃𝗲𝗿𝘆 𝗺𝗼𝗺𝗲𝗻𝘁 𝗵𝗮𝘀 𝘁𝗼 𝗽𝗿𝗼𝗱𝘂𝗰𝗲 𝗮 𝗿𝗲𝘀𝘂𝗹𝘁, and sometimes doing nothing simply means allowing ourselves to be present without immediately turning that time into another task.

𝟲. 𝗪𝗲 𝗱𝗼 𝗻𝗼𝘁 𝗸𝗻𝗼𝘄 𝗵𝗼𝘄 𝗺𝘂𝗰𝗵 𝘁𝗶𝗺𝗲 𝘄𝗲 𝗵𝗮𝘃𝗲 𝗹𝗲𝗳𝘁

The 4,000-week idea assumes we live to around 80 years old, but none of us actually knows how many weeks we have. That does not mean we should become anxious about time or try to accomplish everything as quickly as possible; instead, it makes the question of what deserves our time even more important.

It also made me think about comparison, because we can spend a lot of our limited time comparing our progress with someone else's without knowing their priorities, circumstances, opportunities, sacrifices, or direction. 𝗖𝗼𝗺𝗽𝗮𝗿𝗶𝘀𝗼𝗻 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁 𝗴𝗶𝘃𝗲 𝘂𝘀 𝗮𝗻𝘆 𝗮𝗱𝗱𝗶𝘁𝗶𝗼𝗻𝗮𝗹 𝘄𝗲𝗲𝗸𝘀, so I would rather use that time thinking about where I am going and what I want to give my attention to.

𝟳. 𝗠𝗲𝗱𝗶𝗲𝘃𝗮𝗹 𝘁𝗶𝗺𝗲

The book also looks back at 𝗺𝗲𝗱𝗶𝗲𝘃𝗮𝗹 𝗹𝗶𝗳𝗲, 𝗯𝗲𝗳𝗼𝗿𝗲 𝗰𝗹𝗼𝗰𝗸𝘀 𝗮𝗻𝗱 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝘀 𝘀𝗵𝗮𝗽𝗲𝗱 𝗲𝘃𝗲𝗿𝘆𝗱𝗮𝘆 𝗹𝗶𝗳𝗲 𝘁𝗵𝗲 𝘄𝗮𝘆 𝘁𝗵𝗲𝘆 𝗱𝗼 𝗻𝗼𝘄. People still worked hard and had plenty of difficulties, but they did not think about time in exactly the same way we do today. Their days were more connected to the task in front of them, daylight, and the seasons rather than constantly watching the clock and thinking about how much they could fit into an hour.

There were also far fewer modern sources competing for attention, and the way time itself was understood was different. Today, it can feel like time is something we are always trying to save, manage, optimize, or avoid wasting, while the book reminds us that humans have not always related to time this way.

One thing I appreciate about book club is that the conversation usually goes beyond the book itself. Everyone brings a different perspective, and that can completely change how you think about an idea. 𝗡𝗲𝘅𝘁 𝘂𝗽 𝗶𝘀 𝗮 𝗯𝗼𝗼𝗸 𝗮𝗯𝗼𝘂𝘁 𝗿𝗲𝗷𝗲𝗰𝘁𝗶𝗼𝗻, 𝗮𝗻𝗱 𝗜’𝗺 𝗲𝘅𝗰𝗶𝘁𝗲𝗱 𝘁𝗼 𝘀𝗲𝗲 𝘄𝗵𝗮𝘁 𝘁𝗵𝗮𝘁 𝗯𝗼𝗼𝗸 𝘄𝗶𝗹𝗹 𝗼𝗳𝗳𝗲𝗿 𝗮𝗻𝗱 𝘄𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝗱𝗶𝘀𝗰𝘂𝘀𝘀𝗶𝗼𝗻 𝘁𝗮𝗸𝗲𝘀 𝘂𝘀.

𝗩𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗜𝘀 𝗮 𝗦𝗸𝗶𝗹𝗹, 𝗡𝗼𝘁 𝗮 𝗣𝗲𝗿𝘀𝗼𝗻𝗮𝗹𝗶𝘁𝘆 𝗧𝗿𝗮𝗶𝘁

Yodit Weldegeorgise — Fri, 21 Aug 2026 18:02:43 +0000

One of the things I have been intentionally working on this year is becoming more visible professionally.

Not visibility in the sense of trying to be everywhere or constantly talking about myself, but in the sense of participating, asking questions, sharing what I am learning, contributing to conversations, and allowing people to actually see me grow.

For a while, I thought my challenge with visibility was simply about confidence. But the more I paid attention to what was happening in the moments when I held myself back, the more I realized there was something deeper underneath it.

I was constantly comparing myself to the people around me.

When I met people with more experience, I assumed they had more to contribute. If others understood a technical concept faster than I did, I questioned my own ability. And when I heard someone speak confidently during a discussion, I sometimes wondered whether what I wanted to add was even worth saying.

The thought running quietly in the background was often the same:

𝗘𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗵𝗲𝗿𝗲 𝗶𝘀 𝗯𝗲𝘁𝘁𝗲𝗿 𝘁𝗵𝗮𝗻 𝗺𝗲.

When you repeatedly tell yourself that, it naturally changes how you show up. You hesitate before asking the question, reconsider sharing the idea, or stay quiet during a conversation because you assume everyone else already knows more than you do.

What makes this interesting for me is that I am actually an extrovert. I enjoy meeting people, being around communities, having conversations, and connecting with others, so being social itself was never really the issue.

That distinction helped me understand something important: 𝗯𝗲𝗶𝗻𝗴 𝗼𝘂𝘁𝗴𝗼𝗶𝗻𝗴 𝗮𝗻𝗱 𝗯𝗲𝗶𝗻𝗴 𝗽𝗿𝗼𝗳𝗲𝘀𝘀𝗶𝗼𝗻𝗮𝗹𝗹𝘆 𝘃𝗶𝘀𝗶𝗯𝗹𝗲 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗻𝗲𝗰𝗲𝘀𝘀𝗮𝗿𝗶𝗹𝘆 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝘁𝗵𝗶𝗻𝗴.

You can be an extrovert and still make yourself small in professional spaces. You can enjoy talking to people while hesitating to ask a technical question, love being part of a community while holding back during a discussion, or have an idea and convince yourself that somebody else probably has a better one.

Looking back, I think imposter syndrome affected my professional visibility far more than my personality ever did.

After I was laid off, this became one of the areas I wanted to work on intentionally.

Of course, I also wanted to continue strengthening my technical skills, practicing problem-solving, attending classes, and becoming a stronger developer. At the same time, I realized that continuously improving in private would not automatically teach me how to participate confidently in professional spaces.

I needed to practice being visible too.

For me, that meant making small decisions that challenged the habit of disappearing into the background whenever I felt like everyone else knew more than I did. I started turning my camera on during virtual classes whenever possible, participating more actively in technical communities and online spaces, asking questions even when I worried they might be obvious, sharing what I was learning, and becoming more intentional about following up with people.

One of the biggest lessons from that experience has been realizing that 𝘆𝗼𝘂 𝗱𝗼 𝗻𝗼𝘁 𝗵𝗮𝘃𝗲 𝘁𝗼 𝘄𝗮𝗶𝘁 𝘂𝗻𝘁𝗶𝗹 𝘆𝗼𝘂 𝗳𝗲𝗲𝗹 𝗰𝗼𝗺𝗽𝗹𝗲𝘁𝗲𝗹𝘆 𝗰𝗼𝗻𝗳𝗶𝗱𝗲𝗻𝘁 𝗯𝗲𝗳𝗼𝗿𝗲 𝘆𝗼𝘂 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗲. 𝗦𝗼𝗺𝗲𝘁𝗶𝗺𝗲𝘀 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝗵𝗼𝘄 𝘆𝗼𝘂 𝗯𝘂𝗶𝗹𝗱 𝗰𝗼𝗻𝗳𝗶𝗱𝗲𝗻𝗰𝗲 𝗶𝗻 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝗽𝗹𝗮𝗰𝗲.

𝗩𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝘀 𝗻𝗼𝘁 𝗮𝗯𝗼𝘂𝘁 𝗽𝗿𝗼𝘃𝗶𝗻𝗴 𝘁𝗵𝗮𝘁 𝘆𝗼𝘂 𝗸𝗻𝗼𝘄 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴

I used to think that being visible professionally meant I needed to have something impressive to contribute. If I was going to speak, ask a question, post something, or participate in a discussion, I wanted to be sure that what I was saying was valuable enough.

That standard can make it very easy to stay quiet.

The more I participate, however, the more I realize that professional spaces are not filled with people who already know everything. They include people at different stages of learning, asking questions, experimenting, making mistakes, and figuring things out as they go.

Sometimes visibility simply means allowing yourself to be part of that process.

It can mean asking a question you genuinely do not understand instead of pretending that you do, sharing something you recently learned without positioning yourself as an expert, or contributing your perspective without waiting until you have the perfect answer.

The goal is not to prove that you are the smartest person in the room. 𝗧𝗵𝗲 𝗴𝗼𝗮𝗹 𝗶𝘀 𝘁𝗼 𝘀𝘁𝗼𝗽 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗰𝗮𝗹𝗹𝘆 𝗮𝘀𝘀𝘂𝗺𝗶𝗻𝗴 𝘁𝗵𝗮𝘁 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗲𝗹𝘀𝗲 𝗱𝗲𝘀𝗲𝗿𝘃𝗲𝘀 𝘁𝗼 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗲 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝘆𝗼𝘂 𝗱𝗼.

𝗬𝗼𝘂 𝗰𝗮𝗻 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲 𝘃𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆

One of the most useful changes for me was moving away from thoughts like, “I need to become more confident,” because confidence can feel abstract and difficult to measure.

Instead, I started focusing on behaviors and asking a much more practical question:

𝗪𝗵𝗮𝘁 𝗶𝘀 𝗼𝗻𝗲 𝘁𝗵𝗶𝗻𝗴 𝗜 𝗰𝗮𝗻 𝗱𝗼 𝘁𝗼𝗱𝗮𝘆 𝘁𝗵𝗮𝘁 𝗵𝗲𝗹𝗽𝘀 𝗺𝗲 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗲 𝗮 𝗹𝗶𝘁𝘁𝗹𝗲 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝗜 𝗻𝗼𝗿𝗺𝗮𝗹𝗹𝘆 𝘄𝗼𝘂𝗹𝗱?

Some days, that might mean turning my camera on during class and being fully present. Another day, it could be asking a question even though part of me worries that everyone else already knows the answer, contributing to a discussion, attending another meetup, following up with someone I met, volunteering to help with an event, or eventually accepting an opportunity that feels bigger than what I believe I am ready for.

Those actions may seem small individually, but repeating them begins to change how you see yourself.

You start collecting evidence that you can participate. A question you were nervous to ask leads to a useful conversation. An idea you almost kept to yourself turns out to be valuable. You meet people you once assumed had everything figured out and realize that they are learning too. You take on an opportunity and discover that you are capable of more than you initially believed.

Slowly, the thought that 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗶𝘀 𝗯𝗲𝘁𝘁𝗲𝗿 𝘁𝗵𝗮𝗻 𝗺𝗲 begins to lose some of its power.

𝗖𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆 𝗰𝗮𝗻 𝗰𝗵𝗮𝗻𝗴𝗲 𝗵𝗼𝘄 𝘆𝗼𝘂 𝘀𝗲𝗲 𝘆𝗼𝘂𝗿𝘀𝗲𝗹𝗳

Being involved in communities has also taught me that visibility does not always come from doing something extraordinary. Sometimes it comes from continuing to show up long enough for relationships, confidence, and familiarity to develop naturally.

This month marks one year since I started attending 𝗚𝗼𝗼𝗴𝗹𝗲 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗚𝗿𝗼𝘂𝗽 (𝗚𝗗𝗚) events, and when I look at everything that has happened during that year, I can see how much those small acts of participation added up.

Through community, I was introduced to other communities, met people I would not have met otherwise, found new opportunities to learn, became more involved, continued developing my communication skills, and eventually found myself preparing to speak at my first tech conference.

When I first started showing up, I could not have predicted any of that.

There was also no single day when I suddenly stopped questioning myself and became completely confident. The change happened through many ordinary moments when I chose to participate anyway.

That might be one of the most important things I have learned about visibility.

𝗦𝗼𝗺𝗲𝘁𝗶𝗺𝗲𝘀 𝘆𝗼𝘂 𝗱𝗼 𝗻𝗼𝘁 𝗯𝗲𝗰𝗼𝗺𝗲 𝘃𝗶𝘀𝗶𝗯𝗹𝗲 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝘆𝗼𝘂 𝗳𝗶𝗻𝗮𝗹𝗹𝘆 𝗳𝗲𝗲𝗹 𝗿𝗲𝗮𝗱𝘆. 𝗬𝗼𝘂 𝗯𝗲𝗰𝗼𝗺𝗲 𝗺𝗼𝗿𝗲 𝗿𝗲𝗮𝗱𝘆 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝘆𝗼𝘂 𝗸𝗲𝗽𝘁 𝗮𝗹𝗹𝗼𝘄𝗶𝗻𝗴 𝘆𝗼𝘂𝗿𝘀𝗲𝗹𝗳 𝘁𝗼 𝗯𝗲 𝘃𝗶𝘀𝗶𝗯𝗹𝗲.

𝗠𝗮𝘆𝗯𝗲 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗶𝘀 𝗻𝗼𝘁 𝗯𝗲𝘁𝘁𝗲𝗿 𝘁𝗵𝗮𝗻 𝘆𝗼𝘂

If you constantly walk into professional spaces believing everyone else is smarter, more experienced, or more qualified, that belief begins shaping your behavior before anyone even gets the opportunity to know you.

You might stay quiet despite having a good question, avoid contributing because you assume another idea will be better, or wait until you know more, achieve more, or feel more confident before allowing yourself to take up space.

There will always be moments when you are surrounded by people who seem more experienced, more knowledgeable, or more confident than you. Instead of treating that as proof that you have less to contribute, I am learning to see it differently.

𝗘𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗯𝗿𝗶𝗻𝗴𝘀 𝗮 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗺𝗶𝘅 𝗼𝗳 𝗸𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲, 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲, 𝗮𝗻𝗱 𝗽𝗲𝗿𝘀𝗽𝗲𝗰𝘁𝗶𝘃𝗲, 𝘄𝗵𝗶𝗰𝗵 𝗺𝗲𝗮𝗻𝘀 𝘁𝗵𝗲𝗿𝗲 𝗶𝘀 𝗮𝗹𝘄𝗮𝘆𝘀 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝘄𝗲 𝗰𝗮𝗻 𝗹𝗲𝗮𝗿𝗻 𝗳𝗿𝗼𝗺 𝗼𝗻𝗲 𝗮𝗻𝗼𝘁𝗵𝗲𝗿.

Professional growth does not have to be a comparison of who knows more. It can also be an opportunity to learn, contribute, and grow together.

I am still learning this myself, but I am much more intentional now about not allowing the thought that everyone else is better than me to decide how visible I allow myself to be.

Because visibility is not about pretending you know everything.

𝗜𝘁 𝗶𝘀 𝗮𝗯𝗼𝘂𝘁 𝗴𝗶𝘃𝗶𝗻𝗴 𝘆𝗼𝘂𝗿𝘀𝗲𝗹𝗳 𝗽𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻 𝘁𝗼 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗲 𝘄𝗵𝗶𝗹𝗲 𝘆𝗼𝘂 𝗮𝗿𝗲 𝘀𝘁𝗶𝗹𝗹 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴.

𝗕𝗲𝘆𝗼𝗻𝗱 𝘁𝗵𝗲 𝗝𝗼𝗯 𝗗𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻: 𝗪𝗵𝗮𝘁 𝗜𝘁 𝗠𝗲𝗮𝗻𝘀 𝘁𝗼 𝗕𝗲 𝗮 𝗟𝗶𝗻𝗰𝗵𝗽𝗶𝗻

Yodit Weldegeorgise — Wed, 12 Aug 2026 06:06:31 +0000

After Mark, a co-founder of the entrepreneur and book club I attend, recommended Linchpin by Seth Godin to me, I started listening to it and could not stop because the book goes far beyond the idea of simply becoming good at your job. It talks about how we have been trained to work, why following instructions became such a big part of both education and employment, why we are afraid to stand out, and what it really means to bring something to our work that cannot be written into a job description.

Before going further, 𝗮 𝗹𝗶𝗻𝗰𝗵𝗽𝗶𝗻 𝗶𝘀 𝗹𝗶𝘁𝗲𝗿𝗮𝗹𝗹𝘆 𝗮 𝘀𝗺𝗮𝗹𝗹 𝗽𝗶𝗻 𝘁𝗵𝗮𝘁 𝗵𝗼𝗹𝗱𝘀 𝗮 𝘄𝗵𝗲𝗲𝗹 𝗼𝗿 𝗼𝘁𝗵𝗲𝗿 𝗽𝗮𝗿𝘁 𝗶𝗻 𝗽𝗹𝗮𝗰𝗲, and Godin uses that word as a metaphor for a person who brings value that goes beyond completing the basic requirements of a role. A linchpin is not someone who makes other people dependent on them or hides knowledge so they become impossible to replace; it is someone who can use judgment when there is no clear instruction, take initiative when something needs to happen, connect people, solve problems, create something useful, and handle the human parts of work that cannot always be reduced to a checklist.

Godin goes back to the industrial era to explain how we became so comfortable with the idea that good work means following instructions. As factories became more efficient, work was divided into smaller and more repeatable tasks, which meant a person no longer needed to understand the entire process of making something because they could learn one part, repeat it consistently, and produce the expected result. This made production faster and easier to scale, but it also created a system where individual workers could become easier to replace once their work could be clearly documented and taught to somebody else.

We usually picture this as a blue-collar story because factories, assembly lines, and machines are the easiest examples to imagine, but Godin argues that the same way of thinking eventually became part of white-collar work as well. The setting may be an office instead of a factory, but the work can still be structured around processing information, following procedures, getting approvals, completing assigned tasks, and staying inside clearly defined responsibilities, which means the tools and clothes may have changed while the expectation remained very similar: 𝗳𝗼𝗹𝗹𝗼𝘄 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗮𝗻𝗱 𝗱𝗼 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂 𝗮𝗿𝗲 𝘁𝗼𝗹𝗱.

Godin also connects this way of working to the education system because school has traditionally prepared us very well for structured environments. We learn to arrive on time, follow instructions, complete assignments, study what will be on the test, look for the correct answer, ask permission, and avoid mistakes, and then we enter the workplace where we receive another set of instructions in the form of policies, processes, managers, and job descriptions.

There is nothing wrong with structure because every school and workplace needs some level of it, but the question becomes 𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘄𝗵𝗲𝗻 𝘁𝗵𝗲 𝗶𝗻𝘀𝘁𝗿𝘂𝗰𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗻𝗼 𝗹𝗼𝗻𝗴𝗲𝗿 𝗲𝗻𝗼𝘂𝗴𝗵?

Godin uses the adoption of the washing machine as one example of how uncomfortable a major technological transition can be while people are still learning how to live with it. He writes that during the early adoption of washing machines, hundreds of people a year died while using them, which he uses to show that new technology can arrive before the knowledge, systems, standards, and behaviors around it have fully caught up.

Today, a washing machine feels so normal that most of us would never think of it as disruptive technology, but the people living through that transition did not know what the final system would look like because they were learning while the change was already happening. That part connects with many of the conversations happening around technology today because we often want a clear answer about which jobs will change, which skills will matter, and what work will look like several years from now, even though people living through previous technological changes did not have that kind of certainty either.

That uncertainty is one reason the idea of becoming a linchpin feels relevant now, because a linchpin is valuable not because they already know everything that is going to happen, but because they know how to respond when the old instructions are no longer enough.

One of the examples Godin uses early in the book is Albert Einstein, and he makes the point that 𝗻𝗼 𝗼𝗻𝗲 𝗶𝘀 𝗮 𝗴𝗲𝗻𝗶𝘂𝘀 𝗮𝗹𝗹 𝘁𝗵𝗲 𝘁𝗶𝗺𝗲. Even Einstein had ordinary moments, and Godin uses that idea to move the word genius away from being something reserved only for a few extraordinary people. All of us can have moments when we see a solution that somebody else does not see, explain something in a way that finally makes sense, make a connection between two ideas, solve a difficult problem, or create something useful.

Being a linchpin does not require being exceptional every second of the day.

Godin makes a similar argument when he talks about being an 𝗮𝗿𝘁𝗶𝘀𝘁, because he does not reserve that word for painters, musicians, or writers. In the book, art can happen in almost any profession when someone brings judgment, creativity, generosity, and something personal into what they do instead of simply following the instructions exactly as they were given.

A developer can be an artist when they understand the problem beyond the ticket and create a thoughtful solution rather than only writing code that technically works, a teacher can be an artist when they find another way to explain something a student is struggling to understand, and someone organizing a community can create art by building an environment where people who may never have met begin connecting and helping one another.

Godin's example of the cook and the chef explains this idea very well because a cook can follow a recipe exactly as it is written, while the chef understands the ingredients well enough to adjust, make decisions, experiment, and create something when the recipe no longer has the answer. Following the recipe is not a bad thing because there are many situations where we need instructions, but the linchpin becomes especially valuable when something happens that the recipe did not prepare us for.

The difficult part is that going beyond the instructions also means accepting more responsibility for the result. If I do exactly what somebody tells me to do and the outcome is not good, it is easy to say that I followed the process, but when I suggest a different approach, take initiative, create something of my own, or share an idea publicly, I also have to accept that someone may disagree with me, criticize it, or know more than I do.

Godin calls the part of us that wants to avoid that risk the 𝗹𝗶𝘇𝗮𝗿𝗱 𝗯𝗿𝗮𝗶𝗻.

He uses the lizard brain as a metaphor for the part of us that wants safety, acceptance, familiarity, and protection from embarrassment or rejection, and he connects that fear to our historical dependence on tribes, where belonging to the group once had consequences much bigger than simply whether people liked us. Being rejected by the tribe could have meant losing protection, resources, and support, so avoiding rejection became deeply connected to survival.

We are not living in that same environment today, but we can still feel a strong reaction when we are about to do something that puts attention on us, which is why the public-speaking example in the book makes so much sense.

You can know logically that standing in front of a group is not dangerous and still have your body react very differently once everyone turns around and starts looking at you, because suddenly there is the possibility of judgment, disagreement, embarrassment, or making a mistake where everybody can see it.

I am currently preparing for my first conference talk, so that example feels very real to me. I know standing on a stage is not a dangerous situation, but my brain can still come up with questions about forgetting something, something going wrong during the presentation, or someone in the audience knowing more about the topic than I do.

Godin describes that internal pushback as 𝗿𝗲𝘀𝗶𝘀𝘁𝗮𝗻𝗰𝗲, and what makes resistance interesting is that it does not always sound like fear. Sometimes it sounds responsible because it tells us we should prepare a little more, wait until we have more experience, earn another certification, revise something one more time, or wait until we finally feel completely ready.

Preparation is necessary, but there is also a point where preparation can become another way of avoiding the moment when we actually have to put the work in front of somebody else.

That is why Godin talks about 𝘀𝗵𝗶𝗽𝗽𝗶𝗻𝗴.

An idea can be great, but if it stays in your notebook forever, nobody benefits from it, and a presentation can be carefully prepared, but if you never deliver it, none of that preparation reaches the audience. At some point, the work has to leave our hands and enter a place where other people can use it, respond to it, disagree with it, or criticize it, and that willingness to ship is part of what separates creating from endlessly preparing to create.

Another major part of becoming a linchpin is what Godin calls 𝗲𝗺𝗼𝘁𝗶𝗼𝗻𝗮𝗹 𝗹𝗮𝗯𝗼𝗿, which goes beyond simply controlling our emotions at work. He describes it as doing the important human work even when that work is uncomfortable, and one of the lines from the book explains it clearly: 𝗘𝗺𝗼𝘁𝗶𝗼𝗻𝗮𝗹 𝗹𝗮𝗯𝗼𝗿 𝗶𝘀 𝘁𝗵𝗲 𝘁𝗮𝘀𝗸 𝗼𝗳 𝗱𝗼𝗶𝗻𝗴 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝘄𝗼𝗿𝗸, 𝗲𝘃𝗲𝗻 𝘄𝗵𝗲𝗻 𝗶𝘁 𝗶𝘀𝗻'𝘁 𝗲𝗮𝘀𝘆.

Sometimes the technical part of a job is easier than the human part because it may be easier to fix the code than explain why an approach needs to change, easier to complete your own task than help someone who is struggling, and easier to stay quiet than give feedback that may create an uncomfortable conversation.

Emotional labor can mean staying patient when a conversation becomes frustrating, admitting when your first solution was wrong, helping someone even when it is not specifically written in your responsibilities, making someone feel welcome, speaking up when you notice a problem, or taking responsibility for a decision when there is no perfect answer.

Godin uses the example of a flight attendant who can rush through the required announcement and technically complete the task, while another flight attendant may bring energy, attention, and a real effort to connect with passengers. Both people may complete what the job description requires, but one of them chooses to bring something more human to the experience, and that difference is difficult to describe in a procedure.

That is why so much of linchpin behavior exists 𝗯𝗲𝘆𝗼𝗻𝗱 𝘁𝗵𝗲 𝗷𝗼𝗯 𝗱𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻.

Godin also connects emotional labor with 𝗴𝗲𝗻𝗲𝗿𝗼𝘀𝗶𝘁𝘆 because creating art is not only about producing something impressive; it is about creating something that has value for another person. Sometimes that generosity is sharing what you know, taking extra time to explain something, introducing two people who should know each other, helping someone solve a problem, or bringing an idea into a room without immediately calculating what you are going to get back from it.

We are not going to be generous, creative, courageous, or brilliant every moment, just as Einstein was not a genius every moment, and I think that makes the idea of being a linchpin much more realistic. It is not about becoming a perfect person who always has the answer and always does extraordinary work; it is about recognizing that we have the ability to contribute something beyond the minimum and choosing to practice that behavior more often.

The more I listened to the book, the more I started connecting these ideas together because being an artist requires us to create something, generosity gives that creation value for somebody else, emotional labor asks us to do the uncomfortable human part of the work, and the lizard brain is often the part trying to convince us not to do any of it because following the instructions and staying unnoticed feels much safer.

That is also where the uncertainty around AI fits into this reflection for me, not because I think the book gives a prediction about exactly what technology will do, but because it gives a way of thinking about how to behave when the way we work is changing.

If more routine and repeatable work becomes easier to automate, then trying to make ourselves valuable only by becoming better at following instructions may not be enough. The ability to understand a problem, question an answer, communicate with people, use judgment, take initiative, build relationships, create something useful, and handle situations where there is no clear map becomes even more important.

A job description can tell us what our responsibilities are, but it cannot completely tell us how to handle every person, every unexpected problem, every difficult conversation, or every situation where the answer is unclear.

For me, that is the biggest lesson in Linchpin.

Being a linchpin is not about knowing exactly what the future will look like, becoming impossible to replace, or trying to be extraordinary every day. It is about continuing to build our skills while also developing the judgment to know when following instructions is not enough, being willing to create and share our work, doing the uncomfortable emotional labor, helping other people with what we know, and recognizing when resistance is trying to make the safer decision for us.

The rules around work will continue to change, just as they have changed before, but we do not have to wait for someone to hand us a perfect new instruction manual before we decide how we want to contribute.

𝗚𝗼𝗶𝗻𝗴 𝗯𝗲𝘆𝗼𝗻𝗱 𝘁𝗵𝗲 𝗷𝗼𝗯 𝗱𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻 𝗺𝗲𝗮𝗻𝘀 𝗯𝗿𝗶𝗻𝗴𝗶𝗻𝗴 𝘁𝗵𝗲 𝗽𝗮𝗿𝘁 𝗼𝗳 𝗼𝘂𝗿 𝘄𝗼𝗿𝗸 𝘁𝗵𝗮𝘁 𝗰𝗮𝗻𝗻𝗼𝘁 𝗯𝗲 𝗿𝗲𝗱𝘂𝗰𝗲𝗱 𝘁𝗼 𝗮 𝗰𝗵𝗲𝗰𝗸𝗹𝗶𝘀𝘁, 𝗮𝗻𝗱 𝘁𝗵𝗮𝘁 𝗶𝘀 𝘄𝗵𝗮𝘁 𝗜 𝗻𝗼𝘄 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝗶𝘁 𝗺𝗲𝗮𝗻𝘀 𝘁𝗼 𝗯𝗲 𝗮 𝗹𝗶𝗻𝗰𝗵𝗽𝗶𝗻.

𝗧𝗵𝗲 𝗔𝗿𝘁 𝗼𝗳 𝗦𝗵𝗼𝘄𝗶𝗻𝗴 𝗨𝗽

Yodit Weldegeorgise — Wed, 05 Aug 2026 04:21:02 +0000

Some weeks, consistency looks like completing everything on your schedule. Other weeks, it simply means finding a way to continue when your plans, surroundings, and energy are not ideal.

Recently, I attended a bachelorette getaway while also participating in an algorithm bootcamp. Before the bootcamp started, I made a commitment to attend every live session, turn on my camera, and actively participate instead of joining passively in the background.

Keeping that commitment became more difficult during the trip because I was away from my usual routine, spending time with friends, and traveling between Austin and Dallas. Missing one session would have been easy to justify, especially since I could have watched the recording later.

Instead, I joined the session while my friend was driving us back to Dallas, followed the lesson, and participated as much as I could.

For two weeks, I attended every live session, and it felt incredibly rewarding.

From the outside, this may seem like a small accomplishment, but it meant a lot to me because I followed through on a promise I had made to myself. The satisfaction came from more than simply attending. I felt proud knowing that I stayed committed even when my schedule changed.

Consistency is not always built during calm and predictable moments. Often, it develops in the middle of travel, competing priorities, and circumstances that are far from perfect.

𝗧𝗵𝗲 𝗔𝗿𝘁 𝗼𝗳 𝗦𝗵𝗼𝘄𝗶𝗻𝗴 𝗨𝗽

Showing up does not always mean performing at your highest level or completing a large amount of work.

On some days, it may mean joining a session while traveling, reviewing a concept when you only have a few minutes, or finishing one meaningful task before the day ends.

The effort may appear small, but it strengthens the habit of beginning.

Many of us wait until we have enough time, energy, or focus to do something properly. We delay because we assume that a partial effort will not make a difference.

However, waiting for ideal conditions can easily become another form of procrastination.

𝗧𝗵𝗲 𝗮𝗿𝘁 𝗼𝗳 𝘀𝗵𝗼𝘄𝗶𝗻𝗴 𝘂𝗽 𝗶𝘀 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗵𝗼𝘄 𝘁𝗼 𝘂𝘀𝗲 𝘁𝗵𝗲 𝘁𝗶𝗺𝗲 𝗮𝗻𝗱 𝗲𝗻𝗲𝗿𝗴𝘆 𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗮𝗯𝗮𝗻𝗱𝗼𝗻𝗶𝗻𝗴 𝘁𝗵𝗲 𝗰𝗼𝗺𝗺𝗶𝘁𝗺𝗲𝗻𝘁 𝗮𝗹𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿.

This does not mean forcing everything into an already full schedule. It means understanding what matters to you and finding a realistic way to remain connected to it.

During the getaway, I still wanted to enjoy time with my friends and be present for the experience. At the same time, I did not want to step away from a commitment I had made before the trip.

Finding a way to participate in both required flexibility rather than perfection.

𝗙𝗼𝗰𝘂𝘀 𝗼𝗻 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝗥𝗮𝘁𝗵𝗲𝗿 𝗧𝗵𝗮𝗻 𝗚𝗼𝗮𝗹𝘀

James Clear, the author of Atomic Habits and a writer known for his practical ideas about building better habits, emphasizes the importance of focusing on systems rather than becoming consumed by goals.

Goals give us direction, but systems determine the actions we repeat each day.

My goal may be to become stronger at solving algorithm problems, but that goal alone will not improve my skills. Progress comes from the system around it, including attending live sessions, asking questions, participating in discussions, reviewing the material, and practicing regularly.

𝗔 𝗴𝗼𝗮𝗹 𝗱𝗲𝘀𝗰𝗿𝗶𝗯𝗲𝘀 𝘁𝗵𝗲 𝗼𝘂𝘁𝗰𝗼𝗺𝗲 𝘄𝗲 𝘄𝗮𝗻𝘁, 𝘄𝗵𝗶𝗹𝗲 𝗮 𝘀𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝗳𝗶𝗻𝗲𝘀 𝘁𝗵𝗲 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝗿 𝘄𝗲 𝗰𝗮𝗻 𝗿𝗲𝗽𝗲𝗮𝘁.

Becoming a confident speaker may be the goal, while the system includes practicing regularly, recording yourself, reviewing the video, and applying feedback.

Writing consistently may be the goal, while the system involves keeping notes, setting aside time to reflect, and developing ideas before publication day.

Completing a certification may be the goal, while the system requires studying a manageable amount of material each week and returning to difficult topics until they become clearer.

My exercise routine is another good example. I can become consistent when my schedule is predictable, but once a new commitment is added to my calendar, the routine often becomes disorganized.

I am realizing that the real challenge is not creating a routine that works during a normal week. It is building a flexible system that can adjust when life changes.

Instead of depending on one specific time or waiting for the perfect schedule, I am trying to create smaller options, such as doing a shorter workout on busy days. That way, one change in my calendar does not completely interrupt the habit.

𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝘁𝘂𝗿𝗻 𝗮𝗺𝗯𝗶𝘁𝗶𝗼𝗻 𝗶𝗻𝘁𝗼 𝗮𝗰𝘁𝗶𝗼𝗻.

They also give us something we can control. Results may take time, but we can decide whether we are following the process that makes those results more likely.

Attending every live session for two weeks did not suddenly make me an expert in algorithms. However, it strengthened the system I am trying to build around learning, participation, and consistent practice.

That system matters more than one perfect study session.

𝗡𝗲𝘃𝗲𝗿 𝗠𝗶𝘀𝘀 𝗧𝘄𝗶𝗰𝗲

Another practical rule James Clear shares is: 𝗻𝗲𝘃𝗲𝗿 𝗺𝗶𝘀𝘀 𝘁𝘄𝗶𝗰𝗲.

Missing one day can happen for many reasons. We may be tired, traveling, handling an unexpected responsibility, or simply needing rest.

One interruption does not erase the work that came before it. The greater risk is allowing a temporary break to become a pattern.

Never missing twice is not about forcing yourself to perform perfectly. It is about returning before too much distance grows between you and the habit.

After missing one study session, make an effort to attend the next one. When a workout does not happen, return the following day. When you skip writing for a week, begin again with one paragraph rather than waiting for the perfect idea.

Returning quickly matters because restarting often becomes harder the longer we stay away.

A busy schedule may cause the first missed day. Guilt may cause the second. By the third, we may begin telling ourselves that we have already fallen too far behind.

𝗔 𝗾𝘂𝗶𝗰𝗸 𝗿𝗲𝘁𝘂𝗿𝗻 𝗰𝗮𝗻 𝗶𝗻𝘁𝗲𝗿𝗿𝘂𝗽𝘁 𝘁𝗵𝗮𝘁 𝗰𝘆𝗰𝗹𝗲.

The purpose is not to criticize ourselves for missing a day. It is to make sure that one interruption does not quietly replace the habit we were trying to build.

𝗣𝗿𝗼𝘁𝗲𝗰𝘁 𝘁𝗵𝗲 𝗖𝗵𝗮𝗶𝗻 𝗼𝗳 𝗖𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆

There is something powerful about watching repeated effort accumulate.

One session becomes two, and two sessions become a full week. Over time, that week becomes evidence that you are capable of following through.

The chain is not valuable because every day must look the same. Its value comes from the trust each repetition builds within you.

Every small commitment you keep sends an important message:

𝗜 𝗰𝗮𝗻 𝗱𝗲𝗽𝗲𝗻𝗱 𝗼𝗻 𝗺𝘆𝘀𝗲𝗹𝗳 𝘁𝗼 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲.

That trust makes a difference.

Beginning becomes easier when you already have proof that you can return. Difficult work becomes less intimidating when past experience shows that discomfort does not always stop you.

Protecting the chain is not about obsessively tracking perfect performance. It means creating enough continuity for the habit to remain part of your life.

A productive day may include two focused hours, while a busy one may leave only twenty minutes. The amount can change without breaking your connection to the practice.

Consistency is often less about intensity and more about maintaining that connection.

𝗦𝗺𝗮𝗹𝗹 𝗛𝗮𝗯𝗶𝘁𝘀 𝗖𝗿𝗲𝗮𝘁𝗲 𝗣𝗿𝗼𝗴𝗿𝗲𝘀𝘀 𝗢𝘃𝗲𝗿 𝗧𝗶𝗺𝗲

Small habits are easy to underestimate because their immediate results are often difficult to see.

One live session may not completely change your understanding of algorithms. A single practice recording may not remove every public-speaking challenge. Publishing one blog post may not immediately create a large audience.

Still, every action contributes something.

A live session may clarify one concept, a recording may reveal one habit you need to improve, and a blog post may help you express an idea more clearly.

Progress is often less dramatic than we expect. It may appear as a better question, a clearer explanation, a faster solution, or greater confidence than you had the week before.

These changes can be difficult to notice while they are happening, but their impact becomes significant when they accumulate.

The progress may not be obvious after one day or even one week. Over time, however, the small actions begin to shape your knowledge, confidence, and identity.

You start becoming someone who follows through.

𝗕𝘂𝗶𝗹𝗱 𝗮 𝗦𝘆𝘀𝘁𝗲𝗺 𝗧𝗵𝗮𝘁 𝗖𝗮𝗻 𝗦𝘂𝗿𝘃𝗶𝘃𝗲 𝗮 𝗕𝘂𝘀𝘆 𝗟𝗶𝗳𝗲

A system is only useful when it can continue through inconvenient seasons.

When a routine works only with a completely open schedule, it may not be flexible enough to last.

Busy periods often require smaller versions of our usual habits. A full study session may become a short review, a complete workout may become a walk, and a long writing session may become a few notes saved for later.

𝗥𝗲𝗱𝘂𝗰𝗶𝗻𝗴 𝘁𝗵𝗲 𝘀𝗶𝘇𝗲 𝗼𝗳 𝗮𝗻 𝗮𝗰𝘁𝗶𝗼𝗻 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗮𝘀 𝗴𝗶𝘃𝗶𝗻𝗴 𝘂𝗽 𝗼𝗻 𝗶𝘁.

In many cases, the smaller version is exactly what keeps the habit alive until more time becomes available.

Instead of always asking, “How much can I complete today?” it may be more helpful to ask:

𝗪𝗵𝗮𝘁 𝗰𝗮𝗻 𝗜 𝗱𝗼 𝘁𝗼𝗱𝗮𝘆 𝘁𝗵𝗮𝘁 𝘄𝗶𝗹𝗹 𝗺𝗮𝗸𝗲 𝗶𝘁 𝗲𝗮𝘀𝗶𝗲𝗿 𝘁𝗼 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄?

That question removes some of the pressure to complete everything at once. It allows us to make progress based on the reality of the day rather than the perfect schedule we imagined.

A sustainable system should have room for travel, celebrations, unexpected responsibilities, rest, and life outside the habit.

Otherwise, the system may disappear as soon as life becomes busy.

𝗪𝗵𝗮𝘁 𝗧𝗵𝗲𝘀𝗲 𝗧𝘄𝗼 𝗪𝗲𝗲𝗸𝘀 𝗧𝗮𝘂𝗴𝗵𝘁 𝗠𝗲

Attending every live session for two weeks gave me evidence that traveling did not have to prevent me from staying engaged.

I did not need a perfect environment to participate, and keeping the commitment felt even more meaningful when it was tested by inconvenience.

The bachelorette getaway mattered to me, and the bootcamp did too. I did not want to approach the situation as though choosing one meant completely giving up the other.

Finding a way to take part in both was not about celebrating an overly busy schedule. It was about being intentional with a commitment I had already made.

There will also be moments when showing up means resting, setting a boundary, or accepting that something cannot be completed that day. Consistency should support growth rather than become a reason to ignore our limits.

The lesson is not that everything must always fit into our schedules.

𝗧𝗵𝗲 𝗹𝗲𝘀𝘀𝗼𝗻 𝗶𝘀 𝘁𝗵𝗮𝘁 𝘄𝗵𝗲𝗻 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝘁𝗿𝘂𝗹𝘆 𝗺𝗮𝘁𝘁𝗲𝗿𝘀, 𝘄𝗲 𝗰𝗮𝗻 𝗼𝗳𝘁𝗲𝗻 𝗳𝗶𝗻𝗱 𝗮 𝗿𝗲𝗮𝗹𝗶𝘀𝘁𝗶𝗰 𝘄𝗮𝘆 𝘁𝗼 𝗿𝗲𝗺𝗮𝗶𝗻 𝗰𝗼𝗻𝗻𝗲𝗰𝘁𝗲𝗱 𝘁𝗼 𝗶𝘁.

𝗞𝗲𝗲𝗽 𝗦𝗵𝗼𝘄𝗶𝗻𝗴 𝗨𝗽

This week, I am focusing less on whether every result has appeared and more on whether I am following the system that supports it.

I want to protect the chain without demanding perfection, return quickly after an interruption, and recognize the value of small actions that preserve momentum.

Showing up may not always look impressive.

It may look like joining a session from the passenger seat during a long drive, completing less than you planned without abandoning the process, or choosing continuity over intensity.

Small habits do not create dramatic change in a single day, but they shape what becomes possible over time.

𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗮𝗿𝘁 𝗶𝘀 𝗻𝗼𝘁 𝘀𝗵𝗼𝘄𝗶𝗻𝗴 𝘂𝗽 𝗽𝗲𝗿𝗳𝗲𝗰𝘁𝗹𝘆. 𝗜𝘁 𝗶𝘀 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮 𝘀𝘆𝘀𝘁𝗲𝗺 𝘁𝗵𝗮𝘁 𝗵𝗲𝗹𝗽𝘀 𝘆𝗼𝘂 𝗸𝗲𝗲𝗽 𝘀𝗵𝗼𝘄𝗶𝗻𝗴 𝘂𝗽.

𝗪𝗵𝘆 𝘁𝗵𝗲 𝗣𝗿𝗲𝗽𝗮𝗿𝗮𝘁𝗶𝗼𝗻 𝗠𝗮𝘁𝘁𝗲𝗿𝘀 𝗠𝗼𝗿𝗲 𝗧𝗵𝗮𝗻 𝘁𝗵𝗲 𝗥𝗲𝘀𝘂𝗹𝘁

Yodit Weldegeorgise — Tue, 28 Jul 2026 23:12:52 +0000

I am currently preparing for the Oracle Certified Professional Java SE 21 certification.

In the age of AI, some people may wonder why developers still spend time preparing for a Java certification when AI can generate code, explain concepts, and identify errors within seconds.

For me, the purpose is not only to pass an exam. 𝗠𝘆 𝗴𝗼𝗮𝗹 𝗶𝘀 𝘁𝗼 𝗯𝗲𝗰𝗼𝗺𝗲 𝗮 𝗧-𝘀𝗵𝗮𝗽𝗲𝗱 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿, 𝘄𝗶𝘁𝗵 𝗯𝗿𝗼𝗮𝗱 𝗸𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲 𝗮𝗰𝗿𝗼𝘀𝘀 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗮𝗻𝗱 𝗱𝗲𝗲𝗽𝗲𝗿 𝗲𝘅𝗽𝗲𝗿𝘁𝗶𝘀𝗲 𝗶𝗻 𝗝𝗮𝘃𝗮.

I want to continue learning about databases, cloud technologies, system design, testing, AI, and communication. At the same time, I want Java to be the area where I build stronger depth. I want to understand more than how to write code that works. I want to understand why it works, how Java behaves in different situations, and how small changes can affect the result.

Preparing for OCP Java 21 gives me a structured way to strengthen that knowledge. Passing the exam would be exciting, but the knowledge, discipline, and confidence I develop while preparing may be even more valuable than the final result.

As I started preparing, I asked a friend for advice. He has experience studying for difficult maritime certification exams required for working on ships. Although our certifications are in different fields, both require technical knowledge, consistency, and a clear study plan.

His advice was practical, so I decided to apply it to my OCP Java 21 preparation and share it with others who may also be preparing for a challenging certification.

𝗦𝘁𝗮𝗿𝘁 𝗯𝘆 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗘𝘅𝗮𝗺

His first advice was to gather information before going deeply into every chapter.

At the beginning of your preparation, review the structure of the study material, notice how the chapters are organized, and take notes on the main topics. Becoming familiar with the structure can make it easier to recall the information when you return to study each chapter in more detail.

This is also the time to research the exam itself. Understand the objectives, the style of the questions, and the topics that may carry the most weight. Identify which chapters seem easier based on your current knowledge and which ones may require more time.

He also recommended using different resources, such as YouTube videos and websites, before and after studying a chapter. Sometimes hearing the same concept explained in another way can make it easier to understand.

Another important part of this stage is trying at least three different types of sample exams. Sample exams can help you understand how the questions are written, recognize common patterns, and discover the areas where your knowledge is still weak.

𝗧𝗵𝗲 𝗽𝘂𝗿𝗽𝗼𝘀𝗲 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗼 𝗿𝗲𝗺𝗲𝗺𝗯𝗲𝗿 𝘁𝗵𝗲 𝗮𝗻𝘀𝘄𝗲𝗿𝘀. 𝗜𝘁 𝗶𝘀 𝘁𝗼 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝘄𝗵𝘆 𝘁𝗵𝗲 𝗰𝗼𝗿𝗿𝗲𝗰𝘁 𝗮𝗻𝘀𝘄𝗲𝗿 𝗶𝘀 𝗿𝗶𝗴𝗵𝘁, 𝘄𝗵𝘆 𝘁𝗵𝗲 𝗼𝘁𝗵𝗲𝗿 𝗰𝗵𝗼𝗶𝗰𝗲𝘀 𝗮𝗿𝗲 𝘄𝗿𝗼𝗻𝗴, 𝗮𝗻𝗱 𝘄𝗵𝗶𝗰𝗵 𝗰𝗼𝗻𝗰𝗲𝗽𝘁 𝘁𝗵𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗶𝘀 𝘁𝗲𝘀𝘁𝗶𝗻𝗴.

𝗙𝗼𝗰𝘂𝘀 𝗼𝗻 𝘁𝗵𝗲 𝗧𝗼𝗽𝗶𝗰𝘀 𝗧𝗵𝗮𝘁 𝗠𝗮𝘁𝘁𝗲𝗿 𝗠𝗼𝘀𝘁

After gathering information, identify the main topics that may represent around 60 to 80 percent of the exam.

This does not mean ignoring the remaining material. It means using your study time wisely and giving more attention to the topics that form the core of the exam.

Your study plan should also reflect your personal strengths and weaknesses. A chapter that feels easy to someone else may be difficult for you, and that is completely normal.

For my OCP Java 21 preparation, some topics may only need a quick review, while others may require reading, writing code, testing different examples, and completing more practice questions.

Knowing this early helps me avoid treating every chapter as though it requires the same amount of time.

𝗦𝗽𝗲𝗻𝗱 𝗠𝗼𝗿𝗲 𝗧𝗶𝗺𝗲 𝗼𝗻 𝗬𝗼𝘂𝗿 𝗪𝗲𝗮𝗸𝗲𝘀𝘁 𝗔𝗿𝗲𝗮𝘀

One piece of advice stood out to me the most:

𝗗𝗼 𝗻𝗼𝘁 𝘀𝗽𝗲𝗻𝗱 𝗺𝗼𝘀𝘁 𝗼𝗳 𝘆𝗼𝘂𝗿 𝘁𝗶𝗺𝗲 𝗿𝗲𝘃𝗶𝗲𝘄𝗶𝗻𝗴 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝗷𝘂𝘀𝘁 𝘁𝗼 𝗳𝗲𝗲𝗹 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝘃𝗲.

It feels good to study familiar material. You can move through it quickly, answer the questions correctly, and feel like you completed a lot of work.

However, being busy does not always mean you are improving.

Real progress often happens when you spend time on the topics that feel confusing or uncomfortable. You may need to read the explanation again, write more code examples, watch another video, or ask someone for help.

For me, this means being honest about the Java concepts I understand and the ones I still struggle with. Instead of repeatedly studying the topics that already feel comfortable, I need to spend more time closing the gaps in my knowledge.

𝗧𝗵𝗲 𝗴𝗼𝗮𝗹 𝗶𝘀 𝗻𝗼𝘁 𝘀𝗶𝗺𝗽𝗹𝘆 𝘁𝗼 𝗳𝗶𝗻𝗶𝘀𝗵 𝗺𝗼𝗿𝗲 𝗰𝗵𝗮𝗽𝘁𝗲𝗿𝘀. 𝗧𝗵𝗲 𝗴𝗼𝗮𝗹 𝗶𝘀 𝘁𝗼 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝘁𝗵𝗲 𝗺𝗮𝘁𝗲𝗿𝗶𝗮𝗹 𝗺𝗼𝗿𝗲 𝗱𝗲𝗲𝗽𝗹𝘆.

𝗕𝘂𝗶𝗹𝗱 𝗮 𝗙𝗼𝗰𝘂𝘀𝗲𝗱 𝗦𝘁𝘂𝗱𝘆 𝗥𝗼𝘂𝘁𝗶𝗻𝗲

After researching the exam, reviewing the chapter structure, taking notes, and trying sample questions, the next step is creating a consistent study routine.

My friend recommended studying for two to three focused hours each day without distractions.

Before beginning a study session, decide exactly what you want to accomplish. You may choose to study one section, review a difficult concept, write code examples, or complete a group of practice questions.

Taking notes is also helpful, but the goal should not be to copy the entire book. Notes should capture important rules, helpful examples, mistakes you made, and explanations that made a difficult concept easier to understand.

𝗧𝘄𝗼 𝗳𝗼𝗰𝘂𝘀𝗲𝗱 𝗵𝗼𝘂𝗿𝘀 𝘄𝗶𝘁𝗵 𝗮 𝗰𝗹𝗲𝗮𝗿 𝗴𝗼𝗮𝗹 𝗰𝗮𝗻 𝗯𝗲 𝗺𝗼𝗿𝗲 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝘁𝗵𝗮𝗻 𝗮𝗻 𝗲𝗻𝘁𝗶𝗿𝗲 𝗱𝗮𝘆 𝗼𝗳 𝗶𝗻𝘁𝗲𝗿𝗿𝘂𝗽𝘁𝗲𝗱 𝘀𝘁𝘂𝗱𝘆𝗶𝗻𝗴.

𝗧𝗲𝘀𝘁 𝗬𝗼𝘂𝗿 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗕𝗲𝗳𝗼𝗿𝗲 𝗠𝗼𝘃𝗶𝗻𝗴 𝗙𝗼𝗿𝘄𝗮𝗿𝗱

At the end of each chapter, complete an assessment or answer practice questions.

Before moving to the next chapter, pause and recall what you learned. Try to explain the main ideas without looking at your notes. You can also write a small code example from memory or explain the topic as though you were teaching it to someone else.

Information may feel clear while the book is open, but the real test is whether you can remember and apply it without looking at the explanation.

When you answer a question incorrectly, do not only look at the correct answer and move on. Try to understand what caused the mistake. Was it a concept you did not understand, a small detail you missed, or confusing wording in the question?

𝗘𝘃𝗲𝗿𝘆 𝗺𝗶𝘀𝘁𝗮𝗸𝗲 𝗰𝗮𝗻 𝘀𝗵𝗼𝘄 𝘆𝗼𝘂 𝘄𝗵𝗮𝘁 𝘁𝗼 𝘀𝘁𝘂𝗱𝘆 𝗻𝗲𝘅𝘁.

𝗣𝗿𝗲𝗽𝗮𝗿𝗲 𝘁𝗵𝗲 𝗡𝗶𝗴𝗵𝘁 𝗕𝗲𝗳𝗼𝗿𝗲

Starting can sometimes be the hardest part of studying.

My friend suggested preparing the materials and choosing the next topic before going to sleep. Place your book, notebook, practice questions, and any other resources you need in one place.

After getting enough sleep, you can wake up with more energy and begin without spending time deciding what to study.

This may seem like a small habit, but it removes one more barrier between planning to study and actually beginning.

𝗧𝗵𝗲 𝗣𝗿𝗲𝗽𝗮𝗿𝗮𝘁𝗶𝗼𝗻 𝗜𝘀 𝗔𝗹𝗿𝗲𝗮𝗱𝘆 𝗩𝗮𝗹𝘂𝗮𝗯𝗹𝗲

The OCP Java 21 certification may be the visible result, but the preparation is helping me build something deeper.

It is helping me identify gaps in my Java knowledge, improve my study habits, and become more comfortable working through difficult concepts.

AI can support this process by explaining topics, generating examples, and helping me review my mistakes. However, the responsibility to understand the material is still mine.

I need enough knowledge to evaluate the code AI produces, recognize when something may be incorrect, and make informed decisions instead of accepting every answer without question.

Preparing for this certification is one step toward becoming the T-shaped developer I want to be: someone with broad knowledge across software development and deeper expertise in Java.

𝗧𝗵𝗲 𝗰𝗲𝗿𝘁𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝘄𝗶𝗹𝗹 𝘀𝗵𝗼𝘄 𝘁𝗵𝗮𝘁 𝗜 𝗽𝗮𝘀𝘀𝗲𝗱 𝘁𝗵𝗲 𝗲𝘅𝗮𝗺, 𝗯𝘂𝘁 𝘁𝗵𝗲 𝗽𝗿𝗲𝗽𝗮𝗿𝗮𝘁𝗶𝗼𝗻 𝗶𝘀 𝘄𝗵𝗲𝗿𝗲 𝗜 𝗮𝗺 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗸𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲, 𝗱𝗶𝘀𝗰𝗶𝗽𝗹𝗶𝗻𝗲, 𝗮𝗻𝗱 𝗰𝗼𝗻𝗳𝗶𝗱𝗲𝗻𝗰𝗲 𝘁𝗵𝗮𝘁 𝘄𝗶𝗹𝗹 𝗿𝗲𝗺𝗮𝗶𝗻 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝗹𝗼𝗻𝗴 𝗮𝗳𝘁𝗲𝗿 𝘁𝗵𝗲 𝗲𝘅𝗮𝗺 𝗶𝘀 𝗼𝘃𝗲𝗿.

𝗧𝗵𝗮𝘁 𝗶𝘀 𝘄𝗵𝘆 𝘁𝗵𝗲 𝗽𝗿𝗲𝗽𝗮𝗿𝗮𝘁𝗶𝗼𝗻 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 𝗺𝗼𝗿𝗲 𝘁𝗵𝗮𝗻 𝘁𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁.

The One Where a Job Search Moment Became a Lesson

Yodit Weldegeorgise — Mon, 20 Jul 2026 08:18:13 +0000

I got headhunted for a role that is not even open yet, and this has been one of the most surprising moments in my job search journey so far.

I have had promising conversations before. I have met people who were kind enough to encourage me, share advice, and point me toward opportunities. Some conversations gave me hope, and some reminded me that my experience still matters. But this one felt different because it made me pause and look at my career from a completely new angle.

At first, I felt excited because it reminded me that the experience I have built, the relationships I have been investing in, and the courage to keep showing up were starting to speak for me in rooms I was not even in yet.

But once the excitement settled, a different feeling started to show up. I began thinking about the possibility of failing, about things not progressing the way I hoped, and about whether I would be ready if the opportunity became real.

It is interesting how quickly excitement can turn into fear when something starts to feel close. The opportunity itself was not what scared me. It was the thought of stepping into something new, being seen at a higher level, and wondering whether I could meet the expectations that came with it.

That is when I remembered something my mentor Mike told me.

He reminded me that layoffs are a reflection of so many things, and they are not always a simple reflection of someone’s ability or value. Companies change direction. Teams restructure. Budgets shift. Priorities move. A role can stop aligning with where the company is going, or the environment may not match someone’s skill set, working style, or the kind of support they need to succeed.

Even when performance becomes part of the conversation, it still does not always mean a person is not capable. Sometimes it means the position was not the right fit, the expectations were not aligned, or the timing was not in that person’s favor.

That perspective helped me breathe a little.

Most of us do not usually walk into a role thinking about everything outside of our control, like a company going bankrupt, the market shifting, leadership changing, or a stable department being restructured. But we often still carry the fear of being laid off, replaced, or pushed into an unexpected transition.

The modern age of work is teaching me that job safety is not only about staying with one company until retirement. It is about building the ability to adapt, learn, rebuild, and bounce back when things change in ways we did not expect.

I am starting to think of myself differently now, not only as someone searching for a job, but as an individual consultant or even a small startup who happens to work with one company at a time. That mindset makes me feel more grounded because it reminds me that no matter where I work, I am still carrying my experience, my relationships, and my ability to keep learning into the next chapter.

A company can give me an opportunity, but my career is still something I am responsible for building.

The networking and community work I have been doing did not start from a transactional place. I did not start showing up, writing online, attending events, organizing meetups, or building in public because I wanted someone to give me a job.

It started because I got challenged by two conferences I attended: Commit Your Code Conference and the District 50 Toastmasters Conference. Both experiences pushed me to think differently about visibility, community, and what it means to share my work before I feel fully ready. At first, I was simply trying to step outside of my comfort zone and become more proactive, but I started noticing that showing up in this way was giving me energy.

Meeting people, learning from conversations, sharing what I am building, supporting community events, and documenting my journey started to feel less like another task on my list and more like an energy machine that I could tap into. It reminded me that I do not have to wait until everything is perfect to start showing up.

Now, when opportunities come from the relationships, conversations, and public work I have been building, it feels like a reminder that applications are not the only way doors open. Sometimes they open because people have watched you show up, learn, and contribute consistently.

This opportunity may move forward, or it may not. It may become something amazing, or it may simply become another important conversation that helped me see my value more clearly. Either way, I am grateful because it reminded me that I am not starting from zero.

I have experience, a strong support system, mentors who challenge and encourage me, and a growing ability to reframe fear into perspective.

Most importantly, I am learning to trust that I can succeed in the next chapter, and even when things do not go exactly the way I hope, I believe they can still become part of my learning experience.

𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗔𝗜 𝗜𝘀 𝗡𝗼 𝗟𝗼𝗻𝗴𝗲𝗿 𝗢𝗽𝘁𝗶𝗼𝗻𝗮𝗹 𝗳𝗼𝗿 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀

Yodit Weldegeorgise — Mon, 13 Jul 2026 04:24:36 +0000

What happens when the solution you build to make work easier eventually makes an entire team unnecessary?

One story from the preface of The Developer’s Guide to AI made me pause and think about both the value of successful automation and the unintended consequences it can create.

Jacob Orshalick shares an experience from early in his career. While studying computer science at the University of Texas at Dallas, he joined a company as an intern and was assigned to update press releases on its internal website.

The process was repetitive. The marketing team would send him a press release, and he would copy an existing HTML page, replace the content, make a few changes, and upload the new file. Like many developers would, Jacob saw an opportunity to automate the process.

He created a form that allowed the marketing team to submit the content directly, while a backend process generated the HTML page and added it to the website automatically. The solution worked so well that his team asked him to apply the same approach to the rest of the internal website.

Eventually, the business teams could manage the entire website without depending on the intranet team. Months after Jacob’s internship ended, he learned that the entire team had been laid off because the company no longer needed the same skill set.

As developers, we are trained to notice repetitive work and think about how to make it faster, easier, and more reliable. Automation is usually considered a success, but we do not always stop to think about what happens after it succeeds.

𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝗗𝗶𝗱 𝗡𝗼𝘁 𝗕𝗲𝗴𝗶𝗻 𝗪𝗶𝘁𝗵 𝗔𝗜

The current conversation around AI sometimes makes it sound as though automation is something completely new, but developers have been automating work for decades.

Scripts have replaced manual updates, web applications have replaced paper processes, cloud platforms have reduced infrastructure work, and continuous integration and deployment have reduced repetitive release tasks.

AI is part of that longer history of automation, but the difference is the scale of its impact and the types of work it can now affect.

Traditional automation usually requires developers to define specific rules and workflows. Generative AI can assist with work involving language, documents, research, customer support, content creation, classification, and even software development.

Because AI can affect work that once required human judgment, creativity, or communication, the conversation feels much more personal for developers and other knowledge workers.

𝗧𝗵𝗲 𝗥𝗲𝗮𝗹 𝗟𝗲𝘀𝘀𝗼𝗻 𝗜𝘀 𝗔𝗯𝗼𝘂𝘁 𝗦𝘁𝗮𝘆𝗶𝗻𝗴 𝗔𝗱𝗮𝗽𝘁𝗮𝗯𝗹𝗲

The lesson I took from Jacob’s story was not that developers should stop automating work because automation may affect someone’s job. Avoiding progress is not a realistic career strategy.

The stronger lesson is that our skills cannot remain frozen while technology continues to evolve. A team may be valuable today because its members understand how to maintain a specific process, but tomorrow the company may need people who understand how to automate, redesign, evaluate, monitor, or improve that process.

The work changes, and our skills have to grow with it.

This is especially important in the current AI conversation because the question is not only whether AI can generate code or complete certain development tasks. The bigger question is whether developers are learning how to use it, integrate it, evaluate it, and recognize when it should not be used.

𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗗𝗼 𝗡𝗼𝘁 𝗛𝗮𝘃𝗲 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱 𝗠𝗼𝗱𝗲𝗹𝘀 𝗙𝗿𝗼𝗺 𝗦𝗰𝗿𝗮𝘁𝗰𝗵

One idea I appreciated in the book is the distinction between building AI models and building applications with AI models.

Developers do not need to train a large language model from the beginning to create something valuable. We can work with pretrained models by using tools and skills we already understand, including APIs, software development kits, databases, search systems, application architecture, security, monitoring, and testing.

The book describes developers as “AI chefs.” A chef does not need to build the oven before preparing a meal but does need to understand the ingredients, the available tools, the recipe, and the result they are trying to create.

That comparison connects well with what I have been learning while reading AI Engineering. Making one successful API call is usually the easy part, while the real work is building a reliable system around the model.

𝗔𝗻 𝗔𝗣𝗜 𝗖𝗮𝗹𝗹 𝗜𝘀 𝗡𝗼𝘁 𝗮𝗻 𝗔𝗜 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆

The startup example in the book explains this clearly. A team creates an AI support agent by connecting its application to a large language model.

The model can greet customers and generate natural-sounding responses, but it knows nothing about the company’s actual product. When customers ask specific questions, it provides generic instructions or confidently gives information about a completely different product.

Technically, the API integration worked, but from the customer’s perspective, the solution did not.

A useful AI system needs more than access to a model. It needs the right context, trusted data, clear instructions, security boundaries, evaluation methods, and a plan for handling incorrect responses.

As developers, we still need to determine whether the model has the information it needs and whether its responses should be grounded in company documentation. We also need to decide how accuracy will be evaluated, what should happen when the model hallucinates, and how private company and customer data will be protected.

We must also understand when a human should review the result and whether the problem requires a large language model at all. In some situations, traditional software may still be the simpler and more reliable solution.

Connecting a model to an application may be simple, but building a system that people can trust is much harder.

𝗣𝗿𝗼𝗯𝗮𝗯𝗶𝗹𝗶𝘀𝘁𝗶𝗰 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝗥𝗲𝗾𝘂𝗶𝗿𝗲 𝗮 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗠𝗶𝗻𝗱𝘀𝗲𝘁

Traditional software is generally deterministic, which means that for a given input, we expect a specific output. We write tests to confirm that our code behaves the way we intended.

Large language models are probabilistic, so the same prompt may produce slightly different responses. A model can provide a useful answer one moment and a confidently incorrect answer the next.

This changes how we design and test applications because a successful demonstration is not enough. We need evaluations, monitoring, guardrails, fallback behavior, and clear expectations about where variability is acceptable.

For a low-risk use case, such as brainstorming titles or rewriting a paragraph, a small mistake may not cause serious harm. In healthcare, security, finance, employment, and other high-impact areas, however, even a small error can have serious consequences.

The more critical the decision is, the more important human review becomes.

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗟𝗶𝗺𝗶𝘁𝗮𝘁𝗶𝗼𝗻𝘀 𝗜𝘀 𝗣𝗮𝗿𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗪𝗼𝗿𝗸

The chapter discusses several limitations of large language models, including outdated knowledge, hallucinations, bias, and difficulty with multi-step reasoning. These limitations do not make large language models useless; instead, they define the engineering problems developers must solve.

Prompt engineering can provide clearer instructions, while context engineering can ensure the model receives the right information. Retrieval-augmented generation can ground responses in relevant documents, and fine-tuning can help a model perform specialized tasks or follow a particular style.

Evaluations can help teams measure performance, while human review can reduce risk when decisions have serious consequences.

The goal is not to expect the model to be perfect. The goal is to design a system that recognizes and manages the model’s limitations.

𝗦𝘁𝗮𝘆𝗶𝗻𝗴 𝗖𝘂𝗿𝗿𝗲𝗻𝘁 𝗗𝗼𝗲𝘀 𝗡𝗼𝘁 𝗠𝗲𝗮𝗻 𝗖𝗵𝗮𝘀𝗶𝗻𝗴 𝗘𝘃𝗲𝗿𝘆 𝗧𝗼𝗼𝗹

The AI ecosystem changes quickly, and new models, frameworks, coding assistants, and agent platforms appear constantly. Trying to learn every new tool can easily become overwhelming.

Staying current does not mean becoming an expert in every product. It means understanding the concepts that remain important even when the tools change.

Developers need to understand how models receive context, how their responses should be evaluated, and how sensitive data can be protected. We also need to know when retrieval-augmented generation is a better choice than fine-tuning and where humans should remain involved.

Building a useful system requires balancing cost, speed, accuracy, and reliability. Most importantly, developers must be able to determine whether AI is the right solution to the problem in the first place.

A framework may become outdated, but strong engineering judgment will remain valuable.

This chapter helped me think more deeply about the connection between AI engineering, software development, automation, and career adaptability.

Automation has always changed the kind of work developers perform, but AI is accelerating that change and expanding the types of work that can be automated.

The answer is not to panic, and it is also not to add AI to every application simply because it is popular. The better response is to keep learning, understand the technology beyond the hype, and apply the same engineering discipline we use with every other powerful tool.

For me, learning AI is not about abandoning my background as a software developer. It is about expanding it.

The developers who remain valuable will not necessarily be the ones who use the most AI tools. They will be the ones who know how to choose the right tool, build reliable systems around it, and solve real problems responsibly.

Learning AI is no longer optional for developers, but learning how to use it well is what will make the difference.

𝗔𝗜 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗖𝗵𝗮𝗽𝘁𝗲𝗿 𝟯: 𝗪𝗵𝘆 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗻𝗴 𝗔𝗜 𝗜𝘀 𝗛𝗮𝗿𝗱𝗲𝗿 𝗧𝗵𝗮𝗻 𝗜𝘁 𝗟𝗼𝗼𝗸𝘀

Yodit Weldegeorgise — Tue, 07 Jul 2026 00:54:03 +0000

One of the biggest takeaways from Chapter 3 of AI Engineering was realizing that building an AI model is only part of the challenge. Figuring out 𝗵𝗼𝘄 𝘁𝗼 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗲 𝗶𝘁 𝗳𝗮𝗶𝗿𝗹𝘆 𝗮𝗻𝗱 𝗮𝗰𝗰𝘂𝗿𝗮𝘁𝗲𝗹𝘆 can be just as difficult.

With traditional software, it's usually easy to tell whether something works. If a calculation is wrong or a test fails, you know there's a bug. But AI doesn't always work that way. A model can generate multiple reasonable answers to the same question, making it much harder to determine which one is actually better.

That made me think:

𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗸𝗻𝗼𝘄 𝗶𝗳 𝗮𝗻 𝗔𝗜 𝗺𝗼𝗱𝗲𝗹 𝗶𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗶𝗺𝗽𝗿𝗼𝘃𝗶𝗻𝗴?

𝗕𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸𝘀 𝗡𝗲𝗲𝗱 𝘁𝗼 𝗞𝗲𝗲𝗽 𝗘𝘃𝗼𝗹𝘃𝗶𝗻𝗴

Reading this section made me realize how difficult it is for evaluation benchmarks to keep up with the pace of AI development.

The chapter explains that GLUE (General Language Understanding Evaluation) was introduced in 2018 to measure how well language models performed on common natural language tasks. But within about a year, models had already become so good at it that researchers introduced SuperGLUE in 2019 as a more difficult benchmark.

GLUE evaluates tasks such as:

Question answering
Sentiment analysis
Sentence similarity
Text classification

The chapter also mentions newer benchmarks like:

SuperGLUE
MMLU (Massive Multitask Language Understanding)
MMLU-Pro

Each one was introduced because the previous benchmark was no longer challenging enough.

What I found interesting is that a model getting a higher benchmark score doesn't always mean it understands language better. Sometimes it simply means the model has become very good at solving that particular benchmark.

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗘𝗻𝘁𝗿𝗼𝗽𝘆 𝗮𝗻𝗱 𝗣𝗲𝗿𝗽𝗹𝗲𝘅𝗶𝘁𝘆

Another section I really enjoyed was the explanation of entropy and perplexity.

The chapter explains entropy as a measure of how much information a token carries and how difficult it is to predict the next token in a sequence.

Perplexity measures uncertainty. If a model is very uncertain about what comes next, its perplexity will be higher. If it predicts confidently and accurately, the perplexity becomes lower.

I also liked learning that cross entropy, perplexity, bits-per-character (BPC), and bits-per-byte (BPB) are all different ways of measuring how well a language model predicts text. The better a model predicts text, the lower these metrics become.

Another point that stood out was that there isn't a single "good" perplexity score. The value depends on:

the dataset being evaluated
the tokenizer being used
how perplexity is calculated
how much context the model has access to

That was a helpful reminder that metrics should always be interpreted in context instead of being compared blindly.

I also found it fascinating that these metrics connect directly to text compression. If a model predicts text efficiently, it can represent that information using fewer bits. I had never thought about language models and data compression being so closely related before reading this chapter.

𝗘𝘅𝗮𝗰𝘁 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗼𝗻 𝘃𝘀. 𝗦𝘂𝗯𝗷𝗲𝗰𝘁𝗶𝘃𝗲 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗼𝗻

Another concept that made a lot of sense was the difference between exact and subjective evaluation.

Some tasks have one correct answer.

For example:

Solving a math problem
Passing a unit test
Answering a multiple-choice question

Those are easy to evaluate because the answer is either correct or incorrect.

But many AI applications don't work that way.

How do you measure whether one response is more helpful, more creative, or better written than another?

That's where evaluation becomes much more subjective.

𝗔𝗜 𝗝𝘂𝗱𝗴𝗶𝗻𝗴 𝗔𝗜

This was probably my favorite section of the chapter.

Instead of relying only on humans, researchers are now using one AI model to evaluate another.

An AI judge can answer questions like:

Is this response relevant?
Does it contain hallucinations?
Which response is better?
Which answer would users probably prefer?

The chapter even discusses research showing that some AI judges can agree with human evaluators surprisingly often.

But it also explains why we shouldn't blindly trust these judges.

They can be influenced by:

the prompt
the order responses are presented
the model itself
different scoring methods

One sentence from the chapter really stuck with me:

"Do not trust any AI judge if you can't see the model and the prompt used for the judge."

That feels like a good reminder as more AI tools become black boxes.

𝗟𝗼𝗼𝗸𝗶𝗻𝗴 𝗕𝗲𝘆𝗼𝗻𝗱 𝘁𝗵𝗲 𝗪𝗼𝗿𝗱𝘀

Another idea I found interesting was the difference between lexical similarity and semantic similarity.

Two sentences can use completely different words while meaning almost the same thing.

For example:

"What's up?"
"How are you?"

On the other hand, two sentences can look almost identical while meaning something completely different.

The classic example from the chapter was:

"Let's eat grandma."
"Let's eat, grandma."

A single comma changes everything.

This is where embeddings become so important. Instead of comparing words directly, embeddings represent meaning as vectors, allowing models to compare ideas rather than just matching text.

That's what powers many modern AI applications like semantic search, recommendation systems, retrieval, clustering, and RAG.

𝗖𝗼𝗺𝗽𝗮𝗿𝗶𝗻𝗴 𝗜𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗦𝗰𝗼𝗿𝗶𝗻𝗴

The chapter also discusses comparative evaluation, an approach that compares responses instead of scoring them individually.

It's often easier to compare two responses than to assign one response an absolute score.

It's much easier to say:

"Response A is better than Response B."

than to confidently say:

"This response deserves exactly 8 out of 10."

That idea is now used heavily in preference training and ranking AI models.

This chapter gave me a new appreciation for AI evaluation.

Before reading it, I mostly thought about model architectures, prompting, fine-tuning, and inference. Now I realize that evaluation is just as important.

A powerful model isn't necessarily a useful model. If we can't measure reliability, usefulness, safety, or alignment, it's difficult to know whether a model is actually improving.

One of my biggest takeaways from this chapter is that evaluation isn't just about assigning a score to a model. It's about understanding what those scores actually mean, choosing the right evaluation method for the task, and recognizing the limitations of each approach.

As AI continues to evolve, I think building better evaluation methods will become just as important as building better models.

The Journey of Finding Mentors

Yodit Weldegeorgise — Mon, 29 Jun 2026 04:26:42 +0000

Have you ever met someone who challenged you in a way that helped you grow?

During my undergrad, mentorship was not something I intentionally searched for or even fully understood. Nobody ever sat me down and said, You should go find a mentor.

At that time, I was focused on doing well academically, learning, and building my future one step at a time. Along the way, I had questions, and I had a study guide who helped explain concepts, answered questions, and gave guidance when needed. Back then, I never viewed those interactions as mentorship.

But looking back now, I realize that was actually the beginning of it.

Over the years, I have had six one on one mentors. Each one has contributed to my growth in different ways, and today I'm fortunate to have two mentors who continue to guide me.

They helped me see things differently. They challenged me in ways I did not think I was capable of. Sometimes they saw potential in me before I could even see it myself.

And the interesting part is, none of these mentorships started formally.

There was no application process.
No interview.
No official title.

Most of them happened naturally through situations, conversations, and simply asking questions.

For example, one of my mentors is actually from this club, Jen.

At first, our interaction was very simple. She reviewed my speeches, answered my questions, and gave me the feedback I needed. Whenever I needed help, she was there.

She goes out of her way to evaluate my speeches at different events, whether online or in person. She is always open to my creative ideas, whether it is recording a video, writing a blog, or trying something new.

It’s not just feedback and evaluations. She also finds thoughtful ways to encourage and support my growth.

Over time, without us formally planning it, that relationship naturally grew into mentorship. Now we meet every Monday.

What I appreciate most is not just the advice, but the consistency, encouragement, and perspective. Sometimes I walk into a conversation thinking I fully understand a situation, and then after talking with her, I realize there’s an entirely different perspective I never considered before.

Another mentorship started during a cohort program where I was building in public in a group setting.

One day, my team lead, Mike, messaged me asking if we could have a call.

The moment I saw that message, I got scared.

My mind immediately started overthinking.

Am I being let go from the cohort?
Did I do something wrong?
Should I be worried?

I spent the whole time before the call feeling nervous.

But when we finally talked, the conversation was completely different from what I imagined.

The call was not about removing me from the cohort. It was about hearing my perspective and helping me refine the way I approached things in a way that would benefit me long term.

I'm a very analytical person, so I really appreciated that the feedback came with detailed examples instead of just vague comments.

Mike was not just pointing out problems. He explained why certain approaches were not working and how changing them could benefit me long term.

I remember being really impressed by how thoughtful and intentional the feedback was.

Even though some of it was uncomfortable to hear, I could tell the goal was growth.

One of the greatest values of mentorship is having someone who is willing to say the hard things with the intention of helping you grow.

Eventually, I reached out and asked if he would be open to having ongoing weekly calls with me until the cohort ended.

Thankfully, he said yes.

And even after the cohort ended, the mentorship continued with regular check-ins about once every other week.

And mentorship does not always have to be one on one either.

Some mentors I learn from have group mentoring sessions where people type their questions into the chat during a live session, and the mentor answers them openly.

At first, I used to think, Does this really count as mentorship?

But over time, I realized mentorship is not defined by the format.
It is defined by the growth.

Even if it is not the traditional one on one setup, if someone's guidance, wisdom, or perspective helps you grow into a better version of yourself, that is still mentorship.

Mentorship does not always begin in a formal way. Sometimes it starts with simple conversations, honest feedback, and the willingness to learn.

Sometimes it starts with one question, one meeting, or one honest conversation.

And sometimes, that one conversation can completely change the direction of your life.

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.