Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Workagolism and Chronic Work Overload Bulletin, 2002

Slashdot/Is Programming a Dead End Job

Not always true (Score:4, Insightful)
by kaladorn on Thursday April 25, @03:41PM (#3411001)
(User #514293 Info | http://slashdot.org/)

My boss (our VP and I think CTO) is the developer of utmost Deep Magic. But of course, we're a relatively small company.

But to take the other side of the coin up, I know of developers who made more than their managers (as one of my classmates ascended to management, I know several of the lead developers were making significantly more than he was).

There are two or three GOOD reasons why managers make the big bucks. In theory, they are the RESPONSIBLE ones. The buck stops there. Programmers can often excuse problems as being the result of other people's work, their deadlines, etc. But a manager has no such refuge. That responsibility should be commensurately rewarded.[1]

Also note that some highly paid programmers who make more than their management treat their management like inferiors. I've seen this. At the end of the day, some of the geek community only respect salary or other raw displays of power and authority. Sad but true.

Lastly, good managers are worth their weight in gold and do significantly benefit a project. They coordinate people, resources, and customers. They manage customer expectations, attend to the wellbeing of their managed, and ensure that all required resources are forseen and in place when required.[1].

So even though the comment about programmers not getting paid more than managers has exceptions, there are some good reasons for things to be as they are.

[1] - I know very damn well that the theory often doesn't match practice. For some reason, many companies keep inept management in place, I suspect because the next management level up is equally inept. I've had precisely three fair to okay managers, 1 really great manager, and several of the nightmarishly inept variety. But why companies keep incompetent managers in positions of power despite all the damage this causes is an utterly separate issue from the reasons why managers are paid more than programmers. Valid, but different.

Cliff said it all (Score:3, Insightful)
by Havokmon (rickNO@SPAMhavokmon.com) on Thursday April 25, @02:36PM (#3410478)
(User #89874 Info | http://www.havokmon.com/ | Last Journal: Thursday September 27, @05:18PM)

People who are in this career for the money or the prestige may not like it after a while, but the people who are in this for something else will tolerate quite a bit before deciding to opt out.

And is exactly why Loki lasted as long as it did..

 

[ Reply to This | Parent ]

No way (Score:4, Insightful)
by dciman (kybwilli@indiana.edu) on Thursday April 25, @02:37PM (#3410485)
(User #106457 Info | http://php.indiana.edu/~kybwilli/)

I think that programming is by NO means a dead end. Sure there is a bit of a tough time right now with the economy in its current state. But, we are just now seeing an emergence of whole new computational fields. These mainly being in the life sciences arena. Genomic sequencng projects are quickly overloading scientists with raw data that someone needs to turn into usefull information. The area of developing these tools is vast. Possibly more important will be people who come up with better algorythms for predicting protein structre and interactions based on sequences. This is an amazing field that has the promise of keeping computre scientists, biologists, and bioinformatics people busy for decades to come. I think the field is ready to make leaps and bounds.... and most definitly not a dead end.

Embedded.com - Is This A Dead-end Career

Become a dentist, CPA, or lawyer and odds are you'll be practicing that profession on a more or less daily basis till the day you retire. That seems less likely for engineers and firmware developers. How many EEs or software folks do you know in their 60s who still work as techies? How many in their 40s?

Though I haven't the statistics to support it, my observations suggest that embedded systems development is a field dominated by young folks -- say, those under 35 or so. Middle age seems to wean folks from their technical inclinations; droves of developers move towards management or even the dark side, marketing and sales.

Is salary compression the culprit? My students, all of 21 and armed with a newly minted BSEE, get entry-level jobs at $50-60k. That's an astonishing sum for someone with no experience. But the entire course of this career will see in general less than a doubling of this number. Pure techies doing no management may top out at only 50 percent above the entry-level figure.

Consider that $70k or $80k is a staggering amount compared to the nation's average mid-$30k average family income -- but even so, it's quickly swallowed by the exigencies of middle-class life. That $50k goes a long way when one is single and living in a little apartment. Life happens fast, though. Orthodontics, college, a house, diapers, and much more consume funds faster than raises compensate. That's not to suggest it's not enough to live on, but surely the new pressures that come with a family make us question the financial wisdom of pursuing this wealth-limited career. Many developers start to wonder if an MBA or JD would forge a better path.

What about respect? My friends think "engineer" means I drive a train. Or that being in the computer business makes me the community's PC tech support center. "Doctor" or "VP Marketing" is something the average Joe understands and respects.

Is tedium a factor? Pushing ones and zeroes around doesn't sound like a lot of work, but getting each and every one of a hundred million perfect is tremendously difficult. I for one reached a point years ago where writing code and drawing schematics paled; much more fun was designing systems, inventing ways to build things, and then leaving implementation details to others. I know many engineers who bailed because of boredom.

External forces intervene, too. Though age discrimination is illegal it's also a constant factor. Many 50-ish engineers will never learn Java, C++, and other new technologies. They become obsolete. Employers see this and react in not-unexpected ways. Other employers look askance at the high older engineer salaries and will consider replacing one old fart with two newbies.

Champion of Angry Programmers

The main issue, according to Matloff, is the hiring practices of many technology companies that both discriminate against older programmers and turn foreign-born programmers, working in the United States on H-1B visas, into indentured servants.

The problem stems from the unwillingness of most HR departments to train their employees, combined with an overemphasis on the latest skills. The result, in Matloff's view, is a situation that's completely unacceptable to everyone concerned. Older programmers are viewed as "obsolete" once they reach 30 years of age, he said. And foreign-born programmers, who are being brought in to replace them, are forced to accept jobs for less than market rate while often working under hostile conditions just to get their green cards.

Matloff sees the companies losing out, because they are overlooking experienced, easily retrainable candidates and often hiring less-qualified ones to save money, hoping to reap the benefits of a compliant workforce in an industry notorious for job-hopping.

Matloff speaks to the NetSlaves on the authority of his extensive research and numerous articles on the IT employment situation. He defends himself against charges of xenophobia by citing a group of Indian programmers who have organized to pursue legal action against alleged abuses.

Indentured Servants? (99 MB)
Matloff claims that Silicon Valley is "addicted" to hiring foreign tech workers because it seeks a compliant workforce that can't switch jobs easily, and is often underpaid.

Skill vs. Talent (1.16 MB)
Matloff discusses why technology recruiters are obsessed with the programming "skills du jour," instead of hiring talented programmers with generic abilities.

Washed Up at 30? (1.08 MB)
Why most computer science majors don't stay in the field for more than a few years, and how some older programmers are filing age-discrimination lawsuits.

Self-Defense by Job-Hopping (1.07 MB)
Matloff's advice for younger programmers is to frequently switch jobs.

Like what you hear? Read the book: NetSlaves: True Tales of Working the Web, a beyond-the-hype look at what it's really like to work in the Internet business.

SPIRE Abstract Information Overload - An IR problem  by M.Montebello

Information overload on the World-Wide Web (WWW) is a well recognised problem. Research to subdue this problem and extract maximum benefit from the Internet is still in its infancy. With huge amounts of information connected to the Internet, efficient and effective discovery of resource and knowledge has become an imminent research issue. A vast array of networks services is growing up around the Internet and massive amounts of information is added everyday. Despite the potential benefits of existing indexing, retrieving and searching techniques in assisting users in the browsing process, little has been done to ensure that the information presented is of a high recall and precision standard. Therefore, search for a specific information on this massive and exploding information resource base becomes highly critical. In this paper we discuss the issues involved in resolving the information overload over the WWW and argue that this is solely an information retrieval problem. As a contribution to the field we propose a general architecture to subdue information overload and describe how this architecture has been instantiated in a functional system we developed.

Proceedings of the String Processing and Information Retrieval: A South American Symposium
Copyright (c) 1998 Institute of Electrical and Electronics Engineers, Inc. All rights reserved.

Information overload, internet filtering agents, e-mail filtering, information filtering, user modeling, routing, ranking email

Robert M. Losee,
Minimizing Information Overload: the Ranking of Electronic Messages,
Journal of Information Science, 15, 1989, p. 179-189. Full text of article (in pdf)

Abstract:

The decision to examine a message at a particular point in time should be made rationally and economically if the message recipient is to operate efficiently. Electronic message distribution systems (e.g. email), electronic bulletin board systems, and telephone systems capable of leaving digitized voice messages (e.g., voicemail) can contribute to "information overload," defined as the economic loss associated with the examination of a number of non- or less-relevant messages, as in related information retrieval models. Our model provides a formal method for minimizing expected information overload through information filtering.

The proposed adaptive model predicts the usefulness of a message based on the available message features and may be useful to rank messages by expected importance or economic worth. The assumptions of binary and two Poisson independent probabilistic distributions of message feature frequencies are examined, and methods of incorporating these distributions into the ranking filter model are examined. Bayesian methods to incorporate user supplied relevance feedback are suggested. Analytic performance measures are proposed to predict system quality. Other message handling models, including rule based expert systems, are seen as special cases of the model. The performance is given for a set of unix shell programs which rank internet messages. Problems with the use of this formal model are examined, and areas for future research are suggested.

For additional technical discussion of this material, see Losee, Text Retrieval and Filtering: Analytic Models of Performance, Boston: Kluwer, 1998.

Losee home page at http://www.ils.unc.edu/~losee

[Feb 2,  2002]  Byte: Information Overload Fighting data asphyxiation is difficult but possible

Data is like food. A good meal is served in reasonably-sized portions from several food groups. It leaves you satisfied but not stuffed. Likewise with information, we're best served when we can partake of reasonable, useful portions, exercising discretion in what data we digest and how often we seek it out.

Unfortunately, we often do the opposite, ingesting information constantly to the point of choking on it. The risk of information asphyxiation touches all of us -- managers, Web surfers, even lazy couch tubers.

The most obvious locus of information inundation is the office: e-mail, voice mail, phone calls, meetings, business journals, faxes, memos, manuals, Web research. The list goes on. Far from bringing about the anticipated "paperless office" and reduced work load, technological innovations have increased both areas.

David Shenk, in his book Data Smog, reports that between 1980 and 1990, paper consumption in the U.S. tripled to 1,800 pounds per person. Sixty percent of the average office worker's time is spent processing paper documents. Additionally, "the typical business manager is said to read one million words per week." That's the equivalent of one and a half full-length novels per day.

Diminishing Efficiency

Information technology, in fact, often diminishes workplace efficiency. Scientific American ("Taking Computers to Task," July 1997) pointed out that despite the $1 trillion spent annually across the globe, "productivity growth measured in the seven richest nations has instead fallen precipitously in the last 30 years ... Most of the economic growth can be explained by increased employment, trade and production capacity. Computers' contributions, in contrast, nearly vanish in the noise."

Blame can be pinned on everything from sound cards to solitaire, that numbing front-desk babysitter.

Also at fault, however, is the medium and people's lack of training in how to effectively use it. When employees use e-mail to communicate with someone 50 feet away, there's a problem. Saving customer quotes in a general "user" directory is just asking for the document to become lost among hundreds of other files. Inefficient inventory software yields frustration where a simple list on paper would do the trick.

[Feb 2,  2002]  Coping With Information Overload Too much of a good thing can hurt your job performance.

Paul Saffo, a director with the Institute for the Future in Menlo Park, Calif., told Information Week that it's not the information glut itself that causes problems, but rather our inability to process information. "Information overload is not a function of the volume of information out there," Saffo says. "It's a gap between the volume of information and the tools we have to assimilate the information into useful knowledge."

Yet the solution is an old-fashioned one, contends Emory Mulling, president of the Mulling Group, an Atlanta-based executive coaching firm. In fact, it predates e-mail, the Internet, and voicemail.

"People still must recognize they have to prioritize and winnow," he says. "Just because we may have access to all the information in the world, it doesn't mean we can process it all. In fact, far from it."

[Feb 2,  2002] Corrin Weir's Dissertation Bibliography Among items:


Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: July 30, 2013