Save 37% off PRO during our Black Friday Sale! »

Trophy Winning Teams

Trophy Winning Teams

"Players don't win you trophies, teams win trophies". A team works better when they work together, no matter whether the goal is winning the World Cup or creating amazing websites.

Any development team, whether large or small needs to ensure that it works together as a cohesive unit in order to produce the best possible output. This can mean ensuring there's consistency in the code being written. Ensuring everyone stays up-to-date with the fast-moving pace of the web industry. As well as the ability for any project to be worked on by one or more team members at a time and have the ability to be handed over if a developer takes time off.

In this talk I'll take a look at how as a development team we can work better together, taking a look at some examples from great sporting teams. Covering everything from coding style guides, team training techniques, and code reviews, all the way through to Dutch Total Football; I'll cover a breadth of areas your team can use to improve their teamwork skills and create better cohesion and a great team atmosphere.

Fc7368fd45560e1e7401bc80684f5867?s=128

Adam Onishi

May 28, 2015
Tweet

Transcript

  1. @onishiweb Trophy winning teams Adam Onishi Front-End London May 2015

  2. @onishiweb Hello! @onishiweb

  3. @onishiweb Hello!

  4. @onishiweb 20 developers Hello!

  5. @onishiweb Teams…

  6. @onishiweb – Jose Mourinho “Players don't win you trophies, teams

    win trophies.” Teams
  7. @onishiweb Sporting teams

  8. @onishiweb Planning Sports

  9. @onishiweb Sports @onishiweb

  10. @onishiweb Teamwork Sports

  11. @onishiweb Everyone is equal Sports

  12. @onishiweb Adaptability Sports

  13. @onishiweb Who cares? Sports

  14. @onishiweb Planning

  15. @onishiweb Baseline Planning

  16. @onishiweb Boilerplate Planning

  17. @onishiweb Planning https://github.com/wearearchitect/Frontend-Boilerplate

  18. @onishiweb assets/ |- scss/ | |- settings/ | |- tools/

    |- images/ |- javascript/ | |- src/ | |- vendor/ Planning
  19. @onishiweb Gulp! Planning

  20. @onishiweb Pattern library Planning

  21. @onishiweb @onishiweb Planning

  22. @onishiweb %clearfix { zoom:1; &:before, &:after { content: "\0020"; display:

    block; height: 0; overflow: hidden; } &:after { clear: both; } } Planning
  23. @onishiweb Planning https://github.com/madebymany/css-patterns

  24. @onishiweb Code Consistently

  25. @onishiweb – Mark Otto (@mdo) “Code should look as if

    it's been written by one person, no matter how many people have worked on it” Consistency
  26. @onishiweb Code style guides Consistency

  27. @onishiweb Code style guides Consistency

  28. @onishiweb http://codeguide.co/ Consistency

  29. @onishiweb http://sass-guidelin.es/ Consistency

  30. @onishiweb https://github.com/onishiweb/code-style Consistency

  31. @onishiweb – Mark Otto (@mdo) “Enforce these, or your own,

    agreed upon guidelines at all times. Small or large, call out what's incorrect.” Consistency
  32. @onishiweb @onishiweb Consistency

  33. @onishiweb @onishiweb Consistency

  34. @onishiweb The Rules Consistency https://github.com/wearearchitect/Frontend-Rules

  35. @onishiweb Consistency Where possible all of these rules should be

    followed to the letter. But, all rules are open to discussion and review. Obviously there are also times where a rule must be broken, but you should be able to explain why it was necessary and what benefit it gave you. Rule 1: Obey the rules
  36. @onishiweb Consistency Rule 4: It's all about the bike code.

    None of these rules are personal, there is no agenda in the rules; it's all about the code. The rules are here to help us write good code and work together as a team. It's about learning as well, front end development is continually evolving with new techniques and new tools becoming available all the time, the rules will keep evolving with these best practices and be updated over time.
  37. @onishiweb Consistency Rule 12: The correct number of JavaScript libraries

    to know is n+1 Most front end developers are familiar with JavaScript and jQuery, but there are now more frameworks than you can shake a stick at! Whether it's Angular, Meteor, Backbone, Ember, Coffeescript, or Node.js there's always something new to learn.
  38. @onishiweb @onishiweb Consistency

  39. @onishiweb Enforcing Consistency

  40. @onishiweb Linting Consistency

  41. @onishiweb Code reviews Consistency

  42. @onishiweb Code reviews Consistency

  43. @onishiweb Pull Requests Consistency

  44. @onishiweb Consistency

  45. @onishiweb Consistency Rule 2: Lead by example You should make

    yourself familiar with the rules inside and out and ensure your code always follows the rules. Code reviews will be employed and pull requests will be declined if you're found to be breaking the rules.
  46. @onishiweb Consistency

  47. @onishiweb Nothing Personal Consistency

  48. @onishiweb Teamwork

  49. @onishiweb Smaller teams Teamwork

  50. @onishiweb Mentorship Teamwork

  51. @onishiweb Responsibility Teamwork

  52. @onishiweb Learning Teamwork

  53. @onishiweb Sharing knowledge Teamwork

  54. @onishiweb Developer déjeuner Teamwork

  55. @onishiweb Developer déjeuner Teamwork

  56. @onishiweb Group code reviews Teamwork

  57. @onishiweb Group code reviews Teamwork

  58. @onishiweb @onishiweb Teamwork

  59. @onishiweb Conferences /Meet ups Teamwork

  60. @onishiweb Own goal…

  61. @onishiweb ”The Rules” Fail!

  62. @onishiweb C0de reviews Fail!

  63. @onishiweb C0de reviews Fail!

  64. @onishiweb Code review etiquette Fail!

  65. @onishiweb Extra time!

  66. @onishiweb Great dev teams Summary

  67. @onishiweb • Planning Summary

  68. @onishiweb • Planning • Teamwork Summary

  69. @onishiweb • Planning • Teamwork • Equality Summary

  70. @onishiweb • Planning • Teamwork • Equality • Adaptability Summary

  71. @onishiweb @onishiweb Summary

  72. @onishiweb Thanks Adam Onishi Front-End London May 2015