쉐도잉 연습: How to Become a Great Software Developer — Best Advice from Top-Notch Engineers - 영상으로 영어 말하기 배우기

The job must advise learn Kotlin. That was predictable.

Well, being a good developer, that's a very loaded question.

It starts with the definition of good.

Being a good programmer or developer takes several qualities.

First of all, that's attention to details.

Programming is all about small details.

Like things that...

you in casual communication or in text when you omit a comma or flip a word stuff like that

it doesn't really matter in your non-development life

but in programming like like uh what just one character in your code

or off by one somewhere can uh be a difference between code

that working correctly and code that doesn't work so attention to the small details is is really what makes

professional developers different

and that's the quality that's needed to become good software developer i enjoy working with extremely good

and at the same time very junior developers who arguably know very little, right?

But the way they approach the tasks at hand,

the way they learn, so the way they are curious and hungry to do things.

And it's an amazing experience, and I love them as contributors, and they're great developers.

They're just great junior developers.

So first thing I'll say is that the greatness in this question to me doesn't equate with experience necessarily, especially years of experience.

If I think about this, first thing that I'll say, and again, this is my personal opinion, this is not like a recipe,

but first thing I'll say is a fundamentals.

Like if you're using a data structure, like a library list or a map or something, do you know how that's working?

Like what kind of algorithms are implemented there?

Like why is it fast?

Do you know how memory is managed in the runtime you're using?

Do you know what kind of things are done under the hood to manage concurrency, for example, like synchronized threads and so on and so forth.

Do you know how things work under the hood in general?

And looking into that makes you a better engineer because you learn from other engineering decisions made by other people.

It makes you, it exercises your mind in an analytical way that you really need working on your own code.

And it also makes you just knowledgeable.

It's much easier for you to figure things out and make connections where they're unobvious?

I remember a question I was interviewed by a startup CTO some 12 years ago.

He asked me a question that I then kept asking in my own interviews that I liked very much.

Question is simple.

So for web developers, imagine you have on the web page, there's a button, you click on it, next page comes.

What happened between the button click and the next page?

Think about it for a second, right?

That onion can have five layers or a thousand.

You can spend five minutes answering the question

or you can spend an hour and not be done halfway through

because of how many things happen or can happen

and depending on what level you decide to stop and speak about

and the more layers of that onion you can stop and talk about knowingly

the better you understand that system and the better web developer you will be right.

Things like network protocols, things like database architecture with so much of software available today being open source,

you can be kind of the hood of pretty much any technology that you use, and you should do that.

And you should read books and watch presentations about how this type of software works.

And I think that the main benefit that brings is

that it can help you resolve problems much more confidently

and much more quickly than just if you just poke at things and see, like, if I do this, does this work?

No. Okay, let me try something else.

Don't tie your identity to a specific technology or set of practices.

So I see a lot of people saying that I'm a Kotlin developer, or I'm a Python developer, or I'm an Android developer.

And people who say that kind of think

that people who are not Android developers

or not Kotlin developers are not like me

and probably sometimes I see them as kind of competitors or enemies or something like that.

Or maybe I say that they are stupid

and don't know what they are doing and instead they should be using the best language on the planet which is Kotlin.

I don't think this is healthy.

I don't think this is good.

I think that it's much better to just identify yourself as a developer and learn the tools, learn what tools exist, learn tools,

what tools can benefit you in which cases, and use the best tool for the job and base your identity on something else.

Believe me, during your career you will have to learn many different languages and it is wonderful.

Each language is different, each one can teach you something new and change how you approach programming overall.

For example, I wrote very different code when I coded in Java.

Then when I learned Objective-C, it changed.

When I first touched Swift, it's once again changed.

And each language placed its mark on me.

So learn different programming languages, embrace them, and stay open.

Don't be afraid to learn something unnecessary.

So for example, Speaking of Kotlin, a very common question of people who start to learn Kotlin is, do I have to learn Java?

And this, do I have to learn, I think it's not the best way to put things.

Like, will learning Java make you a better Kotlin developer?

Yes, definitely, because you will be easier able to understand the APIs of different libraries that you probably will want to use.

You'll better understand how this whole environment works, things like that.

You'll better understand why some things in Kotlin are the way they are and not something else.

So don't be afraid to learn something that isn't necessary.

As we advance our careers as engineers, and it doesn't matter whether you're a consultant engineer or a product engineer,

you will be working with people like more and more, inevitably.

You'll be reading their requirements, their stories, their comments, You'll be writing the same thing,

you'll be speaking, you'll be communicating, you'll be explaining, presenting.

You'll work with people a lot, sometimes more than you work with code, especially if you measure your time minutes in the day.

And sort of best engineers are also just great at working with people in everything that that entails.

Don't stick to one career.

You're not doomed to be a software developer for your whole life.

Take me as an example.

I learned to be an information security specialist.

Then I became an Android developer, had to switch to iOS development.

Then I became a team lead, did some backend development.

Then I became a manager and then a product manager.

And now I'm leading a development of a programming language.

And that's actually great because in each

role you learn different skills that may help you in the main one if you decide to return it.

For example, if you are if you will become a product manager, you will be much better in understanding what and why and for whom you are building.

