Zhike님의 프로필ZhiKe --- 光阴似牛车，缓缓前行사진블로그리스트기타  |  도구 도움말 |
|
ZhiKe --- 光阴似牛车，缓缓前行9월 18일 Redmond月记我是懒人，可惜的是命运弄人，总懒不下来。这不，刚从北京搬到Redmond，就缠上买房子，房子买了没几天，眼看着老婆肚子越来越大，合指一算，得赶紧把岳母办过来帮忙坐月子，不然来不及了。前头还有给孩子买家具，买奶粉尿片，房子剪草，清理gutter等等一大票事，以前梦想的一杯清茶，一部xbox(现在是360了) ，一部HDTV，发一天呆，玩一天游戏的日子，好像是越来越远了。。。
来了美国几个月了吧，好像没啥感觉，每天吃饭睡觉上班，跟中国好像没啥区别。从前感叹老美真爽，老开好车，现在想想，真是幼稚。以前在北京打车自由自在的，招之即来，挥之即去，那像现在，开着个破车，还要交保险，油费，年检，开到目的地还要停车，搞不好还要小心自己车技不精，把别人的车蹭了，如果不是这里买菜都要开车去，打死我也不买车。
不过说回来，这边牛人确实多。前不久终于是亲眼目睹了Bill哥风采，虽然已经年届50，依然不减当年。他老人家说了啥我倒是没听清楚，估计也是过一把追星瘾吧。这几天跟一个Architect聊天，对方实在是十八般武器样样精通，至少都说得我插不上嘴，末了set up个1:1，常交流交流，相信武功自然会有长进。在现在的team里我是倒数第二的新人，有些年头的人都对自己的东西有研究，虽然不是人人都是Architect，不过感觉要学的东西还多着呢。
最近从中国transfer过来的也渐渐多起来了，以后这边会热闹起来的。来没几个月，已经有好几个人问我过来的程序阿，手续阿之类（名字要保密），可见这是趋势吧。不过北京的领导估计不会太高兴，如果人人做1-2年就要走，那怎么build一个great team呢？好在，that's no longer my problem. :) 7월 31일 Talking about 4/28/07 House DIY Ref.
Quote 4/28/07 House DIY Ref. 12월 29일 在路上的时间今天回家又没有挤上城铁，在等车的时候顺路写写blog吧。
最近算了一笔账，关于人们在上下班路上花费的时间。 现在每天上下班我都得用2小时，也许算比较多了，那么保守估计平均每个上班的人每天花1小时在路上。
每年有54周，算上公休，年假等，一年工作周大概有45周，也就是45*5=225天。也就是说，每年我花225小时上下班。225小时就是225/24=9.375天，算9天好了。 北京人口保守估计怎么也有1000万，如果1/4是劳动人口（取一家四口只有一个人工作的保守估计），共有250万劳动人口。这些人每天都要上下班，一年下来，他们华在路上的时间就是2,500,000*9=22,500,000天。
假如人的一生有80岁，就是80*365=29200天。22,500,000天就是22,500,000/29200=770.5479452。也就是说，北京市每年在上下班路上就花费了770人一生的生命。
以上都是保守估计，实际只有多没有少。
另一个角度来看，你可以打车上下班，至少能省一半时间，当然花费贵4倍不止。把省下来的时间用于学习，充电，提高自己，这样就能赚更多的钱，打车也不成问题了。
不过，你的工资一半已经交了房租或房贷，父母养大你，还要留点孝敬父母。至于家里的生活开销，水电网费，也刨去了一块。总不能不存钱吧，以后孩子读书还得交好几万赞助费，可不能让他输在了起跑线。还剩下多少？你敢每天打车吗？
Life is so hard. 12월 12일 Very close to burn out.I just shipped Windows Vista, Exchange 2007.
I can't remember exactly when was the last time I had a real *rest*. My vacations are mainly spent on going back to my hometown and visiting my family as well as my relatives, which has no difference than a business trip where you need to visit people, have meetings and answer questions. I am also starting a new parallel release even before I ship Exchange 2007. My work schedule has been always full. After staying in Beijing for 3 years I haven’t had a time to visit Forbidden City once.
We emphasize work life balance a lot in our work. However when you are in an environment where everyone else is working 10 hours a day at least, work life balance is a joke. You want work life balance? Sure, but don’t ask if you are not satisfied with your review score.
Base on estimation, I am pretty close to burning myself out. If I continue to work as I am now for longer than 8 days, I’ll burn out. Don’t ask me where those days come from if you know I am a developer. J 9월 13일 Evil copy paste, live exampleToday I investigated a bug caused by an obvious error. Take a look at the following code snippet (as usual, this is only a demo): if (someBooleanVar && (someReallyLooooooogVariableName == SomeVeryLongEnum.EnumValue1)) As you can see, the variable names are quite long, and thus making the if statements long. The developer who wrote the code obviously made a copy paste after finishing the first "if" clause. Unfortunately he forgot the change EnumValue1 to EnumValue2! Thus the code to "Do something else" will never execute. This was checked in 6 months ago and the bug wasn't discovered till now. Generally I would avoid doing copy paste as much as possible, just to avoid mistakes like this. Typing might slow you down for 5 minutes, but can save you days after check in. Further more, copy paste is the first sight of bad code. Whenever you want to copy paste something, that means you want to duplicate codes that are similar and potentially can be refactored out into a function or something. This is not the first time I saw this error and I am sure this won't be the last time. What's important is, to make sure I as a developer will never make the same mistake. 8월 26일 Lessons learned, the hard way.This is definitely a very good lesson learned. Here is a story. If you want to see how we do software development and what issues we encoutered, read on. I am removing all the names to protect the innocent. 4 weeks ago we took a change to depend on an external tool. That is to run that tool with a certain parameter during one of our task. The bug was opened like a year ago and people keep debating whether we should take that change, and eventually we decided that after all this discussion back and forth with the other team, everything seems good and promising, so let's go ahead and do it. Everything works fine in the first 2 weeks. Smoke all passed, nobody report any issue, etc. Until last week, there is a report that our app doesn't work after install, and it is possibly because of this change. While we are suprised that nobody reported this for the last 2 weeks, we still initiated a thread with the other team and see if there is a bug in their tool. While the thread is still ongoing something even worse showed up. IT is trying to upgrade one of their servers to a later build, and is blocked because of this change! That means the whole corp net upgrade is blocked by it! Why is it broken? Because our task was called by some other teams task during setup to do something we don't own. And thus some assumption we made when writing the task might not be there, because you can choose to install the other team's component but not ours. What's even worse is, apparently this little cool tool has a defect that we were not told off. Its behavior depends on the sequence we run it within our task. Why nobody reports it in the last 2 weeks then? Because everyone is installing everything on their test machine. Nobody tested installing single component. And the tool's behavior is unfortunately affected by the debugger we installed on our test machine (don't ask me why!) . It behaves perfectly if you have the debugger! So nobody ever noticed this until a real customer hit it. We are lucky that this customer is our own IT. If we release product like this, I can't imagine... What choice do we have? I had to work in the middle of the night and back out the change. I also need to re-activate the bug fixed with this change and have triage re-consider it again. And as the side effect, I am now "The guy who broke dogfood upgrade and corp deployment". Lessons learned: 1. Even the seemingly super simple, harmless change will cause regressions! And you will hit them in the last minute. So be careful, be thorough. 2. Dependency is evil, don't take it if you don't have to. If you do, ask any question you can think of, and be prepared to be suprised. 8월 21일 Language Barrier对于我来说，语言始终是一个很难逾越的关卡。从小就在中文环境中长大，思维什么的全都是中文，英语读书的时候确实下过些功夫，考试也还不错，可惜到了工作才知道，之前学的只是入门。3年了，英语说是没有进步是不对的，但是也没有到我想要的地步。日常工作应付是问题不大，不过也就到此为止，想再向前一步就不容易了。比如说上次一个美国人发过来一个笑话图片，我就没有明白，还傻乎乎的回了个email，结果当然是自取其辱。至于日常老美们在办公室里面说的生活笑话俚语，就更是只能干瞪眼了。这个对工作影响不大，不过给人的印象就是你这人只会工作，其他跟你说什么也是白搭，反正你听不懂，结果慢慢下来，跟别人的关系就有些疏理，长远下去，对自己不利。
问题是认识到了，但是解决方法呢？上课？英语课上过不少，但是真的有用的不多。多些出差？显然不是一个好的选择。在办公室里多用英语？除了让人觉得你装模作样假洋鬼子之外，没什么其他效果。最后一招，显然就是回家跟老婆对练啦！可惜我们两个日常生活词汇量贫乏得可怜，连今晚吃什么菜都对话不完整，如此下去必定影响生活质量，三思。
于是回头想起一个经验丰富的同事的一句话："Bilingual by default!"。是形容那些父母一方是西人，一方是中国人的孩子，无疑他们在语言这方面有先天优势。可惜对于我来说，这些东西改变不了了。 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
