No it really didn't help much. There are a number of reasons. A tip or a hack cannot solve what is essentially an emotion regulation problem. You probably don't procrastinate on all tasks. For example you can probably read reddit or play games all day. But you dread even starting some tasks. It might be due to multiple reason: past failures, critical feedbacks etc. You will need to introspect and solve that complicated emotion.
Of course, if you notice a broad pattern in every part of your life please consider professional help.
Countries like India are heavy users of diary products. Lactose intolerance is rare too. But always fare very poorly in the height rankings. So it cannot be concluded that it is diary products alone.
milk(calcium) just enables for bigger stronger bones, thus it provides that advantage when there is a pressure for it. The selective pressure for bigger body is present in cold climate and not present in India and even more - due to poverty one can see a pressure for smaller body there. Milk in India is used for another reason - it is a source of cheap (compare to meat) animal protein.
It is a great example "Worse is better"[1]. XML has a lot more functionality than JSON but very few people can fully understand all the X* family of specifications, whereas JSON is a _lot_ easier and handles majority of the use cases.
There are many, many real life situations where a developer needs to choose between using JSON, XML or YAML to store their configuration data, message formats etc. Simply stating that JSON is good only in one scenario and XML must be used in every other is over-simplification.
In all fairness, 99% of the time you will use a library to serialise and deserialize. So I always found this xml vs json debate a bit sterile. As long as it is possible to inspect the file visually ocasionally, they're both good enough. I don't know anyone who edits manually huge amounts of xml/json, and if they do, there is probably a better way.
One consideration that's worth thinking about is that XML serialization is larger (often not insignificantly) than the same data serialized as JSON.
On the other hand, XML can make error handling much easier by schema-validating received documents and thus rejecting a large class of invalid inputs at an early stage. This is particularly helpful if you're making something interoperable, like a public API.
So even when you're just using a library, there are ramifications to the decision.
Correct. But in the order of things I care the most about, using angle or curly brackets matters a lot less than problems like: can I serialize multi-dimensional arrays, dictionaries, arrays of bytes, etc.
And 99% of the time the JSON serialize/deserialize library is much simpler and straightforward than the XML one, especially if your language has native hashes and arrays.
There's also a bitter taste in many of our mouths left by the "XML All The Things!" crowd that brought us such monstrosities as Maven config files and XLST.
XLST is useful when you want to change an Xml configuration file based on whether you are in debug or release mode, without having to duplicate the whole thing. But I wouldn't hold it against Xml, you only use it if you find it useful.
My biggest problem with these list making solutions are what I call the collateral tasks. For example, my list says "Buy a Christmas gift for Jen".
When I start shopping online, I realize that I don't know much about Jen, so I need to call a friend. Lots of discussion later, I finalize on something to buy then I need to think of a personal note to write.
At the checkout, my banking application tells me that my internet password needs to be changed. The whole process gets aborted!
Probably, I exaggerated a little but my point being that each task involves a million micro steps which may or may not be anticipated. No wonder there is a lot of procrastination!
Spot on. We see this a lot in coding activities. Many tasks are usually more complicated than for example "import this file into database, use the imported data to produce the histogram" ... there's bound to be plenty of "collateral" shyte en route. Non-programmers don't usually understand this.
So how to overcome this?
There's no other way than to cognitively "bring to front" the end goal every time you hit a task hurdle that threatens your concentration or that lets you succumb to distraction. But it takes practice to learn that you are in the process of beginning the "shirk move" ... watch out for this. Can you blame yourself when all you've done your whole life subconsciously toggle to other tasks when the going gets tough. Blame evolution for this.
So two things:
1. Know upfront the discrete sub-task/destination you are hoping to achieve for a given finite stretch of time, achieve it and call it the day; and
2. Kak on yourself solid! for being distracted during a tough spell ... speak it out to yourself by enunciating that you are being distracted, mofo. If someone else is doing the disturbing, find a quiet place next time. (Working with kids in the house can be painful).
I don't understand what's the problem. That you can't include all the collateral tasks in your lists (I don't think you have to do that to be effective) or that these micro steps are a form of procrastination (in your example only the long phone call appears to be a bit procastinuous, yes I reserve the right to invent my own words ;-)?
For what it's worth, when I run into a micro task, I add it to the to-do list, and keep a running document with notes which allow it to be context-switched out. It helps, and makes it easier to see progress.
I have seen sites using captchas which ask such visual questions thinking that only a human can answer them. This project really makes me doubt the effectiveness of such techniques.
Yes. But the Burroughs architecture was literally designed to support the high level language (it was heavily CISC), so that solution did not extend to any other computer systems, whereas C of course was relatively portable.
(To head off complaints about what "portable means": portable enough that people did port Unix and C programs to many architectures, unlike the case with the Burroughs OS and programs.)
So the Unix claims of firsts need qualifiers to be absolutely true, but are true in spirit even when phrased casually: the earlier exceptions are mostly just curiosities.
