中秋诗词集锦

中秋诗词 农历八月十五日是我国传统的中秋节，也是我国仅次于春节的第二大传统节日。八月十五恰在秋季的中间，故谓之中秋节。 我国古历法把处在秋季中间的八月，称谓“仲秋”，所以中秋节又叫“仲秋节”。 中秋之夜，月色皎洁，古人把圆月视为团圆的象征，因此，又称八月十五为“团圆节”。古往今来，人们常用“月圆、月缺” 来形容“悲欢离合”，客居他乡的游子，更是以月来寄托深情。 唐代诗人李白的“举头望明月，低头思故乡”，杜甫的“露从今夜白，月是故乡明”，宋代王安石的“春风又绿江南岸，明月何时照我还”等诗句，都是千古绝唱。 月下独酌 李白 花间一壶酒，独酌无相亲。 举杯邀明月，对影成三人。 月既不解饮，影徒随我身。 暂伴月将影，行乐须及春。 我歌月徘徊，我舞影零乱。 醒时同交欢，醉后各分散。 永结无情游，相期邈云汉。 八月十五夜月 杜甫 满月飞明镜，归心折大刀。 转蓬行地远，攀桂仰天高。 水路疑霜雪，林栖见羽毛。 此时瞻白兔，直欲数秋毫。 十五夜望月 王建 中庭地白树栖鸦，冷露无声湿桂花。 今夜月明人尽望，不知秋思落谁家！ 南斋玩月 王昌龄 高卧南斋时，开帷月初吐。 清辉澹水木，演漾在窗户。 荏苒几盈虚，澄澄变今古。 美人清江畔，是夜越吟苦。 千里共如何，微风吹兰杜。 中秋月 苏轼 暮云收尽溢清寒，银汉无声转玉盘。 此生此夜不长好，明月明年何处看。 中秋月 齐已 空碧无云露湿衣，众星光外涌清规。 东林莫碍渐高势，四海正看当路时。 还许分明吟皓魄，肯教幽暗取丹枝。 可怜关夜婵娟影，正对五候残酒卮。 关山月 李白 明月出天山，苍茫云海间。 长风几万里，吹度玉门关。 汉下白登道，胡窥青海湾。 由来征战地，不见有人还。 戍客望边色，思归多苦颜。 高楼当此夜，叹息未应闲。 夜思 李白 床前明月光，疑是地上霜。 举头望明月，低头思故乡。 月夜 刘方平 更深月色半人家，北斗阑干南斗斜。 今夜偏知春气暖，虫声新透绿窗纱。 嫦娥 李商隐 云母屏风烛影深，长河渐落晓星沈。 嫦娥应悔偷灵药，碧海青天夜夜心。 月夜忆舍弟 杜甫 戍鼓断人行，秋边一雁声。 露从今夜白，月是故乡明。 有弟皆分散，无家问死生。 寄书长不达，况乃未休兵。 望月怀远 张九龄 海上生明月，天涯共此时。 情人怨遥夜，竟夕起相思！ 灭烛怜光满，披衣觉露滋。 不堪盈手赠，还寝梦佳期。 霜月 李商隐 初闻征雁已无蝉，百尺楼高水接天。 青女素娥俱耐冷，月中霜里斗婵娟 秋宵月下有怀 孟浩然 秋空明月悬，光彩露沾湿。 惊鹊栖未定，飞萤卷帘入。 庭槐寒影疏，邻杵夜声急。 佳期旷何许！望望空伫立。 中秋待月 陆龟蒙 转缺霜输上转迟， 好风偏似送佳期。 帘斜树隔情无限， 烛暗香残坐不辞。 最爱笙调闻北里， 渐看星潆失南箕。 何人为校清凉力， 欲减初圆及午时。 倪庄中秋 元好问 强饭日逾瘦， 狭衣秋已寒。 儿童漫相忆， 行路岂知难。 露气入茅屋， 溪声喧石滩。 山中夜来月， 到晓不曾看。 八月十五夜桃源玩月 刘禹锡 尘中见月心亦闲，况是清秋仙府间。 凝光悠悠寒露坠，此时立在最高山。 碧虚无云风不起，山上长松山下水。 群动悠然一顾中，天高地平千万里。 少君引我升玉坛，礼空遥请真仙官。 云*(左车右并)欲下星斗动，天乐一声肌骨寒。 金霞昕昕渐东上，轮欹影促犹频望。 绝景良时难再并，他年此日应惆怅。 中秋月 晏殊 十轮霜影转庭梧，此夕羁人独向隅。 未必素娥无怅恨，玉蟾清冷桂花孤。 中秋月 苏轼 暮云收尽溢清寒，银汉无声转玉盘。 此生此夜不长好，明月明年何处看。 八月十五日夜湓亭望月 白居易 昔年八月十五夜，曲江池畔杏园边。 今年八月十五夜，湓浦沙头水馆前。 西北望乡何处是，东南见月几回圆。 昨风一吹无人会，今夜清光似往年。 天竺寺八月十五日夜桂子 皮日休 玉颗珊珊下月轮，殿前拾得露华新。 至今不会天中事，应是嫦娥掷与人。 中秋见月和子由 苏轼 明月未出群山高，瑞光千丈生白毫。 一杯未尽银阙涌，乱云脱坏如崩涛。 谁为天公洗眸子，应费明河千斛水。 遂令冷看世间人，照我湛然心不起。 西南火星如弹丸，角尾奕奕苍龙蟠。 今宵注眼看不见，更许萤火争清寒。 何人舣舟昨古汴，千灯夜作鱼龙变。 曲折无心逐浪花，低昂赴节随歌板。 青荧灭没转山前，浪*(左风右占)风回岂复坚。 明月易低人易散，归来呼酒更重看。 堂前月色愈清好，咽咽寒*(上将下虫)鸣露草。 卷帘推户寂无人，窗下咿哑唯楚老。 南都从事莫羞贫，对月题诗有几人。 明朝人事随日出，恍然一梦瑶台客。 中秋登楼望月 米芾 目穷淮海满如银，万道虹光育蚌珍。 天上若无修月户，桂枝撑损向西轮。 明月何皎皎 明月何皎皎，照我罗床帏。 忧愁不能寐，揽衣起徘徊。 客行虽云乐，不如早旋归。 出户独彷徨，愁思当告谁！ 引领还入房，泪下沾裳衣。 水调歌头 苏轼 明月几时有，把酒问青天。 不知天上宫阙，今夕是何年。 我欲乘风归去，惟恐琼楼玉宇，高处不胜寒。 起舞弄清影，何似在人间。 转朱阁，低绮户，照无眠。 不应有恨，何事长向别时圆。 人有悲欢离合，月有阴晴圆缺，此事古难全。 但愿人长久，千里共婵娟。 西江月 苏轼 顷在黄州，春夜行蕲水中。过酒家饮酒，醉。乘月至一溪桥上，解鞍曲肱，醉卧少休。及觉已晓。乱山攒拥，流水铿然，疑非人世也。书此语桥柱上。 照野弥弥浅浪，横空隐隐层霄。障泥未解玉骢骄，我欲醉眠芳草。可惜一溪风月，莫教踏碎琼瑶。解鞍欹枕绿杨桥，杜宇一声春晓。 回董提举中秋请宴启 文天祥 照江叠节，载画舫之清冰；待月举杯，呼芳樽于绿净。拜华星之坠几，约明月之浮槎。风雨满城，何幸两重阳之近；江山如画，尚从前赤壁之游。槁秸申酬，轮嗣布。 　 满江红.中秋寄远 辛弃疾 快上西楼，怕天放、浮云遮月。 但唤取、玉纤横笛，一声吹裂。 谁做冰壶浮世界，最怜玉斧修时节。 问嫦娥、孤冷有愁无，应华发。 玉液满，琼杯滑。长袖起，清歌咽。 叹十常八九，欲磨还缺。 若得长圆如此夜，人情未必看承别。 把从前、离恨总成欢，归时说。 秋夜月 当初聚散。便唤作、无由再逢伊面。 近日来、不期而会重欢宴。 向尊前、闲暇里，敛著眉儿长叹。 惹起旧愁无限。 秋蕊香引 留不得。 光阴催促，奈芳兰歇，好花谢，惟顷刻。 彩云易散琉璃脆，验前事端的。 风月夜，几处前踪旧迹。 忍思忆。 这回望断，永作终天隔。 向仙岛，归冥路，两无消息。 长相思 画鼓喧街，兰灯满市，皎月初照严城。 清都绛阙夜景，风传银箭，露叆金茎。 巷陌纵横。过平康款辔，缓听歌声。 凤烛荧荧。那人家、未掩香屏。 向罗绮丛中，认得依稀旧日，雅态轻盈。 娇波艳冶，巧笑依然，有意相迎。 墙头马上，漫迟留、难写深诚。 又岂知、名宦拘检，年来减尽风情。 望汉月 明月明月明月。争奈乍圆还缺。 恰如年少洞房人，暂欢会、依前离别。 小楼凭槛处，正是去年时节。 千里清光又依旧，奈夜永、厌厌人绝。 鹧鸪天 吹破残烟入夜风。一轩明月上帘栊。 因惊路远人还远，纵得心同寝未同。 情脉脉，意忡忡。碧云归去认无踪。 只应曾向前生里，爱把鸳鸯两处笼。 十二时（秋夜） 晚晴初，淡烟笼月，风透蟾光如洗。 觉翠帐、凉生秋思。渐入微寒天气。 败叶敲窗，西风满院，睡不成还起。 更漏咽、滴破忧心，万感并生，都在离人愁耳。 天怎知、当时一句，做得十分萦系。 夜永有时，分明枕上，觑著孜孜地。 烛暗时酒醒，元来又是梦里。 睡觉来、披衣独坐，万种无□憀情意。 怎得伊来，重谐云雨，再整馀香被。 祝告天发愿，从今永无抛弃。 念奴娇.中秋对月 文征明 桂花浮玉，正月满天街，夜凉如洗。 风泛须眉并骨寒，人在水晶宫里。 蛟龙偃蹇，观阙嵯峨，缥缈笙歌沸。 霜华满地，欲跨彩云飞起。 记得去年今夕，酾酒溪亭，淡月云来去。 千里江山昨梦非，转眼秋光如许。 青雀西来，嫦娥报我，道佳期近矣。 寄言俦侣，莫负广寒沈醉。 　 秦淮看月记 潘之恒 戊午中秋，登虎丘见月而思秦淮也。几望及望，月色如昼，逢丽姬金、王两姓，从千人中独见而月不能为之奇。时善音者，皆集金陵，子夜闻之靡靡耳。至已未是 日，则余居金陵已七见圆魄，靳一而将行，秦淮人之曰：“胡曩之不思，思而去之，是将又思。”乃发慨而止。上弦以来，犹吴咋也，几及两夕而忽若失之，则人或 胜于吴，非人胜而情胜也。匝青溪夹岸竞传吴音，而阁中以真情胜者，则元女之珠献彩女之箫，随其孤调皆绿云之音，其为剧，如琵琶、明珠更为奇绝，余悔其闻之 晚而娱耳浅也，应为废吴思，而胡以又之，令当吴游，片石尽肯，可中易仄，剑池一勺，若海印发光矣。因掷笔空中，俄而云开月出，恍置身于虎丘间，因为歌 曰：“我之思兮云隐，月中生兮风中殒，忽如梦兮如醒，我又思兮瀛海，龙街光兮凤舒彩，忽以游兮以嬉，愿千秋兮无改。” 中秋 如果那也算作一次分离 在我年轻的心中 是否可以原谅你 就像落叶可以原谅野风 无礼 青春可以原谅岁月 将她抹去 蟋蟀停止了吵闹 石榴树挂满了羞红的果 最后那一场雨淋湿了野玫瑰 （他们说湖边的玫瑰喜欢歌） 你会不会坐在月下 听我唱 听我的歌飞进山林 飞越湖水 飞向那一轮圆月 中秋月 中秋的月亮 总是那么惆怅 似一洼秋水的悲凉 蕴着我无可奈何的感伤 　 借你纤纤的手 剪一缕朦胧月光 让我把今夜的孤独收藏 八月的桂花开始了飘香 　 而我 再也找不到了来时的方向

