Name: ソフトウェアエンジニアのチームでの働き方（UIデザイナー、プロダクトマネージャー、ソフトウェアエンジニアなど (How software engineers work in teams (UI Designers, Product Managers, software engineers, etc.,))
Uploaded: 2021-01-14T10:45:05.000Z
Duration: 8 min 38 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

Welcome back through the ex Google ex Facebook Tech lead show Now today.

Engineers work in teams, and we're going to be covering a number of people that you may be working with.

Software engineers may generally work with other software engineers, the product manager who may be responsible for the overall feature.

You are designers and engineering managers, so this is for like, a future team type of project, the type of team that I usually work in.

And I thought I will talk about my experiences working with these sorts of people, and if you haven't worked in the team and suffer engineering, then this would give you a good idea of what that's going to be like.

And then someone my tips interests in dealing with these types of people.

Quick pause thanks to our sponsor, Carol's.

The Stream, a subscription streaming video service that offers thousands of nonfiction titles and documentaries from some of the world's best filmmakers, include the exclusive originals.

Check him out a curiosity stream dot com slash tech lead.

So first up, actually, I wanted to talk about you.

I designers who actually come up with a design for a feature.

And I want to mention this because I have a huge problem with you.

I designers, at least the way they currently work.

A graphic about what the future is going to look like.

Advantage the engineer's job to actually translate this graphic into working code that works across all sorts of different screen sizes.

Now the problem with you designers is that there's no holistic thought behind a lot of this, actually.

For example, if you take a look at same material design or Apple's Cupertino designed the human interface guidelines, then that's actually a holistic design.

And what the engineers can do is translate this design system into code like you could have a set of consistent colors padding tech sizes, funds and all of this could just be translated into code, such that you have this one cohesive system and design.

But usually what happens with designers is that as far as I've seen, there's just no consistency.

They just play it by eye, and each time is just like this time.

They want the color to be a little bit off center red.

Or they want the pixel to be just a little bit shifted more.

But they want a text size to be just a little bit bigger than they used to be.

A button to be patted by seven pixels instead of eight pixels.

And what happens is that this just great.

I've actually been in meetings at Facebook, where the designer comes up with inconsistent and different designs for very similar views across different pages of the neck.

So what I'm trying to say is that the design drives the coat.

If the design is consistent and holistic and well thought out, then the coat can also be well thought out and very organized.

But if there's a different design for each different page than you're going to need to duplicate the code that many number of times, as well as just going to be a complete mess, so what engineers can do is work with designers to help them understand the constraints within the system and the need for consistency, because that can actually reduce the amount of coat that you will be ready back at Facebook, I think there are thousands or tens of thousands of views, each one just a little bit different.

I mean, how many views do you really need?

But the reason we have so many thousands of those was because each designer had a different little tweak on each of you and then with one thing to be a little bit different each time.

Not to mention these days, you I just need to be far more complex and needs to support all sorts of screen sizes.

Patrick's dark mood light moved very intact sizes and responsive design.

So the costs and having additional views and you guys just goes up quite a bit just in order to support a small little inconsistency between each one.

Okay, so the second type of person that a software engineer may work with is a product manager, which is like a mini CEO of a small little feature, and the PM helps guide a future forward.

So the product manager is responsible for the overall Rolla off a future coordinating with the suffer engineer that designers maybe the day the scientist analyzed metrics ended to eventually ship a feature.

So oftentimes it is the product manager that is driving a feature for and the engineer just sort of sister and implements whatever work that they're being told to do.

But what I found actually is that engineers can actually help dry future development as well, because it is the engineer that usually knows which feature is easy to do and which is not easy to do.

I found this rather than just sitting around and waiting for the PM to tell you what to do.

You can actually be digging around the code and creatively think about cool ideas or products and propose them to the PM and let them know this type of feature can be built very easily and quickly.