It will drastically help you to become a staff plus engineer because you will not just write code, you will think about business needs.

Or for example, if you are becoming a team lead and then decide to stop doing it,

it will teach you other essential skills like how to plan your time and time of other people,

100

or how to make decisions in uncertainty or other things.

101

So don't stick to one's career.

102

Your life is long.

103

You can try different things and find one that suits you the best.

104

When you're young, it feels like you can work 20 hours a day or 18 hours a day or something like that.

105

And it's a lot of fun to write software.

106

You may end up with your day job and your hobby project

107

and working for eight hours on one thing and then another eight hours on that.

108

Second thing, and this is kind of fun.

109

I did a little bit of that when I was younger, but I think it's very important to not focus on that,

110

not close your eyes to other things, other fun ways to spend the time, other ways to take care of your body,

111

your emotional state, your mind.

112

Read things, go for a walk, do some physical activities.

113

I think finding a healthy balance between all of these will allow you to sustain your productivity

114

and sustain the joy that substance development brings you for a much longer amount of time.

115

Keep learning new things, go deeper, go wider.

116

Look at how things are done nowadays if there is a new big trend, look into it.

117

Like nowadays, it's generative AI.

118

Look into that.

119

It will help you stay up to date.

120

It will help you be a better engineer.

121

And also just aim higher in general.

122

A lot of people underestimate themselves and just don't try things they could have succeeded at.

123

And you should do that.

124

You should try.

125

You should experiment with the things that you feel are out really.

126

You should apply to jobs you think that you're not good enough for.

127

And you should prepare for those interviews and get the job, you can.

128

So that's like top piece of advice that I can give.

129

And learn Kotlin.

✨ 추천 영상

63 문장

이 레슨에서 연습할 내용

이 비디오는 톱 엔지니어들의 조언을 통해 우수한 소프트웨어 개발자가 되는 방법을 다룹니다. 영상에서 사용된 자연스러운 영어 표현과 논리적인 말투를 연습함으로써, 기술적인 주제를 다루는 영어 회화 실력을 키울 수 있습니다. 특히 shadowspeaks와 영상 영어 공부를 통해 쉐도잉 연습을 하면, 발음과 리듬, 의견 전달 능력을 동시에 향상시킬 수 있습니다.

핵심 어휘 및 표현

attention to details: 세부 사항에 대한 주의. "Programming requires close attention to details"와 같이 사용됩니다.
under the hood: 내부에서, 본질적으로. "Do you know how it works under the hood?"처럼 기술적인 원리를 묻는 경우에 사용됩니다.
off by one: 하나 차이로 인한 오류. "An off by one error caused the program to crash"와 같이 코드 오류를 설명할 때 사용됩니다.
loaded question: 다층적인 의미가 담긴 질문. "Being a good developer is a loaded question"처럼 복잡한 주제를 다룰 때 사용됩니다.
concurrency: 동시성. "Managing concurrency is crucial in multi-threaded applications"와 같이 기술적인 맥락에서 사용됩니다.

쉐도잉 연습 팁

이 영상은 말하는 속도가 중간 정도이며, 기술적인 용어가 많아 집중력이 필요합니다. 영어 쉐도잉을 할 때는 다음과 같은 방법을 추천합니다. 첫째, 5초 간격으로 멈추면서 문장을 반복합니다. "attention to details"와 같은 구문은 발음이 빠르므로, 천천히 따라 말하며 리듬을 익히세요. 둘째, "under the hood"와 같은 관용구는 의미를 파악한 후에 자연스럽게 발음하도록 연습합니다. 셋째, IELTS 스피킹 준비에도 도움이 되는 논리적인 말투를 모방하세요. 예를 들어, "First of all, that's attention to details"처럼 주제를 명확히 전달하는 표현을 연습하면, 말하기 실력이 크게 향상됩니다. 마지막으로, shadow speak 방식을 사용하여 자신의 목소리를 녹음하고 원본과 비교해 보세요. 이를 통해 발음의 차이를 찾고 보정할 수 있습니다.

이 영상의 문법

화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.

문형	영상 속 표현
조건문 if + 절, will/would + 동사 — 조건과 그 결과	if you are if you will become
수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점	are implemented · is managed · are done
관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보	people who say · people who are · planet which is

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: How to Become a Great Software Developer — Best Advice from Top-Notch Engineers - 영상으로 영어 말하기 배우기

How To Land Your First Junior Dev Role

QA Automation Interview Questions and Answers

13k

Linus Torvalds Explains What Makes Linux So Fast

AI biết code, vì sao vẫn phải học lập trình? | đi-code ep 35

How Great Software Engineers Are Moving Faster Than Ever

Design Patterns in Java Theory

10 JavaScript Interview Questions You HAVE TO KNOW

I'm an ex-Google interviewer. You're doing LeetCode wrong.

How to Answer System Design Interview Questions (Complete Guide)

How to ACTUALLY Get a DevOps Job in 2026

If you’re an aspiring product designer, watch this (roadmap included)

이 레슨에서 연습할 내용

핵심 어휘 및 표현

쉐도잉 연습 팁

이 영상의 문법

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법