No Country For Old Mann

I have been enjoying the Back To Work podcast with Merlin Mann for some time now and following the 13th episode, which I hope will not be the last one, I want to express some thoughts on some of the issues raised and covered in it, to be specific I want to talk about four topics: Advice, Inspiration, Honesty and Productivity. I am mostly going to talk about Merlin Mann because I think he is the heart of the show, with no offense to Dan Benjamin being the great host

On Advice.

When I think of good advice I have ever received or about good advice in general, I think my biggest criteria would be its timeliness. When you are at G and you want to get to H, last thing you can use is advice on how to get from A to B (cause I already know that) or from M to N (cause I have no idea what you are talking about). Even though Merlin really tries to make the show useful for everyone, I think most of the advice is really for people who are currently trying to get something started, are stuck somewhere or on something or are beating themselves over the head with doubt on whether they are doing the right thing or making enough progress and all sort of similar neurotic thoughts you could and should really do without. I liked when on one of the shows Merlin mentioned his wife telling him that most of 'those' people really need a hug and some therapy rather then another index card management system. I totally agree with that.

The types of people who should not listen to the podcast include those who are not doing anything and are happy as it is and those who are already happily doing something and making great stuff on their own. These types do just fine with regular porn, they don't need productivity porn in their lives as well. For years I was in fallacy of nagging people who are just happy with the ways things are either doing something or doing nothing with all sorts of helpful advice and was extremely irritated when they told me to buzz the fuck off. I totally get it now.

In some way, all Merlin is saying is to stop listening to him because he does not have any real answers. This, in a way, is the highest level of mastery, if you get this kind of thing. To those who are doing nothing, he says, stop listening and go do something, only when you start doing anything you will get what I am talking about. To those who are really doing great he says stop listening to me and do what ever that is you do. And to those who are 'trying' to do things (as himself) he says, listen I don't know what you should do and the most I can do is either tell you what someone else did or what you could do. But never what you should do or what you will do, this is your job, pal, to figure out. Which brings us to the second topic.

On Inspiration

In a way Merlin has put it brilliantly in the episode on inspiration by saying that you can not really make something out of inspiration alone. At most, it can serve as an initial push, after which you will still have to do this clackity noise, regardless. And do you really need an inspiration at all, it might, after all, be highly overrated. I really like Seth Godin's book called The Dip in this regard, and the metaphor is provides. You see this tiny hump in the beginning, you are lucky if the inspiration get you there but all the rest of the way is still yours to cover. If you want to go to a distant place, inspiration might get you out of the door, but you still have to work out through the entire way. And do you really need inspiration at all, just get out with or without it and this is what I think Merlin is trying to tell you there.

On Honesty

It is clear the Merlin Mann has decided on being absolutely and brutally honest in everything he does and talks about whether it works for him or not. He is not trying to make himself a guru or claim originality in any way on things that do not belong him. One of the commenters on the latest show called him a hypocrite for preaching the stuff he does not practice and I think this is a wrong way to go, not because I want to defend Merlin in any way, but because life does not work this way ever and you really should not punish the person telling you the truth, disappointing as it may sound. I could have said that you do not ask your dentist to open your mouth before the visit or for your shrink to tell you about himself first, but I really don't want to go there. Rather, having read a shitload of self help books over the years, what Merlin Mann has to offer deep inside is much much much more valuable that any of that crap if you only listen carefully. If you really listen in to this, you will realize that this is probably the most honest thing you will ever hear on this subject from a guy you basically don't even know on the internet, so treasure it.

On Productivity

In the morning my wife, who is building this toy house model from Styrofoam for a theater production, told me that she just discovered that if you add some color to the otherwise transparent glue you can work much faster because you immediately see which area is already covered with glue and which is not. This allowed her to improve her productivity twofold at least, but since it was the first time she did this kind of job she only discovered it in the middle of her work. If I knew this earlier, she said, it would be done even faster.

That is true, of course, but how much earlier. Imagine someone walking up to you in a street when you are like twelve and saying listen kid, you better mix some color into your glue, that would be the moment that you run like hell and ask the nearest adult you trust to dial nine one one. To sum this up I will paraphrase an famous quote by saying: "Productivity favors the prepared".

