Difference between revisions of "Talk:1319: Automation"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
Line 19: Line 19:
  
 
::I think what Randall is trying to say is EITHER that a) programmers will automate for the sake of the challenge or it being less tedious than the basic way even if it doesn't save time. b) programmers will automate even if it doesn't save time because they can use the code next time the problem arises. But I agree, I think the first graph's "regular way" line should have either continued horizontal, or tappered off somewhere after the "automation" line does. [[User:TheHYPO|TheHYPO]] ([[User talk:TheHYPO|talk]]) 14:56, 21 January 2014 (UTC)
 
::I think what Randall is trying to say is EITHER that a) programmers will automate for the sake of the challenge or it being less tedious than the basic way even if it doesn't save time. b) programmers will automate even if it doesn't save time because they can use the code next time the problem arises. But I agree, I think the first graph's "regular way" line should have either continued horizontal, or tappered off somewhere after the "automation" line does. [[User:TheHYPO|TheHYPO]] ([[User talk:TheHYPO|talk]]) 14:56, 21 January 2014 (UTC)
 +
 +
:::As far as I can tell, the line labelled "work on original task" is not meant to represent the amount of work you'd be doing without any automation (which would indeed remain a straight horizontal line), as the "theory" graph doesn't compare two separate scenarios. Rather, it's just there to be a baseline amount of work (programming work being done on top), which diminishes to near-zero as soon as automation takes over. [[Special:Contributions/108.162.231.221|108.162.231.221]] 18:28, 21 January 2014 (UTC)

Revision as of 18:28, 21 January 2014

Why is this administrator protected? Did an admin lock it just to make sure they'd be the first person to explain it? --Mynotoar (talk) 07:12, 20 January 2014 (UTC)

It is not protected. Check the logs. 108.162.246.117 07:39, 20 January 2014 (UTC)

Alright, done the preliminary explanation. I think I got the joke right, and I'm a programmer myself so I can relate to the graphs. However, laymen may not understand the circumstances of programming world, so maybe simpler words could be used, or a real-life example given. That and I'm not a native English speaker, so someone else should do some grammar check. Also, I posted that from my mobile, it's not really convenient (editing the post itself is already a bit hard) so I'll do some fact checking and citation-linking once I got home. I did check on the screwing definition with TheFreeDictionary, don't have time to do better search now. Raestloz (talk) 08:55, 20 January 2014 (UTC)

Note that in reality, many tasks can be automated successfully: while the programming takes longer that expected, may not simplify the task as much as expected and the program feels unfinished, outside circumstances can force the programmer to abandon ongoing development and use the program for partial automation instead. -- Hkmaly (talk) 09:54, 20 January 2014 (UTC)

The title text reminds me of the old joke about the definition of politics -- "poli-" meaning "many" and "tics" meaning "blood sucking creatures". --108.162.219.202 12:31, 20 January 2014 (UTC)

Or the definition of polygon; "poly" = parrot and "gon" = gone (i.e., deceased). Therefore, "dead parrot" 141.101.99.236 09:55, 21 January 2014 (UTC)

Why do the lines on the "Theory" graph converge shortly after automation takes over? Surely, the idea behind writing a code in this example is to save time. Therefore, the original task line should remain relatively constant and the coding line should plunge below it, no? -- Jevicci (talk) (please sign your comments with ~~~~)

Once the automation takes over, the programmer will no longer have to do anything, the program will take care of it Raestloz (talk) 00:22, 21 January 2014 (UTC)
Yes, but I agree with Jevicci's comment and that's what I was going to post. The point of the automation is (in theory) to save effort. After an initial input of lots of work coding, the "automation" line drops to near-zero. That makes sense, but the "regular way" line should continue horizontal like it does in the 2nd graph because if you don't automate, it should continue to take effort. The first chart suggests that even in theory, automation takes more work and the same amount of time as the old fashioned way.
I think what Randall is trying to say is EITHER that a) programmers will automate for the sake of the challenge or it being less tedious than the basic way even if it doesn't save time. b) programmers will automate even if it doesn't save time because they can use the code next time the problem arises. But I agree, I think the first graph's "regular way" line should have either continued horizontal, or tappered off somewhere after the "automation" line does. TheHYPO (talk) 14:56, 21 January 2014 (UTC)
As far as I can tell, the line labelled "work on original task" is not meant to represent the amount of work you'd be doing without any automation (which would indeed remain a straight horizontal line), as the "theory" graph doesn't compare two separate scenarios. Rather, it's just there to be a baseline amount of work (programming work being done on top), which diminishes to near-zero as soon as automation takes over. 108.162.231.221 18:28, 21 January 2014 (UTC)