Confessions of an Apprehensive Technical Director

Presented at Peers 2014 in Washington DC on April 24th, 2014.

Transcript

1. Confessions OF AN APPREHENSIVE TECHNICAL DIRECTOR
2. About me
3. 3 London
4. 4 New Jersey
5. 5 Rock ’n’ Roll
6. 6 Nashville
7. 7 More Rock ’N’ Roll
8. 8 Seattle, WA
9. 9 Youngsters
10. 10 Professor Fordham
11. 11 MATT FORDHAM PARTNER & TECHNICAL DIRECTOR WWW.WINTR.US / @MATTFORDHAM
13. The challenges of a team 13 • Quality assurance • Code consistency and duplication • Collective code/project ownership • New hire ramp-up time • Ongoing project maintenance • Professional development • Multiple simultaneous projects • Who’s doing what? • etc, etc Overall team efficiency and happiness
14. ✴ Documentation and resources ✴ Workflow ✴ System configuration ✴ Project configuration ✴ People 14
15. Documentation and Resources
16. Master dev process document Write everything down. ! 16
17. Code styleguide • Routinely maintained and version-controlled. • Include all necessary languages. • Include comments and todos. • Create a shared snippet library for your text editor(s). 17
18. Project templates • Routinely maintained and version-controlled. • Begin each project by updating the template. • Include descriptive README. 18
19. Front-end scaffold • For CSS and JS. • Routinely maintained and version-controlled. • For use in projects of all types. • Can be included in Project Templates as sub-module. 19
20. Workflow
21. Agile / backlog • Prioritized user story backlog. • Work on stories of highest value first. 21
22. Agile / backlog • Clearly defined acceptance criteria. • Done is done. Tested. Deployed. 22
23. Agile / meetings • Daily stand-ups. What are you working on? What is blocking you? • Weekly retrospectives. What went well? What could be improved? 23
24. Comment-driven development 24 • Write comments before writing code. • Leads to well-documented and more thoughtful code.
25. Test-driven development 25 • Write tests before writing code. • Leads to maintainable, well- documented and more thoughtful code. • For front-end and back-end. • Consider starting with integration tests for end-to-end testing. • It’s fun… really! ! ! ! ! !
26. Code reviews • Peer and/or director reviews. • User story not done until reviewed • Encourages collaboration. • Ensures code style consistency. • Provides opportunity for professional development. • Promotes greater test and comment coverage. • Promotes shared ownership of code. 26
27. System Configuration
28. Dotfiles • Routinely maintained and version- controlled. • Repo of bash scripts cloned onto new machines to aid in quick setup. ! • Automatically install applications, languages, frameworks, etc (Homebrew, Ruby, Node, PHP, etc). • Setup company-specific shell aliases (repos, IP addresses), create and upload SSH keys, cronjobs, etc. • Install code snippets and text editor configs. ! 28
29. Project Setup
30. Project README • Contains general instructions on getting the project up and running. • Contains list of all dependencies. • Contains list of original developers. • Lives in the project repo • Usually written in Markdown for Github/ Beanstalk readability. ! 30
31. CSS Styleguide • Built before any other pages. • Basic HTML elements are styled first, followed by any repeatable modular blocks. • Ensures CSS classes are premeditated • Keeps duplication to a minimum. • Allows multiple developers to build out pages. 31
32. Project install script • Usually a Shell or Ruby script. • Check system dependencies (Ruby version, Node version, ImageMagick, etc) • Install project dependencies (via Ruby Bundler, NPM, Bower, etc) • Set file permissions • Run migrations or import latest database dump • Create virtual host ! 32
33. Front-end compilation • SASS and Coffeescript (and similar), can greatly improve a team’s workflow. • Cleaner syntax and more modular code. • When working with a team avoid desktop tools, such as CodeKit. • Compile from the command-line. Grunt, Gulp, Guard, etc. • Compilation can also include file concatenation, minification, and c0de-linting. ! ! ! 33
34. Dependency management • All project dependencies should be managed, if possible. • Bundler for managing Ruby Gems • NPM for managing Node Packages • Bower for managing front-end libraries • Using these tools, all dependencies can be install with a single command. 34
35. Automated deployment • Under normal circumstances, all team members have access to deploy to staging, and probably production. • Deploying should should be an easy task, as should be rolling back to a previous version. • Option 1: Deploy via Git push • Option 2: Deploy via Capistrano • Additional automated tasks: • Upload/download images to/from server • Import database from production • Setup automated backups 35
36. People
37. Who to hire? • Developers who love to collaborate, love to code, and love doing “whatever” to bring good ideas to life. • We prefer people who see themselves as “web developers” or “interactive developers”. Not… - “front-end developers” - “back-end developers” - “Rails (or whatever) developers” - etc, etc 37
38. Continuous improvement • Quarterly goal setting and reviews • Weekly team presentations • Weekly project retrospectives • Professional development budget ! ! 38
39. Communication • Flexible and rotating seating • Face-to-face, away from desks • HipChat, Campfire, etc ! 39
40. In Conclusion
41. Thank you! @MATTFORDHAM / WWW.WINTR.US