24
5 lessons every Web developer must learn
Up-and-coming Web developers typically ask the same questions. What programming languages are important to know? What is a good entry level salary? Should I expect paid training from my employer? How do I estimate a new project? Although these are important questions, there is often a lack of interest in lessons learned by other developers. Generally speaking, it is because opinions abound with regards to how those lessons should be learned. Here are five such opinions.
You are not always the smartest person in the room
Before the dot-com bubble burst I worked at a job where one of my co-workers made sweeping claims about voice recognition. In a short time we would all be speaking to our computers and PDAs, surfing the Internet with glee, and without a keyboard. I questioned the validity of his claims, and was met with staunch resistance. How could he possibly be wrong? He had been to a conference! Several similar predictions were made in the months to follow. None came true.
If you find yourself in a similar situation, recognize that you could be wrong, and that you are not always the smartest person in the room. Being willing to consider the alternative will demonstrate more intelligence than thinking you know everything about everything.
Experience does count for something
Writers hate to hear other writers who claim this to be true. So do developers. However, I find that those who have accomplished a task on a previous project, will be more productive when completing the same (or a similar task) on a future project. When stated clearly, it does seem obvious, but developers still argue that our intellect should be enough to guide us to the correct solution. It might guide us there, but the path is treacherous.
The fact is, experience does count for something. Instead of letting jealousy reign supreme, trust in the experience of others and make it your own. Ask questions, get feedback, and admit to your peers when you make mistakes.
There is no silver bullet
Zealots. Every language, framework and OS has them. There is nothing wrong with being passionate, but the belief that any one of these technologies, frameworks, design patterns or languages can solve all your problems on every project is misguided. I used to scoff at job descriptions that required Web developers to have some experience in almost every major language of the day. Now I know why at least some familiarity with each of these languages is important; because there is no silver bullet.
Serious developers may become advocates, but they never become fundamentalist zealots. Unless you work for a software as services company, and it is your job to evangelize the product, be open-minded and willing to change.
The new cool is not always cool
Being pegged as a maintenance resource is a drag. Being known as the developer who always has to have the latest-and-greatest is worse. Working with new technologies and applications is exciting, but on occasion the new cool is not always so cool. Suggesting a tried-and-true approach for a project can lead to smaller budgets, shorter timelines and a happy client. The vast majority of users who use the Web site or Web application that you build will also thank you for sticking to established norms.
Instead, be vigilant about researching new trends in Web development. When the opportunity arises to present an alternative, or just start fresh, then you can push for change. If available, be ready to present case studies that detail how the new technology helped a similar project.
Not every battle is worth fighting
There are times, deep down in my gut when I know I am right. Regardless of the discipline or the nature of the argument, I just know it. It is likely that as a Web developer, with so many disciplines and personalities thrown into the mix, that you have experienced the same feeling. I used to fight each of these battles tooth and nail. I have learned that presenting a viewpoint that is descriptive and untainted by emotions is all that is necessary.
Even though your opinion might not be taken into account, you need to learn to allow others to make mistakes, and let management place discipline leads in charge. Your colleagues will remember your concerns, and you will receive recognition (in the least) for being open to other ideas.
(via reindel.com)
