Team Communication Through Code

Transcript

1. with Rachel Ober Team Communication Through Code
3. 3 It’s not as simple as just TALKING to one another…
4. 4 • Verbally • Facial expressions & body cues • Written language • Experiential learning • …and more How do people communicate with each other every day?
5. 5 Let’s chat about COMMUNICATION TOOLS
6. Rachel Ober Sr. Front End Developer • Started August 2012 • Lives in Brooklyn • Plays Pokémon • Owns a Corgi 6
7. 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
9. Start-up growing pains
11. How does your garden grow?
16. The hypothesis
17. 17 We can learn how to COMMUNICATE in each other’s language
22. 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?
26. Fences and waterfalls
27. 27 Before Content UX/IA Design Back End Ship QA Front End
31. 31 • Pair programing • Design in browser • Mob programming Solution
33. 33 • Front End developers pair with a Designer 2x/week • Designer communicates designs • Front Ender mocks up possibilities with Designer Execution
34. 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
35. 35 Unexpected side-effects
36. 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
37. 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
38. 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
39. Putting things in stone
40. 40 Take the time to write out your STYLE GUIDES
41. 41 • How files should be set up • TABS or SPACES • Best practices • Variables naming • …and more Code styles guides
42. 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?
43. 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
45. 45 “Remember to use color variables…” Side effects “Alphabetical order please!” “We have a mixin for that…” “Can you name this better?”
47. 47 TECHNICAL DEBT
48. Naming things
49. 49 Naming things is HARD
50. 50 Greige
53. CSSWizardry.com
54. 54 “That’s ugly looking…”
56. 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
57. The pattern guide
58. 58 Visual way to show basic BUILDING BLOCKS of the site
59. 59 A pattern guide is a CONTRACT between members of a team
61. 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…
62. 62 Sample
63. Ownership
65. 65 Find project CHAMPIONS to lead an effort
67. 67 Everyone should share KNOWLEDGE
68. Peer training
70. 70 Pick people who can LEARN
71. 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
72. 72 EXPOSE them to every part of the company
73. 73 Pair people with MENTORS
74. 74 What you’re asking me to do is change company culture
75. 75 • Pair with someone • Mentor a new employee who is within your discipline • Offer small tweaks to your development cycle • Get Excited!!!! Small changes
77. Rachel Ober rachel@paperlesspost.com @rachelober Thank you