Categories
Links
Archives
Other Blogs
|
Thor Projects LLC - Welcome : Blog - Robert Bogue [MVP]
Wednesday, March 01, 2006 Monday, February 27, 2006 Friday, February 24, 2006 Thomas Edison was once asked about his failures in creating the light bulb and his response is often quoted as "We now know a thousand ways not to build a light bulb." That's a dedication to staying positive that few (if any) of us could muster these days. It's a passion for creating the light bulb that would not be discouraged.
Through some of the reading I've been doing lately, I've been consumed with thoughts about how you perceive the world around you will drive how the world around you becomes. This probably isn't true in the literal sense (however, I wouldn't discount it.) What is true, however, is that we have two types of people: The optimist, always believing that there is more than their really is – but happy in that thought, and the pessimist, always believing that there is less than there really is – and miserable or fearful in that thought.
The classic is to place a glass with water equal its total capacity and ask if it's half empty or half full. The optimist is supposed to answer that the glass is half full while the pessimist answers that it is half empty. A few severe pessimists, and I know some, would tell me that the glass may only be half empty now but due to evaporation, perhaps a crack in the glass, unidentified forces, etc., they're sure that the glass will eventually become empty. (It's about that time that I reach over and drink it to prove their point. It's a fun thing to do.)
So there's nothing new here. You already have heard these things. But what you may not instinctively realize is that optimism is its own reward. Sure, I have to accept disappointment. I've set the bar higher. I've decided to expect that things will go well, that life is ultimately good. In return, I get to delude myself into a happy state.
And, of course, the "storms" will come, as they always do to try to convince me that the world is an ugly place. And at those moments, I'm frustrated, disappointed, and worse. However, that happens so rarely, that I get most of my days filled with happiness.
The mother of one of my friends is a pessimist, the kind that believes in evaporation, she recently shared with her daughter – "See, I was right." It was in reference to some pessimistic "The sky is falling" prediction. The answer back was the classic answer from an optimist: "So what, if you always predict something bad will happen – eventually you'll be right about one of them." In other words, the optimist doesn't have to assume that everything will always go right, they can be realistic about bad things happening, and they just believe that it's a small proportion of every day life.
Fairly recently we were at a zoo and had our son's wagon stolen. We were able to recover it in relatively short order, however, its impact on our son's small mind was fascinating to watch. It had never occurred to him that someone would steal. Why would you take something that wasn't yours? This plus trying to figure out both mommy and daddy's reactions was putting his poor little mind into overdrive. The end result was we got the wagon back. He still vividly remembers the incident (perhaps too vividly.) He has changed his behavior. He still takes his wagon to the zoo; however, we keep a closer eye on it. He didn't give up. He didn't refuse to enjoy the zoo just because a bad thing happened – he simply is more aware of the possibility of a bad thing happening and tries to plan for it as best he can.
So my parting thought, a quotable, is simply this:
"Failure is only not trying because there is no hope of success. Persistence guarantees eventual success through hope."
Be an optimist, what do you have to loose?
Categories:
Personal
|
Friday, February 24, 2006
I have to say that I was a bit embarrassed to tell people I was reading Peopleware: Produtive Projects and Teams. It wasn't because the material wasn't good -- it definitely is. It's not because I felt squeamish about the title -- I didn't. However, I did feel like I should have somehow managed to have read it before now. With the original edition written in 1987 and the 2nd edition written in 1999 -- I should have read it before now. Alas, I hadn't.
Peopleware is, as the title suggests, about people. It's about how people and software development fit together. It's not another methodology, it's not a set of programming tips. It is, however, some interesting insight on how people work, don't work, and work together. It has hints of Dilbert in that it talks about the things that managers can do to effectively eliminate productivity within a group.
I collected a few quotes that I believe highlight the value of the book:
- "The major problems of our work are not so much technological as sociological in nature" (p4)
- "The statistics about reading are particularly discouraging. The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one." (p12) [Ouch]
- "People under time pressure don't work better; they just work faster." (p18)
- "Speaking of software, that industry has accustomed its clients to accept in-house developed application programs with an average defect density of one to three defects per hundred lines of code." (p21)
- "People just don't work effectively when they're locked into a no-win situation" (p28)
- "The manager's function is not to make people work, but to make it possible for people to work" (p34)
- "People can keep track of only so many human interactions" (p137) [This is particularly interesting if you account for the maximum practical size of a group of people (see The Tipping Point) and the fact that most Agile methodologies work best with smaller groups.]
The book read, to me, as the background information one needs to understand why agile methodologies work. It's sort of like reading a book about the internal combustion engine when you drive a car to work every day. You don't have to know how the car runs, but when you break down on the side of the road it comes in really handy.
If you've not managed to make it through this classic work and you work with others as a manager or as a team member -- you should.
Categories:
Professional, Book Review
|
Wednesday, February 22, 2006 I do a fair amount of writing for Jupiter Media. They have a large number of sites which cover a complete range of technical topics. One of the sites, Intranet Journal, has an index page to the SharePoint content that they have. I reference it all the time to people because it's a great way to see several people's thoughts on SharePoint in one spot. The url is http://www.intranetjournal.com/sharepoint. It's simple and something I can remember.
From there folks can find my articles and the articles of other folks who've written on SharePoint at any of the Jupiter Media sites.
... now I have one less random thought I have to hold in my head.
Categories:
Professional
|
Tuesday, February 21, 2006
Categories:
Professional
|
Monday, February 20, 2006 One of the interesting acronyms that I have run into in SharePoint is Bidi. I never really knew what it was and frankly I put into the category of “I hope I don't have to know.” I mean really, there are so many things you HAVE to know in SharePoint to get anything done, can't I get by without knowing what BiDi is?
I found out the answer is no, I don't have to know what Bidi is ... until I go to multi-lingual sites. I stumbled across it in a blog post for IE.
Categories:
Professional
|
Monday, February 20, 2006
I was trying to post a comment today to check out a book -- a book that I had read and thought I had blogged about but apparently I blogged about it in a dream. (Yea, I know sick)
The book is Professional .NET 2.0 Generics while I can certainly tear apart some of the mechanics of the book, overall it's a thorough coverage of the topic both from a breadth and from a depth perspective. I remember learning more about how the CLR works and the impact of a compile time vs. run-time type generation than I thought possible.
If you've got more than a passing interest in generics you should check it out. You never know, you may just become the generics expert at your organization.
Categories:
Professional, Book Review
|
Monday, February 20, 2006 Ben Fulton was at a recent presentation I gave on the Impact of Coding Standards and Code Reviews on Quality while reviewing some of my referrers I came across a link to his blog. (Yes, I do occaisionally go into my referrers, mainly to thank people for the link -- thanks Ben.)
The one question that he raised on his blog that I didn't fully understand during the presentation was “How do you get a Jr. Developer to review a Sr. Developer's code?” Here are a few of my thoughts on this...
1) It's a lot about personality and relationship. If you make the developer understand that it's not about experience or position and is just about working together as a team it gets easier. I find that it starts to become natural after the culture shifts towards people doing reviews as a habit. Trying to make the Jr review the Sr developers work as the first thing is a bad idea.
2) It doesn't have to be a formal code review to have value. I can't say that the majority of times that I hand code over to a Jr developer that they do a full code review. However, I do make it clear that it's their name that's checking it into source control so they're responsible for it. If I make a mistake they will be held to fixing it by their peers. It's a part of the team commitment. So they may not send me back a complete set of comments, however, my hope is that they at least read the code.
3) If you can't get comments at least get a read. Code reviews seem to work based on a whole bunch of factors. Simply reading each other's code makes everyone better. It helps you understand what the other members of the team are working on and exposes potential descrepancies between your interpretation or undertanding and theirs. This is a good thing.
At any rate. Good luck with getting code reviews to work in your organization.
Categories:
Professional
|
Monday, February 20, 2006
When I blogged about Software that Sells: A Practical Guide to Developing and Marketing Your Software Project I commented that there wasn't much information that was in the book that I didn't already know. The guide was really very light on details. Micro-ISV: From Vision to Reality is a very different story. I found all kinds of things in the book that were interesting.
I rarely “dog ear” a book these days. I make it a point to have a pad of paper and pen with me when I'm reading a book. That's mostly so I can record my thoughts. Sometimes I'll stop reading and start frantically scribbling notes. Anyway, it's lead to a lot of books that don't get “dog eared.” I even have tape flags that I use to mark what page I'm on -- thus no “dog earing.”
However, I haven't even made it through all of the pages I “dog eared” in Micro-ISV. There seemed to be a new web site or product that I didn't know about on every page. Admittedly Micro-ISV will have a relatively short shelf-life in terms of it's value because web sites change and companiese go out of business. However, for now, it's a great reference for those who are struggling to get a product company going.
The other interesting thing about the book is that it has a great number of interviews in it. Real people with real problems not unlike your own talking about them. All in all, a good read. (I suppose it doesn't hurt that the author is a former reporter.)
Categories:
Professional, Book Review
|
Next >>
|
|