Something you probably grapple with on a regular basis is how much you have to deal with nontechnical people.

There are those who come to you because they are too lazy or challenged to figure it out on their own. But what about those who you have to work with like product managers, project managers, marketing teams and other businesspeople who have a direct tie to what you design, build and ultimately deliver?

Anecdotally, I know that I've leaned heavily on people who have technical and systems knowledge that I did not have, and this can very much make for awkward relations sometimes. People don't always want to be interrupted to give status updates, fix a nagging bug, make changes to plans or show examples of how the end result will work. Understandably, those who learn how to handle this without blowing a gasket or having things run up the management ladder will succeed.

When people have incentive (financial or otherwise) to roll out a product or service on deadline, nothing will get in the way of getting that accomplished--not even the technology team tasked with making it happen. Dependencies be damned. Money, revenue and reputations are on the line. Working together is essential, even if it's not always harmonious.

Vault.com, one of the many job boards out there, has some interesting content relating to what it's really like to work in a spectrum of jobs, some that are in IT. I've found a couple of examples that give a sliver of what it's like in technology jobs like programming and IT management.

The thread that seems to run through these articles is that working with others is essential--even in positions where you'd expect people to be left alone to focus on their talents and job descriptions.

There's one "Day in the Life" of a programmer who now works with Yahoo, but had worked at a number of smaller startups previously. The article works because it breaks down a lot of the complexity of what goes into building Websites--such as site architecture, systems adaptability, site performance and working with people who aren't as tech-savvy. From the article:

Sze Hsu programs for Yahoo.com... "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..."

"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."

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."

"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..."

The article goes on to point out that programming work eventually happens, and even then, it involves being able to communicate well with others. In this case, others means other developers. Hsu uses an example at Yahoo of having to integrate My Yahoo and HotJobs, something most programmers at large Web entities would understand to be potentially difficult when one company acquires another and a need exists to somehow make these things work together without rebuilding from scratch.

It's complicated, and one thing Hsu was keen to point out consistently is that teamwork is essential.