iQ Web Team

if you don’t understand the reason for someone’s decisions, distrust can creep in

First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets

always code like you’re working in a team, even when you’re not

Write comments like you’re talking to a rubber duck! Good comments take care of 99% of what you hand over and — more importantly —  take care of your documentation. Your code should be the documentation. Comments are also an excellent way to show off. Ever wanted to tell someone how awesome a bit of your code is but never found the chance? This is that chance! Explain how clever it is, and just wait for people to read it. Egos aside, though, comments do force you to write nicer code. I’ve found that writing extensive comments has made me a better developer. I write cleaner code, because writing comments reminds me that I’m intending for others to read the code

being an expert is more than about getting people to listen. If that is all you can manage, then they will see through this shallow desire and not give you the status that you believe you deserve

design that lessons learned four years ago do not apply today. But I’m not convinced that is the case. In my experience, although technology changes, people do not. The majority of unexpected issues that arise when developing a website relates either to human error or to some element of user experience

Too many of the people I worked with coasted through the years with no passion for their work. Without passion, they had no desire to learn new things or push boundaries.