Why Our Solutions Team Created "The Dev Guide"
When you have a development team working on multiple projects, across multiple interfaces, at the same time, it becomes necessary to have a standard way of writing code. Really, to speak the same language.
We share resources and we juggle dependencies. Sometimes, team members hop in and out of work, trading between projects based on core development competencies. Writing and reading code the same way is a must.
The same way that style guides are important to designing within brand guidelines, and for the reason editorial mission statements direct the voice of a publication, we created The Dev Guide.
No longer is there need for a translator when traveling between projects. We can be fluent, cohesive, and efficient. We can be a team.
What was our inspiration?
That, plus the wonderfully comprehensive
CSS tips, tricks, and techniques put together by Chris Coyier, and a bit of our own team insights brought this book to completion. For the most part, we didn't reinvent the wheel. But we designated certain styles that we knew worked and liked to use.
How do we use it?
Weekly peer code reviews. We look at code written on projects from the past week and match it to The Dev Guide to ensure that our style is aligning with our guidelines. And if it's not? We look at why.
Maybe there are new ways of thinking that we're uncovering which merit readdressing in our handbook. Sometimes new elements need to be added, and sometimes they need to be changed. That's all part of the process.