Insights
Friday, December 31, 2004
Bonne Année!!
Once again, New Year's Eve finds me in la Ville de Chambéry. Unlike last year when I was very, very sick until New Year's Eve, this year has been fantastic. Yesterday, we managed to sneak in an afternoon of skiing at Margeriaz, which is very near Chambéry. It snowed a couple of days ago, so the slopes were brilliant. The only down-side was the hordes of people and the 2-hour wait in the queue to rent equipment. Other than that, it was a great day. I even managed to remember some of the stuff I learned last year at Les Menuires! For those who don't know me, I've been skiing exactly 3 times. The first time was an afternoon in Andorra, then a week last year and yesterday.
New Year's in France is a bit different than other parts of the world. In typically French fashion, a New Year's Eve party is primarily focused on food and conversation. It seems like you can't really have one without the other in this country. Maybe if you're some kind of social outcast or something.... Of course, this is in dramatic contrast to the emphasis on alcohol consumption in Ireland and to a somewhat lesser degree, in the U.S. Still, it's generally entertaining, and you can't argue with the quality of the food and the wine.
Tomorrow will be a big dinner with escargot, smoked salmon, raw oysters, foie gras and a lamb roast. Did I mention that thing about food??? Of course the surprise will be what comes from la cave. It could be anything from a 1979 Bordeaux, a 1988 Bourgogne [it was actually a 1980 premier cru and fantastic! ed.] or something completely different. This is a long way from the all-day college football fest that I grew up with. I doubt the TV will even be turned on. Still, if you're in the US, according to MSNBC there isn't much to look forward to this year in that department either.
Nearly time to head out to the festivities, so I'll wish everyone "Bonne Année" and Happy New Year. Hopefully, in the new year I'll do better at keeping track of the people in the world whom I care about, release the 3.0 version of my SourceForge project and continue to be successful at work. As always, if you haven't heard from me in a while and you're wondering if I fell off the planet, I haven't. I think about all of my (sometimes very extended) group of friends and family a lot more than I let you know. I just don't always do a very good job letting you know how much I appreciate you being part of my life.
Roll on 2005!
¶ 6:18 PM 1 comments
New Year's in France is a bit different than other parts of the world. In typically French fashion, a New Year's Eve party is primarily focused on food and conversation. It seems like you can't really have one without the other in this country. Maybe if you're some kind of social outcast or something.... Of course, this is in dramatic contrast to the emphasis on alcohol consumption in Ireland and to a somewhat lesser degree, in the U.S. Still, it's generally entertaining, and you can't argue with the quality of the food and the wine.
Tomorrow will be a big dinner with escargot, smoked salmon, raw oysters, foie gras and a lamb roast. Did I mention that thing about food??? Of course the surprise will be what comes from la cave. It could be anything from a 1979 Bordeaux, a 1988 Bourgogne [it was actually a 1980 premier cru and fantastic! ed.] or something completely different. This is a long way from the all-day college football fest that I grew up with. I doubt the TV will even be turned on. Still, if you're in the US, according to MSNBC there isn't much to look forward to this year in that department either.
Nearly time to head out to the festivities, so I'll wish everyone "Bonne Année" and Happy New Year. Hopefully, in the new year I'll do better at keeping track of the people in the world whom I care about, release the 3.0 version of my SourceForge project and continue to be successful at work. As always, if you haven't heard from me in a while and you're wondering if I fell off the planet, I haven't. I think about all of my (sometimes very extended) group of friends and family a lot more than I let you know. I just don't always do a very good job letting you know how much I appreciate you being part of my life.
Roll on 2005!
¶ 6:18 PM 1 comments
Friday, December 24, 2004
The Mirror of Self Discovery
I just finished an absolutely brilliant book called "First, Break all the Rules" by Marcus Buckingham & Curt Coffman. OK, so the book isn't new, but it was something I picked up recently in my quest to learn more about leadership and management--two things I've been actively interested in since I read "Rogue Warrior" by Richard Marcinko many years ago.
I'm sure those of you who know who Richard Marcinko is would find it a bit strange to put a reference to these two books in the same paragraph. The reality is, that to me, they're related because Mr. Marcinko is the author who really struck a chord with me about leadership as I was reading it when I was first trying to extend my capabilities in that area. A number of things illustrated by the book really spoke to me about how things could be done to achieve a strong team environment and loyalty from those who report to you. Anyway, that's where it started for me back in 2000.
So, today, I finally finished the book I remembered hearing about in the news and seeing on the bookshelf around that time. In retrospect, I don't think I was ready for the book 4 years ago. I would have gotten a lot out of it, but I think that it actually speaks to you more if you have been in a leadership or managerial role for a while. If you haven't and you read the book, you won't really appreciate it when it expounds that there are differences between skills, knowledge and talent and that "everyone has talent" in one way or another.
What I find extremely fascinating about this book (in addition to it's reference value for future personal assessment) is that it actually shows you what you can do to increase your productivity as an employee as well as a manager. If you step back (which the book suggests a couple of times) and look at yourself using the same criteria your manager should be applying to you, it will give you great insight into yourself and your own personal talents. Once you know these, your chances for personal satisfaction and therefore success in your career will be greatly improved. In another, more tangential way, it provides advice that you can apply to all aspects of your interactions with other people.
Take the supposition from the book that great managers should define the right outcomes and then let each person figure out how best they may be achieved. If you think about this, it makes perfect sense.
Still, it is very easy to be overbearing and try to tell someone exactly how to do something--especially if you think you're right or you've done something similar in the past. This was a particularly hard lesson for me to learn, but one which I had to deal with in nearly my very first team at Informix. However, think about the statement more broadly in terms of your personal interactions. If you've read anything about negotiation skills, you'll probably instantly see that there's a connection here as well:
When you want someone to do something for you, articulate what you want to happen and then accept that they will be able to achieve it.
In negotiation (what we do with people every day if you think about it), you generally establish what you want to happen, and then negotiate about how you get there. The "what you want to happen" is the big-ticket outcome of the interaction. Maybe this is you want to buy a car for 10K less than the asking price, or maybe you are in labor negotiations and you want to get the factory operating again as soon as possible with the smallest negative future impact to the business. Once you have defined your "right outcome", then you can discuss or negotiate the best way that it can be done. In a lot of cases, it is similar to the managerial context: you don't necessarily care the how, you just want something to happen. Of course, it goes without saying that the how must be ethical and not violate any laws. I'm not trying to say the ends justify the means. Sometimes, like the labor dispute, the how does matter.
Even in a more relevant setting (to the blog, at least) like software development, the architect should define the outcomes (the what should be built) and give the individual developers enough freedom in the how this is met so that they can successfully answer some of the key 12 questions in the book. In this specific case, the following ones are most important:
These three questions--in particular the first two, define the foundations on which tangible business performance can be based. The happier your developers are, the more pride they will take in the work they do and therefore the better it will be. As mentioned in a number of sources, the cheapest place to find problems in the software is during development. If you have appropriately talented and motivated employees, the defects are less likely to be introduced in the first place.
If the organization, the manager, or the architect attempts to put too many controls on how the person does their job, they begin to wonder why they are even here. People want to be valued as individual contributers to a greater whole. If they have defined outcomes and an understanding how that fits into the bigger picture, you will generally have productive developers. This does not mean things like coding standards are a bad thing. Basic foundations must be laid for order and safety. You can't just drive on whichever side of the road you like, for example, but it doesn't mean you must drive a VW Beetle or a Ferrari. It just means that everyone's following the same fundamental rules. What you do within those rules is up to you.
I realize I'm drifting off track a little here, but the point I'm trying to make is that anyone who absorbs what is said in "First, Break all the Rules" instead of just reading the words will come away with wisdom which can be applied in all directions: up, side to side and down. If you're responsible for people, it will help you be a better manager, but if you aren't, you'll still learn how you can be a better employee and find a place where your talents can excel and you can be happy. If you don't get these things from the book, come back to it in a couple of years. It will still be as relevant and valid when you do.
¶ 11:46 AM 0 comments
I'm sure those of you who know who Richard Marcinko is would find it a bit strange to put a reference to these two books in the same paragraph. The reality is, that to me, they're related because Mr. Marcinko is the author who really struck a chord with me about leadership as I was reading it when I was first trying to extend my capabilities in that area. A number of things illustrated by the book really spoke to me about how things could be done to achieve a strong team environment and loyalty from those who report to you. Anyway, that's where it started for me back in 2000.
So, today, I finally finished the book I remembered hearing about in the news and seeing on the bookshelf around that time. In retrospect, I don't think I was ready for the book 4 years ago. I would have gotten a lot out of it, but I think that it actually speaks to you more if you have been in a leadership or managerial role for a while. If you haven't and you read the book, you won't really appreciate it when it expounds that there are differences between skills, knowledge and talent and that "everyone has talent" in one way or another.
What I find extremely fascinating about this book (in addition to it's reference value for future personal assessment) is that it actually shows you what you can do to increase your productivity as an employee as well as a manager. If you step back (which the book suggests a couple of times) and look at yourself using the same criteria your manager should be applying to you, it will give you great insight into yourself and your own personal talents. Once you know these, your chances for personal satisfaction and therefore success in your career will be greatly improved. In another, more tangential way, it provides advice that you can apply to all aspects of your interactions with other people.
Take the supposition from the book that great managers should define the right outcomes and then let each person figure out how best they may be achieved. If you think about this, it makes perfect sense.
Still, it is very easy to be overbearing and try to tell someone exactly how to do something--especially if you think you're right or you've done something similar in the past. This was a particularly hard lesson for me to learn, but one which I had to deal with in nearly my very first team at Informix. However, think about the statement more broadly in terms of your personal interactions. If you've read anything about negotiation skills, you'll probably instantly see that there's a connection here as well:
When you want someone to do something for you, articulate what you want to happen and then accept that they will be able to achieve it.
In negotiation (what we do with people every day if you think about it), you generally establish what you want to happen, and then negotiate about how you get there. The "what you want to happen" is the big-ticket outcome of the interaction. Maybe this is you want to buy a car for 10K less than the asking price, or maybe you are in labor negotiations and you want to get the factory operating again as soon as possible with the smallest negative future impact to the business. Once you have defined your "right outcome", then you can discuss or negotiate the best way that it can be done. In a lot of cases, it is similar to the managerial context: you don't necessarily care the how, you just want something to happen. Of course, it goes without saying that the how must be ethical and not violate any laws. I'm not trying to say the ends justify the means. Sometimes, like the labor dispute, the how does matter.
Even in a more relevant setting (to the blog, at least) like software development, the architect should define the outcomes (the what should be built) and give the individual developers enough freedom in the how this is met so that they can successfully answer some of the key 12 questions in the book. In this specific case, the following ones are most important:
- Do I know what is expected of me at work?
- Do I have the materials and equipment I need to do my work correctly?
- Do I have the opportunity to do what I do best every day?
These three questions--in particular the first two, define the foundations on which tangible business performance can be based. The happier your developers are, the more pride they will take in the work they do and therefore the better it will be. As mentioned in a number of sources, the cheapest place to find problems in the software is during development. If you have appropriately talented and motivated employees, the defects are less likely to be introduced in the first place.
If the organization, the manager, or the architect attempts to put too many controls on how the person does their job, they begin to wonder why they are even here. People want to be valued as individual contributers to a greater whole. If they have defined outcomes and an understanding how that fits into the bigger picture, you will generally have productive developers. This does not mean things like coding standards are a bad thing. Basic foundations must be laid for order and safety. You can't just drive on whichever side of the road you like, for example, but it doesn't mean you must drive a VW Beetle or a Ferrari. It just means that everyone's following the same fundamental rules. What you do within those rules is up to you.
I realize I'm drifting off track a little here, but the point I'm trying to make is that anyone who absorbs what is said in "First, Break all the Rules" instead of just reading the words will come away with wisdom which can be applied in all directions: up, side to side and down. If you're responsible for people, it will help you be a better manager, but if you aren't, you'll still learn how you can be a better employee and find a place where your talents can excel and you can be happy. If you don't get these things from the book, come back to it in a couple of years. It will still be as relevant and valid when you do.
¶ 11:46 AM 0 comments
Wednesday, December 08, 2004
"Pacific" is an Ocean
How many times have you been in a conversation with otherwise educated, sensible people and you hear something along the lines of "In this pacific case, I think we should..." You wince internally and just figure they made a mistake because they're in a hurry, or they're trying to make a point and their mouth got ahead of their brain or whatever--generally giving them the benefit of the doubt. However, it seems that this often isn't a one-time occurrence. Funnily enough, none of the 6 entries on dictionary.com for pacific seem to mention that it's an appropriate replacement for specific.
Another one of these sorts of language abuses that I have heard more than once recently when a number of things need to be considered before one is decided goes like this: "We need to make sure this gets trashed out before we have the next meeting." Normally, one would use thrashed in this situation, but it occurs more often than you might imagine.
When I started this post this morning, I didn't have an example which backed up what I'm saying, but, thanks to Slashdot, this timely article from the New York Times about appalling writing skills in corporate America seems to fit the bill. As one Slashdot reader pointed out, the examples are pretty bad. I would be lying to say that I never make mistakes, or that I didn't get my tongue tied in knots occasionally, but stuff like "there" instead of "they're" is just basic English everyone should've learned in grade school. Makes me think back to how the CS students groaned about the campus-wide initiative to require a minimum amount of writing in all classes. Methinks it was not stressed enough.
I only hope that the amount of writing required for students at UMR has increased rather than decreased. No matter how intelligent you are, if you can't communicate orally or in written form, people will think you're an idiot--even if you aren't.
Simley is courtesy of the Gaim project and is Copyright © 1998-2004 by the Gaim team.
¶ 7:26 AM 0 comments
Another one of these sorts of language abuses that I have heard more than once recently when a number of things need to be considered before one is decided goes like this: "We need to make sure this gets trashed out before we have the next meeting." Normally, one would use thrashed in this situation, but it occurs more often than you might imagine.
When I started this post this morning, I didn't have an example which backed up what I'm saying, but, thanks to Slashdot, this timely article from the New York Times about appalling writing skills in corporate America seems to fit the bill. As one Slashdot reader pointed out, the examples are pretty bad. I would be lying to say that I never make mistakes, or that I didn't get my tongue tied in knots occasionally, but stuff like "there" instead of "they're" is just basic English everyone should've learned in grade school. Makes me think back to how the CS students groaned about the campus-wide initiative to require a minimum amount of writing in all classes. Methinks it was not stressed enough.
I only hope that the amount of writing required for students at UMR has increased rather than decreased. No matter how intelligent you are, if you can't communicate orally or in written form, people will think you're an idiot--even if you aren't.
Simley is courtesy of the Gaim project and is Copyright © 1998-2004 by the Gaim team.
¶ 7:26 AM 0 comments
Tuesday, December 07, 2004
No More ThinkPads
I've been following the various news articles about IBM selling off it's PC division with just a little bit of sadness. I have previously owned two ThinkPads (a 350C and a 770X) which were probably two of my favorite machines ever. They were better built, more robust and just nicer to use than any of the similar machines on the market at the time, and for some things, I still like them better than the ones I have now. Of course, the ESC key was in an annoying place for vi usage, but you got used to that after a few errant F1 keystrokes.
Still, with all of the other initiatives Big Blue has on the table, you have to wonder if there isn't merit to some of the points Cormac O'Reilly makes in the opinion piece Apple of IBM's eye over on the Register. If IBM and Apple did get a little cozier, it wouldn't be the first time. I don't know if anyone else remembers Taligent, but it goes to show that the two companies have played software as well as hardware games in the past. The previous link mentions some of the similarities between CommonPoint and Java which is an interesting connection I hadn't thought about. If IBM does start marketing PCs based on the PowerPC chip, it has a few OS choices: AIX, Linux and of course MacOS X. The core OS (Darwin/FreeBSD) is certainly portable, and the desktop will happily sit on top of whatever hardware is running underneath. Those of us who used to run NEXTSTEP know that it ran on M68000, Intel, SPARC and HPPA as well.
Even if it is a nice thought, I don't really see Apple voluntarily giving up its hardware business--something that it surely would be forced to do given IBM's ability to produce hardware at substantially lower costs than Apple can. When Apple bought NeXT in 1996, it had the opportunity (and the promise) that it would still support other hardware architectures. It didn't because Apple couldn't compete as a software-only company. It relies on the premium of the hardware to generate vital revenue. It has also actively killed efforts to stop the production of any clones (or even machines which looked like Macs) which would take away from its own hardware sales. Looking at the market today, I don't think that a PowerPC-based PC from IBM which could run Linux, AIX or whatever else IBM decided was necessary would be a sufficiently large enough carrot to lure Apple into software-only mode.
Even before the announcement by the Korean government proclaiming the Post-PC Era, it was fairly obvious that times are changing rapidly. Web Services, SOA, 3G, PDAs and more capable thin clients (can we say X Terminal or Plan 9/Brazil?) are all becoming more and more prevalent. The original IBM PC (ok, so I had one of the second series with 640K of RAM (128 on the motherboard), a 1200 baud modem, 2 360K floppies and CGA graphics) refined the personal computer into something that proved pervasive. Surely, IBM is forward-thinking enough to believe that it has something which will at least equal the impact and financial contribution of the PC. It has the money, the software and the processing architecture to do just about anything it wants--with or without Redmond's blessing. It will be interesting to see what it will turn into.
¶ 10:31 PM 0 comments
Still, with all of the other initiatives Big Blue has on the table, you have to wonder if there isn't merit to some of the points Cormac O'Reilly makes in the opinion piece Apple of IBM's eye over on the Register. If IBM and Apple did get a little cozier, it wouldn't be the first time. I don't know if anyone else remembers Taligent, but it goes to show that the two companies have played software as well as hardware games in the past. The previous link mentions some of the similarities between CommonPoint and Java which is an interesting connection I hadn't thought about. If IBM does start marketing PCs based on the PowerPC chip, it has a few OS choices: AIX, Linux and of course MacOS X. The core OS (Darwin/FreeBSD) is certainly portable, and the desktop will happily sit on top of whatever hardware is running underneath. Those of us who used to run NEXTSTEP know that it ran on M68000, Intel, SPARC and HPPA as well.
Even if it is a nice thought, I don't really see Apple voluntarily giving up its hardware business--something that it surely would be forced to do given IBM's ability to produce hardware at substantially lower costs than Apple can. When Apple bought NeXT in 1996, it had the opportunity (and the promise) that it would still support other hardware architectures. It didn't because Apple couldn't compete as a software-only company. It relies on the premium of the hardware to generate vital revenue. It has also actively killed efforts to stop the production of any clones (or even machines which looked like Macs) which would take away from its own hardware sales. Looking at the market today, I don't think that a PowerPC-based PC from IBM which could run Linux, AIX or whatever else IBM decided was necessary would be a sufficiently large enough carrot to lure Apple into software-only mode.
Even before the announcement by the Korean government proclaiming the Post-PC Era, it was fairly obvious that times are changing rapidly. Web Services, SOA, 3G, PDAs and more capable thin clients (can we say X Terminal or Plan 9/Brazil?) are all becoming more and more prevalent. The original IBM PC (ok, so I had one of the second series with 640K of RAM (128 on the motherboard), a 1200 baud modem, 2 360K floppies and CGA graphics) refined the personal computer into something that proved pervasive. Surely, IBM is forward-thinking enough to believe that it has something which will at least equal the impact and financial contribution of the PC. It has the money, the software and the processing architecture to do just about anything it wants--with or without Redmond's blessing. It will be interesting to see what it will turn into.
¶ 10:31 PM 0 comments
