Confessions of an Apprehensive Technical Director

Confessions of an Apprehensive Technical Director

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

Cd9764f01f1237c5843b36162104056a?s=128

mattfordham

April 29, 2014
Tweet

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

  12. None
  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