俞敏洪：像树一样活着

人的生活方式有两种，

第一种方式是像草一样活着，

你尽管活着，每年还在成长，

但是你毕竟是一棵草，

你吸收雨露阳光，

但是长不大。

人们可以踩过你，

但是人们不会因为你的痛苦，而他产生痛苦；

人们不会因为你被踩了，而来怜悯你，

因为人们本身就没有看到你。

所以我们每一个人，

都应该像树一样的成长，

即使我们现在什么都不是，

但是只要你有树的种子，

即使你被踩到泥土中间，

你依然能够吸收泥土的养分，

自己成长起来。

当你长成参天大树以后，

遥远的地方，人们就能看到你；

走近你，你能给人一片绿色。

活着是美丽的风景，

死了依然是栋梁之才，

活着死了都有用。

终于混进了鸟巢

偏偏在我最穷的时候开了奥运会，都没法请父母过来看看，只能自己混进去逛逛了。

Managing and Motivating Developers: Tips for Management Cluefulness

June 24, 2008 — CIO — In many ways, managing a developer is just like managing any other employee. Developers want managers who'll help them solve business and technical problems, who'll protect them from unnecessary office politics and who will help them meet their personal career goals. But programmers are...different. Like musicians, these creative folks can alternate between big-picture thinking and persnickety detail in a heartbeat. They can be sidetracked by silly toys, and convinced to work overtime by the promise of pizza and a T-shirt. Trying to understand and motivate these people can drive managers—particularly nontechnical managers—to distraction.

