Yuan Yijun (bbbush) wrote,
Yuan Yijun
bbbush

  • Mood:

20051107

购物



购物
周末去购物,一共花了大概是八百多。如果市面上的东西都很便宜,千把块钱就可以搞定一个冬天的穿用该有多好。:(
除了键盘鼠标之外,买的大宗物品就是两件衬衣合计两百五十。不知道在我的蹂躏下,洗一水之后会不会彻底毁掉。该买一个烫衣板之类的吧。
比较得意的是找到了那种防潮防霉的“衣物整理袋”。不知道谁起的这种名字,不过很好用。以前一直纳闷为什么深圳没有,甚至想从南京买几个寄过来。不买到这样的东西,千万不能买好衣服。在万佳超市慢慢找,终于找到了。也有适合被褥和西服的,虽然还没有穿西服的必要。下周打算再买件毛衣,买条裤子,一双鞋。如果要切换风格,那么还需要一大笔,所以还是这样吧。努力向中伟帅哥,杭以及翔学习穿衣服。比较麻烦的是,我喜欢花纹甚于款式,所以衣服总是不合适,不搭调 :(
另外的大宗物品就是三张 CD,合计两百,一份是传说中的 Henryk Szeryng, J.S.Bach "Sonatas and Partitas for Solo Violin" BWV 1001-1006, 因为 concertofish 提到过所以决不放过。不过没有听的动力了,只能说,这张盘的盒子还是挺漂亮的。(暴殄天物,买椟还珠。。。。) 另外一张是 Tim Buckley,"Tim Buckley & Goodbye and Hello",也许是剪辑?想不出怎么会只有一张 CD 并且售价高达六十 (打三折)。李冬有这张 CD,因为这个封面以前见过。第三张是 Nancy Wilson, Ann Wilson, "The Essential Heart",因为封面上两位很眼熟,很漂亮,所以就买下了。这样,除了 Szeryng 的这一张,未了的心愿就剩下了 Gould, J.S.Bach, "Inventions et Sinfonias"。万佳超市楼下的那个 CD 店齐刷刷的摆了一排 Glenn Gould,看得我头上冒汗两手发凉,因为似乎都在李冬那里见过吧。
说起来我和 CD 店里遇到的那个女人很像。她毫不隐瞒自己的鉴赏水准,觉得好听就要听,据她自己炫耀,家里器材也不错,“我很发烧的哦,你帮我看看,这张 CD 是啥内容。。。。” 我真恨不得告诉她所有的都很好听,都买下来吧,最好送我一张。。。。
最后就是买被子。才发现并不是越大的东西越贵。棉胎只要 60,好一些的各种被胎也就是百十来块。可是被套,一个被套至少一百七,这就是万佳的还算便宜的价格,并且没有我喜欢的花样。男孩子,这个挺好,一百七,送一条运动毛巾给你。哎,算了吧,我再去找找。以前黄之光那套斑点狗的好漂亮,现在应该还有他那张慵懒的照片吧。这个家伙埋头复习中,好久不见了。他这样的人真少。


二流教材看完了。昨天是百无聊赖,虽然书柜里摆了几本书一定要看完的,可是懒得。zhaoway 大人列出来隐居一年以来读过的书,果然奇妙,不知道他怎么能潜心阅读的?昨天继续在 《具体数学》里面看有趣的注释,因为内容看不太懂。想想高普当年是如何潜心研究数学的呢?
高普和史栋杰两位诗人,这几天在 MSN 里面对话,超级文雅的。如果从小写诗成了习惯,那么不文雅也难。如果从小的作文就像这样罗嗦,平淡,那么现在不平淡罗嗦也难。



今天中级开发者们又开会,我们小的们又没有任务做,本周即使周六加班,我预计也不会很忙吧。怎么不浪费时间呢?很奇怪,我觉得在公司里闲着是一种罪恶,却不知道如何能更主动一些。

一篇好文章:"管理者如何控制公司中的 Geeks"
Fast Company Magazine

How to Manage Geeks

Eric Schmidt, CEO of Novell, believes that "geek" is a badge of honor. (After all, he is one!) But how do you manage these geek gods? Just follow his nine-point techie tutorial.
From: Issue 25| June 1999 | Page 174 By: Russ Mitchell Illustrations by: Ed Fotheringham

There's a saying in Silicon Valley: "The geeks shall inherit the earth."

That's a sign, if you needed one, that we have permanently entered a new economy. Once a term of derision, the label "geek" has become a badge of honor, a mark of distinction. Anyone in any business in any industry with any hope of thriving knows that he or she is utterly dependent on geeks -- those technical wizards who create great software and the powerful hardware that runs it. The geeks know it too -- a fact that is reflected in the rich salaries and hefty stock options that they now command.

But how do you manage these geek gods? Perhaps no one knows better than Eric Schmidt, CEO of Novell Inc. Schmidt, 44, is a card-carrying geek himself: His resume boasts a computer-science PhD and a stint at Sun Microsystems, where he was the chief technology officer and a key developer of the Java software language. And, as if his technical skills weren't enough to prove the point, Schmidt even looks the part, with his boy-genius face, his wire-rim spectacles, and his coder's pallid complexion.

Two years ago, Schmidt left Sun and took charge at Novell, where he has engineered an impressive turnaround. After years of gross mismanagement, the $1 billion networking-software company, headquartered in Provo, Utah, had been written off by competitors and industry observers alike. Since Schmidt's arrival, however, the company has become steadily profitable, its stock price has more than doubled, and, within its field, Novell has again come to be seen as a worthy competitor to Microsoft.

A good deal of the credit for Novell's turnaround must go to Schmidt, who excels at getting the best out of his geeks. He has used his tech savvy to bring focus to Novell's product line and his geek-cred to reenergize a workforce of highly skilled but (until recently) deeply dispirited technologists. In general, Schmidt speaks of his geeks in complimentary terms, while acknowledging their vulnerabilities and shortcomings. "One of the main characteristics of geeks is that they are very truthful," says Schmidt (who, in fact, uses the term "geek" only occassionally). "They are taught to think logically. If you ask engineers a precise question, they will give you a precisely truthful answer. That also tends to mean that they'll only answer the question that you asked them. If you don't ask them exactly the right question, sometimes they'll evade you -- not because they're lying but because they're being so scrupulously truthful."

With that rule of geek behavior in mind, Fast Company went to Novell headquarters to ask Schmidt a series of precise, carefully worded questions. His answers add up to a short course in how to bring out the best in your geeks.

You've got to have your own geeks

Today innovation drives any business. And since you don't want to outsource your innovation, you need to have your own geeks. Look at trends in e-commerce: Who would have thought that all of these "old" companies would have to face huge new distribution-channel issues, all of which are driven by technology? The truth is, you need to have a stable of technologists around -- not just to run your systems but also to help you figure out which strategies to pursue, which innovations to invest in, and which partnerships to form.

The geeks control the limits of your business. It's a fact of life: If the technologists in your company invent something ahead of everybody else, then all of a sudden your business will get bigger. Otherwise, it will get smaller. You simply have to recognize and accept the critical role that technologists play. All new-economy businesses share that property.

Get to know your geek community

According to the traditional stereotype, geeks are people who are primarily fascinated by technology and its uses. The negative part of that stereotype is the assumption that they have poor social skills. Like most stereotypes, it's true in general -- but false at the level of specifics. By society's definition, they are antisocial. But within their own community, they are actually quite social. You'll find that they break themselves into tribes: mainframe-era graybeards, Unix people who started out 20 years ago, the new PC-plus-Web generation. They're tribal in the way that they subdivide their own community, but the tribes don't fight each other. In fact, those tribes get along very well -- because all of them fight management.

Perhaps the least-becoming aspect of the geek community is its institutional arrogance. Remember, just because geeks have underdeveloped social skills doesn't mean that they don't have egos. Tech people are uppity by definition: A lot of them would like to have been astronauts. They enjoy the limelight. In a power relationship with management, they have more in common with pro basketball players than they do with average workers. Think of your techies as free agents in a highly specialized sports draft. And the more specialized they are, the more you need to be concerned about what each of them needs as an individual.

Learn what your geeks are looking for

This is a golden era for geeks -- it doesn't get any better than this. In the early 1970s, an engineering recession hit, and we reached a low point in engineering and technical salaries. Ever since then, salaries have been going way up. Geeks have figured out that increasing their compensation through stock options is only fair: They expect to share in the wealth that they help to create through technology. Today technology salaries are at least twice the national average. In fact, tech salaries are going through the roof, and non-tech salaries are not -- which presents a serious problem for many companies.

But, as important as money is to tech people, it's not the most important thing. Fundamentally, geeks are interested in having an impact. They believe in their ideas, and they like to win. They care about getting credit for their accomplishments. In that sense, they're no different from a scientist who wants credit for work that leads to a Nobel Prize. They may not be operating at that exalted level, but the same principle applies.

Create new ways to promote your geeks

If you don't want to lose your geeks, you have to find a way to give them promotions without turning them into managers. Most of them are not going to make very good executives -- and, in fact, most of them would probably turn out to be terrible managers. But you need to give them a forward career path, you need to give them recognition, and you need to give them more money.

Twenty years ago, we developed the notion of a dual career ladder, with an executive career track on one side and a technical career track on the other. Creating a technical ladder is a big first step. But it's also important to have other kinds of incentives, such as awards, pools of stock, and nonfinancial kinds of compensation. At Novell, we just added a new title: distinguished engineer. To become a distinguished engineer, you have to get elected by your peers. That requirement is a much tougher standard than being chosen by a group of executives. It's also a standard that encourages tech people to be good members of the tech community. It acts to reinforce good behavior on everyone's part.

Either Geeks are part of the solution -- or they're the problem

Here's another thing you need to know about the geek mind-set: Because tech people are scientists or engineers by training, they love to solve really hard problems. They love to tackle a challenge. The more you can get them to feel that they're helping to come up with a solution to a tough problem, the more likely they are to perform in a way that works for you.

When you talk with them, your real goal should be to engage them in a dialogue about what you and they are trying to do. If you can get your engineering team to agree with what you're trying to accomplish, then you'll see them self-organize to achieve that outcome. You'll also need to figure out what they're trying to accomplish -- because, no matter what you want, that's probably what they're going to do.

The next thing you need to remember is that you can tell them what to do, but you can't tell them how to do it. You might as well say to a great artist, "I'll describe to you what a beautiful painting is. Then I'll give you an idea for a particular painting. I'll tell you which colors to use. I'll tell you which angle to use. Now you just paint that painting." You'd never get a great painting out of any artist that way -- and you'll never get great work out of your geeks if you try to talk to them like that. You need to give them a problem or a set of objectives, provide them with a large amount of hardware, and then ask them to solve the problem.

The best judges of geeks are other geeks

Make sure that there is always peer-group pressure within your project teams. For example, if you want to motivate your project leaders, just require them to make presentations to each other. They care a great deal about how they are perceived within their own web of friends and by the professional community that they belong to. They're very good at judging their own. And they're often very harsh: They end up marginalizing the people who are terrible -- for reasons that you as a manager may not quite understand.

It sounds like I'm touting tech people as gods, but there are plenty of bad projects, and there is plenty of bad engineering and bad technology. You're always going to encounter techies who are arrogant and who aren't as good as they think they are. A team approach is the best way to deal with that problem. Tech people know how to deal with the wild ducks in their group -- on their own and with the right kind of peer pressure.

Look for the natural leaders among your geeks

In a high-tech company that is run by engineers, what matters most is being right. And what's "right" is determined by outcomes. You can listen to lots of exceptionally bright people talk about their brilliant vision. I've done it for the past 25 years. But what matters is, Which ones deliver on their vision? When a project is on the line, who actually gets the job done?

Every team has a natural leader -- and often that leader is not a team's official manager. Your job is to get the team motivated. Once you do that, the natural leaders will emerge very quickly. If you keep an eye on the team, you can figure out who those natural leaders are -- and then make sure that they're happy and that they have everything they need to do their job. For instance, natural leaders need to feel that they have access to the company's senior managers. Don't forget: They feel like they're changing the world -- so you need to make them feel like you're helping them do that.

There are easy ways that you can help them out. For example, encourage them to bypass layers of middle management and to send you email directly. Sure, that will piss off the people in middle management, but it's better to piss off those people than to piss off your key project leaders.

Be prepared for when the geeks hit the fan

You can divide project teams into two categories. First, there is the preferred variety: You get an engineering team that's absolutely brilliant, that executes well, and that's exactly right in its assumptions. Second, there is the more usual variety: You get an engineering team that has a very strong opinion about what it's trying to do -- but that's on the wrong track, because some of its assumptions are wrong. That second kind of team is what you have to focus your attention on. But often you can't intervene from the top down. You have to find a way to come at the problem from the side.

At Novell, we have a series of checkpoints at which our teams get lateral feedback -- feedback that comes from outside of the management hierarchy. Every six weeks, we have three days of product reviews. But it's not just management conducting those reviews. We also bring in smart technologists with good memories: They remind us of what everybody committed to.

In most technology companies, there are always a few people who, everyone agrees, have better taste than anyone else. Those are the people whom everyone goes to; they serve as reviewers or advisers. At Sun Microsystems, for instance, it's Bill Joy. At Novell, it's Drew Major, the founder and chief scientist. Everyone knows that when Drew gets involved in a project, he'll size up quickly what needs to get done, and people will listen to him.

In general, as long as you consider everyone's ideas, most teams react well to management decisions. If you have to make a business decision that conflicts with what your engineers want to do, they'll accept it -- as long as it is truly a business decision. On the other hand, if the decision is based on a technology analysis by someone whom the engineers do not respect professionally, then they'll never agree to it. So, if you're facing a decision that you know will affect a team negatively, you must vet that decision through a technologist who has that team's respect.

Too many geeks spoil the soup

If you want your geeks to be productive, keep your teams small. The productivity of any project is inversely proportional to the size of the project team. In the software business, most problems draw on the efforts of large numbers of people. Typically, companies deal with a problem by putting together a large team and then giving that team a mission. But in this industry, that approach almost never works. The results are almost invariably disappointing. Still, people keep doing it that way -- presumably because that's the way they did it last year. The question is, How do you break out of that mode? It seems to be a cancer on the industry.

On a large team, the contributions of the best people are always smaller, and overall productivity is always lower. As a general rule, you can count on each new software project doubling in team size and in the amount of code involved -- and taking twice as long -- as the preceding project. In other words, the average duration of your projects will go from 2 years to 4 years to 8 years to 16 years, and so on. You can see that cycle with almost any technology. Two or three people invent a brilliant piece of software, and then, five years later, 1,000 people do a bad job of following up on their idea. History is littered with projects that follow this pattern: Windows, Unix, Java, Netscape Navigator.

The smaller the team, the faster the team members work. When you make the team smaller, you make the schedule shorter. That may sound counterintuitive, but it's been true for the past 20 years in this industry, and it will be true for another 20 years. The only method that I've found that works is to restrict the size of teams arbitrarily and painfully. Here's a simple rule of thumb for techie teams: No team should ever be larger than the largest conference room that's available for them to meet in.

At Novell, that means a limit of about 50 people. We separate extremely large projects into what we call "Virtual CDs." Think of each project as creating a CD-ROM of software that you can ship. It's an easy concept: Each team has to ship a CD of software in final form to someone else -- perhaps to another team, perhaps to an end user. When you treat each project as a CD, you enable one group to say to another, "Show me the schedule for your CD. When is this deliverable coming?" It's the kind of down-to-earth approach that everyone can understand, that techies can respect and respond to, and that makes almost any kind of project manageable.

Russ Mitchell rmitchell@usnews.com , a senior writer for U.S. News & World Report, writes about business and technology from Silicon Valley. You can visit Novell Inc. on the Web (www.novell.com).
Copyright © 2005 Mansueto Ventures LLC. All rights reserved.
Fast Company, 375 Lexington Avenue.,New York , NY 10017


今天很喜欢这个词:Resemblance.
Tags: 流水账
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments