21 thoughts on “Edmond Lau: “The Effective Engineer” | Talks at Google

  1. 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.

  2. 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 ?

  3. 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

  4. 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 complexity
    code, 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

  5. 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

  6. Thank you Edmond for adding emotional intelligence!

    Many engineers are detached .

    Your also very easy to look at, meaning your HOT !

Leave a Reply

Your email address will not be published. Required fields are marked *