The Most Important Project In Anyone's Career

The most important project in anyone's career is not their biggest project, not their hardest project, and not the one that earns them a big bonus. It's their first project in the workplace.

I recently had an interesting conversation with a colleague about computer science education; he works in industry and teaches at a local university. One of the most common IT problems I see is poor software engineering -- software professionals can write, test, debug, and integrate code, but they usually perform poorly when asked to use basic methods (SASD, UML, etc.) to analyze requirements and design software. So, I asked my collegue why computer science students weren't learning software engineering.

My colleague told me it's not a lack of education, it's that computer science students are skeptical about everything they learn in college. What matters is what they experience on their first project out of college. If the project uses strict UML with peer reviews or code-like-hell all nighters, that's how they think all professionals do it.

A few weeks later, I spoke with another colleague, one with 40 years experience with technical projects. His experience with secretaries extended this "first project" theory. He had seen several secretaries break into the workplace on demanding projects. The workers that replaced them picked up on the intensity and carried that with them through successful careers. This colleague also saw several secretaries that were "broken in" on quiet projects. He thought those projects would be beneficial because the secretaries would have time to learn properly. That didn't happen. Those secretaries had difficulty developing an intensity at work.

There is something about a person's first project in the workplace. Those projects burn themselves into our minds. And why not? First experiences of any kind stay with us. Our first day in school, first paying job, first date, and so on.

Far-sighted IT managers should understand and employ this. We must concentrate on each new employee's first project. Should we throw a new employee into a cleanup-a-mess software maintenance project, a code-like-hell-to-catch-up project, or a complete development led by our best, most disciplined software engineer?

Sometimes we don't have a choice. We assign the people we have to the projects we have. But sometimes we do have a choice. We can use these opportunities to teach a new employee when they are most apt to learn. It may mean sacrificing some resources on a hectic, catch-up project. The result, however, is an employee who believes that all the best practices are the way to do it in the real world.

Dwayne Phillips works as a software and systems engineer for the US government. He recently wrote "The Software Project Manager's Handbook, Principles that Work at Work," published by the IEEE Computer Society.