The Twitter Tag Project
What is an Internet Service Provider?
Great talk. Thanks, Edmond. Thanks, Google.
This talk makes me think how these principles can be applicable for non-software engineers.
Brilliant talk – thank you.
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.
it does not explain why the rate DROPPED 25%
This is one of the google talks that I love the most. Awesome talk!
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 ?
1. Optimise for learning2. Invest in iteration speed3. Validate your ideas aggressively and iteratively4. Minimise operational burden5. Building a great engineering culture
Edmond is so passionate & so intelligent ! Wonderful talk !
Fantastic Talk. Very well put! Taking a lot of good points to work from here.
Phenomenal book. Has changed my worklife. I also recommend Deep Work by Cal Newport.
Google has the true continuous deployment, with fast tests and minutes to production.
Recommend skipping to 12:00 to get to the actual strategies
My notes (stuff that resonates with me, with the lens of someone in a very early stage startup)
1. Optimize for learning=> Own your story=> Make a habit out of improving every single day
2. Invest in iteration speed=> Write tools
3. Validate your ideas aggressively and iteratively=> experiment-driven product design is a powerful tool=> incrementally validating your assumptions is high leverage=> hypothesis testing=> do the scariest part first (the one with the most unknowns / risk)
4. Minimise operational burden=> do the simple thing first=> be stringent about cutting sources of complexity (go watch “simple made easy” by Rich Hickey if you have not watched it at least 3 times)=> beware of the hidden costs of complexitycode, system, product, organizational complexity=> ask: what’s the simplest solution to this problem
5. build a great engineering culture=> engineering enjoy working in environments that focus on high-leverage activities
Stuff I think is important and not in the talk:=> Learn to move on rapidly when something is good enough. Done is way better than perfect=> YAGNI (you ain’t gonna need it): be very mindful of solving problems you might have (eg: premature optimisation), but don’t have now. It’s usually better to tackle the problems you do have now, the king where you are sure they are real problems and they need to be solved.=> Hardship / Strong team (common vision / team dynamics / compassion). Is anyone comfortable talking freely about hard issues (technical or personal) ?=> Enjoying the process (of coding, learning, getting better). If you don't like to some extend what you do, you won't persist when it gets tough and invest yourself less in it.=> Good alignment of incentives between founders / engineers / users=> Successful startup: Hardship + effective team
I love Talks at GOogle, thanks fot making this public
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
Thank you Edmond for adding emotional intelligence!
Many engineers are detached .
Your also very easy to look at, meaning your HOT !
Your email address will not be published. Required fields are marked *
Save my name, email, and website in this browser for the next time I comment.