While it's been nearly 5 years since I toiled in COBOL, I can assure you that much of the information infastructure you deal with on a daily basis still runs on legacy mainframe hardware with COBOL programs being fed your charge card data, airline reservations, utility usage, pharmaceutical claim adjudications, etc....
There are plenty of COBOL Programmers out there, the problem is nobody in IT wants to hire old people.
True. Or the "hire" would be at a rate of 50-60% of what that same programmer made previously. I still get soliciations for mainframe COBOL work and the rates and salaries advertised to me are an absolute joke.
The problem is not lack of Programmers. The problem is managers who think a developer needs many years of experience with a specific language or technology to be able to work with it. I am sure many programmers would be willing to work on their COBOL systems, but without the required "10 years of experience with COBOL" on their resume, they would never be hired.
Well, code is code, but I would caution that:
More essential is experience with the legacy platform that those COBOL programs are running on. Are you familiar with the vagaries of S0C4 or S0C7 ABENDs? Do you JCL? Can you read an MVS dump? Do you know how to allocate a file?
Grizzled veterans can pinpoint root cause in short order while it may take an inexperienced crew days, if not weeks, to troubleshoot a problem. It's not about being smarter, it's knowing where to look, with the cruder, less evolved diagnostic tools.
Wow, if this is a COBOL system, you mean no one took the time and energy to document the system and all of its glorious parameters during the ramp-up to Y2K? I'm shocked...SHOCKED to hear that a bureaucracy would waste such a golden opportunity as the Y2K scare to look long-term and decide that hey, as long as we're in the process of vetting code, why don't we document it as well?
And yes, there are already those out there jumping up and down pointing out that fixing a year from a two digit to a four digit format is way different than figuring out how to reprogram an ancient computer language. Gotta love the State Government, home to Silicon Valley, too myopic to even consider upgrading something as non-essential as a payroll system.
Most of the Y2K effort focused simply on alleviating eventual issues with two digit dates by "windowing". No expansion of existing database fields -- as much of the processing in legacy world on a fixed column basis, and lengthening the field was considered "out of scope" -- just a simple if statement to test if it was the 20th or 21st century. And regarding documentation, you're being glib, right? As staffs are downsized, support and application teams siphoned off to India or replaced by imported non-immigrant visa holders, documentation, which never was a top priority, has been given even shorter shrift.
This sounds like a typical "we have to re-write everything" attitude I hear from a lot of programmers who have to work with legacy code.
They have an application that calculates the salary. They don't need to change anything in the existing application, all they need is to "decorate" the app with an additional wrapper that rolls back the salary the appropriate amount.
A rather naive assertion. In legacy systems much of the business logic is embedded deep within the bowels of the code. There may be a "business analyst" who is the overseer, but they are totally reliant on somebody else who can actually read code. And it will be far from straightforward, even for a gifted wizard, as the code in question may be decades old, and littered with patches and interfaces placed on top of all the cruft.
I'll give $3 to the first person who can explain to me why on Earth you need to edit the software to change p
Caps Lock -- tap the shift button twice and you are in "caps mode". You can also drag your finger press from shift and enter a capital letter in that fashion -- 1 tap!. And after character is "typed", you're back with the regular alpha keyboard.
Punctuation characters like "/" -- again, one tap to drag across the ".?123" button and the "/" character (as well as parenthesis, quotes, commas, digits, etc....) are all accessible. And again, after you lift your tap, your keyboard display is alpha, ready for the next alpha char.
And a jailbroken (not necessary to "unlock" to "jailbreak") iPhone can indeed perform terminal functions, including ssh. Of course one may not wish to do that their phone, but the capability does exist.
As far as typing on the keyboard, I've had no problem, though I will admit that I'm not as fast as I used to be with Grafitti on the old Handspring PDA, but I don't believe that's because my tapping isn't nimble enough, just that it seems to second for the characters to pop up on the display. Haven't gotten fast enough to see if my outracing the buffer drops too many characters.
The error rate is high because (big fuckin' surprise, just like everyone predicted) there's no tactile response. There's no caps lock or sticky shift. Only alpha characters are on the main keyboard; you have to go into sub-keyboards, and there's no way to return automatically after typing one punctuation letter. My Nokia 6820 had most of this down perfect.
This: "/etc/init.d/http restart" would take forever (each / and . would take three taps), and because of the error rate, you'd run the risk of triggering an account lock or ssh abuse prevention IP block just trying to get into your machine. God help you if your password is actually secure (ie alpha AND numeric with some punctuation or case changes.)
Article bangs on the "mighty mouse" as not really being a 2 button mouse......while I am no fan of it, I recently hooked my Mom up with a new IMac and played with the mouse and the button on the side does right click and the knobby deal in the middle acts as a scroll wheel, at least it worked for me......and on my MacBookPro two fingers on the pad can accomplish same functions as a 2 button mouse...
I was disappointed with this title
on
Rails Cookbook
·
· Score: 1
I own both titles ("Rails Recipes" by Chad Fowler) and IMO neither does a great job -- there's nothing in this book not already covered by the definitive DT/DHH Agile Rails Development book. About the only redeeming value was the information on Mongrel and the detailed instructions to get Rails installed and running on all the different platforms.
Speaking of which, though, the devoting of a good chunk of paper real estate to installation, seems to be space better left for meatier topics. Especially on a topic that changes significantly on a monthly basis -- it would seem that for a book, it would be more prudent to focus on matter not so ephemeral, knowledge that would arm and equip someone learning Rails to handle any task or illustrate more advanced techniques a web developer wishes to accomplish.
Unfortunately, I've plunked down money for a bunch of hardcopy books on AJAX and the new fangled javascript tidings — yes, I know I could find most of the requisite documentation online and/or I even question the silliness of amassing a library over a simple API call and a few demonstrative examples. But if I were to choose one book to buy or keep on the subject, this would be the one, easily.
Why? Well, because the author takes a problem centric view after a basic tutorial (i.e., how to handroll your own remoting, simple code examples). Then, all the things you can do with the tools are detailed, within a templated question and answer framework, and unlike the reviewer here, I appreciated the inclusion of all the URLs so I could research further. Also, a big part of learning anything is just getting the terminology down, so that those can serve as "keys" for subsequent knowledge acquisition. Also, the author doesn't seem mentally tied down to a given platform (take note.NETers and Rubyists) and explains things from a purely algorithmic perspective.
This is a worthy title for anyone wishing to expand their AJAX knowledge, though if you're totally comfortable with online discovery, you could forego it.
Are these quotes correct — that Gates Foundation only gives away 5% of its worth?
At the end of 2005, the Gates Foundation endowment stood at $35 billion, making it the largest in the world. Then in June 2006, Warren E. Buffett, the world's second-richest man after Bill Gates, pledged to add about $31 billion in installments from his personal fortune. Not counting tens of billions of dollars more that Gates himself has promised, the total is higher than the gross domestic products of 70% of the world's nations.
Like most philanthropies, the Gates Foundation gives away at least 5% of its worth every year, to avoid paying most taxes. In 2005, it granted nearly $1.4 billion. It awards grants mainly in support of global health initiatives, for efforts to improve public education in the United States, and for social welfare programs in the Pacific Northwest.
It invests the other 95% of its worth. This endowment is managed by Bill Gates Investments, which handles Gates' personal fortune. Monica Harrington, a senior policy officer at the foundation, said the investment managers had one goal: returns "that will allow for the continued funding of foundation programs and grant making." Bill and Melinda Gates require the managers to keep a highly diversified portfolio, but make no specific directives.
By comparing these investments with information from for-profit services that analyze corporate behavior for mutual funds, pension managers, government agencies and other foundations, The Times found that the Gates Foundation has holdings in many companies that have failed tests of social responsibility because of environmental lapses, employment discrimination, disregard for worker rights, or unethical practices.
Two live diamondback rattlesnakes were released in an Arizona movie theater during a showing of the new film "Snakes on a Plane," according to Local 6 News.
Authorities said pranksters released the young venomous rattlesnakes in a dark theater at the AMC Desert Ridge near Tatum and Loop 101 in Phoenix.
The two snakes caused a panic in the dark theater, according to the report.
"That to me is very scary," herpetological association representative Tom Whiting said. "I would hate to be watching a movie about snakes and have a rattlesnake bite me."
Wranglers were called to collect the snakes, the report said.
No one was injured in the incident and, so far, the culprits have not been caught.
Officials believe the snakes were smuggled into the theater in backpacks.
"This thing is under someone's chair and they go to sit and they just push your foot in the air and startle it -- obviously all they got to do is startle this thing," Phoenix Herpetological Society spokesman Daniel Marchand said. "It's dark. They can't see you, you know that well. If it's scared, boom it strikes."
The snakes were released into the desert.
H1B candidates are needed because there are a shortage of American high tech professionals. No, incorrect, H1B has been used to displace American workers and it has undercut median wage for programmers and engineers. I've witnessed firsthand at multiple companies the saga of staff replacement with a mix of offshore programmers/improted NIV programmers. I've seen company programs that recruited and promoted internal talent scrapped so that $said_company could join the race to the bottom.
H1B candidates are paid prevailing wage. True for some, but most are shuffled about and treated like chattel, in worse fashion that the traditional American bodyshops treated their personnel. And a H1B candidate is much more restricted in job mobility than an American would be. Yes, there has been a recent uptick in contract/job advertisements but the pay rates, outside of specialty realms, is still total suckage. Rates/salaries lower than I made 12+ years ago. If there is such a strong demand being unfulfilled, why are not salaries/contract rates increasing significantly?
H1B candidates are "highly skilled" professionals, and are greatly desired and valued. In some cases, yes, but for the most part, these spots in no way can be construed as "highly skilled" -- again, in my experience, candidates sent to the U.S. might have had resumes boasting of requisite skills and experience, but when I met the candidate after his/her plane flight to the states, it would become readily apparent that their "skills and experience" consisted solely of a training curricullum overseas and a perusal of manuals on the plane ride over. Yet, as stated, we're doing a disservice to our own youth -- I realize many programmers opt for sexier type application devlopment like creating and deploying web applications, but even at the pay alotted to the offshore "bodyshop" vendors, these would be excellent jobs and career opportunities for young Americans. I have no problem with H1B or even citizen status for field luminaries like Linus Torvalds or others of genius level. But I believe it's a better national strategy to fill entry level positions with Americans, not foreigners.
Companies are legally prevented from replacing Americans with NIV workers.. Totally untrue, as if one takes time to research will discover. There are other legal provisions regarding how the H1B program operates, but enforcement is nil. Campaign contributions from "American" firms sway legislators into swallowing that corporate motives are benevolent. Employees are outright lied to. Again, I've experienced this firsthand.
But there is a dynamic at work here, namely that since "American" firms have invested so much (money, resources, strategy, time, etc....) in offshore vendors and importing NIV programmers they have created a defacto dependency on the paradigm. As they've chased Americans out of the field, in preference of a cheaper foreign factory approach, they now are much more reliant upon foreign engineers and programmers. Most of my colleagues have moved on to other career fields or they simply are hanging on as SMEs, marking the days to retirement. It's no wonder that computer and engineering student enrollments are declining -- there'll always be young Americans who answer to a calling despite potential career conditions and ramifications (i.e., see teaching), but statistics are now bearing out that the majority will pursue a more fruitful career path, both in terms of short term financial reward and long term job stability.
Ironically, or comically, or tragically (depending on your particular perspective!), from what I understand from conversing with friends who are directing such offshore/NIV programmer teams, the offshore vendors don't seem to acknowledge the great gift bestowed upon them. Instead, they've fouled it up, focused entirely on short term profits, managing their operations like multi-level marketing schemes. Shuffling workers to maintain a subserviant force, yet failing and leaving core systems of our largest companies in a sordid state of disrepair.
Vaguely written rants laced with trendy buzzwords and university eggheads flaunting their scholarly beaks at plebian programmer tools aside, let's look at why LAMP has been and will continue to be a viable web development platform.
First, I've coded on just about all platforms, from COBOL, REXX/CLIST and Assembler on IBM mainframes to C on Unix boxes to LAMP to Ruby (including some RoR apps). And, code is code — in the hands of an unskilled practicioner, the product is going to be crap no matter what the tool. And a gifted artisan can craft a masterpiece with nearly any tool.
There's a great deal I detest about PHP. But, any language that I've toiled in for over a few years in writing relevant legacy code/enterprise applications/dynamic web software shows its unsavory side. No such thing as the one true programming language exists — they're all just tools, and just as they have their selling points that shine, they all suck in some sense of matter.
Anyway, here's a short list of why LAMP is good.
F/OSS — I spent many years coding on proprietary platforms with commercial language platforms. And I would gladly exchange it in a heartbeat for the opportunity as we have today to work with Free/Open Source software tools. Being freed proprietary whim is a great blessing that I think many take for granted today, or are blindly unaware of the ramifications. I realize this doesn't address whether Linux + Apache + MySQL + PHP> some other F/OSS solution like Ruby, ROR, lightpd (which are far superior, IMV, to Micro$oft, $un, !BM) etc....
Shared hosting and LAMP package availibility/ubiquitousness — most likely, an entity wants a dynamic web site, a step up from the circa 1996 static html page variety, but their requirements are far less than something that requires a dedicated server. They pay someone with a little knowhow like me a little coin to set them up a LAMP site, either with a F/OSS project output platform customized for their usage or for a little more money, my own hand crafted framework solution. LAMP still excels in this regard, as most of the snazzy Web 2.0 offerings arn't freely releasing thier codebase as a "point, click and install solution" as the litany of PHP open source modules that populate the web space today.
Low startup barrier — any enterprising developer can get off the ground and running in a moments notice. Granted, this is a source of great consternation, as hand in hand, it has led to a large amount of hideous, ugly, unstructured code, giving a lot of the PHP community, justifiably so, a bad rap.
Having laid a case out for LAMP out, let me share some concerns about future LAMP direction:
Have to agree that about the assessment offered in another comment here about MySQL getting squeezed from both ends. For low volume sites, or even sites with considerable traffic but "read heavy" on the DB load, SQLite, built into PHP5, can easily take the place of MySQL and on the higher end, not sure if MySQL is going to remain a quality player. I expect that the "feature" to plug whatever DB you wish to use is going to grow in importance.
I finally made the leap to PHP5 and won't do any new project work with PHP4. Even in the shared hosting arena, there are enough hosts now that offer PHP5, that it shouldn't be an issue. Now, this scratches a great deal of existing PHP product out there for consumption, but I have discovered, to my surprise, that moving PHP4 code to a PHP5 environment has not been difficult at all, though there are a few gotchas to contend with.
"written in COBOL": 43,100 "written in REXX": 809 "written in CLIST": 168 "written in scheme": 34,900 "written in RPG": 700 "written in FORTH": 10,900 "written in objective-c": 26,700 "written in WFL": 5 "written in tcl": 106,000 "written in bash": 24,000 "written in korn": 480 "written in smalltalk": 20,400
Dating back to Burroughs machines and managers who didn't know how to use a text editor, preferring to use punched cards and "punched card emulation", but yet they could do a randomizer calculation without a calculator in their head within a second or two.
I've also had the opportunity to train mainframers in shops where MVS platforms were displaced by *nix based platforms. So, here is a subject that, no doubt, I can speak about:
The major factors/differences:
First, most of the mainframer programmer contingent has been moved offshore or is being done by NIV programmers. Really not much of a career path here, but OTOH, a great deal of critical systems (charge card processing, airline reservations, utility company systems) are still coded in MVS COBOL/DB2 (or IMS, a hierarchical mainframe database platform for IBM MVS). To convert these systems means you need to be able to understand these systems, and please don't give me a business analyst -- the days of their expertise are long gone, and the metamorphisis of systems over time means business knowledge is embedded in the code.
Mainframers don't get GREP. I've tried so many ways to impart this wonderful tool, but all I get back is puzzled stares and bewilderment, for anything more complex than what could be accomplished with a non-regex, or simple wildcard search.
Globals. This is something that put me aback 6-7 years ago, when I made the leap into Unix programming, and traded C/REXX/CLIST for C/Perl/etc... COBOL is structured into divisions and all your data declarations are laid out and globally accessible. Though many COBOL systems are quite complex, with a "program" actually being a driver for a whole hierarchy of 20-40 sub-programs, and the necessity to restart at a given point in processing can make things quite complex.
Approvals, checkoffs, signoffs, and procedures. They're largely absent in the Unix (and most webdev work) world, but mainframers have grown accustomed to reams of authorization and approvals for even simple changes. Lead times of a week or more, along with VP signoff, QA signoff, user group signoff, fellow developer signoff, etc.... Even getting a downstream system to agree to test changes may take a formal request process and budgetary allocation of thousands of dollars. This is probably the biggest divide, and future schisms will be prevalent, as data center leadership trys to impose this kind of checks and balances on developers not accustomed to these obstacles. IBMs trouble and difficulty in the web server world offer a prime example -- business being told that it'll take 3-4 months to get a server online, and folks who know better just can't understand that.
Lack of user tools. A big part of what I did as a mainframer was building tools, using BTS and File-Aid to allow developers and testers to create their own test bed and automate the test process. On Unix side, the tools come with the OS, and awk, Perl, and all the other CLI goodies make automating testing a snap.
File in/File out vs. piping. Mainframers have a tendency to see everything as file-in/file-out. In a way so do *nix coders, but a seasoned *nix programmers sees the tools all being able to feed eachother. Rather than step1 filein fileout, step 2 sort filein, out fileout, step 3 filein, reportout, etc...
On the age thing, most of the really skilled mainframers now, like myself, do Unix or migrated to Java. Others are awaiting retirement, or head over to six sigma teams, business analyst roles, or seek refuge in management, escaping the axe that clears the way for the offshore coder.
Paper over softcopy. Got to have that printed listing, and the sticky notes (and before that, paper clips). I still remember a senior manager telling me when I first broke in how his appraisal of a programmer was how many fingers he needed to act as placeholders when he perused a program listing.
The question that I would like to pose in this article is a simple one: How are we, as a society, going to respond to this robotic revolution? If we handle it properly, the arrival of robots could be an incredibly beneficial event for human beings. If we do not handle it properly, we will end up with millions of unemployed people and a severe economic downturn that will benefit no one. Can we modify the American economy now to prevent this downturn? Are there things that we can do today to smooth the transition to the robotic nation?
In a recent newsletter I wrote about a new corporate plan by Honeywell that some of their executives called a "Census Adjustment". Their cutsie corporate terminology is just another way of describing their new policy of replacing U.S. labor with cheaper foreign labor. I equated Honeywell's "census adjustment" to a corporate policy of "ethnic cleansing".
Since that newsletter was published I have received credible information about several of the specifics of the Honeywell plan. The following information may seem like a spoof, but I assure you that it's no joke and nobody at Honeywell will be laughing as of July 1st.
DISCLAIMER: Although this information contained in this newsletter is from a credible source, there may be some factual errors. I have no way of independently verifying any of these factoids below.
***** Dictionary of terms used by Honeywell corporate executives *****
Learning the dialects used by the corporatists can help us understand how they view the world. These are a few terms that I learned by studying information from Honeywell.
Census Adjustment: mass replacement of higher priced American employees with lower cost foreign employees. They don't make a distinction between foreign workers that come to the U.S. on H-1B/L-1 visas and workers that are in offshore positions. In most cases the foreign workers are high-tech workers from India or Eastern Europe. This term is going out-of-favor among Honeywell executives because so many employees made derisive comments and jokes about it.
Globalization: the use of workers as a global commodity to lower cost. This term can be used interchangeably with "census adjustment".
Globalized engineers: usually used when referring to foreign engineers that come to the U.S. by using H-1B and L-1 visas, but it can also be used to describe overseas engineers that work for Honeywell (the exact meaning depends on the context). The phrase is a clever code-word that corporate execs and HR lap-dogs use for "Cheap engineers".
Infill - the process of filling job positions with workers. There is no distinction made between the hiring of new workers or the transferring of workers from one Honeywell location to another. "Infill" is a trendy term that is very popular with borks and HR departments.
----- Honeywell's Plan for Census Adjustment by Globalization -----
Honeywell executives have decided that revenue spent for engineering must go below 15% of their total expenditures. In order to cut costs they will "globalize" their engineering departments. This globalization process will focus on cutting the cost of labor by using the following methods:
* Replacing current Honeywell workers with L-1 visa holders. These L-1 visa holders will come mostly from Russia, Czech Republic, and India.
* Whenever possible all positions in engineering and its support functions will be outsourced to overseas locations.
* All new IT jobs will be required to be outsourced offshore.
* No external hiring will be allowed, and transfers of employees within Honeywell will be discouraged until the job terminations are complete.
* Open job positions will be "backfilled with globalized engineers at a lower cost." Managers that refuse to go along with this process will be replaced with more cooperative ones.
* American subcontractors are currently being eliminated and replaced with foreign companies.
The following factoids pertain specifically about Honeywell's Component Engineering in their Commercial Electronic Systems (CES) on Deer Valley Road in Phoenix, Arizona and Aerospace (AES). Similar tactics will be used at other Honeywell locations.
>> Honeywell CEO, Dave Cote, has ordered Roman Jamragowiecz, VP of Engineering, to globalize 25% of AES engineering. It is generall
Then it dawned on me how outsourcing is important to young Indians
Problem with that statement is that those Indians who are benefiting from the tide of outsourcing, are not those in poverty, but the upper crust of a still rigid class society, that still adheres to the caste system, despite proclaimations to the contrary.
At least this has been the firsthand experience I've had in training offshore replacements -- that these folks were all mostly from rich, well-to-do families, and were sheltered from life, having to call a maintenance man to change a light bulb.
Graham's a few years late on this trend spotting..
on
Return of the Mac
·
· Score: 5, Insightful
...personally, I made the OS X switch in 2003, and it was my first ever exposure to Apple's world, and my days had been spent in Linux/UNIX, PC and MVS realms......I even liked running Linux on the desktop, but spent a lot of time tinkering to get stuff to work, and frequently simple stuff that just works on Mac/Win platforms is a chore on Linux (USB back a few years ago, wireless, syncing other hardware...).
However, my powerbook purchase brought the joy of computing back into my life. I frequently read the comments of those who decry the overpriced Mac when compared to constructing your own box (which I used to do - and I still believe that a Mac is equivalently priced with Dell/Gateway/IBM hardware, when all things are factored in properly) and while true on one level, it misses the mark on the total picture. That is depending on your interests and usage desires:
Time spent on system administration tasks is time not spent on other activities. Time is a non-renewable resource and I'd rather spend it writing software, using software (i.e., playing a game or other activity) than fiddling with the system to figure out why things arn't working or what's gunked up the box. I never see this factored into "cost" metrics -- that is, if you figure conservatively, your time at $20 per hour (maybe more, maybe less, I'm just gauging on median 40K salary), each additional 10 hours you spend a month administering your Win box is $200 per month difference. Which means in the span of 3-6 months, the Mac OS X will prove its cost superiority.
It really is the best of both worlds -- the shiny, eye friendly Aqua GUI plus having a full fledged *nix/BSD system at your disposal. Running MySQL/Apache/Perl/Python/PHP all on a local box where I can have my own testbed sandbox before presenting to clients. Yes, Win platform is capable of doing same thing, but to me, it's a kludge, and again, back to that time thing, where I waste time setting it all up and then dealing with the discrepancies between that environment and the *nix environments where the software will eventually run. And running PuTTy or Exceed is a weak substitute for an anti-aliased terminal window, custom setup. The one major thing that bugged me about OS X, that I missed from running Linux, was the virtual desktops, until I discovered this gem.
I realize there are specialized software needs that may not be met with OS X, but for most, the available software plus the F/OSS normally primarily in the domain of Linux OS is available to run on Mac OS X. And I don't even run Fink anymore, I just have a few X11 apps (Gimp, and a few others...) that I compiled and built and placed them within the X11 environment.
Life got a lot simpler when I replaced my wife's Win XP box with an iMac. No more weekly degunk sessions, antivirus, malware consternation and constant admonitions for her to be vigilant about keeping her machine clean were necessary. And she took to it like a charm -- things were unfamiliar (and still sometimes she stumbles on a Win -> Mac how-to-do question) but she is enthralled with it now and spends more time on email/web browsing than she ever did on the Win box. The iLife/iPod deal is just gravy and really we've experienced firsthand on how much more hassle-free life became after the Mac switch.
So, I'm not swayed by saving a couple hundred dollars. Just like I wouldn't buy a Kia or a Yugo, I'm not going to opt for a bargain basement PC over a quality machine like a Mac. No, it's not perfect and presents its own set of flaws, but at this juncture, it seems to be the product of greater quality for me.
...considering I turned in my two weeks notice resignation letter to my boss on Monday. Yes, I'm leaving a software engineer position without anything lined up, but I do freelance web programming and have income for at least the next month or two. I am actively seeking positions but I'm bumping up against that age discrimination deal plus I really want to work on Unix based systems, though mainframe work would be OK too, but most of that work is now done in India or by imported NIV (non-immigrant visa) workers.
Despite the fact that I like the folks on my team and my immediate management have treated me OK, I just dread the act of going into work and really don't like the role I was assigned. While it's no sweatshop, we're dreadfully undermanned (due to mergers and consolidation, and general cluelessness on the part of management).
Why am I departing? Well, there are a bunch of reasons and they weigh heavier than the impetus to stay, including the big fat paycheck that I could just go through the motions and keep ringing the bell every 2 weeks.
Work environment is atrocious - Yes, it's the age of the factory IT worker now, and cubicles are a thing of the past and we're crammed into office space where the noise is unbearable, the incessant ringing of cellphones, lack of conference rooms, people holding conferences behind your back, many desks seating 3-4 people instead of the cramped confines that even one occupant endures. Before I converted to full time employee status, I served a stint as a contractor and one day when I arrived at work, I had no chair and no chair could be found anywhere on the entire floor. I went home and worked from home for a couple of months until our group was relocated. Other amenity busters include 4 total bathrooms over thousands of staff, making the lavratory trip a most unpleasant experience. Parking is in short supply also and if you don't come in early or leave for offsite meeting during core hours, you will have to ride a shuttle. Even walking between the buildings on campus may take 15 minutes as construction forces a giant perimeter walk around (which isn't so bad, it's just the totality of all the suckage).
Inferior work tools - My title is "software engineer" and I administer MVS & UNIX boxes including installing Apache & Tomcat & other vendor software but I am not worthy of adminstrative rights to my own issued laptop. And that wouldn't be that big of a deal if I had the proper software. Instead I had to DL stuff that didn't require admin rights to do my job (i.e., Vim for Win, PuTTy, QWS3270, etc....) -- even more irksome was that we went through a lengthy checklist compilation process that preceded a "tech refresh" where all the officially sanctioned software was spreadsheeted and were told that the boxes would be set back to the way they were. Instead, they were stripped, and entire days were lost to reconstructing your software configuration and network settings. And Gates forbid if you needed Oracle and/or Informix or other third party software that required admin rights to install. The trouble ticket system is HP service desk, and I find it very painful to use, and it makes the old IBM InfoMan deal look like precision engineering. Maybe it's because we have to run it via Citrix, and the response time can exceed >10 seconds. And searches on text you can verify are actually are in a ticket will return no matches. I've spent entirely too much time just trying to find something I was looking at earlier in the day or week, and have had to resort to a paper index of ticket numbers.
Dearth of hands on coding - I don't mind support work, I enjoy the challenge of figuring out what went wrong and undertaking tasks that prevent trouble tickets or problem conditions from ever occuring. However, our group cannot touch the code at all and must turn changes over to another engineering group. It's become plainly obvious that my manager has a strict "help desk" view that measures success on h
And this is not likely to change, no matter how many public pronouncements from IBM executives. Ironically, some issues that would preclude OS transformation in the workplace are indeed no longer valid restraints -- for instance, the notion of being able to run the same OS at home as at the office, considering that many corporate environments only permit (officially) company owned (or leased) machines to connect to the network. Basically, in much of the corporate world, to do work you must work from a box provided by your work. That takes care of the argument that you need to have the same setup as you do at work...
However, the past 10 years has seen M$ firmly implant itself in the corporate desktop suite and it would take the next ten years to dislodge it. Not just the M$ Office applications (REAL programmers don't use spreadsheets or even a word processor...), which for many users, there is no suitable substitute -- I'm looking at the parade upon parade of dorky, kludgy, awkward third party Windows applications that now have pervade the business environment, both in IT and general business users. Another strong irony is that a good bit of this stuff is now Java based, which was touted as "write-once, run anywhere" but totally dependent on Windows to run. Either via custom Windows desktop client software, or piggybacked on MSIE or through proprietary database requirements that alternative OS usage was never ever factored in by the vendor selling. Go stroll through the software suite of any large corporation (most all of which are IBM clients) and it's heavily laden with gooberish offerings totally reliant on the Windows platform. Even the server software will have frontends unusable without IE and/or Windows.
Even if the software and hardware fulfilled the bill of need for business usage, users would still resent and resist change from familiar work patterns. This will always occur, even if the change is an obvious beneficial move of immense proportions. To a business user, even those computer savvy, it's a learning challenge hoisted on top of an already filled worklog platter. A mandate has to come down from above, that a change has been blessed and sanctioned, and that there is no choice in the deal.
In my view, most firms would profit hugely from a switch, at least those entities not dependent upon special software not available in alternative OS (including Mac OS X along with Linux) -- more stable, less virus/malware/spyware concerns, less employee "goofing off" factor (most games are Windows only), etc.......but then, expecting a large company to behave in a cost sensible fashion is folly, as they'd rather pay someone else to guarantee the deal or take the blame when things go south......at the shop I presently work, I've heard the network and system support engineers (and their managers) bemoan the existence of Linux and FOSS at our company, that they'd much prefer it all was HP/IBM/MS stuff, so they could simply "open a ticket" to the vendor to fix a problem......and it fits in with the "let's move it to India" instead of hiring a few good people and letting them manage the systems......but then I've drifted into another rant here...
Re:I do not pay much attention to Joel Spolsky
on
Joel On Software
·
· Score: 2, Insightful
Good Gates, how could this comment be moderated down to -1. Agree or disagree with the poster, but valid points are made.
Read through Mr. Spolsky's web site and see that he doesn't acknowledge free software/open source at all other than sterotypical blanket bromides.
The most disturbing thing about this article is it's point of view on social security. It shows a compleate lack of understanding and total disreguard for reality.
Social Security wasn't created to be retirement program. It was put into effect to keep old folks from dying in the streets, and evaluated on that criteria, it has been very successful.
And fear moners and profit mongers nonwithstanding, social security is still in solid health. By the most pessimistic of predictions, the program is slated to take in more revenue than pay out for another 15 years. And every year the CBO and Social Security Trustees release their report, that number gets bumped up (previous years accounting showed 2017 as the year where payouts finally match revenues).
According to the latest trustee report, 2053 is the year where full scheduled payments may be impacted. But again, every year the trustees produce their report, the margin from the current date increases.
The scare is a manufactured one, a campaign of Wall Street making to get their grubby hands all over lucrative administrative fees for such a regulated, bureaucratic alternate privately funded looting.
Dave Kopel, research director at The Independence Institute, has a very different take. No surprise since the institute is a "market-oriented" organization funded in part by the rightwing Castle Rock Foundation, a creation of the Coors brewing dynasty based in Golden, Colorado.
From 1999 to 2002 (last available data), the number of "programming" jobs in the U.S. earning on average $64,000 fell by some 71,000. But jobs held by application and system software engineers earning on average $74,000 increased by 115,000. Thus, even as it increases the number of IT jobs, global sourcing of software and services changes the nature of IT jobs, moving them up the skills ladder and diffusing them throughout the U.S. economy.
First, basing conclusions on an incomplete dataset is foolhardy. The quoted numbers do not capture the complete status of affairs. Much work in IT is done via contract/consultancy and those job losses arn't reflected in the numbers listed. If Fortune 500 companies replace domestic consultants with those working for offshore vendors, it really won't register in those quoted statistics. But it's been happening on a grand scale - as I type this, I am surrounded by ~500 offshore visa workers.
Numbers aside, there is a larger theme that Ms. Mann and others of her ilk neglect - if lower end "grunt" positions are being snuffed out in lieu of higher, "up the skills ladder" posts, then shortly, in a few years, both ends will inevitably be filled in such capacity. Where, pray tell, do qualified IT "engineers" earn the experience and prove their mettle? By toiling on systems bottom-up and then gaining an appreciation and understanding of complex system underpinnings. Or am I to understand that these ranks are now to be filled entirely by MBAs and sociology majors? Young folks are choosing alternate career paths, heeding the alarms that the parents and older friends send their way.
... Java is a tool, and in the hands of any gifted programmer, it can be used to craft quality software.
Java, the language, sucks, but yet has made huge inroads into commercial realms, supplanting COBOL and other languages as the language of choice for business applications. And it's a shame, as there are loads of shortcomings, that offset the advantages of Java and the JVM deal:
Sun's dictatorial control of standards as has been previously detailed. I believe it's the Win/Unix client/server setups that influences decision to develop in Java, both for business software units and third party software vendors selling wares to such customers. In *nix-less shops,.net or whatever the Micro$oft platform dujour is called these days, and Java may not flourish there.
Too resource intensive. Running a mini-OS VM on top of another OS is never going to be a performance maven. Java applications on both client and server suck in this regard. Huge memory footprint, excessive startup/load times, and measurable delays in graphic intensive applications plague this beast bad.
Serious issues with threading prevent it from serving for any serious server workhorse. No doubt, talented engineers are still trying to crack this nut, but threaded Java applications pushing large chunks of data about are very susceptable to insidious behavoir, depending on the machine architecture and other system software instances mix.
The natural handicaps built into the language, that can make for inelegant and unflexible solutions. Say what can be said about Perl, Python, C, Lisp, etc., but those tools are remarkably more expandable and resilient when it comes to possible solution spaces. Also, forcing one to treat everything as an object, as has been written by others, is a limitation, not a benefit.
But the programmer != the tool. It might make it more difficult, or more lines of code, or more kluginess, but a talented codesmith can work with primitive tools too.
Turn based strategy where you strive to be the one and true God over all the land. Steep learning curve, cheesy graphics, complex game startup instructions and foreign spelled names can make it difficult to get into, but once you do, it's an incredible game, if you're into that sort of strategy thing.
Slashdot Mirror
While it's been nearly 5 years since I toiled in COBOL, I can assure you that much of the information infastructure you deal with on a daily basis still runs on legacy mainframe hardware with COBOL programs being fed your charge card data, airline reservations, utility usage, pharmaceutical claim adjudications, etc....
True. Or the "hire" would be at a rate of 50-60% of what that same programmer made previously. I still get soliciations for mainframe COBOL work and the rates and salaries advertised to me are an absolute joke.
Well, code is code, but I would caution that:
Most of the Y2K effort focused simply on alleviating eventual issues with two digit dates by "windowing". No expansion of existing database fields -- as much of the processing in legacy world on a fixed column basis, and lengthening the field was considered "out of scope" -- just a simple if statement to test if it was the 20th or 21st century. And regarding documentation, you're being glib, right? As staffs are downsized, support and application teams siphoned off to India or replaced by imported non-immigrant visa holders, documentation, which never was a top priority, has been given even shorter shrift.
A rather naive assertion. In legacy systems much of the business logic is embedded deep within the bowels of the code. There may be a "business analyst" who is the overseer, but they are totally reliant on somebody else who can actually read code. And it will be far from straightforward, even for a gifted wizard, as the code in question may be decades old, and littered with patches and interfaces placed on top of all the cruft.
...when using your iPhone keyboard.
And a jailbroken (not necessary to "unlock" to "jailbreak") iPhone can indeed perform terminal functions, including ssh. Of course one may not wish to do that their phone, but the capability does exist.
As far as typing on the keyboard, I've had no problem, though I will admit that I'm not as fast as I used to be with Grafitti on the old Handspring PDA, but I don't believe that's because my tapping isn't nimble enough, just that it seems to second for the characters to pop up on the display. Haven't gotten fast enough to see if my outracing the buffer drops too many characters.
Article bangs on the "mighty mouse" as not really being a 2 button mouse... ...while I am no fan of it, I recently hooked my Mom up with a new IMac and played with the mouse and the button on the side does right click and the knobby deal in the middle acts as a scroll wheel, at least it worked for me... ...and on my MacBookPro two fingers on the pad can accomplish same functions as a 2 button mouse...
I own both titles ("Rails Recipes" by Chad Fowler) and IMO neither does a great job -- there's nothing in this book not already covered by the definitive DT/DHH Agile Rails Development book. About the only redeeming value was the information on Mongrel and the detailed instructions to get Rails installed and running on all the different platforms.
Speaking of which, though, the devoting of a good chunk of paper real estate to installation, seems to be space better left for meatier topics. Especially on a topic that changes significantly on a monthly basis -- it would seem that for a book, it would be more prudent to focus on matter not so ephemeral, knowledge that would arm and equip someone learning Rails to handle any task or illustrate more advanced techniques a web developer wishes to accomplish.
Unfortunately, I've plunked down money for a bunch of hardcopy books on AJAX and the new fangled javascript tidings — yes, I know I could find most of the requisite documentation online and/or I even question the silliness of amassing a library over a simple API call and a few demonstrative examples. But if I were to choose one book to buy or keep on the subject, this would be the one, easily.
Why? Well, because the author takes a problem centric view after a basic tutorial (i.e., how to handroll your own remoting, simple code examples). Then, all the things you can do with the tools are detailed, within a templated question and answer framework, and unlike the reviewer here, I appreciated the inclusion of all the URLs so I could research further. Also, a big part of learning anything is just getting the terminology down, so that those can serve as "keys" for subsequent knowledge acquisition. Also, the author doesn't seem mentally tied down to a given platform (take note .NETers and Rubyists) and explains things from a purely algorithmic perspective.
This is a worthy title for anyone wishing to expand their AJAX knowledge, though if you're totally comfortable with online discovery, you could forego it.
Are these quotes correct — that Gates Foundation only gives away 5% of its worth?
But there is a dynamic at work here, namely that since "American" firms have invested so much (money, resources, strategy, time, etc....) in offshore vendors and importing NIV programmers they have created a defacto dependency on the paradigm. As they've chased Americans out of the field, in preference of a cheaper foreign factory approach, they now are much more reliant upon foreign engineers and programmers. Most of my colleagues have moved on to other career fields or they simply are hanging on as SMEs, marking the days to retirement. It's no wonder that computer and engineering student enrollments are declining -- there'll always be young Americans who answer to a calling despite potential career conditions and ramifications (i.e., see teaching), but statistics are now bearing out that the majority will pursue a more fruitful career path, both in terms of short term financial reward and long term job stability.
Ironically, or comically, or tragically (depending on your particular perspective!), from what I understand from conversing with friends who are directing such offshore/NIV programmer teams, the offshore vendors don't seem to acknowledge the great gift bestowed upon them. Instead, they've fouled it up, focused entirely on short term profits, managing their operations like multi-level marketing schemes. Shuffling workers to maintain a subserviant force, yet failing and leaving core systems of our largest companies in a sordid state of disrepair.
Vaguely written rants laced with trendy buzzwords and university eggheads flaunting their scholarly beaks at plebian programmer tools aside, let's look at why LAMP has been and will continue to be a viable web development platform.
First, I've coded on just about all platforms, from COBOL, REXX/CLIST and Assembler on IBM mainframes to C on Unix boxes to LAMP to Ruby (including some RoR apps). And, code is code — in the hands of an unskilled practicioner, the product is going to be crap no matter what the tool. And a gifted artisan can craft a masterpiece with nearly any tool.
There's a great deal I detest about PHP. But, any language that I've toiled in for over a few years in writing relevant legacy code/enterprise applications/dynamic web software shows its unsavory side. No such thing as the one true programming language exists — they're all just tools, and just as they have their selling points that shine, they all suck in some sense of matter.
Anyway, here's a short list of why LAMP is good.
Having laid a case out for LAMP out, let me share some concerns about future LAMP direction:
"written in COBOL": 43,100
"written in REXX": 809
"written in CLIST": 168
"written in scheme": 34,900
"written in RPG": 700
"written in FORTH": 10,900
"written in objective-c": 26,700
"written in WFL": 5
"written in tcl": 106,000
"written in bash": 24,000
"written in korn": 480
"written in smalltalk": 20,400
And finally...
"written in curses": 40
Or is it suited for single platform (Win OS) only?
Multiplatform development has been wildly successful for Blizzard, it would profit Civ IV.
I've also had the opportunity to train mainframers in shops where MVS platforms were displaced by *nix based platforms. So, here is a subject that, no doubt, I can speak about:
The major factors/differences:
First, most of the mainframer programmer contingent has been moved offshore or is being done by NIV programmers. Really not much of a career path here, but OTOH, a great deal of critical systems (charge card processing, airline reservations, utility company systems) are still coded in MVS COBOL/DB2 (or IMS, a hierarchical mainframe database platform for IBM MVS). To convert these systems means you need to be able to understand these systems, and please don't give me a business analyst -- the days of their expertise are long gone, and the metamorphisis of systems over time means business knowledge is embedded in the code.
Mainframers don't get GREP. I've tried so many ways to impart this wonderful tool, but all I get back is puzzled stares and bewilderment, for anything more complex than what could be accomplished with a non-regex, or simple wildcard search.
Globals. This is something that put me aback 6-7 years ago, when I made the leap into Unix programming, and traded C/REXX/CLIST for C/Perl/etc... COBOL is structured into divisions and all your data declarations are laid out and globally accessible. Though many COBOL systems are quite complex, with a "program" actually being a driver for a whole hierarchy of 20-40 sub-programs, and the necessity to restart at a given point in processing can make things quite complex.
Approvals, checkoffs, signoffs, and procedures. They're largely absent in the Unix (and most webdev work) world, but mainframers have grown accustomed to reams of authorization and approvals for even simple changes. Lead times of a week or more, along with VP signoff, QA signoff, user group signoff, fellow developer signoff, etc.... Even getting a downstream system to agree to test changes may take a formal request process and budgetary allocation of thousands of dollars. This is probably the biggest divide, and future schisms will be prevalent, as data center leadership trys to impose this kind of checks and balances on developers not accustomed to these obstacles. IBMs trouble and difficulty in the web server world offer a prime example -- business being told that it'll take 3-4 months to get a server online, and folks who know better just can't understand that.
Lack of user tools. A big part of what I did as a mainframer was building tools, using BTS and File-Aid to allow developers and testers to create their own test bed and automate the test process. On Unix side, the tools come with the OS, and awk, Perl, and all the other CLI goodies make automating testing a snap.
File in/File out vs. piping. Mainframers have a tendency to see everything as file-in/file-out. In a way so do *nix coders, but a seasoned *nix programmers sees the tools all being able to feed eachother. Rather than step1 filein fileout, step 2 sort filein, out fileout, step 3 filein, reportout, etc...
On the age thing, most of the really skilled mainframers now, like myself, do Unix or migrated to Java. Others are awaiting retirement, or head over to six sigma teams, business analyst roles, or seek refuge in management, escaping the axe that clears the way for the offshore coder.
Paper over softcopy. Got to have that printed listing, and the sticky notes (and before that, paper clips). I still remember a senior manager telling me when I first broke in how his appraisal of a programmer was how many fingers he needed to act as placeholders when he perused a program listing.
http://zazona.com/ShameH1B/JobDestructionNews.htm
In a recent newsletter I wrote about a new corporate plan by Honeywell that some of their executives called a "Census Adjustment". Their cutsie corporate terminology is just another way of describing their new policy of replacing U.S. labor with cheaper foreign labor. I equated Honeywell's "census adjustment" to a corporate policy of "ethnic cleansing".
Since that newsletter was published I have received credible
information about several of the specifics of the Honeywell plan. The following information may seem like a spoof, but I assure you that it's no joke and nobody at Honeywell will be laughing as of July 1st.
DISCLAIMER: Although this information contained in this newsletter is from a credible source, there may be some factual errors. I have no way of independently verifying any of these factoids below.
***** Dictionary of terms used by Honeywell corporate executives
*****
Learning the dialects used by the corporatists can help us understand how they view the world. These are a few terms that I learned by studying information from Honeywell.
Census Adjustment: mass replacement of higher priced American employees with lower cost foreign employees. They don't make a distinction between foreign workers that come to the U.S. on H-1B/L-1 visas and workers that are in offshore positions. In most cases the foreign workers are high-tech workers from India or Eastern Europe. This term
is going out-of-favor among Honeywell executives because so many employees made derisive comments and jokes about it.
Globalization: the use of workers as a global commodity to lower cost. This term can be used interchangeably with "census adjustment".
Globalized engineers: usually used when referring to foreign engineers
that come to the U.S. by using H-1B and L-1 visas, but it can also be
used to describe overseas engineers that work for Honeywell (the exact
meaning depends on the context). The phrase is a clever code-word that
corporate execs and HR lap-dogs use for "Cheap engineers".
Infill - the process of filling job positions with workers. There is no
distinction made between the hiring of new workers or the transferring
of workers from one Honeywell location to another. "Infill" is a trendy
term that is very popular with borks and HR departments.
----- Honeywell's Plan for Census Adjustment by Globalization -----
Honeywell executives have decided that revenue spent for engineering
must go below 15% of their total expenditures. In order to cut costs
they will "globalize" their engineering departments. This globalization
process will focus on cutting the cost of labor by using the following
methods:
* Replacing current Honeywell workers with L-1 visa holders. These L-1
visa holders will come mostly from Russia, Czech Republic, and India.
* Whenever possible all positions in engineering and its support
functions will be outsourced to overseas locations.
* All new IT jobs will be required to be outsourced offshore.
* No external hiring will be allowed, and transfers of employees within
Honeywell will be discouraged until the job terminations are complete.
* Open job positions will be "backfilled with globalized engineers at a
lower cost." Managers that refuse to go along with this process will be
replaced with more cooperative ones.
* American subcontractors are currently being eliminated and replaced
with foreign companies.
The following factoids pertain specifically about Honeywell's Component
Engineering in their Commercial Electronic Systems (CES) on Deer Valley
Road in Phoenix, Arizona and Aerospace (AES). Similar tactics will be
used at other Honeywell locations.
>> Honeywell CEO, Dave Cote, has ordered Roman Jamragowiecz, VP of
Engineering, to globalize 25% of AES engineering. It is generall
Problem with that statement is that those Indians who are benefiting from the tide of outsourcing, are not those in poverty, but the upper crust of a still rigid class society, that still adheres to the caste system, despite proclaimations to the contrary.
At least this has been the firsthand experience I've had in training offshore replacements -- that these folks were all mostly from rich, well-to-do families, and were sheltered from life, having to call a maintenance man to change a light bulb.
However, my powerbook purchase brought the joy of computing back into my life. I frequently read the comments of those who decry the overpriced Mac when compared to constructing your own box (which I used to do - and I still believe that a Mac is equivalently priced with Dell/Gateway/IBM hardware, when all things are factored in properly) and while true on one level, it misses the mark on the total picture. That is depending on your interests and usage desires:
Life got a lot simpler when I replaced my wife's Win XP box with an iMac. No more weekly degunk sessions, antivirus, malware consternation and constant admonitions for her to be vigilant about keeping her machine clean were necessary. And she took to it like a charm -- things were unfamiliar (and still sometimes she stumbles on a Win -> Mac how-to-do question) but she is enthralled with it now and spends more time on email/web browsing than she ever did on the Win box. The iLife/iPod deal is just gravy and really we've experienced firsthand on how much more hassle-free life became after the Mac switch.
So, I'm not swayed by saving a couple hundred dollars. Just like I wouldn't buy a Kia or a Yugo, I'm not going to opt for a bargain basement PC over a quality machine like a Mac. No, it's not perfect and presents its own set of flaws, but at this juncture, it seems to be the product of greater quality for me.
Despite the fact that I like the folks on my team and my immediate management have treated me OK, I just dread the act of going into work and really don't like the role I was assigned. While it's no sweatshop, we're dreadfully undermanned (due to mergers and consolidation, and general cluelessness on the part of management).
Why am I departing? Well, there are a bunch of reasons and they weigh heavier than the impetus to stay, including the big fat paycheck that I could just go through the motions and keep ringing the bell every 2 weeks.
Command + `
Will cycle thru the windows in a given application, just like Command + Tab will cycle through all your open applications.
However, the past 10 years has seen M$ firmly implant itself in the corporate desktop suite and it would take the next ten years to dislodge it. Not just the M$ Office applications (REAL programmers don't use spreadsheets or even a word processor...), which for many users, there is no suitable substitute -- I'm looking at the parade upon parade of dorky, kludgy, awkward third party Windows applications that now have pervade the business environment, both in IT and general business users. Another strong irony is that a good bit of this stuff is now Java based, which was touted as "write-once, run anywhere" but totally dependent on Windows to run. Either via custom Windows desktop client software, or piggybacked on MSIE or through proprietary database requirements that alternative OS usage was never ever factored in by the vendor selling. Go stroll through the software suite of any large corporation (most all of which are IBM clients) and it's heavily laden with gooberish offerings totally reliant on the Windows platform. Even the server software will have frontends unusable without IE and/or Windows.
Even if the software and hardware fulfilled the bill of need for business usage, users would still resent and resist change from familiar work patterns. This will always occur, even if the change is an obvious beneficial move of immense proportions. To a business user, even those computer savvy, it's a learning challenge hoisted on top of an already filled worklog platter. A mandate has to come down from above, that a change has been blessed and sanctioned, and that there is no choice in the deal.
In my view, most firms would profit hugely from a switch, at least those entities not dependent upon special software not available in alternative OS (including Mac OS X along with Linux) -- more stable, less virus/malware/spyware concerns, less employee "goofing off" factor (most games are Windows only), etc.... ...but then, expecting a large company to behave in a cost sensible fashion is folly, as they'd rather pay someone else to guarantee the deal or take the blame when things go south... ...at the shop I presently work, I've heard the network and system support engineers (and their managers) bemoan the existence of Linux and FOSS at our company, that they'd much prefer it all was HP/IBM/MS stuff, so they could simply "open a ticket" to the vendor to fix a problem......and it fits in with the "let's move it to India" instead of hiring a few good people and letting them manage the systems... ...but then I've drifted into another rant here...
Good Gates, how could this comment be moderated down to -1. Agree or disagree with the poster, but valid points are made.
Read through Mr. Spolsky's web site and see that he doesn't acknowledge free software/open source at all other than sterotypical blanket bromides.
Social Security wasn't created to be retirement program. It was put into effect to keep old folks from dying in the streets, and evaluated on that criteria, it has been very successful.
And fear moners and profit mongers nonwithstanding, social security is still in solid health. By the most pessimistic of predictions, the program is slated to take in more revenue than pay out for another 15 years. And every year the CBO and Social Security Trustees release their report, that number gets bumped up (previous years accounting showed 2017 as the year where payouts finally match revenues).
According to the latest trustee report, 2053 is the year where full scheduled payments may be impacted. But again, every year the trustees produce their report, the margin from the current date increases.
The scare is a manufactured one, a campaign of Wall Street making to get their grubby hands all over lucrative administrative fees for such a regulated, bureaucratic alternate privately funded looting.
Dave Kopel Debunked
First, basing conclusions on an incomplete dataset is foolhardy. The quoted numbers do not capture the complete status of affairs. Much work in IT is done via contract/consultancy and those job losses arn't reflected in the numbers listed. If Fortune 500 companies replace domestic consultants with those working for offshore vendors, it really won't register in those quoted statistics. But it's been happening on a grand scale - as I type this, I am surrounded by ~500 offshore visa workers.
Numbers aside, there is a larger theme that Ms. Mann and others of her ilk neglect - if lower end "grunt" positions are being snuffed out in lieu of higher, "up the skills ladder" posts, then shortly, in a few years, both ends will inevitably be filled in such capacity. Where, pray tell, do qualified IT "engineers" earn the experience and prove their mettle? By toiling on systems bottom-up and then gaining an appreciation and understanding of complex system underpinnings. Or am I to understand that these ranks are now to be filled entirely by MBAs and sociology majors? Young folks are choosing alternate career paths, heeding the alarms that the parents and older friends send their way.
Java, the language, sucks, but yet has made huge inroads into commercial realms, supplanting COBOL and other languages as the language of choice for business applications. And it's a shame, as there are loads of shortcomings, that offset the advantages of Java and the JVM deal:
But the programmer != the tool. It might make it more difficult, or more lines of code, or more kluginess, but a talented codesmith can work with primitive tools too.
Turn based strategy where you strive to be the one and true God over all the land. Steep learning curve, cheesy graphics, complex game startup instructions and foreign spelled names can make it difficult to get into, but once you do, it's an incredible game, if you're into that sort of strategy thing.