Yeah -- and why doesn't vasoline rhyme with gasoline? Tell me that!
This Erroneous Life -- A bit-smasher remembers...
on
Gnarly Error Messages
·
· Score: 1
The Burroughs 1714 small business system, circa 1975:
There is an incongruency between your intent and mine...
The console on this box took only 2-letter commands, I knew them all. Trying to demonstrate an "Unknown input" error message to a novice, I typed "shit". The system halted so I rebooted and retried. Same result. 3 days later tech support informed me of an undocumented command "Set Halts (i.e. SH).
By the way, I've always used the same command to test the unknown input scenario on all systems ever since then and have not run into trouble. Some committee should designate a word for this purpose, to avoid launching consequences when you're only trying to test. Otherwise, I've discovered a solid reason to have taboo words in a digital society. (Word police -- take note!).
Donald Knuth (think mathematics, here) is reputed to have this message on his office door:
I am sorry, due to faulty induction, the number you have reached is temporarily out of service, please try again at another time.
I once wrote a batch input report program with error messages for data entry clerks. I put out the simple text "Invalid Account". A new clerk ran up the next day and asked "How did the Account get sick?". Emphasis on the first syllable (invalid) had confused her. I didn't have the character space to expand the text, so I substituted "No such Account" in the same letter count and saved both our jobs.
I forget which system, but I truly did recieve a message "Wrong error". The workaround was to make a different error which re-synched the parser.
At one point some IBM mainframes had a message code "IBMBEER". Must have been been a misspelling of IBMBERR, whatever that meant.
For internal program usage, a lot of programmers use 0 as a success code and -1 for error. Thinking hex, I came up with a better error code, can you?
You forget to tell us anything about yourself. Have you managed anything? What sort of people managed you? Have you worked as a coder? A trainee? A tester? How many children do you want to have? What sorts of issues do you have strong opinions on? Tell us about your work experience.
It doesn't make sense to give advice without individual knowledge unless everybody should go to the same school and live the same life.
Facts I Know That Might Help You:
There is a reason that the large and successful software companies don't emphasize process over talent.
Have you ever developed software under a process system? In the majority of cases, the process adds little or detracts.
Pittsburgh winters are terrible.
The programming field is being flooded by the weak economy and there is a cap on salaries, implemented by the flow of H-1B temps from third world companies. Software development is becoming a third world career with third world living standards. Globalization in action.
On the other hand, programming has become credentialist, now that credentials (degrees) are commonly available.
There is a complete ecosystem of bureaucratic mid-level managers in large engineering organizations that suck up resources by being talented in writing reports and making presentations to upper management, organizing vast armies of developers and engineers based on charts and diagrams. Many of these people can't produce a thing. Does this mean we need you to learn your craft and replace these drones, or you should run like hell and avoid becoming one of them?
On the other hand, there are and have been far too many "Software Managers" who simply do not know what software is. I am serious. You are already far beyond that, so you really could make a positive contribution.
Process and Software Engineering management techniques often get trumped by the true tools of project management: a) The budget, and b) The schedule. Anything that tries to buck either of these "Force Majeure" entities gets squashed.
Once you get promoted up past the level of software development manager, your software development and software engineering skills become almost irrelevant. Perhaps you'd prefer to get an MBA?
Wise people have learned that the decades-long effort to produce the technology that will be beyond programming has proved fruitless and we will need humans doing software development forever. Yeah, and wise people once knew the earth was flat. The future is unpredictable.
There are more people who have become millionaires in Real Estate than in Technology. This is a criticism of our economic system, by the way.
Microsoft is the 2000 pound gorilla in software. This will impact your life even more than it has.
The climate in Redmond is quite nice.
If you're already unemployed, going to school is a pretty good idea, if you can afford it.
Try to remember the little guy, the rest of us might end up working for you.
Software Development = Mathematics + Organization + Problem Area Knowledge.
Perhaps the worst effect of the excess of H1-B visas is that the lowered income of software engineers is discouraging college students from majoring in computer fields, slowing the country down in the long run.
In a free-market economy, there is no such thing as a shortage, just a rise in prices. Bringing in cheap imports just discourages domestic production, whether it be of steel or software engineers.
--
Don't believe me? okay, how about this Wharton School
article.
I've already seen want-ads requiring experience in C# programming -- no other knowledge will substitute! Managers do not know how to recruit and keep software engineers, so they punt and try to hire cheap workers with the exact precise experience in the exact job they are hiring for.
The root problem is probably that managers don't have enough experience in software development themselves. --
If they could shift the work to India, they would. It's much cheaper than hiring H1-B workers.
I personally know 3 H1-B programmers who were laid off by their first employer and had to scramble around and find a job quickly or be deported. They complained to me about being "indentured servants" but I didn't understand at the time.
You can figure out that they didn't bargain too hard when applying for their next job, either.
Those few people we really need to bring in should be given green cards or have similar workers rights. It's a matter of respect for them and for our own workers.
You are also missing his main point. The difference between domestic and H1-B workers is price, not quality.
There is no advantage to having American companies get the business: When they are just wrappers around foreign countries. When foreign workers get the professional experience and skills. When the money is repatriated overseas. When these skilled people are eventually sent back home. When skilled American programmers are unemployed.
Perhaps the worst documented effect of the excess of H1-B visas is that the lowered income of software engineers is discouraging college students from majoring in Tech fields, slowing us down in the long run.
In a free-market economy, there is no such thing as a shortage, just a rise in prices. Bringing in cheap imports just discourages domestic production, whether it be of steel or knowledge workers. --
The report is hard to read, but his essential point about H1-B's is true. They are not the best and the brightest. They are, on average, average. And his salary information backs him up. You can still use salary numbers to make an analysis if you compensate for the H1-B discount.
The best and the brightest free-market people are making well over $100K. Discount that by the 33% or 19% he quotes (from different reports), and you still get $66K or more. The H1-B's are getting paid in the $40K range. They are paid much below the best and the brightest recruits the H1-B program was meant for.
Not to mention the whole injustice of paying foreigners less for the same work by eliminating their freedom to compete in the marketplace.
Ship/NoShip rules have to be relative rather than absolute. The nature and severity bugs in the software the customer is using right now must be taken into account.
If you've discovered 4 "showstopper" bugs in the release 1.0 at the customer sites, and you've got a new patch that fixes 3 and adds 1, you usually have to ship the patch with 2 "showstopper" bugs in preference to the 4 baddies. Neither customers nor managers will boycott the buggy competition while you slowly grind out perfection. That "perfect" space shuttle software was awfully expensive to produce and took a very long time.
It's worse. You think you've got 2 bad ones in the patch, and you think you've got 4 bad ones in the field, but you could be wrong.
Bug severity isn't just program behavior. If you've fixed the software so there are more internal checks and better error messages, you may have to ship this diagnostic version to fix the bugs. Hopefully, you have prevented this embarrassment. But maybe not.
The decision to ship may be fed by quantitative factors, but the decision requires human judgement. But you knew that.
A more typical problem is that written specs and written quality standards usually do not exist. So how do you quantify the degree of conformance to the specification? Sometimes I can cut the Gordian knot by asking "Will somebody call us up to complain, or ask for support?". Suddenly, everybody agrees it's a bug (or it isn't). Users will complain about "features" they don't appreciate, but then, they should.
Sharing a resource doesn't mean Communism, which is one-man rule over a one-party withered-away State that owns the means of ALL production, not just particular pieces software in a sea of proprietary code.
The difference between Visual (windowing) UIs and Voice UIs isn't just the front end of the UI. It's the whole engine.
I've tried navigating through menus and icons using voice tools. Very clumsy. A natural voice command would be "Change that last sentence to bold, 10 point". Visually, that's a mouse-down, drag, and mouse-up, a click, and a list selection.
The only practical way to make these more-intuitive interfaces is with a voice-oriented scripting language. The now-obsolete Dragon Dictate had a scripting language that did exactly this.
A round trip is two round trips! From me to you means going up to the satellite and back. Back from you to me is another two trips. So the subjective round trip time is a full half second for a game player, or the user of an internet phone. This assumes we're both on earth. The speed of light is 299,792,458 meters per second, according to this treatise. The altitude of a geosynchronous orbiting satellite according to this byte article is 22,238 miles. They also have a longer article discussing the same issues we covered here, and the alternative satellite systems.
Performing the calculations, (22,238 miles X 1609.344 meters per mile)/(299,792,458 meters per second) X 4 trips =.47751 seconds.
See this Byte article for further discussion of TCP and latency. Also see this student article for a discussion of alternatives.
I know several smart professionals, a couple in Finance, another a professor in Poly Sci, and one with a Ph.d in Computer Science, who simply don't want to bother with a command prompt, or troff formatting macros, or even with learning to configure Windows. They're very busy, their minds are worked to the limit with their jobs, and they don't need the hassle of learning how a computer works. They can't change their oil, either. --
Slashdot Mirror
Yeah -- and why doesn't vasoline rhyme with gasoline? Tell me that!
The console on this box took only 2-letter commands, I knew them all. Trying to demonstrate an "Unknown input" error message to a novice, I typed "shit". The system halted so I rebooted and retried. Same result. 3 days later tech support informed me of an undocumented command "Set Halts (i.e. SH). By the way, I've always used the same command to test the unknown input scenario on all systems ever since then and have not run into trouble. Some committee should designate a word for this purpose, to avoid launching consequences when you're only trying to test. Otherwise, I've discovered a solid reason to have taboo words in a digital society. (Word police -- take note!).
Donald Knuth (think mathematics, here) is reputed to have this message on his office door:
I once wrote a batch input report program with error messages for data entry clerks. I put out the simple text "Invalid Account". A new clerk ran up the next day and asked "How did the Account get sick?". Emphasis on the first syllable (invalid) had confused her. I didn't have the character space to expand the text, so I substituted "No such Account" in the same letter count and saved both our jobs.
I forget which system, but I truly did recieve a message "Wrong error". The workaround was to make a different error which re-synched the parser.
At one point some IBM mainframes had a message code "IBMBEER". Must have been been a misspelling of IBMBERR, whatever that meant.
For internal program usage, a lot of programmers use 0 as a success code and -1 for error. Thinking hex, I came up with a better error code, can you?
It doesn't make sense to give advice without individual knowledge unless everybody should go to the same school and live the same life.
Facts I Know That Might Help You:
It WAS that guy Tony from New Jersy -- he just cracked into the South African police computers to set up his patsies...
In a free-market economy, there is no such thing as a shortage, just a rise in prices. Bringing in cheap imports just discourages domestic production, whether it be of steel or software engineers.
--
I've already seen want-ads requiring experience in C# programming -- no other knowledge will substitute! Managers do not know how to recruit and keep software engineers, so they punt and try to hire cheap workers with the exact precise experience in the exact job they are hiring for.
The root problem is probably that managers don't have enough experience in software development themselves.
--
I personally know 3 H1-B programmers who were laid off by their first employer and had to scramble around and find a job quickly or be deported. They complained to me about being "indentured servants" but I didn't understand at the time. You can figure out that they didn't bargain too hard when applying for their next job, either.
Those few people we really need to bring in should be given green cards or have similar workers rights. It's a matter of respect for them and for our own workers.
You are also missing his main point. The difference between domestic and H1-B workers is price, not quality.
There is no advantage to having American companies get the business: When they are just wrappers around foreign countries. When foreign workers get the professional experience and skills. When the money is repatriated overseas. When these skilled people are eventually sent back home. When skilled American programmers are unemployed.
Perhaps the worst documented effect of the excess of H1-B visas is that the lowered income of software engineers is discouraging college students from majoring in Tech fields, slowing us down in the long run.
In a free-market economy, there is no such thing as a shortage, just a rise in prices. Bringing in cheap imports just discourages domestic production, whether it be of steel or knowledge workers.
--
The best and the brightest free-market people are making well over $100K. Discount that by the 33% or 19% he quotes (from different reports), and you still get $66K or more. The H1-B's are getting paid in the $40K range. They are paid much below the best and the brightest recruits the H1-B program was meant for.
Not to mention the whole injustice of paying foreigners less for the same work by eliminating their freedom to compete in the marketplace.
--
Ship/NoShip rules have to be relative rather than absolute. The nature and severity bugs in the software the customer is using right now must be taken into account.
If you've discovered 4 "showstopper" bugs in the release 1.0 at the customer sites, and you've got a new patch that fixes 3 and adds 1, you usually have to ship the patch with 2 "showstopper" bugs in preference to the 4 baddies. Neither customers nor managers will boycott the buggy competition while you slowly grind out perfection. That "perfect" space shuttle software was awfully expensive to produce and took a very long time.
It's worse. You think you've got 2 bad ones in the patch, and you think you've got 4 bad ones in the field, but you could be wrong.
Bug severity isn't just program behavior. If you've fixed the software so there are more internal checks and better error messages, you may have to ship this diagnostic version to fix the bugs. Hopefully, you have prevented this embarrassment. But maybe not.
The decision to ship may be fed by quantitative factors, but the decision requires human judgement. But you knew that.
A more typical problem is that written specs and written quality standards usually do not exist. So how do you quantify the degree of conformance to the specification? Sometimes I can cut the Gordian knot by asking "Will somebody call us up to complain, or ask for support?". Suddenly, everybody agrees it's a bug (or it isn't). Users will complain about "features" they don't appreciate, but then, they should.
--
So, what happened to pSOS ??
--
Sharing a resource doesn't mean Communism, which is one-man rule over a one-party withered-away State that owns the means of ALL production, not just particular pieces software in a sea of proprietary code.
We don't even have a Gulag!
--
Mr. Dickinson is not the problem. The Law is the problem.
--
The difference between Visual (windowing) UIs and Voice UIs isn't just the front end of the UI. It's the whole engine.
I've tried navigating through menus and icons using voice tools. Very clumsy. A natural voice command would be "Change that last sentence to bold, 10 point". Visually, that's a mouse-down, drag, and mouse-up, a click, and a list selection.
The only practical way to make these more-intuitive interfaces is with a voice-oriented scripting language. The now-obsolete Dragon Dictate had a scripting language that did exactly this.
Scripting Rules!
--
Performing the calculations, .47751 seconds.
(22,238 miles X 1609.344 meters per mile)/(299,792,458 meters per second) X 4 trips =
See this Byte article for further discussion of TCP and latency. Also see this student article for a discussion of alternatives.
--
I know several smart professionals, a couple in Finance, another a professor in Poly Sci, and one with a Ph.d in Computer Science, who simply don't want to bother with a command prompt, or troff formatting macros, or even with learning to configure Windows. They're very busy, their minds are worked to the limit with their jobs, and they don't need the hassle of learning how a computer works. They can't change their oil, either.
--