The Community for Technology Leaders
RSS Icon
Subscribe
Issue No.01 - January/February (2003 vol.20)
pp: 5-7
Published by the IEEE Computer Society
As a college professor, I often get an opportunity to speak with incoming freshmen who have decided to major in computer science. Virtually all these young people share a single attribute: they have no idea what a professional software developer does. This means that many students who pick this career will either be unsuccessful or, worse yet, successful at a career they'll hate until they retire. At the same time, many students who would find the profession enjoyable and be quite good at it might not give it a second thought.
And they won't learn much more about the business in their first few years in college, either. They'll probably get a good dose of writing simple C++ or Java programs, almost invariably as a solo effort and after the professor has given them a detailed set of specifications of how the assigned software is to behave. By the end of their second year, most students are certain the software development business is all about while loops, if statements, and being very, very clever and self-reliant. In this distorted view of our profession,

    • The developer always has a complete spec (or if they don't, they can make it up as they go along).

    • All development begins with a brand new program.

    • If your program doesn't core-dump in response to a test case, its behavior is correct.

    • No one else (with the exception of the professor, perhaps) ever looks at your code.

    • The developer never, ever has to read someone else's code.

By the end of their fourth year, if they're lucky, the hopeful software developer will have started to catch on. Unfortunately, most will just view the team projects, class presentations, software life cycles, and ambiguous problem statements as "hoops they have to jump through" to graduate. I recall a meeting with a student who was having trouble working with her project team in a recent class. She actually asserted with some confidence that the problem she was having with her team members (not acknowledging her as the finest software architect in the land) wouldn't happen in industry. She was stunned when I explained that her teammates were going to graduate the same time she was and that even if she might not end up working with them, she would likely be working with someone much like them.
Delivering a Dose of Reality
I have recently begun trying to learn how to better prepare students for the reality of software development. This doesn't mean looking for more realistic projects or figuring out how to move code inspection exercises into freshman Introduction to Computer Science classes. If young people had a better understanding of what professional software development is really like, those with a propensity for working in teams, coding to a specification, and following rigorous, well-defined processes would more likely study software development, and those not so predisposed wouldn't.
As my sons get closer to high school graduation, I have noticed that they and their friends seem to know a lot about some professions (software development is not one of them, in spite of their father), and I am trying to understand how they acquired this knowledge. As far as I can tell, the best-understood career path for young adults (at least in North America) is a toss-up between law enforcement and firefighting. They know the vernacular, they can describe the equipment, and they can immediately recognize the agency initials. I suspect the reason is that young people these days tend to get a lot of their information from television and movies. While they end up learning some incorrect (or at least distorted) information by watching "reality" TV, most young people have a pretty fair idea of what police officers or firefighters do, the environment in which they work, and the organizational structure within which they operate.
Hollywood Lessons
On the other hand, most software developer hopefuls don't have a clue about what they will be spending the rest of their lives doing. And the information they do receive from movies about software developers is consistently inaccurate. Because of this, I have begun a semi-serious study of how Hollywood portrays software developers, analyzing a number of classics in which computers and software play major roles in the plot. Disney's TRON (1982), WarGames (1983), and The Net (1995) are representative of the way movies portray computer folk. The image that emerges is not a pretty one.
In TRON, Jeff Bridges is a gifted programmer who singlehandedly writes several computer games that are subsequently stolen by David Warner. These titles become huge hits in the marketplace and propel Warner to become executive senior vice president. Angry that his work has been stolen, Bridges quits his job and retreats into a video arcade, from which he emerges only to try and break into his previous employer's computers. While Bridges portrays a cooler than normal computer geek, he nevertheless manages to give the impression that his life revolves around computer games. Eventually, he gets electronically sucked into the mother of all computers and, as the saying goes, the rest is history.
In WarGames, Matthew Broderick is a high school nerd with few friends. He does somehow end up with a girlfriend (Ally Sheedy), but she is just as nerdy as he is. In his spare time (since he doesn't spend much effort on his school work, he appears to have plenty of it), he hacks into random computers using an automatic phone dialer that calls random numbers until he connects to a modem. He finally hacks into the NORAD Defense Department War Computer, which has complete control over the US nuclear arsenal. (In the movie, this computer is called WOPR. I have been told that NORAD's real system in the 1970s was called BURGR.) Naturally, the software controlling every US missile was written by a single person (John Wood), who has retreated to a cabin in the Pacific Northwest where he lives alone and avoids visitors.
In The Net, Sandra Bullock plays a software developer who works from home and spends her free time in online chat sessions. She is so isolated from in-person social interactions that when her identity is stolen, she can't find a single individual that can physically identify her. The fact that her personality is better developed as the plot unfolds and she becomes less of a comic book character than the software experts in the first two films makes her portrayal a bit more unsettling.
There are a dozen other films that reinforce this image of software developers as brilliant yet socially awkward individuals who code on the fly, singlehandedly develop ultracomplex systems, and aren't above breaking into a computer or two. Not surprisingly, this misconception attracts to computer science many brilliant, socially awkward young people who code on the fly, think they can singlehandedly develop ultracomplex systems, and are interested in breaking into computers.
Ironically, as a college professor, I have the opportunity to meet a large number of employers of software developers. Invariably they are looking for graduates who socialize well in groups, are team players, are articulate, and are able to give coherent oral presentations. Although they obviously expect some technical ability, overwhelmingly the traits that most distinguish new graduates are communication abilities and the willingness to be a team contributor. This is exactly the opposite of movies' portrayal of software developers.
Conclusion
The film critic Roger Ebert once wrote that it was a grave mistake for professionals to see movies about their trade because it is impossible to suspend disbelief when you see your trade misrepresented. But the way software developers are portrayed in the cinema goes beyond simple misrepresentation. Rather, it influences the way young people—potential future software developers—think about the profession. It can encourage students who will never be happy working on programming teams, dealing with customers, or working through a well-defined software process to seek software development careers. More importantly, it can discourage those who would welcome such an environment but mistakenly fear spending their career stuck in a cubicle hunched over a computer monitor.
Of course, when all is said and done, these movies and others like them are immensely entertaining, and as long as we can keep young people from thinking that they even remotely represent the reality of software development, I suppose they really cannot be too harmful.
I'd love to hear your opinions about the impact of the cinema and television on new software developers' expectations, as well as learn of any films that do a better job of portraying our profession. Please write to me at Warren.Harrison@computer.org.
16 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool