Web Developer
by Kim Higgins
Part II: A Typical Day for a Web Developer
A typical morning starts with checking my email to see if any new issues have come up since the previous day. Occasionally a bug in an existing project is discovered. Sometimes there are changes to be incorporated into new projects. If the request is high priority, such as a bug in a Web application that has already been published, it will be the first issue I address. Problems the end-users experience are the first that have to be fixed. The most important rule of thumb in Web development is the less downtime a Web site sees, the better!
If it is the beginning of the work week, I will email a status report to my manager updating him on all the projects on which I am working. I'll notify him of any outstanding issues and tell him if my projects are still on track for their original completion dates.
By mid-morning, I might put the finishing touches on a project I've been working on for the last few weeks. I'll test it one last time to make sure everything looks like it is working according to the specs given to me by my Project Manager. If all is well, I'll let my Project Manager take a look at it, and with his/her ok, I'll send it off to Quality Assurance (QA), where they will test it thoroughly for bugs or malfunctions. Depending on the size of the application, it may be hours or days before I receive any feedback on what they have found.
By early afternoon, it's time to dig into the new highest-priority project and start chugging out some code. There may be a lot of planning before I start writing anything. By this time, I have already discussed with my manager what tools I should use for this project. Perhaps Java will do the trick, or maybe it is a combination of XML and Cold Fusion. If there is any back-end data related to this project, I need to coordinate with the Database Administrator.
Once I start writing the code, I might find out that the Web application should not allow users to register more than once. I might gather some feedback from other programmers on the best way to fix this problem and then continue with my coding.
By late afternoon, QA might have come back with the first round of bugs or issues they have found with an earlier project. I'll look over the list and prioritize which bugs should be fixed first and which are of less importance. Now it's time to debug my code and try to find out what is causing the problem. If the project was planned carefully and I documented my code well, this may only take a few minutes, but it can take hours. After all the bugs are addressed, I send the program back to QA for another round of testing.
By the end of the day, I've put together a prioritized to-do list of what I need to work on tomorrow. Finally, I'll check my email one more time before I leave to make sure there is nothing serious that needs to be addressed before I go home.