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

Confessions of an Apprehensive Technical Director

Confessions of an Apprehensive Technical Director

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


April 29, 2014

More Decks by mattfordham

Other Decks in Programming


  1. 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
  2. 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
  3. Project templates • Routinely maintained and version-controlled. • Begin each

    project by updating the template. • Include descriptive README. 18
  4. 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
  5. Agile / backlog • Prioritized user story backlog. • Work

    on stories of highest value first. 21
  6. Agile / meetings • Daily stand-ups. What are you working

    on? What is blocking you? • Weekly retrospectives. What went well? What could be improved? 23
  7. Comment-driven development 24 • Write comments before writing code. •

    Leads to well-documented and more thoughtful code.
  8. 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! ! ! ! ! !
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. Continuous improvement • Quarterly goal setting and reviews • Weekly

    team presentations • Weekly project retrospectives • Professional development budget ! ! 38