Name: ジュニアエンジニアが知らないこと (What junior engineers don't know)
Uploaded: 2021-01-14T10:17:41.000Z
Duration: 10 min 4 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

Hey, tech late here and welcome back to another episode of the attack.

命令形

It is about top things that I wish junior engineers with.

Now, for those of you who are new did the channel.

I am an ex Google Tech lead, which is amazing.

It's just something to keep in mind as you're watching my videos.

And that's something that you probably couldn't say about anybody else that you know.

Not your dad, not your mom, not your brother or sister or your friends.

And if you can say this about somebody, then you just need to keep in mind that they're not necessarily the tackle It I am v Tech lead.

You can confirm that by checking the user name on my YouTube channel.

That confirms that I have taken up that name and that's really why you should listen to me.

That's really the basis for my whole entire YouTube channel.

So without further ado, let's get to our sponsor of the day daily coding problem dot com slash stoeckley Check him out.

Whiteboard Questions Made two straight Every day you can learn about data structures, algorithms, hash maps, Q stacks, Rikers in immigration officers of white board, including questions you can read upon them.

Think about them throughout your day, stuffing them when you're bored.

I'll be doing them, too, so check him out.

Daily coding problem dot com slash tech lead So let's go under the first tip here we have a junior engineer.

His name is Jake, and he writes in that he's got some for architect at work disagrees with the way the software architect is doing things.

They've been given in a much simpler way and then, meanwhile, the software architect left for three weeks, came back with 50,000 lines of code of sequel coat and said that we have to use that as a framework.

And meanwhile, Jake just feels that there's just a much simpler way of doing this thing.

And Jake is just thinking that the sum for architect is ridiculous.

But this stark for architect is actually me.

I am to suffer architect that you've been complaining about.

I don't actually look like this in real life.

I put on the mask so that people don't actually know who I am.

I know you're complaining about me at work.

I'm going to make sure that you get what you deserve.

The reason that I went out and wrote 50,000 lines of code okay is because tech is not necessarily about being right.

There are a lot of things about computer science, but being right is not one of them.

If you only cared about being right, I recommend that you go become a professor and you can get into all the academics about this.

But computer science programming specifically is the application of code, and the application to practical application is messy.

a sturdy reality is ugly, and there could be many aspects beyond just being right.

When they see somebody go out and write 50,000 lines of over engineered garbage code, you have to think about what their motive is.

Is it simply because they're stupid is a simply because they're just trying to over engineer a bunch of stuff, wait up under time?

The reason they're doing this is such that they can carve out an ownership area for themselves for their team.

They can show that project to management.

They can show their everybody and Jake, if you can get on board with this offer architect, help that person billed out this huge project.

That person's already doing the book off the work.

50,000 lines of code already in there for you free and you just go help out.

You can become part time owners of this brand new project, and it can lead to great things for you and your team.

So that's the first thing is that there can be many different aspects, and I might remind you that this isn't necessarily simply about politics.

All the politics may play a big part at work, and you just need to keep that in mind.

But there could be some very good reasons for this.

For example, one time I was working in the company, I saw a far greater, easier way to build something.

I would just say, Hey, let's just take this component from open source.

But this person wanted to spend months building on this project, and I didn't understand why this person would be going around trying to do all this work until later on.

I realized that there a lot of actual benefits riel practical benefits, for example, having ownership of something could let you modify the code more easily.

You could at that that however you want it to, you could really make it flexible.

You could make it a much bigger, longer term project and stuff.

Just solving one small short term go finishing it, shipping the product and moving on.

Maybe you could actually turn this into a much bigger framework, something that could be useful and supported and used across many different teams within your company.

And if you have that long term vision than you may see that there's really much more that may be doable.

It's a lot like when you're driving and somebody cuts you off.

If you continue dr into this person, yeah, you're going to be right in the eyes of the law.

You'll be right, but you'll also be dead now.

The second thing I want you junior engineers to know is to pick your battles.

And this also has to do with not necessarily being right all the time.

Because if you take a look at this junior engineer Jake here, that disagreement with a senior engineer and what really happens is that the senior engineers, your colleagues, they're going to be the ones writing your peer reviews.

It's just not going to do you any good if you start causing conflict with people in your area.

The best way to deliver criticism if you're going to do it is to ask questions as questions is that people can think about the problem.

I think about how their answer that if they can't find the answer.

Maybe then you would have shown them the problem.

Encourage them to the justice solution and save some face instead of having you just come in and point out that they're wrong and embarrass them in front of everybody.

The other things is actually going to be in your best interest to get this senior engineer promoted such that it makes space for you.

Of course, if this person doesn't deserve promotion, then fine, but is often going to be in your interest to support your attack lead.

And this is why I say a lot of people think that I'm joking when I say that your job is to support your attack lead.

But it's going to be in your interest to just make sure that the people around you, your whole team, everybody is doing well getting promoted.

You will rise as a team or you will sink as a team.

And as you clear up space above you, then there's going to be more space for you to grow son zoo in the art of war.

字幕リスト動画再生

ジュニアエンジニアが知らないこと (What junior engineers don't know)

stuff

subscribe

deserve

term