But after working on real applications, I have started to think about architecture a little differently.

Good architecture is not the architecture with the most abstractions. It is the architecture that makes the system easier to understand, change, and maintain.

Architecture is a developer experience problem

We usually think about developer experience in terms of documentation, tooling, onboarding, or how quickly someone can get a project running locally. Architecture is rarely included in that conversation, even though it has a huge impact on how developers experience a codebase.

When a developer needs to change one small feature and has to jump through ten different layers just to understand where the actual business logic lives, the architecture is creating friction.

On the other hand, when responsibilities are clear and a developer can quickly answer questions like where does this logic belong?, which part of the system owns this data?, and what could this change affect?, the codebase becomes much easier to work with.

Simplicity becomes more valuable as a project grows

One of the lessons I keep coming back to is that simple code is not the same thing as poorly designed code.

Sometimes a straightforward solution is exactly what a system needs. Introducing an abstraction just because a design pattern exists can actually make the application harder to understand.

The best abstraction is often the one you introduce only after you understand the problem well enough to know that you actually need it.

This is especially important in backend development. A clean controller, a focused service, a well-designed database relationship, and a clear API can often provide more long-term value than a complicated architecture built around hypothetical future requirements.

Reliability starts with understandable systems

Reliability is not only about uptime. It is also about predictability.

A reliable system should behave in ways that developers can reason about. When something fails, we should have a reasonable path toward discovering why it failed. When a feature changes, we should have confidence about what parts of the application might be affected.

This is where clear boundaries, meaningful naming, good logging, validation, and sensible data models become extremely important.

Think about the next developer

Every piece of code we write will eventually be read by someone else. Sometimes that person will be a teammate. Sometimes it will be someone joining the project months later. And sometimes it will be us six months from now, wondering why we made a particular decision.

That is why I try to think beyond “Does this code work?”

I also ask:

• Can another developer understand this without asking me?
• Is the responsibility of this component clear?
• Will changing this feature unexpectedly affect something else?
• Will debugging this system be reasonably straightforward?
• Am I solving today's problem or inventing tomorrow's problems?

Architecture should serve the people building the product

At the end of the day, architecture exists to help us build and maintain software. It should reduce unnecessary complexity rather than become complexity itself.

As I continue working on larger applications, I find myself appreciating boring solutions more and more. Clear code. Clear responsibilities. Predictable behavior. Good database design. Useful logs. Small, understandable components.

None of these things are particularly exciting on a diagram, but together they create something incredibly valuable: a system that developers can trust.

Explain the concept. Show an example. Let people write some code. Answer questions. Move to the next topic.

But after spending more time mentoring and working with different groups of developers, I realized that teaching technology is only a small part of the job.

People learn differently

One of the first things you notice when leading a workshop is that everyone arrives with a different background.

Someone might already understand the fundamentals but struggle with a particular framework. Someone else might be completely new but surprisingly comfortable experimenting. Another person may understand the technical concept but hesitate to ask questions because they are worried that their question is too simple.

That makes teaching a very different challenge from simply preparing slides.

You are not only explaining a concept. You are trying to create an environment where people can understand it in their own way.

The best workshops are not lectures

I have gradually become more convinced that people learn technology best when they actually build something.

A slide explaining an API can be useful. A diagram showing how authentication works can be useful. But there is a different kind of understanding that happens when someone writes the request themselves, gets an error, searches for the reason, fixes it, and finally sees the expected response.

That moment of “Oh, now I understand” is difficult to create through theory alone.

Questions are part of learning

One of the biggest things I learned from mentoring is that a question is not necessarily a sign that someone is behind.

Sometimes it means they are thinking deeply about the problem.

A healthy learning environment should make people comfortable saying:

• “I don't understand this.”
• “Why are we doing it this way?”
• “What happens if we change this?”
• “I tried this, but it didn't work.”

Those questions often lead to better discussions than simply following the prepared material.

Mentoring is also about confidence

Technical skills matter, but confidence matters too.

I have seen developers understand a concept but hesitate to write the code because they are afraid of making a mistake. That is something a good mentor should actively work against.

Making mistakes is not an interruption to learning. Making mistakes is part of learning.