This is not, of course, a new challenge. Managers have been trying to inspire programmers since mainframe days, and several classic books still have relevance today. For example, Tom DeMarco's Peopleware was probably the first to recommend that developers be given telephones with ringers that could be turned off to minimize distractions from the warm, creative fog in which a creative person innovates.

Stan Rifkin, an advisory services provider with Master Systems, referred to a Harvard Business Review essay called "Who are your motivated workers?" by M. Scott Myers, written in 1964 (vol. 42, issue 1, pp. 73-88, if you want to look it up). "'How to motivate engineers' is an old, well-known subject; note the date of the article cited," says Rifkin. The article, in turn, relies on Herzberg's pioneering work, published in HBR a year or two earlier. He added, "So many of our questions have been answered by research and evidence. We just have to learn how to find those answers."

Based on plenty of conversations with developers, however, most managers still haven't learned the proper skills.

So, in the expectation that developers know how their managers can motivate them and can manage them most effectively, I asked in several online communities and social networks, "What one thing, one thing, should the CIO understand about managing and motivating developers?" Developers did give me quite a bit of input, though not at the volume I saw from earlier articles in the Getting Clueful series (which highlighted IT workers' opinions of the key things bosses should understand about telecommuting, software requirements, Agile development, fighting spam and computer consulting). I've summarized the responses below; as you'll see, the introspective nature of the question gave some surprising answers.

Trust Developers to Do Their Jobs

Some managers act as though developers, left to themselves, would never write a line of code, and instead would spend all day playing computer games. That just isn't true. The primary wish among developers who responded to my question was that managers recognize their own and their team's abilities, and trust them to get the work done. ("Try and challenge me. I'm so much more than what you use me for," wrote one anonymous developer via Twitter.)

"All motivation comes from within," says SQL consultant Rudy Limeback, who was a developer for 30 years. "Developers need to be allowed to develop because that's what they love to do," he says.

Managers can appeal to the pride a developer feels in his work. "Find out what the developers like to do, and find a way to let them do it so that it benefits the company," suggests Ilja Preuß software developer at disy Informationssysteme GmbH. "The most motivated people are those who do what they like doing."

"I want my IT manager to understand that I care about the quality of my work," says Bruce Lindman, senior database consultant for Quick Solutions in Columbus, Ohio. "I comment my code with my name, and thus 'sign' every script or procedure I write. Nothing frustrates me more than having to do a shoddy job or compromise quality."

You can't appeal to developers' creativity unless you give them the time and space to think and create. "Techies need time to think as well as doing the code," says Lotus Notes guru Ben Poole.

"Developers, as a general group, are highly competent individuals," wrote Paul Danielson, IT director for a newspaper publishing company. "They need to be given room to develop solutions on their own (although perhaps subject to peer reviews to some extent) without being hand-fed work and methodology by management—especially at the CIO level. Nothing quashes the spirit of a good developer quicker than being given a task and then told how he/she must accomplish it."

Nor should managers expect software to be cranked out by factory methods. Software development is not a Six Sigma activity. "You're discovering, not producing widgets," wrote James, a senior developer.

Instead, give developers the big picture. "The more work I am assigned in advance, the better," wrote one via Twitter. "I can see the endgame on my own instead of having it fed to me by someone else."

Don't Ask Developers to Deal With Nondevelopment Stuff

Most developers want to focus on creating good code. And just about everything else is irrelevant to them.

To many, the manager's most important role is to protect developers from office shenanigans. Developers want and expect their management (including the layers between themselves and the CIO), Limeback says, "to take care of all the corporate crap, useless meetings, paperwork and other time sinks."

Leading that list is the marketing department, or whoever decides on arbitrary ship dates. Says Jim Pensyl, a senior performance engineer, "The more you cave to marketing time lines and avoid realistic estimates, the more you set yourself up for a project that will extend beyond marketing's promised date."

Other developers complain about managers who remind them about pending and late deadlines several times a day. They resent managers who tell them to serialize their tasks. "Give me a priority queue of tasks and let me get stuff done," wrote one developer via Twitter. "Get out of my way. I know what I'm doing." Many developers say they work best with people who give them problems to solve and do not interfere with how the individual solves them.

Listen. Respond. Praise.

Developers don't necessarily expect that the boss will understand what they're doing. They do, however, want the boss to listen and respond to her staff before making decisions. "Chat with the people who do the work once in a while. See what motivates them, and perhaps even get an idea of what it takes at their level to complete a project," IT professional Michael Furmaniuk recommends. "Motivation can start at the top and bottom, but if they never directly communicate, there is no real understanding."

"Listen actively, speak openly" is an important goal for Jason Trebilcock, a self-described BrickHead from Minneapolis. "Thankfully, our CIO does just that." But, Trebilcock adds, "It doesn't just apply to CIOs. It should apply to everyone across an organization... Without open and honest communication, you set yourself up for a lot of heartache." Be specific; subtlety is often lost on developers who are very cause-and-effect oriented. "Non-directive" suggestions aren't helpful, since a developer may not have any idea what you're hinting at.

Communication doesn't mean only the accurate exchange of information. It also means giving feedback and praise to developers—especially if you want to motivate them. "Verbal praise works for me," wrote one anonymous developer via Twitter. "Even if I'm not the best, I still need some positive talk to move me."

But feedback isn't always about telling developers how good they are. It's about setting expectations and being both consistent and fair. Here are four verbatim responses from Twitter (for which I must acknowledge the help of Michael Lopp, who was kind enough to ask his followers for 140-character-or-less input):

• I'd take harsh but consistent and fair over nice but wishy-washy any day.
• Passive-aggressive put-downs even though clear goals and expectations were not set. Snide personal remarks about your qualifications.
• Give me criticism and my perfectionism will make me work harder. Within reason; I'm not a workaholic.
• Acknowledging and leveraging my skills and talents to make good use of me.

QA specialist Joe Strazzere emphasizes the CIO's need to communicate. "While there may be an 'I' in the middle of your title," he writes, "At the root, all problems are people problems. Consider the people first, and the technology second."

The Difficult One: Pay Developers a Lot of Money.

When I asked developers what motivated them, I expected most of the answers you read above. Most people want to be appreciated for the skills they bring to the table, to be trusted to deliver their best work, and to be given honest and useful feedback. But I didn't expect that several responses would be utterly mercenary.

For example, one developer's response to the base question "If you could get your CIO (or IT manager) to understand one thing about managing and motivating developers, what would it be?" was a single word: Money. And to the automatic follow-up question, "Why did you pick that?"—"Chicks dig it."

I did laugh aloud at that response, but other developers (who remain anonymous for obvious reasons) repeated the sentiment. "As far as motivation goes, if I am not getting paid, I am not getting out of bed," wrote one. "That simply saying I'm the exceptional one who can do this amazing thing doesn't motivate if I'm not being paid exceptionally," said another. "Money is the main motivator for any job; get it right and you will have a happy employee," added a database administrator, who recommended that CIOs keep an eye on what the job market is doing for his role, and make reasonable adjustments to ensure the staff is within the comfort zone for their pay scale.

You and I could take this at face value. Developers are trained professionals who expect to be well compensated for their experience and skill. Certainly, one way to give feedback to developers, especially the ones you value most, is by showing your appreciation on the paycheck.

But surely that isn't the whole story. Every one of us could describe a job about which we'd say, "There's no amount of money you could pay me to do that," and most of us can cite jobs that paid relatively poorly in income terms, but from which we gained a great degree of personal satisfaction. Perhaps I'm wrong in this conclusion (as a confirmed hippie who believes that all work should come from personal passion, and the money will follow), but I don't think so. Given a choice between a high-paying dead-end job and a rewarding one (for slightly less money) that generates personal pride and a sense of accomplishment—well, I have a hard time believing that most developers would choose the former.

My interpretation of the mercenary answer is that most developers don't really know what motivates them... which means that their managers have to make individual judgments about the people who report to them. "Money" is an easy response—too easy—because we all like to be paid a lot.

Developers, however, are not necessarily introspective. Unless they personally have a tropism toward team (if not upper-level) management, they may not give much thought to the things that bosses can do to motivate them to do their best work. That task, then, remains firmly in your lap. In which case, it probably will help to apply the advice given above by the developers who do know what they want.

A Purr-fectly Reasonable Analogy

It may be helpful to think of good IT people like cats, wrote Pat Phelan, a database administrator who specializes in PeopleSoft technologies. "If you treat them well, offer the occasional special treat, and discipline them fairly, it can be done and done well. If you miss a point or two now and then, they'll adjust," he says. "If you miss any of these points consistently for too long, the really good ones will start to wander off in search of better opportunities."

And managing them is a lot like herding cats. The corollaries apply, too, says Phelan. For example, micromanaging a cat is pointless; the results are frustration for both you and the cat. "Make sure that the cat understands what you want. If you've done a halfway good job of handling the cat, it will consistently surprise you by doing a better job than you can imagine, and often in ways that you would never have thought of and couldn't explain if you had thought of them!" he says. Plus, trying to understand a cat is highly educational, but rarely profitable because, after all, cats do what cats do. It is a bad idea to either over- or underfeed a cat, Phelan advises. "Overfed, they get lazy. Underfed, they'll do things you don't want them doing. Find the appropriate level for each cat. Always leave room for the occasional treat (some earned, and now and then one 'just because')."

Do not abuse the cats, he adds. They'll do things to get even that you'll never think of. Remember, too, that cats learn a lot by playing. Always try to leave them time to play. The exercise is good, the team building is good, and you often end up with better-behaved cats.

Other stories by Esther Schindler