Archive for the ‘lifehacks’ Category
I believe he is wrong, and I will tell you why.
UPDATED: to remove the embedded video Why are we happy?
Like many people I am lazy, this is sometimes handy as it means I will automate mundane important tasks and ignore unimportant tasks. And it’s a pattern that I’m not always happy with, even with it’s obvious advantages. I go on time management binges, spend my time creating frameworks for organizing my time, yet I often don’t get to the execution of the framework. The journey is sometimes more fun, than the goal.
This means that many handy, and even some fun things, are left in to do lists with little chance that they will be crossed off. And I’m quite happy with the situation.
This leads me to the reason I started this post: I watched Dan Gilbert’s TED video Why are we happy? and came to the question: Can I enable myself to see my inaction as a choice? And choose something different?
I may be unhappy whether I do or don’t, says Gilbert. Wondering whether I made the right choice until the end of time. It’s also impossible to see the choice as immutable as the choice can always be changed at a moments notice. And yet, as is suggested by Gilbert, the power of the mutability of decision is an illusion. Having the ability to choose will make it impossible to know whether the path chosen is the right path – even if there is no right or wrong.
This leads me to believe that the Reinhold Niebuhr quote: Grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference. should actually read: Grant me the serenity to accept the things I can change, the courage to not change the things I can, and the wisdom to make choices immutable.
In a recent Popular Science article Science Confirms the Obvious a number of studies are examined on some seemingly obvious subject. I’ll leave the discussion on the value of the studies to the article and focus on the result of a study on Group Dynamics: Too Many Meetings Make You Grumpy.
Meetings are usually seen as an interruption in to the work which needs to be done. Meetings can often be complementary to the work which needs to be done, whether it is in defining the tasks, the path or the result. Meetings can be a good way of getting the team aligned, and days chock-full of meetings cuts into time which can be more effectively directed at tasks. They are sometimes seen as a team building exercise, and although brainstorming no holds barred meetings are part of a creative process they are also few and far between.
While brainstorming on this I realized that this is also an example of role-based actions, as I discussed in my review of the Lucifer Effect. The system here is not a prison, as in the Stanford Prison Experiment, but the office environment. The roles are directors, manager and staff. Is holding meetings what is expected from these roles?
What’s the solution?
“Organizations [should] be sensitive to the number of meetings employees are required to attend,” is a suggestion from the researchers and “formal guidelines” for meetings. Which means setting a agenda before the start of the meeting and sticking to it. Time boxing is another effective way of reducing the time spend, time box the agenda items and the whole meeting. When there is a need for a longer meeting – > 1 hour – allow for coffee and/or smoking breaks.
I was forwarded the link to In Synch, a tool which will calculate the Language Style Matching for two pieces of text.
“[In Synch] determines the degree to which any two samples of language are similar in their language styles. It can be most helpful in analyzing two sides of the same conversation.”
All that is needed are two writing examples – instant messages, text chats, text messages, transcribed conversations or other writing samples – with a minimum of 50 words for each the language style can be analyzed and a score can be calculated. The scoring is from 0.50 – 1.00, so the closer you are to 1.00 the more in synch you are with the author.
Possible uses for this could be verification that a piece of written text is from an author. And in combination with text-to-speech and speech analysis this could lead to an additional factor which could be used in authentication.
I was inspired by Driving Technical Change to write this. Please read the following for context:
Expertise, even for the very experienced, is a fluid thing. With the exception of abandoned technology, every tool, technique, or product that you are trying to push is changing everyday. The producers are adding more features. The community is posting more commentary. Users discover bugs, and product teams fix them. Nothing is static. Therefore, even the most expert of experts is only as good as the last thing they read. There is no standing still as an expert. And yesterday’s expert is tomorrow’s dinosaur after as little as two years of not keeping up.
I think this is a sweeping generalization which I believe is wrong, and I know is wrong for me. I regularly go on sabbatical for 3-6 months where I don’t or hardy use a computer, with hardly I mean I checked my mail once after 3 months. In this time due to the fact that I’m traveling I don’t read computer books or magazines. Coming back after this time I notice one important thing, nothing has changed except the version numbers. New features have been added to old software, new design patterns have been thought up and new frameworks have been created, whole sections of the linux kernel have been rewritten. And with in a week I am at my expertise level, and a week later I have covered most of the important things I’ve missed.
People who follow changes live are often stuck in the noise of the present, which for an expert a timeline can often look like this:
- Somebody suggests or codes a feature
- Feature is discussed on a mailing list and in chat
- Feature is attacked for obvious weaknesses
- Feature is tested and updated
- Feature is implemented in the alpha
- Feature breaks when combined with other updates or breaks other features
- Mails/articles are written for and against the change
- Patches are exchanged and evaluated
- Feature undergoes further testing
- Feature reaches the beta
- Discussions on the direction of the software
- Possibly a branch is created
- Feature is updated in next beta
- Discussions on the feature
- Articles are written about the new features in the next release
- Feature is released
- Articles are written about the new feature
- Revisions of books on the software or framework are written which include the new feature
This can take anywhere up to 6 months for larger features or changes to large frameworks. Following the noise allows you to adapt to the change over a longer period of time, and allows you to experiment more with the feature. This same result can be reached by reading the articles which are published round the time the feature is live, with the exception of the generated noise. One of the advantages is that this noise can be used for reference material, when the noise is of good quality. And this example covers only one feature for one software package or framework.
Being caught up in the daily noise also has a bigger problem. In some cases I may not be a direct contributor to a software package or framework and this noise can reduce the time that I can spend learning other things from the new books or articles which cover the other areas in which I consider myself an expert.
Something which is also neglected in the statement above is that experts have often been their and seen that. CVS works similar to SVN, which with a context shift works similar to Git. Each solving a different problem, and with the knowledge of the problem being solved it is easy to apply previously learned unrelated knowledge to new software or a new framework.
A great book!
Some days ago I tweeted to Prosper, a personal loan marketplace, whether they would allow somebody to take out a personal loan and use it to fun a project on Kiva. The idea came to me after reading a note from somebody on recycling money on Prosper for investment – borrowing at a low rate and lending at a higher rate.
So I thought I should ask Proper about the possibility, they said:
Yes! Just choose “other” on your loan type and explain to potential lenders what you are using the loan for. Thanks 4 asking
Naturally you are responsable for any defaults on the loan, but spreading small amounts round different projects will reduce your risk, while allowing you to make a difference for others even if you yourself don’t have the money to lend.