I would add a few more caveats to the whole argument of "calories come from the food that you consume." Being lactose intolerant, ice cream and other "rich" aka calorie laden desserts may wipe out any other calories consumed. If I eat too much ice cream then whatever else I might have eaten just "goes away" (hard to describe rapid elimination while being SFW). Another issue for me is black or white pepper. As with lactose, the pepper can result in a rather quick stomach dump. Mood also affects how settled my digestive system is, which again affects how many of the calories consumed are calories digested.
Add one more to the list. As a Mechanical Engineer I had the "Standard Handbook for Mechanical Engineers" by Baumeister & Marks. Some 40 years later, the great bulk of material is unchanged. And now the book is even bigger (for more $). I still use it.
I was the first student on Carnegie-Mellon's campus with a calculator. People ask me how I knew. The answer is, they were generally unaffordable at $250 ($1,500 current dollars).That said, I had straight (a few), and both types of circular slide rules. The first type had two indicators (this was a Gilson slide rule, the same kind held by Peter Sellers in 'Dr. Strangelove'.) The second type had a rotating disk and one indicator (made by Concise). I found and bought another one with a bunch of conversion tables in Paris in 1974.
Engineer here with a lot of experience with Finite Element Analysis software. Sparse arrays are NOT some amusing construct to see how well you code an obscure problem. FEA is *THE* tool to create a design that is less likely to fail. Programs such as ANSYS are used design just about every single vehicle on the road (cars, trucks, bicycles), airplanes -- the airframe and the engines, locomotives. And FEA is also used to design bridges, buildings, cranes used to build this stuff. The use of sparse matrix algorithms enable this software to get results in a reasonable time frame. As mentioned elsewhere, sparse matrices are very useful in design optimization, which is frequently coupled with FEA.
Wow. Thank you for the truly depressing statistic about which I can do absolutely nothing. I have an engineering degree, which binds me to the desk. Having moved into upper management, my ability to leave the desk is reduced even further. My possible exercise, going into the shop with the fumes and dust and particulates is perhaps just as bad. This is just what we need to add to the STEM shortage.
On an earlier job I was sharply criticized for just leaving my desk, at all. I was working in software docs and really had to talk to the developers. My typical process was to try the software on my own, develop a rough outline (the hard part was coming up a 'suggested use.' with so many options, what was the 'intended use'?), and then march the draft to the developer to see what I had missed. This took so much less time than the email flurry. I was at least a factor of four faster than the other writers. But I was accused of "annoying the developers" by trying to do things the right way.
Oh, cancer risk, too? Well I had it (in remission but getting scans and inspections every three months or so). Gotta run to the shop. No more time to write.
My wife ran close to a 4.0 undergraduate and graduate. She was also naive, having done grade school through HS at a small private women's school. In college at a large state school, the prof noticed a group of minority students that actively cheated off my wife, who always sat first row. For the final, the prof shoved my wife into a far back corner, rendering the cheating strategy impossible. The cheaters were given full opportunity to show how little they had learned. They spent the hour glaring at wife who was complying with the prof's request.
The only time I was cheated from was in grade school. The teacher assumed (or rather confused me with) my brother who was not quite so well behaved as I. When the classmate cheated from me, she did a poor job, but she still got a higher grade than I did.
Face it. Life is unfair.
I was working at a software firm that tried to implement diversity, by hiring the wives of "star" male employees. These women had neither the background, the skillset, nor the ability to learn. Nominally a Marketing Writing Manager, my boss was a HS English teacher. There is some irony in her on-line profile where she has downgraded her job to make it look like she was a worker bee. She could not write commercially, talk with either vendors of customer (the product was engineering analysis software), or even create an outline. Her best efforts were freely plagiarized. She lifted paragraphs -- entirely unedited for context or tense or any trace of grammatical comparability and strung these random bits into an "article." Granted the opportunity to write the press release that defined the company's future (all revenue would shift from "big iron" to workstations and smaller boxen) she, "Was too busy selecting literature for the upcoming trade-show." Yet, she was immune from criticism. Any doubts on her abilities were cast as sexism. A parallel boss (of equal "wife" status) stiffed Sun Microsystems in the 1980's when she refused to pay shipping charges -- part of her attempts cover up her incompetence. Sun (one of the top revenue producers for the firm -- this was millions in revenue) stopped paying attention the software firm, because the boss stiffed them of $1,800 that the spouse had agreed to pay. It is with great joy that neither "boss" has ever had a follow-on job with ANY staff. The writing boss did some work, but only onsey-twosey and little repeat business (too many small jobs in way too many big companies). If you are any good you become "captive" and write a lot for one department.I have recovered and left writing and now am the second in command at a small manufacturing firm. My boss in the family run firm is a competent woman. She does her job well and we get along great.
That is my wife you are besmirching. She is a headhunter. She does not follow the typical mold in that she actually cares about the candidates and does her best to match the corporate requirements with the available talent pool. She will be straightforward with the candidates and actually preps them with what to expect in the interview.
On the one job she found for me (her engineer husband) I was there for only six weeks and then she was promoted to a city across the state (PA). One co-worker actually asked what my wife's fee was for placing me. As she knew the president of the firm and worked with him before, the fee was zero. So my response to the lout was, "Come to think of it, her fee was 'my entire salary.'"
Not really happy to read this. Part of my cancer treatment was radiation therapy to the head. I had a severe loss of taste, but smell was nearly intact. With an overly sensitive nose, I guess I was down to what would be a "normal" level. Considering what could have happened (a partial list): loss of sight, loss of hearing, loss of hair, damage to vision, damage to tears, difficulty in swallowing, loss of muscle control of tongue, loss of teeth, loss of smell, inability to chew, and more. Losing taste for a few months was not bad. I ate a lot of Indian food. The problem was eating enough to maintain weight to have the treatment mask fit. Allowable weight variation was zero lbs. I just used a portion control. I am athletic and continued bike miles during treatment. I would do the "french fry" trick in reverse. In a typical diet, you set aside the four fries you are "allowed" to eat, creating a DO NOT EAT pile. I created a somewhat larger pile of YOU MUST EAT THIS. As a conditioned (albeit older athlete) I knew how much to eat to balance calories out with calories in. I was used to being so tired that taste really was never an issue. Tasting takes effort. BTW, taste did come back but still not at 100%. Considering the option -- death -- loss of taste temporarily was OK.
The logical outcome of Fear Driven Development is Fear Drive Documentation. I once had the great misfortune to work for a "vanity" software firm created by an industry legend as a nice place for his kid to work. The "standard" work week was a mandatory minimum of 50 hours, getting paid for 40, of course. I never worked less than 60 and the usual was around 70. Working in docs (solo under ten developers), my job was to fix the paper to match the latest suite of changes. If the developers worked in fear, then I worked in stark, raving terror. To match the shipping schedule, I issued 12,000 pages of docs in a year. Adding to my joy, one project manager had the temerity to complain about 3 typos in a 1,000 page document set. The conversation that given the choice between a few typos and missing documents did not go over well. And yes, the company did fade away, but not before I was replaced by a manager and three worker bees that promised less than half of what I had done and missed even that low bar.
I learned a long time ago how to work fast in documentation. Given the task of moving documents into FrameMaker from wherever, I stored the document as text, imported the stuff as Body copy and then used keystrokes to apply the right formatting. Storing the stuff as straight text gets rid of the typical line-by-line format removal. One boss type was initially given the project and gave a three month estimate to move 350 pages. I got the job as, "See what you can do," and finished in a day and half. Being that fast would have gotten me fired. I even dodged that process, quitting first. Being too good is a faster way to get canned than effing up.
I shudder to think that i am now an "older" engineer. I graduated from Carnegie-Mellon in the mid 70's which means that my curriculum was was developed mostly in the 50's if not earlier. Yes, I did take The Calculus (four classes including a second class in partial differential equations). I was even part of an "experiment" where freshman year Physics and Calculus was taught as a "single" class. The math and physics profs shuffled the class time by first showing the physical phenomena and then the math behind it. This class was 5 hours/week of lecture and 4 hours/week of recitation.
This rigid formatting has worked for me. I have spent a lot of time with R&D and was never showed by the math. I have a lot of simulation experience with FEA as well as chip and circuit design, embedded system compilers, and some real-time testing of mechanical stuff ranging from tires (small) to 17 ton compressor rotors.
More importantly, I learned how to deal with change. I was the first student on campus with an electronic calculator. The acceptance of the technology was instantaneous, the profs just added more problems to the tests. The simple act of "doing more stuff" has followed me during my entire career.
The greatest irony has been my lack of "formal" computer training. I had a single programming class in high school. Yet, my entire career has been computer-based. My computer usage has not been limited to "engineering." I have done a lot writing (trade press) and learned layout work along the way. Doing documentation for a CAD vendor, you learn how to write in a different style and QA just becomes part of the process -- you do want make sure what you write about actually works. Working for FEA vendors, I again learned how to make the stuff work and created simple examples to show the process. (The heavy duty math helps you understand how FEA works). And my coding skills were used in crafting documents with an early flavor of XML.
Learning though a rigid structure has allowed me cope with whatever comes my way.
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
Slashdot Mirror
I would add a few more caveats to the whole argument of "calories come from the food that you consume." Being lactose intolerant, ice cream and other "rich" aka calorie laden desserts may wipe out any other calories consumed. If I eat too much ice cream then whatever else I might have eaten just "goes away" (hard to describe rapid elimination while being SFW). Another issue for me is black or white pepper. As with lactose, the pepper can result in a rather quick stomach dump. Mood also affects how settled my digestive system is, which again affects how many of the calories consumed are calories digested.
Add one more to the list. As a Mechanical Engineer I had the "Standard Handbook for Mechanical Engineers" by Baumeister & Marks. Some 40 years later, the great bulk of material is unchanged. And now the book is even bigger (for more $). I still use it.
I was the first student on Carnegie-Mellon's campus with a calculator. People ask me how I knew. The answer is, they were generally unaffordable at $250 ($1,500 current dollars).That said, I had straight (a few), and both types of circular slide rules. The first type had two indicators (this was a Gilson slide rule, the same kind held by Peter Sellers in 'Dr. Strangelove'.) The second type had a rotating disk and one indicator (made by Concise). I found and bought another one with a bunch of conversion tables in Paris in 1974.
Engineer here with a lot of experience with Finite Element Analysis software. Sparse arrays are NOT some amusing construct to see how well you code an obscure problem. FEA is *THE* tool to create a design that is less likely to fail. Programs such as ANSYS are used design just about every single vehicle on the road (cars, trucks, bicycles), airplanes -- the airframe and the engines, locomotives. And FEA is also used to design bridges, buildings, cranes used to build this stuff. The use of sparse matrix algorithms enable this software to get results in a reasonable time frame. As mentioned elsewhere, sparse matrices are very useful in design optimization, which is frequently coupled with FEA.
Wow. Thank you for the truly depressing statistic about which I can do absolutely nothing. I have an engineering degree, which binds me to the desk. Having moved into upper management, my ability to leave the desk is reduced even further. My possible exercise, going into the shop with the fumes and dust and particulates is perhaps just as bad. This is just what we need to add to the STEM shortage.
On an earlier job I was sharply criticized for just leaving my desk, at all. I was working in software docs and really had to talk to the developers. My typical process was to try the software on my own, develop a rough outline (the hard part was coming up a 'suggested use.' with so many options, what was the 'intended use'?), and then march the draft to the developer to see what I had missed. This took so much less time than the email flurry. I was at least a factor of four faster than the other writers. But I was accused of "annoying the developers" by trying to do things the right way.
Oh, cancer risk, too? Well I had it (in remission but getting scans and inspections every three months or so). Gotta run to the shop. No more time to write.
My wife ran close to a 4.0 undergraduate and graduate. She was also naive, having done grade school through HS at a small private women's school. In college at a large state school, the prof noticed a group of minority students that actively cheated off my wife, who always sat first row. For the final, the prof shoved my wife into a far back corner, rendering the cheating strategy impossible. The cheaters were given full opportunity to show how little they had learned. They spent the hour glaring at wife who was complying with the prof's request.
The only time I was cheated from was in grade school. The teacher assumed (or rather confused me with) my brother who was not quite so well behaved as I. When the classmate cheated from me, she did a poor job, but she still got a higher grade than I did.
Face it. Life is unfair.
I was working at a software firm that tried to implement diversity, by hiring the wives of "star" male employees. These women had neither the background, the skillset, nor the ability to learn. Nominally a Marketing Writing Manager, my boss was a HS English teacher. There is some irony in her on-line profile where she has downgraded her job to make it look like she was a worker bee. She could not write commercially, talk with either vendors of customer (the product was engineering analysis software), or even create an outline. Her best efforts were freely plagiarized. She lifted paragraphs -- entirely unedited for context or tense or any trace of grammatical comparability and strung these random bits into an "article." Granted the opportunity to write the press release that defined the company's future (all revenue would shift from "big iron" to workstations and smaller boxen) she, "Was too busy selecting literature for the upcoming trade-show." Yet, she was immune from criticism. Any doubts on her abilities were cast as sexism. A parallel boss (of equal "wife" status) stiffed Sun Microsystems in the 1980's when she refused to pay shipping charges -- part of her attempts cover up her incompetence. Sun (one of the top revenue producers for the firm -- this was millions in revenue) stopped paying attention the software firm, because the boss stiffed them of $1,800 that the spouse had agreed to pay. It is with great joy that neither "boss" has ever had a follow-on job with ANY staff. The writing boss did some work, but only onsey-twosey and little repeat business (too many small jobs in way too many big companies). If you are any good you become "captive" and write a lot for one department.I have recovered and left writing and now am the second in command at a small manufacturing firm. My boss in the family run firm is a competent woman. She does her job well and we get along great.
I was out of work and, yes, my wife found me a job. This was a win for all involved.
That is my wife you are besmirching. She is a headhunter. She does not follow the typical mold in that she actually cares about the candidates and does her best to match the corporate requirements with the available talent pool. She will be straightforward with the candidates and actually preps them with what to expect in the interview. On the one job she found for me (her engineer husband) I was there for only six weeks and then she was promoted to a city across the state (PA). One co-worker actually asked what my wife's fee was for placing me. As she knew the president of the firm and worked with him before, the fee was zero. So my response to the lout was, "Come to think of it, her fee was 'my entire salary.'"
Not really happy to read this. Part of my cancer treatment was radiation therapy to the head. I had a severe loss of taste, but smell was nearly intact. With an overly sensitive nose, I guess I was down to what would be a "normal" level. Considering what could have happened (a partial list): loss of sight, loss of hearing, loss of hair, damage to vision, damage to tears, difficulty in swallowing, loss of muscle control of tongue, loss of teeth, loss of smell, inability to chew, and more. Losing taste for a few months was not bad. I ate a lot of Indian food. The problem was eating enough to maintain weight to have the treatment mask fit. Allowable weight variation was zero lbs. I just used a portion control. I am athletic and continued bike miles during treatment. I would do the "french fry" trick in reverse. In a typical diet, you set aside the four fries you are "allowed" to eat, creating a DO NOT EAT pile. I created a somewhat larger pile of YOU MUST EAT THIS. As a conditioned (albeit older athlete) I knew how much to eat to balance calories out with calories in. I was used to being so tired that taste really was never an issue. Tasting takes effort. BTW, taste did come back but still not at 100%. Considering the option -- death -- loss of taste temporarily was OK.
The logical outcome of Fear Driven Development is Fear Drive Documentation. I once had the great misfortune to work for a "vanity" software firm created by an industry legend as a nice place for his kid to work. The "standard" work week was a mandatory minimum of 50 hours, getting paid for 40, of course. I never worked less than 60 and the usual was around 70. Working in docs (solo under ten developers), my job was to fix the paper to match the latest suite of changes. If the developers worked in fear, then I worked in stark, raving terror. To match the shipping schedule, I issued 12,000 pages of docs in a year. Adding to my joy, one project manager had the temerity to complain about 3 typos in a 1,000 page document set. The conversation that given the choice between a few typos and missing documents did not go over well. And yes, the company did fade away, but not before I was replaced by a manager and three worker bees that promised less than half of what I had done and missed even that low bar.
I learned a long time ago how to work fast in documentation. Given the task of moving documents into FrameMaker from wherever, I stored the document as text, imported the stuff as Body copy and then used keystrokes to apply the right formatting. Storing the stuff as straight text gets rid of the typical line-by-line format removal. One boss type was initially given the project and gave a three month estimate to move 350 pages. I got the job as, "See what you can do," and finished in a day and half. Being that fast would have gotten me fired. I even dodged that process, quitting first. Being too good is a faster way to get canned than effing up.
I shudder to think that i am now an "older" engineer. I graduated from Carnegie-Mellon in the mid 70's which means that my curriculum was was developed mostly in the 50's if not earlier. Yes, I did take The Calculus (four classes including a second class in partial differential equations). I was even part of an "experiment" where freshman year Physics and Calculus was taught as a "single" class. The math and physics profs shuffled the class time by first showing the physical phenomena and then the math behind it. This class was 5 hours/week of lecture and 4 hours/week of recitation.
This rigid formatting has worked for me. I have spent a lot of time with R&D and was never showed by the math. I have a lot of simulation experience with FEA as well as chip and circuit design, embedded system compilers, and some real-time testing of mechanical stuff ranging from tires (small) to 17 ton compressor rotors.
More importantly, I learned how to deal with change. I was the first student on campus with an electronic calculator. The acceptance of the technology was instantaneous, the profs just added more problems to the tests. The simple act of "doing more stuff" has followed me during my entire career.
The greatest irony has been my lack of "formal" computer training. I had a single programming class in high school. Yet, my entire career has been computer-based. My computer usage has not been limited to "engineering." I have done a lot writing (trade press) and learned layout work along the way. Doing documentation for a CAD vendor, you learn how to write in a different style and QA just becomes part of the process -- you do want make sure what you write about actually works. Working for FEA vendors, I again learned how to make the stuff work and created simple examples to show the process. (The heavy duty math helps you understand how FEA works). And my coding skills were used in crafting documents with an early flavor of XML.
Learning though a rigid structure has allowed me cope with whatever comes my way.
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.
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.
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.
.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.
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
Yes, BASIC started me on the road to ruination. 40 plus years later and I am still at it.
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.
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.
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.
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.
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."
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.
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.
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.