MZ.

Locked in Pandora's Box

It is coming up here and there, and I can totally relate, the idea that simplistic customization and adaptivity in information services can lead to you only seeing the same limited set of stuff you have been established to like. This topic is covered in the recent TED talk by Eli Pariser, who calls it 'personalization bubbles'.

One of the simple ways to demonstrate this is through Pandora, the best music radio site ever which I absolutely adore and which allows you to play music you like not by genre or artist but by its musical characteristics and does this extremely well. If you pick up some non mainstream music you can vote songs up and down until after a certain period of time you will be looping through a list of ten of ten songs or so.

This does have interesting implications in other areas as well, certainly when it goes into even more polarized domains such as, interestingly, politics.

Extraordinary as usual

Merlin Mann is being absolutely awesome.

If you feel down, unmotivated or just could use a boost of good spirit I would recommend this podcast, and this presentation (slides) from Webstock 2011.

Enjoy

Introducing Familinearity

Familinearity is when a person makes decisions in a new situation based on some other familiar situation while assuming that the relation between them is linear. This is also how software development planning is done in most companies.

The idea for this term came to me last Wednesday, when I have attended the FogBugz World Tour in Tel Aviv to finally see Joel in person and also learn a bit about version control and bug management. Both the organization of the event and the presentations were excellent and enjoyable completely making up for the apparent dryness of the subject. Even though I do not use FogBugz myself, I got an impression that it is an excellent and very powerful product, well integrated with version control systems and easy enough to use in both medium scale and large projects.

One feature in FogBugz that really caught my attention, however, was the Evidence Based Scheduling (EBS). The idea behind it was to match actual time of task performance to the estimated one for each developer over some period of time and then statistically process it to derive meaningful information about project planning and scheduling. Such information could, for example, include the developer timelines and velocity as well as estimated completion times that would allow you to determine a completion date for any subset of the project with definite probability.

A priori, I am extremely skeptical about the overall precision and usefulness of such methods. Not to say that evidence based approach in general is incorrect, it is certainly in fashion and gaining speed in medical community while also taking shots at other areas. It is other considerations, both practical and theoretical nature that cause my doubts and I will explain them in brief.

The practical concerns for the applicability of this tool are too long for this post, probably too long an entire book. Just a quick look at the article called "How to estimate software tasks" from FogBugz documentation can give a great example of the problems we face in this area. One paragraph towards the end of the article claims that giving people unrealistic schedules and hope they will be "motivated" by them is "brain-dead", a statement with which I completely agree. It is still a fact, however, that there are entire companies that live by this principle and lots of managers who did not read "A Mythical Man-Month" even though it is, as the article claims, a requirement. Joel Spolsky himself, of course, knows more than most people about those problems and have written numerous articles on the subject. These companies, by the way, can at times be very successful, and you will have a hard time trying to convince them that their management practices are flawed.

My point, in this case is that when a tool like EBS is deployed in an organization that has that specific management culture and later, one of the team leaders comes up to his boss to claim that based on previous experience his estimate has only 2% chance of being correct, it will more likely result in fireworks than in the manager amending his ways. Another problematic situation might occur when the manager will come to the above team leader and inquire why the feature that was a week ago 99% on time still late. All that, assuming the organization really deployed EBS and paid all the additional costs of constantly updating all estimates and drilling down all tasks without which the method will not work at all at best or produce highly inaccurate results at worst.

But even if we leave the practicalities aside, the theoretical aspects of using bootstrapping based statistical methods seems a bit problematic. As Joel himself would tell you, in software you rarely do the same things twice. It is design, and design is similar to an exploration of a highly fluid terrain, with high complexity. Using methods that use linear extrapolation based on precision of your previous estimates to provide precise answers seems at least problematic and might raise similar objections to the ones Nassim Taleb provided for the use of VAR formula in economics.

I am not saying that this tool is not useful, it might for example, reveal the "epistemic arrogance" of the management by showing the ill precision of their previous estimates and thus benefit tired and demotivated programmers. It might provide a good bottom margin for the prediction errors. But not taking into account the complexity and non linearity of the domain at hand it could hardly offset the existing "familinerarity" of the software development planning process.