Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Team Communication Through Code

Rachel Ober
September 13, 2014

Team Communication Through Code

Rachel Ober

September 13, 2014
Tweet

More Decks by Rachel Ober

Other Decks in Programming

Transcript

  1. 4 • Verbally • Facial expressions & body cues •

    Written language • Experiential learning • …and more How do people communicate with each other every day?
  2. Rachel Ober Sr. Front End Developer • Started August 2012

    • Lives in Brooklyn • Plays Pokémon • Owns a Corgi 6
  3. 7 • A case study in how a small start-up

    transitions through growing stages • Techniques for dealing with interdisciplinary teams • New ways to think about collaborating with your teammates • Documenting your knowledge in different, but easily distributed formats Key take-aways
  4. 13

  5. 14

  6. 15

  7. 20

  8. 22 • Solve problems • Work independently • Have idea

    they want to work on • Make money • Creative outlet • etc. Why do (I think) people get into development?
  9. 29

  10. 33 • Front End developers pair with a Designer 2x/week

    • Designer communicates designs • Front Ender mocks up possibilities with Designer Execution
  11. 34 • Designers have deeper insight into development • Developers

    understand the Designer’s intention • Can quickly determine if something is going to “work” or not Effects
  12. 36 • It doesn’t always make sense to pair all

    the time • Dedicated Designer and Front Ender on each feature team who collaborate • Grab the right people and work in a conference room How it’s changed
  13. 37 • Before meeting, pick the topic you are going

    to explore • Sometimes a session can be exploratory, sometimes set an expectation of what you want to accomplish • Set time limit • Come prepared • This can be applied to any type of pairing session (Developer/ Developer, Designer/Developer, Designer/Designer) Tips & tricks
  14. 38 • Take breaks • Discuss the meaning behind the

    design so that the developer understands • Discuss technical limitations to a possible design • Show how things change in the browser in real-time • Grab a conference room • Mix disciplines! (UX/Design/Developer) Tips & tricks
  15. 41 • How files should be set up • TABS

    or SPACES • Best practices • Variables naming • …and more Code styles guides
  16. 42 • Code review can concentrate on more architecture changes

    • A contract that developers make • Write in a way that everyone should be able to understand Why a coding style guide?
  17. 43 • Take a look at other companies’ coding style

    guides • Work with your team members to determine what your own best practices are • Write it down in your company’s intranet or in a Gist file on GitHub • What you do code reviews point to the style guide first if the developer should take care of those low hanging fruit first Execution
  18. 45 “Remember to use color variables…” Side effects “Alphabetical order

    please!” “We have a mixin for that…” “Can you name this better?”
  19. 46

  20. 56 • Holistic design • Individual teams but ownership of

    key features • Come up with a system that works for your team • Communicate this system to other teams so they can use it too! Solution
  21. 61 • Accessible to anyone in the company • Made

    up of visual, usable components • Neatly organized • Includes code and documentation on how to use it • Includes Designer notes and considerations • An example of what appears on the site A good pattern guide is…
  22. 71 • Know what they don’t know • Wants to

    make themselves better • Listen to what the job entails and gets excited • Want to learn from others Interesting interviewees
  23. 75 • Pair with someone • Mentor a new employee

    who is within your discipline • Offer small tweaks to your development cycle • Get Excited!!!! Small changes