Instead of immediately fixing someone's code, sometimes it is more useful to ask another question and let them discover the answer themselves. The goal is not just to solve today's problem. The goal is to help someone become better at solving the next problem without you.

Community makes learning sustainable

Workshops might only last a few hours or a few days, but the relationships created around them can last much longer.

When developers share what they know, help each other debug problems, talk about their experiences, and celebrate small wins, learning becomes a community activity instead of an individual struggle.

That is one of the things I value most about being involved in the developer community.

What I take away from every workshop

Every workshop has taught me something different. Sometimes it is a better way to explain a technical concept. Sometimes it is a reminder to slow down. Sometimes it is simply learning that the problem I thought would take five minutes actually needs thirty.

But the biggest lesson has been simple:

Teaching is not about proving how much you know. It is about helping someone else discover what they are capable of learning.

That mindset has changed the way I approach mentoring, workshops, and even everyday collaboration with other developers.

And honestly, some of the best lessons I have learned while teaching were lessons I did not expect to learn at all.

But emotions are rarely that simple.

Sometimes what looks like anger is actually disappointment. Sometimes frustration is really exhaustion. Sometimes silence is not peace but uncertainty. And sometimes we react to something without fully understanding why it affected us in the first place.

Learning to name what I feel

One of the simplest things I have been trying to practice is putting a name to what I am feeling.

Instead of saying “I feel bad,” I try to ask myself a more specific question: “What exactly am I feeling right now?”

Is it frustration? Disappointment? Anxiety? Embarrassment? Overwhelm? Loneliness? Excitement?

Sometimes finding the right word changes the way I look at the situation.

Why naming an emotion helps

When we cannot identify an emotion, it can be easy to react to it immediately.

We send the message we probably should have waited to send. We become unnecessarily defensive. We withdraw from a conversation. We assume someone else caused the feeling without taking a moment to understand what is actually happening inside us.

Naming the emotion creates a small pause.

There is a difference between feeling an emotion and immediately becoming a reaction to that emotion.

That pause can be valuable.

Emotional intelligence starts with self-awareness

We often talk about emotional intelligence as a skill that helps us communicate better with other people. But I think it begins much closer to home.

Before we can communicate what we need, we need to understand what we are experiencing ourselves.

Self-awareness helps us recognize patterns. Maybe certain situations consistently make us defensive. Maybe criticism affects us more than we realize. Maybe we become impatient when we are tired. Maybe we avoid difficult conversations because uncertainty makes us uncomfortable.

Recognizing those patterns does not immediately solve them, but it gives us something important: awareness.

Understanding is not the same as judging

Another thing I am learning is that understanding an emotion does not mean judging ourselves for having it.

Feeling angry does not automatically make us an angry person. Feeling jealous does not make us a bad person. Feeling insecure does not mean we are weak.

Emotions are information. They can tell us something about what matters to us, what we fear, what we need, or what has affected us.

A small practice with a big impact

I am still learning this myself.

Sometimes I notice an emotion only after I have already reacted. Sometimes I still struggle to explain exactly what I am feeling. But even noticing that has become part of the process.

Instead of trying to suppress every uncomfortable emotion, I am trying to become more curious about them.

What happened?

What am I feeling?

Why might I be feeling this way?

What do I actually need right now?

We are all still learning ourselves

As developers, we spend a lot of time learning how systems work. We study frameworks, databases, programming languages, architectures, and tools.

But understanding ourselves is a different kind of learning, and arguably just as important.

Learning to recognize and name our emotions will not magically make difficult situations disappear. But it can help us respond to those situations with a little more awareness and a little less impulse.

Sometimes emotional intelligence begins with something as simple as finding the right words for what we feel.

How should I explain the topic? Which examples should I use? How much code should I prepare? What should the participants build?

Those questions were important, but over time I discovered that the hardest and most rewarding part of a workshop had very little to do with the code itself.

It had to do with people.

A room full of different learners

Every workshop brings together people with different experiences, personalities, expectations, and levels of confidence.

Some participants ask questions constantly. Some prefer to observe before trying something themselves. Some are comfortable making mistakes publicly, while others need more time before they are willing to show their work.

A workshop becomes much more effective when you recognize those differences instead of expecting everyone to learn in exactly the same way.

Explaining something is not the same as teaching it

As developers, we sometimes assume that if we understand something clearly, we should be able to explain it easily.

