Here at RIT they put a big emphasis through all of our coursework on working in teams and being able to cooperate with others. Now I perfectly understand this mentality. It’s great when you can find people who compliments your skill-set and then being able to produce a better product or project together.

With that said, I HATE WORKING IN GROUPS. I have had three major group projects so far and I always seem to get group members who either have misplaced their brain entirely, or just haven’t read the manual yet on how to use it.

The worst is having group members who don’t yet understand or appreciate the advantage of planning, especially for teamwork. They want to forgo planning and design and just code. So when they jump into the coding they get lost and are unsure of what to do. So they just get it to work in a hodged-podged format instead of properly.

The second most aggravating part of working with others is working with people who have no sense of style standards. Despite declaring a standard for the team right from the bat I’d get code contributions from team members that is not compliant to the standard, let alone commented and readable for other people.

The one thing that I wish my professors put more emphasis on, instead of being nice all the time, is style and readability in code work. Too many times I’ve seen professors who will be like “Well, it works.” and give the credit for the work instead of fixing the issue.

The world would be better if everyone coded the same way and with the same style. Oh what a world that would be.

With the start of 2006 I’ve taken on a lot more design work to try and step up my status as a freelance designer. It was a risky decision taking on so many projects at the same time simply because if I don’t meet deadlines it will have a very negative effect. But I am currently getting through it all. How am I doing it?

My hidden secret that I’ve just pulled out of retirement is my handy iPod. The song lists are a little out of date and I no longer have iTunes installed to manage some playlists, but it has been a nice change of pace to aid in the design process.

I don’t know what it is, but sitting down to my desk and throwing my headphones on I just get lost in the time and in the computer screen. Last night I had a streak of an hour where I came up with 11 concept designs that I spent today fleshing out.

Needless to say that I think I’m going to keep up this practice of using my iPod and drowning out the world around me with music, oh sweet music. :) Now some of you, probably none but I still like to boost my ego, might be wondering what exactly it is that I listen to. When it boils down to it, the music doesn’t really matter and I just need something in the background. But I prefer listening to either alternative, rock, or classic rock. Occasionally the techno or country gets brought out if I’m looking for a certain style. But as long as it’s not rap and classical music it’ll be allowed onto my iPod.

What do some of you other designers and developers use for music while you work?

I’ve gotten a couple of emails asking what’s the best way to get started making a site 100% compatible across multiple browsers. So I’ve gathered up a listing of some of the basic steps to follow in order to make sure your site can be 100% compatible.

The first phase when you’ve got your design completed and are moving to the XHTML / CSS coding of the layout is to start in a CSS compatible browser. For example, I start using Mozilla Firefox when I code my XHTML/CSS. I’ll get everything in order using Firefox.

Once you have everything in order in a CSS compatible browser that is when you move over to a less compatible browser. When you switch to other browsers you must obviously make small tweaks in the original browser in order to make them deal the same. The key to this phase is to avoid “hacks” at all costs. Utilize standard compliant code in order to make sure that as many browsers are understanding the CSS as possible. If this is impossible then that is when you move to browser specific stylesheets. Standard specific stylesheets will allow you to incorporate specific settings per the browser that is being used to view the site’s layout.

Once you’ve handled the most recent generation of browsers that is when you worry about going back to older versions of already compatible browsers. Only after you’ve got the most recent do you ever step back into their old and out-dated versions, otherwise you will run into issues with legacy code.

Now that you’ve got an idea of the process to use how do you check all the different browsers that are available across the multiple platforms. Well to answer that question, there are few different answers. You could …
Install the browsers on your system and test yourself.
Invite friends and colleagues for a closed beta test with a variety of browsers.
Utilize a service to simulate multiple browser environments to see how it would look.
Have a public beta where you just release the site and hope for input from visitors.

Any of these options is feasible, and used quite often, so it’s just a matter of what you feel comfortable doing to make sure that your site is fully supported across the browsers.

Good luck in your quest for compatibility.

Code readability is key when working on software development. It makes it significantly easier for other developers, or even yourself, to look through code and find what you’re after or be able to navigate it without seeing it in action.

Even though this is a standard towards software programming it still applies to web programming. Writing readable code is an essential skill when working with a team of developers. If you adhere to a single style it’ll be much easier to develop faster and collaborate on code.

I’ve gathered a few techniques and tips that I believe help write readable code. Whether you are a new developer or an old one everyone should be focusing on readability and everyone has something to learn in the field.

Structuring Your Code
The basic structure of your code does come down to a style standard that you decide to follow. But my main advice to someone looking to have readable structure would be to have nesting and order that makes sense.

For example which makes more sense?
[div id=“header”][/div]
[div id=“navigation”][/div]
[div id=“content”][/div]
[div id=“footer”][/div]
OR
[div id=“content”][/div]
[div id=“footer”][/div]
[div id=“header”][/div]
[div id=“navigation”][/div]

I am a firm believer in having everything fall into a linear path as you write your code. Work top down, don’t have yourself running all over the place.

Structuring Your Code Part II – Indenting
This is something that can fall into personal preference but the big thing that must be emphasized is that it MUST exist. Too many times will I look at code that has been generated by other people and none of the organization of the indenting makes sense. If something contains another element, that other element should be one indentation past the containing element.

Meaningful Names
The next key step is having names that make sense for what they are doing. If the name makes sense to you, but no one else than it is no good. It has to be meaningful to everyone, at least to developers.

For example which makes more sense? #header, #navigation, #content, #footer
OR #bigPart, #buttons, #text, #btmStuff

The top portion is obviously easier to understand what each components purpose is. This also segways into our next readability step.

Name Styling
There are two major name styles to follow. Each have their upsides and each have their legacy in software programming. If you utilize a name with multiple words in it for example nav and footer there are two ways to name the component. Either nav_footer or navFooter. Now I’m not going to try and push one style or the other on anyone, but what you must follow is a consistent style. If you choose the underscore method it should appear throughout the code. Or if you choose to uppercase the first letter than that must appear throughout. If you change between styles throughout your code it’s hard to follow.