At Code School, we work hard to constantly improve the front-end development team organization. I thought I’d spend some time talking about the organization as it stands right now.
Members
Currently, there are four total members of the front-end team:
- Drew Barontini (me)
- Dan Denney
- Jordan Wade
- John D. Jameson
Responsibilities
Each member is responsible for:
- Implementing full and partial designs
- Working in and maintaining codebases across all properties
- HTML/CSS/JavaScript authoring
- Making design decisions and collaborating with designers
- Making implementation decisions and collaborating with developers
- Writing documentation
- Contributing to open-source projects, such as MVCSS, Spellbook, etc.
- Writing blog posts on the Code School blog
- Recording podcasts for Front-end Five
A Lead on Every Project
For each project, there is a lead front-end developer. This person is responsible for:
- Making architectural and design decisions
- Working with designers and developers
- Managing the project
- Providing estimates, timelines, and status updates
- Organizing the Trello board and GitHub issues
- Providing project managers with project status
- Sitting in weekly check-in meetings
- Leading other front-end developers that help on the project
- Assigning tasks
- Reviewing and merging in Pull Requests (code reviews)
Although I lead the team, it’s overkill for me to micromanage on the project level. I fully trust each member of the team to run their respective project. If I jump into a project run by another front-end developer, they will give me the tasks to work on. This helps to promote the interoperability of the team.
Internal Tooling Rotation
Ideally, there will always be one member of the team on the Internal Tooling Rotation, which consists of building some internal tool, or improving an open-source project, while learning a new technology. For example, a team member could build an application that helps improve our efficiency in some way, and then choose a new technology, or something they’re less comfortable with, to build the application. The specifications generally are:
- Initial discovery meeting with relevant people/groups
- 2-4 week sprint to develop MVP
A few example applications we have built, or are building, are:
- Voltron: An application for posting ideas that others in the company can pledge to.
- Aerial: A Basecamp-powered calendar that shows specified calendars and events by priority.
- Directory: An internal team directory for adding members, teams, and keeping individual members’ information up to date.
- Codebase Evaluations: A visualization/charting application for codebase metrics that can be shown over time (more on this later).
Refactor & Bug Smash Rotation
In addition to the Internal Tooling Rotation, we have the Refactor & Bug Smash Rotation, which is for dedicated time to fix bugs and refactor, as you might expect. Additionally, it’s useful for the times when a project is in “blocker” mode; you have some time, but need to be able to jump back when things are freed up again.
Pairing
We try to pair at least once a week. We find something that’s good to pair on, grab another front-ender, and go to a conference room to pair for a few hours (or an entire day).
Pairing is a popular part of the development workflow, and I find it useful for sharing ideas to build something better and faster than you might on your own. Frequently, one of us will have come across the problem before, so it’s faster, and more beneficial, to pair in order to solve the problem.
Jank Busting & QA
“Jank Busting” is what we call those polish steps close to the launch of a project or feature. When the project is ready, we let the other front-end developers (generally those who haven’t worked on the project) jump in and just start hacking away, posting issues, helping fix things, and just making sure that the polish is there before launch. This part of the process is an excellent way to catch all of the small things that can be missed before launch.
Code Reviews
Whenever changes are made, it’s important that at least one other front-end developer takes a look at the Pull Request and gives the proverbial “thumbs up.” It’s always good to have a second set of eyes on something to catch any of those little things that get skipped. Furthermore, it’s important for each member of the team to be comfortable and up to date with the latest changes to any codebase, especially since these are living codebases that we continually iterate on.
Front-end Problem Solving
Every other Tuesday, the entire front-end team meets to talk about front-end problems we’re having. We bring these problems to the meeting and we collectively figure out. We also use this time to put conventions to any things that we’ve come across on projects, if it doesn’t already exist. These changes are then reflected in MVCSS, Spellbook, etc.
Codebase Evaluations
Once a quarter, we meet to evaluate each of the codebases. In this meeting, we go through the code and determine what refactoring steps are necessary, what needs to be cleaned up, and add documentation so someone can tackle these issues during a Refactoring & Bug Smash Rotation.
The Codebase Evaluations we’re building (as mentioned earlier) will allow us to document and track these metrics as we improve the codebases over time.
Project Journals
For each project, we create a document for keeping notes, thoughts, problems, and solutions throughout the build of a project. It’s a running list of things that can be used later to write a blog post, or to do a retrospective since everything was documented along the way. This is a new component that we’ve added, but something we’re excited about.
That’s All, Folks
That’s a quick look at the organization of the front-end team at Code School. We’re always working to improve our internal efficiencies and structure to allow for happy development that gives way to constant improvement of the team, as well as each individual member.