The Birth And Death Of Privacy: 3,000 Years of History Told Through 46 Images

The Birth And Death Of Privacy: 3,000 Years of History Told Through 46 Images” is a rather extensive look at the history of privacy.

Privacy, as we understand it, is only about 150 years old.  Humans do have an instinctual desire for privacy. However, for 3,000 years, cultures have nearly always prioritized convenience and wealth over privacy.

I said “there is no such thing as privacy, and there never was” way too many times.  But I never had to go deep into the subject to defend it.  This article, on the other hand, does a much better job defending the argument than I ever cared to.

List of cognitive biases

List of cognitive biases is probably the single most useful resource on practical psychology that I’ve seen in my life.

Cognitive biases are tendencies to think in certain ways that can lead to systematic deviations from a standard of rationality or good judgment, and are often studied in psychology and behavioral economics.

Although the reality of these biases is confirmed by replicable research, there are often controversies about how to classify these biases or how to explain them. Some are effects of information-processing rules (i.e., mental shortcuts), called heuristics, that the brain uses to produce decisions or judgments. Such effects are called cognitive biases. Biases have a variety of forms and appear as cognitive (“cold”) bias, such as mental noise, or motivational (“hot”) bias, such as when beliefs are distorted by wishful thinking. Both effects can be present at the same time.

This will take me a very long while to process …

On Impostor Syndrome

David Walsh shares some thoughts on an impostor syndrome.  I’m sure anyone in the tech industry can relate.  I certainly do.

“Impostor” is a powerful word but that’s how I have felt during all of my career as a professional web developer. I feel like I’ve learned every day of the ride but I feel like I’m way behind. I feel like people see me as something of an expert where I see myself as an accident waiting to happen. I’m a complete impostor. A fraud.

Apart from the honesty of his feelings, I like his ways of snapping out of it.  They do work for me too:

  • Look at your (hopefully decent) employment history and know that, on a basic level, you’re much more wanted than you’re wanted gone
  • Log onto the IRC channel of a skill you feel comfortable with and answer questions of those asking
  • Realize that people who consider themselves “experts”, and don’t go through waves of self doubt, are idiots that are so arrogant to not know what they don’t know
  • Remember the last time a non-developer friend asked you the most basic of computer-related questions
  • Perform any simple exercise in the JavaScript console
  • BLOG!  The worst thing that can happen is someone corrects you and you learn something out of it
  • Review your code and find little nits to fix

One other thing that helps me, is this bit by Joe Rogan:

He talks more generically about life, but I think it’s equally applicable to technology knowledge as well.

Programmer Interrupted

Slashdot runs a thread on “Are Remote Software Teams More Productive?“.  The original post links to a few research references that, unsurprisingly, show how expensive interruptions are to programmers, and how unprepared we are, as an industry, to deal with this problem.  I particularly liked a rather in-depth look at the issue in “Programmer Interrupted” article.

Like you, I am programmer, interrupted. Unfortunately, our understanding of interruption and remedies for them are not too far from homeopathic cures and bloodletting leeches.

Here are a few points, if the article is too long for you to handle:

Based on a analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers (Parnin:10), we found:

  • A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.
  • When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.
  • A programmer is likely to get just one uninterrupted 2-hour session in a day

And also this bit on the worst time to interrupt a programmer:

If an interrupted person is allowed to suspend their working state or reach a “good breakpoint”, then the impact of the interruption can be reduced (Trafton:03). However, programmers often need at least 7 minutes before they transition from a high memory state to low memory state (Iqbal:07). An experiment evaluating which state a programmer less desired an interruption found these states to be especially problematic (Fogarty:05):

  • During an edit, especially with concurrent edits in multiple locations.
  • Navigation and search activities.
  • Comprehending data flow and control flow in code.
  • IDE window is out of focus.

Overall, not surprising at all, but it’s nice to have some numbers and research papers to point to…