My First Time on Stage — And the Question That Got Me There

A couple of weeks ago, I did something I had never done before — I stood in front of an audience and gave a talk.

It was a student event, and honestly, the idea of being a speaker still feels a little surreal to me. I'm used to writing code, not speeches. But when I got the opportunity, I thought: why not? If I spend most of my days solving problems I've never seen before, surely I can handle talking about something I actually know.

In this post, I want to share both the topic of my talk and what it felt like to be on the other side of the mic for the first time.

The Event

The audience was mostly students — people who are at the beginning of their tech journey. They were the students of computer science and related faculties.

I work as a Senior Software Engineer, and in my current position, about 90% of my time is spent creating new functionality. I personally have almost no meetings, but that is just how things happened in my case. I have a colleague whose situation is the opposite: he might code for half a day per week, while the rest of his time is spent in meetings.

The reality is that the field is wide, and there are many ways to build a career in it. That's exactly why I chose to talk about a somewhat controversial topic that isn't limited only to the IT field.

The Question

Is it better to be a generalist or a specialist in one specific area?

Before I go further, I want to be clear: what I shared was my own experience and my personal view. Please treat it as one possible perspective rather than a universal truth.

Since I currently work mostly in IT, the examples I give come from this field.

My Path Into Tech

My educational background, if I explain it briefly and in simple terms, was to become a train driver.

I was familiar with computer science only through Mathcad. For those who are not familiar with it, Mathcad is software for mathematical calculations, but it also includes a programming block.

Toward the end of my studies — I think it was around my eighth year of education — I realized that programming was more interesting to me in many ways than operating rolling stock.

And that's when I faced this exact question: should I learn everything at once, and if so, what exactly? Or should I focus on one specific thing — and again, which one?

• Frontend: HTML, CSS, JavaScript, Gulp, jQuery, and so on.
• Mobile development: Swift, Kotlin.
• Backend development: Java, Python, PHP.

DevOps as a category was only starting to gain popularity at that time.

At the right moment, I happened to come across a book about frontend development, so I decided to focus on that.

Since this world was completely new to me, I kept asking myself how deeply I needed to learn a technology for it to be "enough."

The short answer is: there is no limit.

Seeing the Bigger Picture

Over time, I started looking at how everything works together as a system: how the client communicates with the server, how the whole thing is hosted, what CI/CD mechanisms exist, and how to make this process faster and more reliable.

When you understand the full lifecycle of an application, it becomes much easier to solve different kinds of problems.

For example, if something breaks during deployment, you don't necessarily need to go and fix the problem entirely on your own. By looking at the logs, you can quickly assess the issue.

If you know what it is, you can try to fix it yourself. If you don't know, then at least you know who to contact — and you can already provide them with useful context.

The Flashlight Analogy

Studying and working in only one narrow area is like using a flashlight that shines very far, but in a very narrow direction.

In the modern world, when almost any information can be found in seconds, it is not necessary to keep everything in your head.

Honestly, based on my own experience, the market needs people who are specialists in all areas — ideally with a solid understanding of everything: backend, DevOps, and frontend.

How to Actually Learn All of This

So how do you learn all of this and still have enough life left?

Choose the direction that feels most interesting to you. Choose something you enjoy working with and experimenting with, whether it's a technology or a programming language.

Make it your main daily thing — something you do without constantly thinking, "How much is still left?"

Around every direction, there will always be related libraries, frameworks, different approaches, and so on. Those can be learned in practice when they're actually needed.

There is no point in filling your head with reference materials that you can take from the shelf at any moment.

At the same time, no matter what technology or direction you choose, it is important to understand how you will deliver it to the end user: where you can deploy it, how to deploy it, how to update it, and how to test it at each of these steps.

Infrastructure Matters

Knowledge of infrastructure is very important.

Today, if you look at job descriptions, in most of them knowledge of CI/CD processes, setup, and maintenance will be considered a significant advantage.

This is where knowledge of related technologies, infrastructure, and similar areas can give you an advantage over other candidates.

Job descriptions never contain just one sentence: "Perfect knowledge of Java." Period.

The Interview Question That Reveals Everything

Some of you may have seen videos on YouTube where mock interviews are conducted. Very often, they ask a question that can reveal a candidate's seniority:

"Tell me what happens when you open a browser, type a query into the search field, and press Enter."

The answer can be one sentence, or you can spend half the interview talking about it, going deeper into the OSI model (Open Systems Interconnection).

This single question perfectly illustrates the generalist-vs-specialist debate. The breadth and depth of your answer says everything about how you understand the system as a whole.

Finding the Balance

To summarize what was said above, it is important to be both a specialist and a generalist.

You need to find the right balance that is necessary for your work, your studies, or your interview preparation.

As banal as it may sound, you need to learn how to learn. You need to structure information properly so that it doesn't fill your entire head today and disappear tomorrow, even though you spent a whole week studying it.

By the way, I'd like to recommend a book on this topic:

Barbara Oakley — A Mind for Numbers: How to Excel at Math and Science

You will never learn "enough" in a narrow area. It will always be insufficient, and there will always be somewhere further to go. That is why it is important to understand the level of sufficiency and relevance.

The Skill Nobody Teaches You

We've been talking about hard skills, but there is another important skill set that sometimes matters much more than knowledge of programming languages, patterns, and so on: soft skills.

This is something that is usually not taught when learning programming.

Soft skills are the ability to work with your colleagues in such a way that after work on Friday, you still want to go somewhere together.

Here are a few basic pieces of advice:

• Respect for colleagues — this is the most important one.
• Adaptability and flexibility — adapt to new conditions, colleagues, and the environment in general.
• Emotional intelligence (EQ) and self-organization.
• The ability to discuss conflicts and misunderstandings within the team.

This applies to teamwork, difficult meetings such as project or feature planning, resolving various discussion points, and so on. In this area, you definitely need to be a specialist.

What I Learned as a Speaker

This was my first time giving a talk, and I want to be honest about the experience.

I was worried too much, in real, when you stand in front of the audience, and holdind a microphone, you forget about the time, you start telling your story.

During the preparation for this talk, I asked for help from my wife and colleagues, I asked them to listen and give me true feedback. This helped me a lot to find places to improve.

One more thing I learned is that knowing your audience gives you the ability to adjust your talk for them, prepare for the Q&A session, and so on.

Final Thoughts

Preparing and delivering this talk was, in itself, a generalist exercise. I had to organize my thoughts, structure a narrative, manage my nerves, and communicate with a live audience — none of which are "coding" skills, but all of which made me a better engineer that day.

If you're thinking about speaking at an event, here's my honest take: it's uncomfortable, it's stressful but it's rewarding, and brings you more confidence. I would definitely recommend you to do it.

And if you're currently stuck on the "generalist vs specialist" question — don't stress it too much. Pick what excites you, learn the ecosystem around it, and understand how your work reaches the user. The rest will follow.