Tech Worker Groups Boycott IBM, Infosys, Manpower
I was working for a "minority" company (two women) doing documentation and was billed at some absurd rate where I received 20-30% of the rate. When forced to do mandatory 50 hour weeks (a urination contest between my boss and her managers, NOTE: a 20% increase in output would NOT dent a 1.5 year backlog) I was paid straight time for the overage while the contractor collected double time. I could not protest as this would have left me unemployable in the Midwestern-type city.
When a thinking manager was asked how to cure the backlog, he replied, "Triple my trained staff." While he was being truthful, his candor got him moved to job where he could do no harm.
Once upon a time in a far away land I was pounding away at my Apple ][. I forgot to save and lost an hour and a half of work. That was the best mistake I ever made. Since then I have always saved, made backup copies, sent the text to myself on email, written a CD/DVD, saved to a thumb drive, and so on. An hour and a half was a very cheap loss to have, if I was forever safe thereafter.
Autosave still has not cured me. I will still CTRL-S every few lines. Even with autosave on CAD I will still do other saves. Still, my paranoia does save me.
Not so long ago, I discovered that several years of engineering files had been vanished. We had paper copies but still that loss was annoying.Turns out that I had made a backup of that file set and it was found in my home cache of "work" disks. I slept better.
Apple, Google Agree To Settle Lawsuit Alleging Hiring Conspiracy
The "class" is a bit bigger than the direct set of 64,000 affected. For most jobs, "reasonable and customary" was taken as the California wage which was then discounted for the folks NOT working in California. Working on the east coast, you would of course receive less than the folks in Silly Valley. And because your starting salary was artificially depressed, then you would of course receive a substantially lower sum over the span of your career. The one time I was given an actual raise of more than a few percent, I was moved out of my "salary band" and received no further raises. And folks wonder why efforts to promote STEM may fizzle out.
Born To RUN: Dartmouth Throwing BASIC a 50th B-Day Party
As a senior at Taylor Allderdice HS (Squirrel Hill) in Pittsburgh, I had my ONLY formal programming class, in BASIC. When I went to engineering school at Carnegie-Mellon, I was not required to take any programming classes, so I chose not to.
So of course my entire career has been spent using computers. I did use BASIC on my first job (HP 9830, dual cassette drives and a whopping 16KB of RAM), doing real-time data acquisition on large centrifugal compressors. I also wrote a resume as a series of PRINT statements in 1976. This resume was handed back to me in 1983 when I went to work at Penton publishing -- separate story. I have done a lot of CAD, structural analysis, software docs (issued 12,000 page of embedded systems compiler docs one year) and webwork. For another doc project, I hand-coded the help as .jsp. I was the doc person for a dozen or so developers. And to the chagrin of my daughter (a redditor) I sometimes hand code the corporate website.
Yes, BASIC started me on the road to ruination. 40 plus years later and I am still at it.
Your Car Will Tell You How To Hit the Next Green Light
Cars, people, and "automation" is a great recipe for more problems. As with the red light cameras, there will be bias in reporting the effectiveness of the solution. wrt the cameras, the number of red lights NOT run and tickets issued are listed as benefits. What is missing from the glowing reports is the number of accidents CAUSED . The deletion is allowed because the accidents happen before the light. "Oh, this is a separate issue," does not cut it when I cautiously stop and then get rear-ended by someone trying to make the light.
Rational behavior in software will not necessarily result in rational behavior in driving.
One In Ten Americans Thinks HTML Is a Type of Sexually Transmitted Infection
I left tech writing because I became disenchanted with what became increasingly fictional documents. Development rarely bothered including me in any meetings, so I never knew what had changed or even what was supposed to be new.
The kicker at one firm was a sterling developer who demanded -- nope, did not ask politely, that my references to the "host" computer be identical throughout the 150 page manual. I made the requested changes and the idiot developer reviewed the same manual -- yes, the one that had no corrections -- and I was fired because he could not read a date. He insisted that I ignored him when in fact, he was too stupid to realized he reviewed the "old" manual again.
So if developers are that slow, then I guess non-developers are less with it.
At my current workplace, I've outlasted ...
On my last job at a software company, I had eight bosses in my five years of employment. This includes some double counting when I had the boss again after a few years of gap. While in tech, the average tenure of a boss was under nine months in a long career. I do not regret leaving software.
Yesterday was my eleven year anniversary at a smallish manufacturing plant, doubling my time spent at any software firm. I still do a lot of CAD and some design, but now also do more management. I also do the website, high-level sales, customer support, and whatever else the boss does not have the time for. I check slashdot, reddit, and overlawyered.com among others for IP related issues. Those CAD sketches are also real IP.
How loud is your primary computer?
Correction first, Garde-toi du Jaseroque, mon fils! (per Frank L. Warren)
I can't hear the fan over my 2+1 sound system with the subwoofer which is blasting music from my 8,355 songs on Google Music.
Python Scripting and Analyzing Your Way To Love
Getting the first date is truly a matter of chance. Despite his massive efforts to "perfectly select" a viable companion, he had an effectiveness of approximately zero (88/[population of OKCupid] = ~ 0.00%. Even his 88 dates are vanishingly small considering the gross number of potential candidates he reviewed.
The real effort is in making/having the relationship last. While my wife and I are very different, we come from a compatible SES and religious philosophy. While she was humanities, I was engineering all the way. The kicker was that the night future spouse and I met, I was playing the rating game with another engineer, en francais. Wife to be heard that and the decision was made. As McKinlay discovered, sometimes a single parameter model does work.
Electrical Engineering Lost 35,000 Jobs Last Year In the US
Getting a PE license is dependent on working on a firm that still employees a PE. As a PE is expensive, this is becoming increasingly difficult to find. Companies will fire high salaried individuals. Yet another complication is that you have to stay employed at one firm long enough to get the time required to qualify. Frequent job switches (which always happen in engineering) make the goal of getting a PE still more elusive. At one SW firm, I had eight bosses in five years. I have not done the math, but the requirement of having a PE boss/supervisor may have declined to the point where getting a PE is not sustainable.
Users Identified Through Typing, Mouse Movements
I've seen that one before. Still, identification is a lot like a gait analysis of someone walking (or the pedal stroke analysis alluded to earlier). As a person, you will fall into identifiable patterns. You just have to think about how to identify those patterns. Measuring the timing between not so random button pushes (banging on the keyboard) is by no stretch of the imagination a difficult or complex analysis. Quoting Steven Wright, "No matter where you go, there you are."
However, if you can identify a pattern then this is just the first step toward spoofing that pattern. And so the battle for honesty and authenticity continues. According to George Burns, "The most important thing is sincerity. If you can fake that you've got it made."
Users Identified Through Typing, Mouse Movements
And this is a "surprising" result because...? Of course you develop patterns based on how "fast" you type. As a "some fingers" typist, my timing between key presses probably does not vary too much. It is easy to see how the time difference between key presses (based on the prior and following characters) and even some words can be predicted with a reasonable degree of accuracy. Thinking of these patterns like the "stripes" on a DNA scan you can easily do a pattern match to uniquely identify which set of keystrokes "belong" to you. This does not sound like rocket science as it is pure observation.
The technology is probably similar to the type of motion analysis done with most sports. As a committed cyclist, there are a number of tools to measure your pedal stroke (power, speed, position). Again, you can easily do a pattern match. Muscle memory is visible when plotted.
My only surprise is that it has taken so long for this non-astounding discovery.
Do You Need Headphones While Working?
As "the engineer" I have a private office. OK. It used to be porch until the area was enclosed. As headphones do not go over too well, I have a Creative 2+1 system with a sub-woofer. On occasion, when I am enjoying the music too much the boss asks for a volume decrease. Frequency response and quality of the sound system is better than what I would get with headphones. I only have 23 days of music on Google play.
Does Software Need a Siskel and Ebert?
I have spent my entire career dealing with "engineering software." So, yes it really does depend on what the intent of the review is. Consider for a moment, CAD software. Does the product perform as specified? It is "easy to use?" Well, first you must define, "Ease of use?" Does the software allow you quickly establish elaborate models that most users will never begin to understand (Think Design of Experiments, Optimization software, Finite Element Analysis, Electromagnetic Simulation, Computational Fluid Dynamics,etc.) and yes, this topic gets messy really fast. And this ignores the reality of converting the "Geometry" into a product through machining, assembly, material selection, and on, and on and on.
Or perhaps we should explore another software black hole, "web." Tools a professional would swear by an amateur would swear at. And what about content management? Can you imagine even beginning to explain why you need content management (to your grandparents)?
Even "entertainment" software gets messy. I have iTunes that has uploaded the bulk of my music to Google Play. Where I love the random feature of iTunes and how it actually tries to thread songs to a theme, Google Play has a lousy random algorithm. How do you simply quantify "bad" to an innumerate audience?
It is tough to be all things to all people for all topics.
45% of U.S. Jobs Vulnerable To Automation
I grew up in Pittsburgh and remember when the steel jobs just went away. The air was cleaner, but the economy was anything but "green." Fortunately the Pittsburgh has recovered but the jobs shifted to the massive medical/research/college community. A few year later, in Akron, a staunchly pro-labor town, the plants just stopped production. Many engineers proclaimed, "We're engineers, we're safe." I saw the had writing in the wall once and I escaped into technology, for a while. (The plant is now a brown field and the few engineering jobs at that company have moved elsewhere.) While at the plant, I learned a bit of CAD, QA, FEA, statistical QA, vibration analysis, programming, etc. My next move was into writing for the trade press, in the early days of PC-based CAD (mid 1980's). I got paid to write about all the topics previously listed AND I was also paid to play with computers. This gave me a lot of career flexibility, as opposed to the folk who had retired in place.
The task of moving knowledge-base solutions into engineering was dropped when early AI attempts fared poorly. But the success of Watson, should make every engineer quake. The "engineering problem" can be succinctly described as making the best possible stuff with the fewest resources, the least possible effort, and have a low failure rate. This sounds like a computer-solvable problem to me. The STEM crisis may be avoided, but many folks will NOT like the result. There will only briefly be STEM jobs, due to automation. However , STEM may be one of the few professions where the end goal is to put all the profession out of work.
What Marketers Think They Know About You and What They Really Do
I saw the page and all the "required" information and said NOPE. Somewhere I saw that with birth city, birth day and birth year this identifies 87% of the US population. I have been using fictional dates for a while, but this will only slow down determined folks. The price of the "deal" to provide that much information for what may be very little does not interest me.
What's Causing the Rise In Obesity? Everything.
There is also the other factor of the diet issue, EXERCISE. This has changed because of the new "nanny state" where kids are not allowed to play outside. One article in the UK told of how in their grandparents era, kids would ride their bikes (or walk) to a pond miles away, spend the day and then ride/walk back home. The parents were perhaps allowed to go to town (a still smaller circle). Now kids are lucky to be allowed on the street to go to end of their cul-de-sac. Most kids are confined to a yard, if that. Zero travel and limited indoor play equals low calorie burn. Fat is no surprise.
I am a dedicated cyclist and will regularly ride a short 34 (but quick) miles or so in about 2 hours with hills. For these rides I will drink a sports beverage but that still leaves a calorie deficit of 1,500 or so. I have learned to balance how much I ride with what I eat. Irony alert. I love the folks who will burn less than the calorie count of the sports beverage trudging on a treadmill, consume the entire beverage and then complain about the taste, all while violating the rule of burn more than you consume if you want to lose weight. My mantra is, "If you can complain about the taste, then you are not tired enough to NEED a sports drink."
Stop Fixing All Security Vulnerabilities, Say B-Sides Security Presenters
Disclaimer I have not read the paper.
Once upon a time I did software documentation for a fast moving product. I was never given updates and worked basically in the dark. One brilliant manager asked me to, "Document all the bug fixes for this product." There were over 2,000. At 15 minutes each that time span was a bit over the week I was given. Doing the math, this comes out to 12.5 40 hours weeks, uninterrupted. At half time -- a better estimate this would have been half a year. One week is not 25.
I requested a list of the bugs, sorted by priority. I was met with stares. I then said, "Until I get the list, I will work in strict numerical order until I get the list." The manager screamed at me, "But I don't want that." This time I replied, "I agree, but until I get the list from you I will do the work in numerical order, just so you don't yell that am not working." I never got the list and the random selection from the strict list was a nice demo of the types of bugs found. The end result was OK, but not by choice. Introduction done, but this was a similar problem. You need some guidance 'cause you cannot do everything.
With limited resources, fixing everything all the time is an infeasible task. Using a pure visual analogy, "fix the biggest hole." The problem is that as bad as people are at fixing, they are perhaps even worse at classifying. And assessing the potential damage of a "hole" is another part of the problem. You must also assess the likelihood of someone finding/using that hole. Add in the reality that each fix is time-sensitive and the time to fix a bug is all over the place, and you have a very real mathematical and practical mess. "What do we fix first?" is neither a short or an easy question to answer.
Paper: Evolution Favors Cooperation Over Selfishness
Another "proof" is in the book, Quiet: The Power of Introverts. In a sales situation, because introverts are NOT pushy (selfish) they will often lose that first sale. However, over time -- especially with a consultative sales model, introverts will outperform extroverts. Sales is a cooperative venture where you try to determine if your product will meet the customer's need. Introverts will listen -- a basis of cooperation, and then respond appropriately, because they heard what you had to say. Too introverts are more attuned to non-verbal cues (even over the phone). They will hear the pauses and hesitation and respond.
As such, introverts naturally follow a cooperative path. They prosper by helping others. Sounds like a winning strategy to me.
Why Your Users Hate Agile
I was once attached to a group doing an early flavor of CAD in the Cloud. I was THE documentation person for a dozen or so developers. I was writing the HELP as a series of JSPs, with just emacs as the authoring tool. I never got any notice of what had changed, I just saw some of the new stuff, which was fluid to say the least. Once, I was told, "Just look at the program," to see what had changed. Really, a dozen programmers changing everything and I had no notes at all? And at every single meeting I heard the twin refrain, "Don't change the docs, we have to localize it," and "The docs really s_ck." Which statement was true and what should I have done about it?
The kicker was that as a favor to users (as expected, the product was real bear to use), I created a cheatsheet in the form of an index. This was an alphabetical listing of the commands and each entry had a short explanation of what each command did and a showed a command stream with the most common options. All the command streams were cut-and-paste from an "approved" manual. This index sat on a boss's desk for about three or four revision cycles. If you count the number of real revisions, you have the first pass and then the second pass to "fix" bugs created by the first pre-release. QA was so backed up checking releases that they had not reviewed the docs in MONTHS.
Anyway, when the boss finally looked at the index, all the COPIED command streams were somehow wrong. How do you carefully explain that fictional docs are really hard to create? So now, the problems with unreviewed docs based on amorphous code become MY problem. The product died soon thereafter, but as the doc person I was blamed for poor work habits and being uncooperative.
It is worth noting that not a single email, note or conversation was ever held to tell me what changes had been made. Both QA and development kept me isolated. And I was uninvited from all meetings. Yup, QA did not look at the docs for months, the developers issued about 8 total rewrites of the code, I was struggling to document just the new stuff I was told about (yes, the pre-release flavor was always different for every single "new" part of the code). In reality, I created a draft flavor for each feature, reviewed the changes made since the developer did the first show-and-tell (round 2 or of corrections), and then I would fix the docs after the developer made more fixes. And this was just for the stuff they TOLD me about.
Please keep me out the loop forever when the code is agile. Agile means no one ever tells what they have changed
mrhippo3 hasn't submitted any stories.
mrhippo3 has no journal entries.