For the 1st part of the series we are going to look at code, but we are not going to talk about perfect html/css semantics, many others have done that, and it is probably a series in itself. The goal with this article is to provide a few simple tips that will help when working in a team environment, as well as provide some solid resources for further learning.
For many of us single line css, our own routines, choice of naming conventions and personal approach to writing and organizing code is a way of life, and we are very comfortable in it. When working as a part of a development team a lot of these comfort-zones can be challenged, but the ability to be flexible not only saves frustration, but also says a lot to those we work for about our ability to be a productive part of a team, which goes along way in the work place. Here are some things that I have learned, tried, and found to be very helpful. I will provide reference links so you can do more research if so inclined.
1) Link / Import your stylesheets, and scripts.
This may seem like simple beginner css/html, but we must remember that everyone on our team my not be well versed in our areas of expertise. The cleaner and more organized our html (and css) files are the easier it is for others to pick them up navigate through the code and execute their project responsibilities.
One of the ways to do this is to keep all styles out of the html in an external style sheet that you link or import to the html file. The same goes for scripts wether we are using jquery, mootools, or some other scripting we should do our best to keep it out of the main html document (there are exceptions… google scripts, flash, and browser detection to name a few).
The main idea is to keep our code very clean, readable, and easy for others to use. When we compartmentalize our different code elements it makes it easier for others to know what to expect, where to find it, and keeps a solid framework for team development from initial development to revisions. For more on this check out Jina bolton’s presentations on Sexy Stylesheets there are some great insights.
2) The Name Game – Responsible Convention Naming
When creating our html and css files it can be easy (for times sake) to cut some corners and name our div id’s and classes very general terms. Initially I can understand this thought process, but I think we do out team members a disservice by taking this simple approach.
If someone were to pick up our work and need to edit it would our naming conventions help them get to the section they need to edit quickly, or would they have to search through our files filtering through general terms to try to find it?
As you can see this isn’t very efficient, I am sure that many of you are thinking “that sounds great in principal, but it just isn’t practical.” I agree there are times and environments that don’t lend to this idea, but as much as we can we should make our best effort to help our team by clearly defining “id’s” and “classes”, so that when someone else picks up one of our files to edit, they can easily find the section where the edits need to take place.
Using terms like main, left, right may seem easy and even familiar to us, but can lead to frustration when digging though files looking for content to edit/update. We should try to give our id’s and classes names that describe their purpose and placement on the page.
Andy Clarke put it well when he said.
“ That is why I think that establishing a set of naming conventions makes sense, not because I’m some kind of Maoist revolutionary who thinks that we should all wear the same grey boiler suits, but because it can make life easier for us and our end-users. “
Our team members and end-users should be the driving force behind setting up good practices. I encourage you if you haven’t to check out his site, and especially his writings I have found them very informative, and helpful.
Again for those of us who use css/html on a more advanced scale some of these concepts may seem simple, but we must remember that the focus of this series is to work towards bettering our development team.
3) Use Comments
If we take into consideration the above ideas and build upon them further by implementing a comment system we all but serve up great mark up on a silver platter for our dev teammates.
Working with Mike A (@miacevedo) we implemented commenting for easy browsing through code, as well as version tracking to help keep track of when revisions happened and who executed them. This allows us to both work on the same style sheet, or html pretty seamlessly, and will without a doubt increase efficiency of our front end development efforts.
This is something that I also picked up from Jina Bolton’s “Creating Sexy Stylesheets” presentation.
As you can see a them the idea is to communicate well by the code we write. At times this will cause us to have to take some extra steps, and go beyond what is asked of us, but in the end it will lend to a better end result, not to mention earn the respect of our teammates, which will go a long way. The only way we can see improvement in our development team is if we start with our contribution.
Wrapping Up
These are just a few simple tips that I have picked up along the way. A lot of the concepts and inspiration comes from talks that I have heard and blogs that I have read. There is a wealth of knowledge out there just waiting to be soaked up.
If you have any input, or tips that you have used, please feel free to share them.
1) Building a Successful Dev Team
2) Coding In a Team Environment
3) Building Development Team Communication