That is not always true.

Teaching forces you to break your own understanding into smaller pieces. You have to identify what someone actually needs to know before they can understand the next concept.

And sometimes, when someone asks a question you did not expect, you discover that your own understanding was not as complete as you thought.

The unexpected lessons of leadership

Leading a workshop also taught me to become more comfortable with uncertainty.

Not every session goes exactly according to plan. A setup issue can consume half an hour. A participant can ask a question that takes the discussion in an unexpected direction. An example that worked perfectly on your machine might fail somewhere else.

At first, those situations can feel like problems.

Eventually, you realize that they are part of the experience.

People remember how you made them feel

A participant might forget a particular code example a few months after the workshop. They might forget the exact syntax you taught them.

But they may remember that they were encouraged to ask questions. They may remember someone patiently helping them debug their first project. They may remember that making a mistake did not make them feel stupid.

That is why creating a welcoming environment matters so much.

A good workshop should leave people not only with more knowledge, but also with more confidence.

Community is bigger than technology

One of the most rewarding parts of organizing and participating in technology communities is realizing that the community itself becomes a learning resource.

Developers learn from developers. Beginners learn from experienced people, but experienced developers also learn from beginners. Different perspectives often reveal problems or possibilities that one person would never have noticed alone.

That exchange is what makes a community valuable.

What I learned

Leading workshops changed the way I think about technical leadership.

Leadership is not always about having the answer. Sometimes it is about asking the right question. Sometimes it is about giving someone enough space to figure something out. And sometimes it is simply about being the person who tells someone, “Yes, you can do this. Keep going.”

The more workshops I lead, the more I realize that I am not just teaching technology.

I am learning how people learn, how communities grow, and how much better technology becomes when we build it together.

New framework? Learn it. New library? Try it. New architecture pattern? Understand it. Someone built something impressive? Figure out how it works.

For a while, that mindset felt motivating.

Then eventually, it became exhausting.

When learning stops feeling exciting

One of the strange things about development is that there is always something else to learn. The industry changes quickly, frameworks evolve, tools appear overnight, and there is always another technology that seems important.

That can make you feel like you are falling behind even when you are actually making progress.

I have had periods where I would sit in front of my laptop knowing that I wanted to learn something new, but I simply could not concentrate. I would read the same documentation multiple times without actually absorbing it.

At first, I interpreted that as laziness.

Later, I realized that sometimes your brain is simply asking you to slow down.

Burnout doesn't always look dramatic

When people talk about burnout, we often imagine someone completely unable to work. But it can be much more subtle.

Sometimes it looks like losing curiosity. Sometimes it looks like constantly switching between tutorials without finishing anything. Sometimes it is opening a project and immediately feeling overwhelmed.

And sometimes it is realizing that something you normally enjoy has started feeling like an obligation.

I started changing how I learn

Instead of trying to learn everything at once, I started giving myself permission to focus.

One problem. One project. One concept.

Rather than watching five tutorials about a technology, I would try to build something small with it. Rather than trying to understand an entire framework, I would learn the part I actually needed for the problem in front of me.

This made learning feel much more practical and much less overwhelming.

Rest is not wasted time

This is probably one of the hardest lessons for developers who enjoy learning.

When you genuinely like technology, it can be difficult to tell yourself to stop.

But stepping away from the screen does not mean you are falling behind.

You don't have to be learning every minute to be moving forward.

Sometimes the best thing you can do for your development career is close the editor, go outside, talk to people, work on something completely unrelated, or simply get some rest.

Progress is not always visible

We tend to measure development progress through things we can see: commits, completed projects, new technologies, certificates, job titles, and shipped features.

But there is another kind of progress that is much harder to measure.

Understanding a problem better. Becoming more patient with yourself. Learning how to debug without panicking. Becoming comfortable admitting that you don't know something. Learning when to ask for help.

Those things matter too.

Learning at a sustainable pace

I still want to learn. I still get excited about new technologies. I still have a long list of things I want to build.

The difference is that I no longer believe I have to do all of them immediately.

Software development is a long journey. There will be periods of intense growth, periods where things feel slow, and periods where you simply need to recover.

And I am learning to be okay with that.

Slowing down does not mean giving up. Sometimes it is exactly what allows you to keep going.