##CONTINUE##
Programmers care about languages. Opinion on the topic is generally divided into two schools of thought. One holds that a good programmer will be versed in a selection of different languages, to be better equipped to handle a variety of coding styles and challenges. The other school maintains that the best way to remain marketable as a developer is to become an advanced specialist in a single, popular language, such as C# or Java.
Programmer and blogger Jeff Atwood definitely falls into the second camp, only with a twist. According to Atwood, what matters most is not the language you code in but the language you speak. Programmers who want to be successful can be fluent in any languages they choose, he says -- just as long as one of them is English.
If the thought of claiming English as the lingua franca of software development makes you just a little bit uncomfortable, join the club. Atwood even titled his own blog post "The Ugly American Programmer." It doesn't help that one of his supporting citations comes from open source luminary Eric S. Raymond, a self-described gun nut.
Still, I'll see Atwood's point and raise him one further. Language proficiency is important, but not just in the sense of grammar, vocabulary, and syntax. Rather, what programmers need most are good, old-fashioned communication skills -- the same kind that are in demand for any other job.
As the global economy shrinks, the role of the rote coder is disappearing. Today's developers must be equally effective in the conference room as in their cubicles. They must be fully engaged, not merely in the software design and implementation process but in the business itself. For many programmers, that means learning not just a language but a whole new set of skills. And woe betide those who can't keep up.
The coder as typist
Sure, basic English proficiency is a boon for any programmer. Just for starters, the keywords and library function names of the vast majority of programming languages are based on English words. The bulk of technical jargon itself is derived from English. The majority of developer instruction and discussion is conducted in English. And commenting and documenting code in a language that's understood by all present and future maintainers of that code is just good practice.
Contrary to what Atwood says, however, programmers aren't all that exclusive in this regard. English is rapidly becoming the language of global commerce, no matter what your profession. It's not uncommon to hear English spoken in offices throughout Europe and India, and its use in Asia is growing. Increasingly, what matters is not just that you can put together the mechanics of the language -- to document code, for example -- but that you can communicate effectively in it.
Mechanical proficiency did matter, once. Forty years ago, I would have dictated this post to a secretary, rather than keying it in myself. That secretary would have been a master of the mechanics of writing: grammar, vocabulary, spelling, punctuation, and presentation, to say nothing of being able to work a typewriter accurately at breakneck speed. In turn, my secretary might have forwarded the post to a typing pool to have copies made: one for my editor, two or three for the copy desk, and one for the editor-in-chief.
Those typing and secretarial jobs put food on American tables for decades. Today they're all gone. As it turns out, it's much more efficient for me to put my own ideas to the page myself -- with the aid of modern technology -- than to communicate my ideas through a series of intermediaries. By the same token, I couldn't get hired for an editorial job today if I didn't know how to type.
Unfortunately, however, too many software development teams are still staffed like secretarial pools. Ideas are generated at the top and then passed downward through general managers, product managers, technical leads, and team leads. Objectives are carved up into deliverables, which are parceled off to coders, often overseas. Those deliverables are then reviewed, tested, revised, and parceled off again. The idea that this structure can be sustainable, when the U.S. private sector shed three-quarters of a million jobs in March 2009 alone, is simple foolishness.
Smarter developers, leaner enterprises
Fred Brooks said it years ago, in his seminal book "The Mythical Man-Month." Just as nine women can't make a baby in a month, throwing more bodies at a programming project doesn't make the team more efficient. It makes it less so.
We've seen what happens to companies that ignore this lesson. If you haven't yet, be sure to read Moishe Lettvin's account of how one Microsoft development team had to draw input from 43 separate employees to implement a single feature in Windows Vista. "By the way, 'feature' is much too strong a word," Lettvin says. "A better description would be 'menu.'"
The counterexample? Open source software. By now we've dispensed with the notion that open source projects are developed by thousands of scattered developers worldwide. The truth is that most projects are developed primarily by a core group of dedicated programmers. It's only natural: In this model, the developers with the deepest architectural understanding of the code, the closest interaction with the code, and the most responsibility for the code are the ones who wield the greatest decision-making power in the overall project.
So why is this kind of meritocracy so difficult to duplicate in the corporate world? Part of the blame goes to old-economy business practices, favoritism, and creeping "manageritis." But the other issue is that the oft-repeated complaint of software companies -- that they just can't hire enough skilled developers -- is true, at least in a sense. The problem is that the industry is focusing on the wrong skills.
In 2009, software development managers shouldn't be sifting through resumes choked with acronyms and lists of technologies. Software development doesn't need more typists, secretaries, intermediaries, or middle managers. What it needs are more skilled, engaged, communicative, responsive, assertive developer-analysts -- the kind who can understand, influence, and guide development efforts, rather than simply taking dictation. The shrinking economy makes this need ever more acute -- so for those who can fill the bill, the opportunity has never been greater. For those of you who are still trying to decide which language to learn next, on the other hand, I don't envy you.
-----------------------------BY Neil McAllister
Source：InfoWorld
© 1994 - 2009, InfoWorld Inc., Reprints, Permissions, Licensing, IDG Network, Privacy Policy, Terms of Service.
All Rights reserved. InfoWorld is a leading publisher of technology information and product reviews on topics including viruses, phishing, worms, firewalls, security, servers, storage, networking, wireless, databases, and web services.
Posts
0 comments:
Post a Comment