Although they comprise a minority of IT jobs, dot-com and other technology companies still hire a significant portion of the tech workforce, and many people usually think of dot-com companies first when they think of IT jobs. Although the environments at such companies can differ from those of non-tech companies, the responsibilities and requirements remain much the same for either.

Sze Hsu programs for Yahoo.com. Despite the lone, geek programmer stereotype, Hsu has found that programming at a dot-com requires a lot more than a keyboard. "When I decided to go into programming, I thought I would simply be in front of a computer screen all day long banging out code," says Hsu. "Since then, I have worked for computer companies large and small. I now realize that this may be true only when you first start off, where all your day-to-day tasks are planned out for you. Once you are past that point, programming is actually only half the story. In a typical day, I usually don't get my hands dirty digging into the code until the end of the day. There are plenty of administrative, procedural, and even political tasks that must be done."

There are many stages to a regular programmer's day.

Production

According to Hsu, a typical day starts with group planning. This means keeping a keen ear open at meetings, and sounding in when technical advice would be useful. "First, there is working with product managers/producers. Usually, product managers do the market research, investigate usability, and come up with the best features for a software release. However, without an understanding of the technological architecture, it is often difficult for them to realize any limitations or innovations that may be possible. This is where development can lend a hand."

Hsu cites an example of interdepartmental cooperation. "At my old company, cityQuicker.com, we followed a paid-subscription business model. So a lot of thought went into the service registration system. The system had to be able to detect fraudulent registrants, but at the same time be user-friendly for valid registrants. Now, the product managers did not understand how email domains are managed. Because of this, as they designed the workflow for the registration process, they did not consider asking users for email addresses. Once the developers suggested feasible methods of determining if an email address was valid, many new possibilities became open."

"Personally, I find this the most rewarding/interesting part of the job, probably because it is an opportunity to help shape the end product, something the developer is not typically involved in."

Architecture

With planning come the limitations of budget, manpower, and a constant dose of reality. In system architecture planning, Hsu points out, "Usually, it boils down to three things: trade-offs, trade-offs, and more trade-offs."

"In 99% of the cases, there is no perfect solution, just like in the rest of life. There are many opposing considerations, like performance versus extensibility, a rich feature set versus scalability, and maintainability versus supporting multiple platforms. And given that one has to find the best coinciding middle ground on all these axes, this is probably the toughest part of the job. The basis for this decision is totally dependent on the task at hand. When creating a high traffic web site, you need to lean towards performance. When creating a banking application, you probably need to lean towards stability. Bottom line: there is no easy answer. Thus, traditionally, such architecting is done by more senior programmers."

Systems

After meetings and planning come the hardware and software work. Tech job responsibilities overlap as budgets shrink, and larger companies often require their applications to be built to fit specific systems. Thus, programmers must typically address server and hardware needs to be effective.

"Most companies have a designated system administration department," says Hsu. "In smaller companies, this responsibility falls on the shoulder of the developer. But, in either case, the developer must create applications with system considerations in mind."

"At the company Community Connect Inc. (CCI), we ran a dynamic web site, which received around one million page views per day. Now, although there are many sites that get much higher volumes of traffic, CCI was a small company with a small budget. So, the site all had to run off of one, medium-sized server that used an Oracle brand database. And, given that the budget was limited, we had no third party software like search engines or transaction servers. Because of this, the application had to be tweaked and tweaked again for database and server optimization."

The programming

"Finally, we come to what the original job description entailed: programming," says Hsu. "This is the part of the job where one puts on his/her headphones on and just bangs away at the keyboard. All the data structures, control loops, and system protocols from Computer Science 101 will finally come into practical use."

Although the education comes in handy, each new task brings new problems that college does not prepare one for. "There is no magic formula for how to be a good programmer. Like the architecting, there are always tradeoffs. And to find the proper, middle ground is just a matter of experience."

Communication still reigns as the most important skill, even in this most technical duty. "For most real world projects, there will be more than one developer involved," reminds Hsu. "So, another major component of the job is working with fellow developers. To ensure that the various components from different developers will interact properly, a lot of team work and communication must be involved."

"At Yahoo.com, one of the projects we did was to integrate two of Yahoo's larger divisions: HotJobs and MyYahoo. In order for the two teams to complete the integration successfully, each side had to first get a basic understanding of how the other side worked. Then, a detailed plan had to be worked out, listing the necessary tasks on both sides and how those efforts would couple each other in the end. All this communication and coordination had to be done before any actual development began."

"Overall, I would say programming is definitely a challenging job. There are all sorts of issues involved than just programming. So, although knowing a slew of programming languages like C/C++, JAVA, or Perl will help - and in many cases necessary - that is not what makes a programmer. There must be the collective of knowing the languages, recognizing system considerations, and being able to design application architectures, as well as understanding non-technical issues like production and teamwork."