The Effective Engineer | Edmond Lau | Talks at Google
ฝัง
- เผยแพร่เมื่อ 13 ธ.ค. 2015
- How do the most effective engineers make their efforts, their teams, and their careers more successful?
In this talk, Edmond will share the most valuable insights that leaders from various top tech companies learned and the most common and costly mistakes that they've seen engineers - sometimes themselves - make. He will distill down some of the key themes and share a unifying framework called leverage that you can use to identify activities that produce disproportionate results.
1. Optimise for learning
2. Invest in iteration speed
3. Validate your ideas aggressively and iteratively
4. Minimise operational burden
5. Building a great engineering culture
Thank you for making me more effective today. Won't continue to watch nor buy the book.
@@noli-timere-crede-tantum LMAOOOO im dead that's funny
Basically so everything faster and smarter. THANKS
I always hope people use these outlines to judge whether the talk is worth watching, and don't think it it conveys everything the talk does. I can imagine someone reading this list and thinking "yep, got it!"
This guy should also give a talk on public speaking. Very easy to listen to, excellent talk.
To add to what Ed said about unit testing. "Rails Conf 2013 The Magic Tricks of Testing by Sandi Metz" was a great talk (on the youtubes) to solving for the unit test problem. It reduces to "write unit tests your public methods" and "test drive your private methods which are ok to break" Another engineer shouldn't be afraid to run your test suite.
Another issue is that these approaches need an environment where critical thinking and questioning of assumptions is actually encouraged and where programmers are not just supposed to 'just do it', so question #0 is where do you find such an organization and how do your fit in ?
Michael Moser I agree the type of orgs that foster this type of culture are few and far in between.
Excellent lessons. Applying the engineering mindset of breaking down problems to feature validation (experiment-driven development) was the best take-away for me.
This is one of the google talks that I love the most. Awesome talk!
Fantastic Talk. Very well put! Taking a lot of good points to work from here.
Edmond is so passionate & so intelligent ! Wonderful talk !
Brilliant. Every engineer needs to here this!
Great talk. Thanks, Edmond. Thanks, Google.
Actually, after work many years, I recognize that if your team is not effective enough, that is your problem because you join the wrong team/company.
Every leader likes positive words but rare to implement them.
The polling's result before class makes me feel psychologically balanced. :-)
This talk makes me think how these principles can be applicable for non-software engineers.
Wondering what reward structure exists for effective engineers? Another thought: what you describe as an "effective" engineer is a pretty good description of the senior engineers who built the original codebase. Of course they are most effective because everyone else has to spend most of their time deciphering that codebase and the weird conventions the senior engineers created. Those senior engineers might be pretty hopeless if you threw them into someone else's small pond. On the other hand, a lot of what you describe as in-effective is the process of building features your marketing team did not correctly prioritize. In the end, what you are saying is a very corporate message: engineers should simply want to improve themselves- it is their fault if a company does not succeed. Coming back to the orginal question.
Great talk but I found a small part of it to be effective engineer and a great part of it to be the effective company
The internet and information systems are the ultimate levers. Nearly infinite leverage. But you have to choose the right boulders to move. Don't be afraid to try moving the wrong ones if you at first think they are right - just one right one can set you up for life.
Engineers do work on new stuff, but also after getting enough expierience how to make new things they may see a time coming to be paid for making improving existing things all unprioritized, bad paid or disliked tasks which did not disturbe in the first place, but after some time making it harder to maintain or changing/adding features than it should be.
Company culture helps in balancing between most liked tasks and necessary quality aspects.
Great talk, thanks!
Brilliant talk - thank you.
I don’t agree on infinite scrolling case study since we don’t even know whether assumption is even correct.
My theory is infinite scroll makes tracking back items harder.
can anyone recommend videos like this one is? thanks in advance
Thank you Edmond for adding emotional intelligence!
Many engineers are detached .
Your also very easy to look at, meaning your HOT !
@Nihar Biseas thanks so much, very clever. Have a spectacular 2021, Blake.
This talk is more about project management than about engineering
25:25 What about second-order and higher interaction effects between treatments? Applied statisticians use design of experiments (DOE) to determine just that.
Great talk man
All are good points.
Great video!
Nobody drips with workplace trauma like software engineers
Recommend skipping to 12:00 to get to the actual strategies
effective!
it does not explain why the rate DROPPED 25%
I think it’s 2 things. Number of choices prob yields a diminishing return after a certain number, as far as decisiveness goes. Also, parsing by page gives the browser natural breaks to reflect on what they just saw. Infinite scroll doesn’t have that moment built in, so more data and less reflection / appreciation for what you just saw. Would love anyone else’s thoughts on it.
Google has the true continuous deployment, with fast tests and minutes to production.
The Q&A section was disappointing. To be fair, the questions being asked were very difficult problems to solve, and which mostly boil down to bad management or flaws in the team's engineering process. E.g. managers constantly pushing for minimum viable products with aggressive deadlines, not allowing for resolution of the inevitable technical debt this incurs, and then eventually hitting a productivity wall where adding more features takes too long due to system complexity and endless support tickets consuming developer time.
Bookmark : 33:12
Back when Quora was still a startup.
Engineer - I have a great idea which will increase performance, automation and efficiency
Manager - No, go back to your job because it's not my idea.
Imagine working so hard for quora
😊😊😊😊😊😊😊😊😊😊
Excellent all around, almost. If you say "sort of" one more time
Almost every sentence near the end
Do you have a degree.
Lol, 15:35? OG bobby Johnson? th-cam.com/video/WH79_OxpqK0/w-d-xo.html
HAHA. I just saw an article about how Google is enacting simplicity steps as a productivity method. 10 bucks says this is a part of their assigned reading, why it has more views than usual and is showing up in the algorithm now? Hey Google, just do better... You guys are probably experiencing a transition in business in which stagnation is the most prevalent threat. Please do not stagnate and keep innovating. you're previous ways of doing things may not work any more. get rid of redundancy. Also, your corporation is probably owned by a rich oligarch that wants to extract as much profit as possible. the simplicity steps most likely will not work.
Third
First
+Vincent van go second
I think it’s too verbose