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.
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."
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.
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.
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
When I had a boss who turned plagiarism into a fine art, I had great fun seeing how paragraphs were borrowed verbatim. (Trying very hard to be gender neutral here). The boss even took one brochure, stripped out the images, found a pretend "author" and published the thing as an "article." This was pre-Internet so she was not caught. Still, like a cut-and-paste ransom note, you can borrow (steal, appropriate, copy verbatim) lines from a dozen or so sources and create a nearly anonymous cobbling of content that says exactly what you want while removing your own digital footprints.
"Flattened Fauna" is an older book by Ten Speed Press. The subtitle of the revised edition is, "A Field Guide to Common Animals of Roads, Streets, and Highways." One of the more amusing notes is that unlike most guides that list the type of camera used to take the photos, this book lists the type of copier.
At one point we were on a monthly push for a web-based application. I was stuck in documentation and got all my changes last minute. Once I was told, "The software is ready, are the Help docs?" I asked for a day to see what the software had morphed into to make sure the docs were still OK and to then write/fix what had to be fixed only for the most current changes/new features.
My problem was with the monthly pushes, QA was locked in testing the code and stopped reviewing the docs as they had no time to check the code. After a number of release cycles, all the un-reported code changes had altered the software so much the docs were wrong. I could never explain that I had no talent for fiction. I was not sufficiently creative to rewrite the docs just so they could be wrong. Every single page was reviewed at least once. However, given that I was barely keeping up with new/fixes, a complete rewrite to match months of changes was not possible.
The software is only as good as the Help.
Once upon a time I was driving a dealer's diesel Rabbit while my gas version was in the shop. The diesel got great mileage BUT was anything but quick. In Southwestern PA, you had to seriously plan your shifts and allow a big space before entering a nominal 55 mph roadway. On some stretches I had do 3rd to get up the hills, 4th gear lacked power.
Once upon a time I wrote software docs. I pushed out 12,000 pages in one year. Another "record" was 25 pages generated from a single small yellow Post-It! note -- the product was an embedded systems compiler. The note listed a new set of features (each denoted by a single character compiler flag option) being added to a "target" environment. During review, I had a single context sensitive typo and the developer started to screech at me for being a lousy writer. I asked how long it would have taken him to create the docs and he replied a month. I shot back, "You review the docs for 1/2 hour and find one error in 25 pages and it took me two days. Just shut up and walk away." The best revenge was after I left. I was replaced with a non-working manager and THREE other writers. They complained about the workload and ended up doing 1/3 as much as I did. The kicker was that I was on MANDATORY 50 hour weeks but rarely worked less than 70.
My sole computer class in HS and college was THE class senior year of HS in 1971. We used an acoustic modem to talk to a local university computer, some IBM box. The language was BASIC. Storage space for the school of 3,500 was either 8 or 10KB (not a typo, it really was kilobytes). Anything bigger was written on paper tape at a teletype. I used password protection and could create programs that the teachers could not touch. That said, my entire career has been computer-based. First job was computerized equipment test and data acquisition. After 6 months as lead programmer, my boss asked how much prior experience I had. When I said none, she asked me to never tell that to anyone else and keep up the good work. I saved the company well over $500,000 in testing expenses that year. Since then I have done statistical QA, CAD, FEA and software docs. There were also a few years writing for the trade press.
Slashdot Mirror
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.
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."
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.
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.
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
When I had a boss who turned plagiarism into a fine art, I had great fun seeing how paragraphs were borrowed verbatim. (Trying very hard to be gender neutral here). The boss even took one brochure, stripped out the images, found a pretend "author" and published the thing as an "article." This was pre-Internet so she was not caught. Still, like a cut-and-paste ransom note, you can borrow (steal, appropriate, copy verbatim) lines from a dozen or so sources and create a nearly anonymous cobbling of content that says exactly what you want while removing your own digital footprints.
"Flattened Fauna" is an older book by Ten Speed Press. The subtitle of the revised edition is, "A Field Guide to Common Animals of Roads, Streets, and Highways." One of the more amusing notes is that unlike most guides that list the type of camera used to take the photos, this book lists the type of copier.
At one point we were on a monthly push for a web-based application. I was stuck in documentation and got all my changes last minute. Once I was told, "The software is ready, are the Help docs?" I asked for a day to see what the software had morphed into to make sure the docs were still OK and to then write/fix what had to be fixed only for the most current changes/new features. My problem was with the monthly pushes, QA was locked in testing the code and stopped reviewing the docs as they had no time to check the code. After a number of release cycles, all the un-reported code changes had altered the software so much the docs were wrong. I could never explain that I had no talent for fiction. I was not sufficiently creative to rewrite the docs just so they could be wrong. Every single page was reviewed at least once. However, given that I was barely keeping up with new/fixes, a complete rewrite to match months of changes was not possible. The software is only as good as the Help.
Once upon a time I was driving a dealer's diesel Rabbit while my gas version was in the shop. The diesel got great mileage BUT was anything but quick. In Southwestern PA, you had to seriously plan your shifts and allow a big space before entering a nominal 55 mph roadway. On some stretches I had do 3rd to get up the hills, 4th gear lacked power.
Once upon a time I wrote software docs. I pushed out 12,000 pages in one year. Another "record" was 25 pages generated from a single small yellow Post-It! note -- the product was an embedded systems compiler. The note listed a new set of features (each denoted by a single character compiler flag option) being added to a "target" environment. During review, I had a single context sensitive typo and the developer started to screech at me for being a lousy writer. I asked how long it would have taken him to create the docs and he replied a month. I shot back, "You review the docs for 1/2 hour and find one error in 25 pages and it took me two days. Just shut up and walk away." The best revenge was after I left. I was replaced with a non-working manager and THREE other writers. They complained about the workload and ended up doing 1/3 as much as I did. The kicker was that I was on MANDATORY 50 hour weeks but rarely worked less than 70.
My sole computer class in HS and college was THE class senior year of HS in 1971. We used an acoustic modem to talk to a local university computer, some IBM box. The language was BASIC. Storage space for the school of 3,500 was either 8 or 10KB (not a typo, it really was kilobytes). Anything bigger was written on paper tape at a teletype. I used password protection and could create programs that the teachers could not touch. That said, my entire career has been computer-based. First job was computerized equipment test and data acquisition. After 6 months as lead programmer, my boss asked how much prior experience I had. When I said none, she asked me to never tell that to anyone else and keep up the good work. I saved the company well over $500,000 in testing expenses that year. Since then I have done statistical QA, CAD, FEA and software docs. There were also a few years writing for the trade press.