Sometimes I just build a prototype over a weekend and show people on Monday, and that may launch a project for it because nobody except the engineer really knows which features are easy to do and which are difficult.

For example, the project manager may suggest a pop up dialogue, which they may think it's pretty easy to do but could take 2 to 3 weeks, just the implement for the engineer, whereas in fact, if you were to navigate to a new pages that that could save you 2 to 3 weeks of implementation and just help you ship things much faster.

So as an engineer, I would consider it part of your job to work with the project manager.

Occasionally you can come up with suggestions or ideas.

Alternatives to help influence the product direction.

Now, another person that you may be working with are the engineering managers.

In my experience, the managers they're not so technically hands on.

But they're more focused on your career development as a person, so just making sure you're hidden here goes getting good performance ratings and any promotions that may be coming your way.

As faras engineering managers go, my only suggestion would be to try to find the technical manager who used to be a programmer, if at all possible, because, in my opinion, only they would truly be able to understand what type of work you're doing and be able to sympathize with the hardships and challenges that you may be going through.

Otherwise, you know, a manager may just be driving you without truly understanding how difficult the tasks you may be doing red, they may just a come on, it's just button.

Maybe you have to implement it on the front and then go into the back and using a completely different language, just a wire, everything up.

But in the logging testing wire up, the metrics support accessibility right to left international languages, so there could be a host of other things there.

But generally I find that managers they're there to support you build out your career, and you just need to let them know what you want.

And they can help guide you in that direction.

And then one more type of person you work with as a software engineer.

Our other software engineers now the relationship between suffer engineers I find to be somewhat competitive, as was collaborative as well.

What happens is I find the Love software engineers.

They're competing with each other to try to take on projects that are highly impactful, and if there's a good project idea, sometimes people will fight each other for it.

Sometimes you see engineers just inventing random frameworks, and then they want everybody else to use these frameworks, these over engineered pieces of garbage, just such that they can claim that on their performance review.

And if you don't use their friend wish they're going to feel a little bit offended.

And then there wouldn't go through your code and tried to migrate your code and re factors such that it's using their framework.

And then you have to go through tons of code reviews.

And before you know what, you've just got over engineered to trash.

Other times you're working with suffer engineers and they're just not pulling their weight, you gotta do everything yourself.

And then they're taking your credit claiming that they helped work on this project in which they didn't really do that much.

Not in my opinion, the proper way to go about this is actually to take on initiative.

When you can take on the initiative and come up with a really great project idea, you actually create more opportunity, and then people will be clamoring to try to work with you on this project.

If everybody is able to come up with a really cool, big initiatives.

Then you want to work with other engineers who came up with this idea, and other people want to work with you on your idea.

And if you're not able to come up with some impactful project idea, then yeah, maybe you should just go work with another engineer who is able to come up with that.

Maybe somebody who's probably more senior, who has more contacts and experience and then learn from that person.

And then later on, you'll be able to drive your own projects as well.

Cure us thieves dream dot com slash tech lead One of the world's first streaming video service is focus on understanding, exploring and learning More about our World, Created by the founder of the Discovery Channel, is content.

Spend science, nature, history, technology, society in life.

So I particularly like the episode African and the More rescue following their crew saving some of the world's most exotic and endangered wild animals.

Callum that access and they just turned 99 a month or 1999 the year and your plans and gift cards are 40% off for a limited time.

And because I'm the tech lead, I'm giving you a free 30 day trial completely free to check him out across the stream dot com slash tech lead.

But my overall message is that as a suffer engineer, you probably have far more influence than you may imagine, because software engineers are the only ones who are actually working with the product in the code.

And they know what can and cannot be done so that do it for me.

I hope this gave you a clear idea of house offer engineers working teams.

If you like the video, give it like and subscribe.

ソフトウェアエンジニアのチームでの働き方（UIデザイナー、プロダクトマネージャー、ソフトウェアエンジニアなど (How software engineers work in teams (UI Designers, Product Managers, software engineers, etc.,))