Christopher Warner

Recently, I have picked up a copy of “Fearless Change” at the recommendation of one of my old professors and am a couple of chapters in. I am having what would be a communication problem, and/or am simply lacking the appropriate language to get my points across. However, it was pointed out that it maybe more change that people fear. They are so scared to do anything new, or anything different, that they just continue to label something new, but do the same exact thing! So, with that, here we are. I’m not normally a big fan of this sort of book because I believe the content usually dictates rather than guides and people will find validation in whatever nuggets apply to their specific situation. Which leads to an obtuse and distorted skew of what the original authors had in mind. However, this book seems to be more a guide thus far, leaving the “patterns” described to later chapters in the book. This way it can be used as a reference down the road. I’m not currently finished but there is a passage that I’ve come to on page 46, chapter six. Which describes my own situation down to the marrow. It discusses a pattern called Just Do It which is second nature to opensource types but not so much for the business side of things. It states:

Linda recently received an e-mail from an old friend. He knows that she’s written three books and has another in progress. He’s thinking about writing one so he asked her advice. They exchanged some e-mails. He asked about the format for the proposal and whether he should have most of the book written before he contacted the publisher and if his idea was too broad or whether he should focus on just one part of it and…. Finally Linda said, “Brad, I’ve got a great pattern that you might think about applying at this point in your writing adventure. It’s called Just Do It(177).”

There is also another great term used in the following paragraph deemed “analysis paralysis“. Which I have seen more times than I can count and is usually the nail in the coffin or slow down for any successful project. Basically, one tries to perfect or plan every single little detail and function of a project without having done any of it at all. They eventually sit down to do something and it’s so overwhelming that they begin to cut, cut and cut some more to where they are eventually where they would have been if they started the project weeks if not months ago! This book alone was worth it for that term but also for some of the quotes:

Baseball legend Casey Stengel quipped, “Finding good players is easy. Getting them to play as a team is another story.”

Once finished I will attempt an overall summary review but so far it’s looking like a useful read.

Hah! This blog is great!! It’s pretty much for the most part all true. From standardizing to gconf and so on (unfortunately he hasn’t done anything interesting discussing gdb yet). These are all valid criticisms of anyone dealing with Linux on a daily basis. The latest Ubuntu upgrade has some serious mutex/futex issues in regards to sound devices as well. Anyway, all this bitching is good; i’ve done my fair share and hopefully something good comes of it. I suspect though, there will be a lot of talking, much reflecting and then everyone will go back to the same old; that’s what always happens. The next step; he’ll find much to bitch about in regards to OSX soon; then he’ll smarten up and realize it’s an industry problem. By then he’ll probably be reaching his first “jaded” stage. All you end up doing is working on solutions for your own problems and then moving on with your life. The next stage is to say “fuck all this shit, I don’t need this”. The final stage is to stop caring; and that’s where I’m at. I’m largely and wholly indifferent, if the tool works I’ll use it; free or not.

This leads back into opensource projects having process managers and knowing when idealism is useful. Realizing that it’s about solving problems and if it’s not solving any problems then you don’t even have your foot in the door. It’s just not about code.