-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathatom.xml
More file actions
827 lines (488 loc) · 68.3 KB
/
atom.xml
File metadata and controls
827 lines (488 loc) · 68.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title><![CDATA[残剑]]></title>
<link href="http://txgcwm.github.io/atom.xml" rel="self"/>
<link href="http://txgcwm.github.io/"/>
<updated>2016-04-09T22:35:53+08:00</updated>
<id>http://txgcwm.github.io/</id>
<author>
<name><![CDATA[残剑]]></name>
</author>
<generator uri="http://octopress.org/">Octopress</generator>
<entry>
<title type="html"><![CDATA[读明朝历史有感]]></title>
<link href="http://txgcwm.github.io/blog/2016/04/09/du-ming-zhao-li-shi-you-gan/"/>
<updated>2016-04-09T22:31:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2016/04/09/du-ming-zhao-li-shi-you-gan</id>
<content type="html"><![CDATA[<p><img src="http://upload-images.jianshu.io/upload_images/15016-429d97da733d625d.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="唐太宗" /></p>
<p>总感觉中国古代的历史就是一个悲剧,底层的百姓面对世事的变故只能忍受,却不能有大的改变,不说老百姓,即便是那些重要人物也不能,都寄希望于一个英明的皇帝。当然,除非到了很多人都活不下去的地步,人们才可能起义。</p>
<p>徐阶一个大大的能臣,面对嘉靖这样一个不理朝政的皇帝,也只能默默地等待,却不能作大的改变,只能等到他死后,才能做一些正确的事情。可是若是一个皇帝活得很长久,那么老百姓必然跟着受罪。</p>
<!--more-->
<p>当面对一个昏庸的皇帝,或许很多人都会怀念唐太宗这个明君,因为他真的很棒,能够合理利用他手下的各种能臣,创造了一个太平盛世。那个时代,有太多太多的能臣:左武卫大将军长孙无忌、监校千牛卫大将军李孝恭、左仆射杜如晦、建议大夫魏徵、右仆射房玄龄、尚书高士廉、尚书尉迟敬德、鹤城太守李靖、尚书令萧瑀、颇炉将军段志玄、尚书刘弘基、洛阳郡守屈突通、荆州长史殷开山、右武卫上将军柴绍、京兆尹长孙顺德、洛州长史张亮、扬州郡守侯君集、武威长史张公谨、虎贲将军程知节、尚书虞世南、左令刘政会、右令唐俭、上将军李勣和虎威将军秦琼。</p>
<p>古代是封建王朝,若要改变就需要自上而下,商鞅变化因为有秦孝公的支持而取得巨大成果,缺少上层的支持则任何事都推动不了,王安石的变法几经波折便是一个例子。那么自下而上是不是一种新的选择呢?是一个选择,但它成事的概率很小。起义就是自下而上的变革,但历史告诉我们农民起义几乎没有成功的。</p>
<p>自上而下的改变能否持续长久呢?答案是目前还没有见到这样的例子。秦国算是一个做得比较好的朝代,从秦孝公到秦始皇,历代皇帝都遵循“依法治国,奖励军功”的国策,从而达到了一统江山的宏愿。相比之下,魏国就差很多,魏文王使用李愧进行变法,使得魏国变得强大,成为当时的一大霸主,但接下来的帝王就没有遵循那一套准备,以致国家变得越来越弱。那么秦国统一后又为何不能持久呢?它从此缺少了目标,没有了以目标为导向的准则。</p>
<p>统一后的朝代,大多缺少了目标,选择不了正确的道路,所以变得越来越弱,直至灭亡。若是一个团体缺少目标,是一件极其可怕的事情,因为它不知道自己将走向何方,所以变成了一个无头苍蝇,随处乱窜。</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[该对2015说再见了]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/30/gai-dui-2015shuo-zai-jian-liao/"/>
<updated>2015-12-30T23:03:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/30/gai-dui-2015shuo-zai-jian-liao</id>
<content type="html"><![CDATA[<p>在年初的时候,给自己定下了一些要求,回想一下,有完成的,也有做的不好的。</p>
<p>1、工作上的改进,完成度达到80%;</p>
<p>2、学车,刚过了科目一,没有继续进行;</p>
<p>3、旅行,去了一些地方,有了不一样的感受;</p>
<p>4、读书,硬着头皮看了几本书,有些书看得很快,有些则很慢,收获也是很大;</p>
<p>5、写作,一直持续着。</p>
<!--more-->
<h1>工作</h1>
<p>14年那一整年,工作上是没有多少突破的,因为一直在维护老的东西,漏洞很多,有心去改进却发现很难入手,只是尽量尝试着去做。所以那一年,会看上去很闲散,自己都觉得那种状态不是很好。那一年也精简化过代码,但没有具体用到项目上,所以就把新弄的东西搁置在了一边。</p>
<p>今年3、4月份的时候,有一个新的项目,那时我的态度是使用新的代码架构。实际上,我们真的使用了它。那时在内心真的是燃起了一团火,似乎自己已经看到了光明。学着秦老师的架构模式,在3、4月份那会重新架构了代码,将各个模块功能再一次细分。那个项目,秦老师开发了绝大部分模块,我参与开发了其中的一些模块及处理相关的bug。</p>
<p>7、8月份那会,又有一个新设备过来,秦老师还是主力,这次我开发的模块多了一些,但也不是太多。这期间,又重新架构了代码,把很多不必要的东西给删除了。之后的一些日子,断断续续重新架构了代码,但变动的幅度不是太大。</p>
<p>当然,陆陆续续也把其它的一些代码加入到了新的SDK中,期间做了很多原本就应该做的工作。之后也有很多新设备过来,可只是简单的移植,也并未确定是否要使用。</p>
<p>最近,发现自己比较较真,看到不舒服的地方总是想去改变它,这种行为可能会伤害到同事,但它却是对公司有利的,希望大家能够谅解。朝着好的方向发展,是大家共同的目标,可有时行动比想法更重要。</p>
<h1>学车</h1>
<p>刚开始的时候兴头很大,过了科目一之后,就失去了兴趣,没有紧跟着去练车,但这始终是自己懒惰造成的。</p>
<h1>旅行</h1>
<p>这一年,去过的地方还是很多的,跟随其它的户外组织,公司户外的活动也基本没有落下。出去走,不仅是看风光,更多的是体验。</p>
<h1>读书</h1>
<p>书读了不少,无形之中也影响着自己的思考方式,那些书籍真是太棒了。看到好的地方,总是不由自主的画上,时而也会写下自己的心得。如果画的地方多了,趁着闲暇时间会把那些精彩的片段摘录下来,同网上的朋友分享。</p>
<h1>写作</h1>
<p>从13年以来,简书成为了我记录想法的地方,一有什么想法就在上面写,写作也成为了我的生活习惯。原本要求自己在今年写下10万字的,到最后还是差六、七千字。如果逼自己一把,是可以完成这个指标的,但我不想那样对自己,毕竟这只是一项爱好,逼自己了,反而会让这项爱好变成一种负担。</p>
<h1>卖猕猴桃</h1>
<p>实现了自己一年前的承诺,今年继续给公司的同仁带来福利(廉价的猕猴桃)。销售额虽然没有去年的高,但也不错,毕竟这一年公司的变动还是很大的。</p>
<h1>活动</h1>
<p>今年给部门举办了四次活动,每一次都是不同的玩法,我不愿雷同,因为那样我自己会觉得没有意思。总体来说,自己还是比较满意的。</p>
<p>这一年,还是有太多的事情可以说的,但有些事只适合埋藏在心里,那就这样吧!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[读书社构想]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/20/du-shu-she-gou-xiang/"/>
<updated>2015-12-20T18:18:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/20/du-shu-she-gou-xiang</id>
<content type="html"><![CDATA[<p><img src="http://upload-images.jianshu.io/upload_images/15016-f162c035c3487770.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="书" /></p>
<p>读了一本书,是否产生过探讨的欲望?</p>
<p>当获取到一个新的观点或观念时,是否想过和身边的人分享?</p>
<p>看了一些书,是否有过购买新书的欲望?</p>
<p>浏览了其他人推荐的书籍列表,却不知道选择购买哪本书?</p>
<p>对,我们有太多的问题,然后却找不到一个合适的答案。这些问题时常困恼着自己,所以我们经常去寻找组织,希望从那里获取到我们想要的答案。其实,每个公司都有很多的人喜欢阅读,只是他们可能从未坐到一起,让思想的火花迸发出来。</p>
<!--more-->
<p>那么,我们自己是否可以组织一个读书社群呢?</p>
<p>很多组织往往存在着一些现象:</p>
<p>1、组织里的人员很杂乱,各色人都有;</p>
<p>2、很少有人愿意分享自己获得的知识;</p>
<p>对于以上的问题,可以通过以下的方式解决:</p>
<p>1、小团体化,加强成员的审查资格,只能让符合团队价值的人员加入,加入之前需要投名状,就是要先分享一次;</p>
<p>2、鼓励团队里的成员分享,对于那些只听而不分享的人采取严厉的惩罚措施,有必要的情况下可以直接驱逐出团队。</p>
<p>分享内容,可以有以下的一些好处:</p>
<p>1、强化对已有知识的学习;</p>
<p>2、提升个人的演讲能力。</p>
<p>如何构建一份分享内容:</p>
<p>1、讲述自己从中获取到的知识或是理念;</p>
<p>2、讲讲书籍中的结构;</p>
<p>3、挑选自己最喜欢的章节进行分享;</p>
<p>4、结合自身的观点或现实的例子,对文章中的内容进行分析;</p>
<p>5、提出问题,与听众进行探讨。</p>
<p>当没有人探讨的时候,我们的观点永远是孤立的,而且也得不到验证。说出来,与大家一同分享,或许会让自己的视野更加开阔。</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[买书]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/20/mai-shu/"/>
<updated>2015-12-20T17:34:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/20/mai-shu</id>
<content type="html"><![CDATA[<p>细数自己以往买的书,有很多没有看过,甚至有一些根本没有打开过。但就因为自己没有打开过,就要告诫自己不要再买书了吗?显然不是这样。</p>
<p>有些书并不是买来就得看的,因为有些需要是需要依靠人的阅历的,没有达到那个水平的时候会觉得索然无味,但有那种人生阅历之后,细细阅读那些书籍又会有新的体验。</p>
<p>是不是所有没有翻阅过的书籍等到一定阶段后都能读出味道呢?答案也不是完全肯定的。人总是会做一些错误的决定,买到一些不合自己口味的书籍也是常有的事情,所以遇到这类书籍也不要过于纠结,不看也没有什么损失,若是逼着自己看反倒没有什么好处。当书买的多了,自然就知道哪些书籍是符合自身需求了,买到差书或是不符合自己品味书籍的概率就变小了。</p>
<p>一开始并不知道买什么书合适,即便网上有推荐的书单,但很多也不是适合自己的。最好的办法,是找和自己品味差不多的人推荐书籍,那样会大大降低买错书的概率。</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[利用人脉信息]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/20/li-yong-ren-mai-xin-xi/"/>
<updated>2015-12-20T17:17:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/20/li-yong-ren-mai-xin-xi</id>
<content type="html"><![CDATA[<p>在《联盟》一书中作者提到要利用公司员工的人脉网络获取到信息,从而达到促进公司发展的目的。而且该公司还专门设立了“小道消息”奖项,鼓励员工分享获取到的有价值的信息。一系列的举措,确实都是不错的主义。</p>
<p>国内的很多企业都是抄袭的高手,可往往都是等别人的产品出来后,才有一个模板来学习,所以不停地去抄袭,别人做成什么样,自己也跟着做成什么样,完全没有自己独特的见解。这不是好的现象,会让人成为一种抄袭思维,从而丧失自己的思考。</p>
<p>如果能够合理地利用员工人脉网的情报,或许很多事情不会那么被动,在别人开发某项功能的时候,或许我们也有相同的时间去开发类似的功能,在摸索的过程中也能够得到更多有价值的东西,达到知其然的目的。</p>
<p>每个人每天接触的信息种类也大不相同,可能其中就有很多是有新意的,说不定就能收集到一些好的信息,比如一些会议信息,或是对手公司的产品信息。</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[落寞]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/20/luo-mo/"/>
<updated>2015-12-20T16:50:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/20/luo-mo</id>
<content type="html"><![CDATA[<p>时常听人们讲起,这里没有以前热闹了。对,没错,时常待的一些论坛是没有以前热闹了,而且不时有人离开这里。很多地方曾经热闹过,可最后还是萧条了。感叹这些问题的人,有大部分没有好好去思考。</p>
<p>当一个地方落寞的时候,必然在另外一个地方有新崛起的霸主,它们用独特的方式吸引着人们到那里去。</p>
<p>当面临威胁的时候,最可怕的不是我们做了一些错事,而是毫无察觉,还不停地埋怨。人来人往,再平常不过了,不能吸引人,只能说明做得还不够好,问题的根本定然是出现在自己的身上。</p>
<!--more-->
<p>如果你喜欢一个地方,那么可以为它贡献自己的一份力量,无论做什么,只要你能够做到的任何事情。</p>
<p>每当看到这些衰败的地方,时常让我想起闻一多先生的《死水》。</p>
<blockquote><p>这是一沟绝望的死水,<br/>
清风吹不起半点漪沦。<br/>
不如多仍些破铜烂铁, <br/>
爽性泼你的剩菜残羹。 <br/>
也许铜的要绿成翡翠, <br/>
铁罐上绣出几瓣桃花。 <br/>
再让油腻织一层罗绮, <br/>
霉菌给他蒸出云霞。 <br/>
让死水酵成一沟绿酒, <br/>
飘满了珍珠似的白沫; <br/>
小珠们笑声变成大珠, <br/>
又被偷酒的花蚊咬破。 <br/>
那么一沟绝望的死水, <br/>
也就跨得上几分鲜明。 <br/>
如果青蛙耐不住寂寞, <br/>
又算死水叫出了歌声。 <br/>
这是一沟绝望的死水, <br/>
这里断不是美的所在, <br/>
不如让给丑恶来开垦, <br/>
看他造出个什么世界。</p></blockquote>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[联盟摘要]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/15/lian-meng-zhai-yao/"/>
<updated>2015-12-15T23:36:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/15/lian-meng-zhai-yao</id>
<content type="html"><![CDATA[<p><img src="http://upload-images.jianshu.io/upload_images/15016-0be12b1210a0e55c.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="联盟" /></p>
<p>理想的雇佣关系框架应鼓励员工发展个人人脉、勇于开拓实干,而不是成为唯利是图的跳槽专业户。</p>
<p>在联盟中,管理者可以开诚布公地谈论公司愿意为员工进行的投资和公司期望的回报。员工可以开诚布公地谈论他寻求的发展类型(技能、经验等),以及他通过努力可以为公司做出的回报。双方都设定了明确的预期。</p>
<!--more-->
<p>拥有创始人思维的人会推动改变、激励人心、出色地完成任务。</p>
<p>让员工专注于开创事业是件好事,毕竟,如果员工感觉不到积极投入自身事业的迫切需求,就可能无法做出公司调整和成长所需的迅速决断。</p>
<p>领导者的任务不是培养能人,而是认识到人们已有的才华,并创造出让其产生和成长的环境。</p>
<p>联盟提高了员工的适应力和技能,从而让他们更有价值,它能帮助并指导管理者更好地与直接下属合作,还将教会公司有效地利用和留住开创型员工。</p>
<p>我知道我的员工可能在某个时间离开公司。承认这一事实并不会影响我对他们的投资兴趣,相反,它赋予我这样做的动力。我向他们保证,一起谈论他们未来的工作绝对没问题,即使他们打算去别的公司。这有助于创造开诚布公的氛围,也有助于让他们理解我们的目标一致,都是为了让他们更上层楼。</p>
<p>他们的责任是利用在这里的工作经验抓住这种机会,为自身创造长期价值。在某些情况下,这种价值将在他们离职后的职业生涯中体现得最明显。</p>
<p>你应该雇佣你能找到的最优秀的人才,然后,创造环境让优秀人才决定留下来并专心投入工作。</p>
<p>声称公司的使命是打造优秀产品和满足客户需求基本上毫无意义,因为这些使命能够而且应该适用于任何公司。</p>
<p>首先,让这位员工写下3个他钦佩之人的名字。然后,让这位员工在每个名字后面列出3种他最钦佩的品质(一共9种品质)。最后,让他根据重要性对这9种品质排序。</p>
<p>任期的“正确”结构也取决于员工的个人需求。看重不同经验的员工可能需要大量短期多变的任期。重视稳定的员工可能偏好少量长期持续的任期,他们的目标是进入基础期。</p>
<p>对于推出过一种产品的员工而言,延长任期可以让他学会如何壮大这种产品的市场或规模,而公司可以利用最初打下的市场,而不必培养新人从头来过。</p>
<p>在开始一段新任期之前,员工应协助招聘和培训继任者,以继续完成前一个任期的项目。或许继任者是该项目后续阶段更适合的人选。继任者计划还为员工画上了更令人满意的句号,这样当他完成任期时,就能知道他管理了数年的产品、项目或计划将在可靠人选的手中继续下去。</p>
<p>当下一个明确目标迟迟不出现时,你和员工将备受煎熬——你们都希望继续这段关系,但不确定如何才能继续。在这种情况下,最佳行动是延长当前的任期,但规定一个在未来数月而非数年重新审视各种可能性的时限。</p>
<p>你应该和员工一起制定出过渡计划,并起草一份交接清单。交接清单的目的是列出公司为了完成目标而需要员工做的每件事,尤其是接手项目的继任者人选。如果员工完成了清单上的所有事项,就可以被认为善始善终地完成了任期,并可以在离职后与公司保持良好关系。</p>
<p>扩大职业人脉有助于员工改变职业生涯,员工人脉有助于公司改变自身。</p>
<p>人脉更广的劳动力可以带来更有价值的情报,当员工向公司提供他们通过人脉获得的信息时,他们将帮助公司解决重大的商业挑战。</p>
<p>“回头客”员工拥有独一无二的价值,因为他们可以将外部人视角与内部人掌握的公司流程与文化结合起来。</p>
<p>最后,同事还能提供急需的外部视角。公司很容易陷入自我满足,而当前员工指出忠言逆耳的现实时,他们既拥有必要的客观性,又对公司保持着尊重和信任。</p>
<p>我们认为当合适的人才在拥有合适理念的公司中遇到合适的机会时,就会发生神奇的转变。</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[阅读书单]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/13/yue-du-shu-dan/"/>
<updated>2015-12-13T17:12:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/13/yue-du-shu-dan</id>
<content type="html"><![CDATA[<p>《嵌入式Linux应用开发完全手册》</p>
<p>《抛弃c程序设计中的谬误与恶习》</p>
<p>《c陷阱与缺陷》</p>
<p>《征服c指针》</p>
<p>《c专家编程》</p>
<p>《黑客与画家》</p>
<!--more-->
<p>《浪潮之巅》</p>
<p>《Unix环境高级编程》</p>
<p>《创客:新工业革命》</p>
<p>《编程珠玑》</p>
<p>《乔布斯传》</p>
<p>《增长黑客》</p>
<p>《程序员修炼之道——从小工到专家》</p>
<p>《合伙人:如何发掘高潜力人才》</p>
<p>《从0到1》</p>
<p>《创业维艰》</p>
<p>《重构:改善既有代码的设计》</p>
<p>《More Effective C++》</p>
<p>《Effcetive C++》</p>
<p>《数据之巅》</p>
<p>《C++ Primer Plux》</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[《创业维艰》摘要]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/13/chuang-ye-wei-jian-zhai-yao/"/>
<updated>2015-12-13T16:53:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/13/chuang-ye-wei-jian-zhai-yao</id>
<content type="html"><![CDATA[<p><img src="http://upload-images.jianshu.io/upload_images/15016-4690df212b7f47e1.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="创业维艰" /></p>
<p>领导力是一种能让别人追随你的能力,即使别人只是处于好奇。</p>
<p>在特别严峻的形势下,当“事实”似乎已经注定了某一结果时,我会学着从截然不同的角度去寻找另一种表述和解释,以此打开我的视野。</p>
<p>如果我们不能公平、公正地对待那些即将离开公司的人,那些留下的人就永远不会再信任我了。</p>
<!--more-->
<p>可是,世俗的观点和事实真相往往相去甚远,有效的市场假说都具有欺骗性。</p>
<p>局势正在快速发生变化,要想始终处于上风,我们必须对产品架构做出重大改变。</p>
<p>纵观那些失败的公司,你会发现,很多员工早在公司倒闭之前就知道公司的症结是什么。既然知道这些致命的问题,他们为什么不说呢?原因往往是该公司的文化阻碍了坏消息的传播,真相始终处于隐匿状态,等到采取行动时却为时已晚。</p>
<p>给新工程师分配任务之后,这些工程师就会竭尽全力地想办法完成这些任务。通常情况下,这意味着对架构内现有设备进行复制,这种复制会导致用户体验不一致、各种性能问题,以及整体混乱。</p>
<p>排除经济因素之后,我发现人们辞职主要有两个原因:</p>
<p>第一、他们讨厌自己的管理者。缺乏指导、职业发展前景不明朗、收到的反馈多为负面的,这些因素通常会令员工感到惊恐不安。</p>
<p>第二、学不到东西:公司没有投入资源,帮助员工学习新的技能。</p>
<p>因此,培训必须具有强制性。</p>
<p>挑选团队中最优秀的管理者去教授其他课程,把参与这些课程变成一种荣誉,同时也变成一种强制性的要求。</p>
<p>讽刺的是,实施培训项目的最大障碍是:有些人认为,这会花费太多时间。要记住,在提升公司生产力方面,其他任何投入都比不上培训。</p>
<p>好的产品经理让团队将重点放在收益和客户身上,而差的产品经理则让团队关注竞争对手的产品有多少新功能。</p>
<p>人们意识不到自己的缺点时,很少会对其加以改正。</p>
<p>一个团队内部无论哪个层面出现了滥竽充数的人,他们都会像蛀虫一样影响其他成员,最终使得能力出众的人也渐趋平庸。</p>
<p>平庸与杰出之间的差距往往就源于你的态度,源于你是否放手让员工大胆创新,不折不扣地实行问责制。</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[可笑的年初计划]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/06/ke-xiao-de-nian-chu-ji-hua/"/>
<updated>2015-12-06T17:59:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/06/ke-xiao-de-nian-chu-ji-hua</id>
<content type="html"><![CDATA[<p><img src="http://upload-images.jianshu.io/upload_images/15016-7720cf4351793472.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="目标" /></p>
<p>去年写作超水平发挥了,竟然写了15字左右,所以在今年年初的不切实际地给自己下了一个目标,今年一定要写上10万字。</p>
<p>可是,如今细想起来,这不是一个准确的预算,截至现在才写了将近9万字。虽然只剩下一万字,而且有些个别主题已经定下来,还是能写上4、5千字的,但另外的6、7千字怎么办呢?有东西写,当然会写得很快,若是没有东西或主题,这些字数是很难憋出来的。</p>
<!--more-->
<p>去年那会能写这么多,主要是对过去几年的一个总结,所以有很多的题材,而今年不同,只有这一年的阅历,根本没有多少的内容,题材来源本身就是一个问题。</p>
<p>早些时候,就感觉到自己不太可能完成这个任务,甚至有几个月是在逼自己写一些东西,写出来的文章质量显然不是很高。朋友也对我说,没有必要逼自己,顺其自然就好了。但我始终做不到,觉得应该去完成它,承诺过自己的事情不能不做到,对自己都没有信誉,又怎么可能让他人对自己产生信任呢。所以,今年的目标无论如何都是要达成的,下年的目标务必要定的低一些,绝对不能让爱好成为一种负担。</p>
<p>年底这会我突然想起这事务必要完成,不禁让人想起之前某些zf部门的年底突击消费。最近也在阅读《创业维艰》这本书,作者在做ceo时眼见不能完成年初预订的目标,临时更改了目标,这样做是一个危险的信号,这会让市场上的投资者失去信心,严重的可能会导致公司破产。而我这种不合理的计划,顶多是让自己不开心,影响信息,可这也不是明智的选择,若是做其它事情呢?</p>
<p>如果你有什么好的主题,不妨告诉我一声,我还缺少六、七个主题来完成我今年的任务。下一次计划,我一定慎重些!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[我们需要更多的书籍]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/06/wo-men-xu-yao-geng-duo-de-shu-ji/"/>
<updated>2015-12-06T17:01:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/06/wo-men-xu-yao-geng-duo-de-shu-ji</id>
<content type="html"><![CDATA[<p><img src="http://upload-images.jianshu.io/upload_images/15016-ff7903b04c5fbe7d.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="书籍" /></p>
<p>古人曾说过,读书近乎勇,书能够让人明白道理,总之可以给人类带去很多的东西。尤其当今这个社会,不学习相当于退步,所以根本没有理由不多读书。知识是进步的阶梯,这说得一点也没有错。</p>
<!--more-->
<p>在学校期间,我常看到“毕业后就没什么时间看书”的论调,当时的我也相信了这一说辞,工作嘛,当然会很忙很忙,又怎么会有闲暇的时间阅读呢!但工作之后,我觉得这种说法完全是给自己找理由,毕业之后还有很多人坚持在学习,为何其他人就没有时间学习呢,难道那些读书的人更闲吗?答案恰恰相反,反而是那些读书多的人需要工作的时间更长,更没有额外的时间。每当看到那些大牛人写的读书心得,总是让我感慨,他们既要写代码,又要管理组织或者部门里的人员,怎么还有空闲的时间学习呢?答案应该是他们从书籍中学习到了更多的经验,从而提升了工作的效率,让自己在和大家相同的时间里可以做更多有意义的事情。</p>
<p>读书是有用的,可以让你学习到新的技能,同时也可以让你看到自身的不足之处,对于一个人的提升是有很大帮助的。如果没有,那么可能就是读的书不对,或者是学习的方式不正确。</p>
<p>依稀记得毕业之后到第一家东家的状况,那会我们要转向linux的开发,而99%的人却从未接触过这方面的知识。部门老大就组织大家学习,尤其是我们这些新人比较起劲,买了厚厚的书在那里学习,时不时在晚上分享我们的学习成果。针对提到的一些问题,我们时常激烈地讨论。在这个过程中,没有人是退步的,而是整个团队都提升了实力,在后续的开发中发挥了作用。那时的学习,至今都让我受用。</p>
<p>当时,公司里有专门的书柜是藏书的,只要想看,都可以去借阅。当每个人的工作桌上都摆满书籍的时候,对于身边的人来说是一种压力,更是一种动力。</p>
<p>读书,然后分享,促进团队彼此的交流,那才是进步!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[毕业已五载]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/06/bi-ye-yi-wu-zai/"/>
<updated>2015-12-06T15:49:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/06/bi-ye-yi-wu-zai</id>
<content type="html"><![CDATA[<p><img src="http://upload-images.jianshu.io/upload_images/15016-97c20aa764645c9b.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="五年匆匆" /></p>
<p>不久前,提到同事谈到他们自己毕业的年数已经有十年了,如今孩子已经上小学,不禁感叹岁月流逝。细想自己,也在职场上“混”了五年。过去的总总事情已经变得模糊,但似乎还是有些记忆,或许该把它们记录下来,然后重新上路。</p>
<p>原本在四五个月就该写了,因为那时真的刚好是毕业五年的日子。就因为自己的懒惰,才一直拖着。我不能再拖下去了,不然就接近2015的尾声了,那时应该做的事情是记录15年了。现在也找不到合适的理由不去写了,那么就开始码吧!</p>
<!--more-->
<h1>工作</h1>
<p>还未毕业,就到了深圳的一家台企子公司实习,而且在那里完成了我的毕业设计。在那里一年半的时间里,让我学习到了太多的东西:编码习惯、系统架构、做事方式、学习的态度等等。一起去的新人都很优秀,现在的很多人都成了领导者或者是核心人物,是他们激发了我内心学习的欲望,还有那种强烈的竞争意识。每个人的心中都有一个信念,就是要变得更加优秀,否则就落后于他人。从那段经历来看,我确实没有他们优秀,我需要学习的东西太多了,需要加倍的努力。为此,还专门去参加了arm培训班,不是万不得已去培训,而是想让自己学得更多。</p>
<p>第一个东家,很多东西都很好,但就是不跟随时代的脚步,一直维护着老的东西,而没有去开阔更广大的市场,所以我们一群新人都看不到未来的方向,纷纷离开了公司。据我所知,目前留下的可能就只有一个了,或许是零。</p>
<p>离开第一个东家是有代价的,在金钱上付出了昂贵的代价,可我不在乎,相比我的前途来说,那些花费并不算什么,失去的东西将会在我未来的发展上得到弥补。</p>
<p>11年7月份那会,离开了深圳来到了杭州,更换职业是一件麻烦的事情,尤其是很多杭州的企业根本不知道那家知名的台企,所以在杭州被很多大公司拒绝在了门外,当然跟我的水平是有很大关系的。不过,也没有那么差劲,在杭州还是找到了一家创业型的公司,那里的员工都很和善,尤其是带我的人教会了我很多东西,有些解决问题的方式很新颖。在一家小公司的坏处就是没有多少人可以带你,很多东西需要自己去学习,否则就真的什么也不会了。还好,自己不算是一个堕落的人,独自学习了很多的东西,尽管这些东西在工作中都从未用到过,可还是拓展了自己的知识面。</p>
<p>第二家东家里的员工相处得真的很好,但对公司的发展方向实在不看好,第一年合约结束时本想离开,但最终还是选择留下来再待一年,因为我觉得自己应该为它做点什么,毕竟公司没有亏待我。很多老人陆陆续续走了,在终端开发上我成了支撑,我知道自己早晚会离开,在那期间尽力留下了一些文档,不至于让新人接手的时候不知所措。</p>
<p>那会学习到的东西还真的是不少,不止是技能方面的,还有关公司发展方面的,只有经历过那些事,才知道很多不合理的事情就是那样发展着。</p>
<p>因为坚定了心里的信念,那次是毫不犹豫离开的,随后并没有开始找工作,而是开始了一次不可思异的旅行,事后都觉得自己很疯狂。这些事情,也会在随后的旅行部分慢慢讲述。</p>
<p>找到第三家东家已快2013年的年末了,对这家外资企业还是有很多想象的,毕竟网上对它的评价没有什么负面的,而此时的我需要进入一家大型的企业去学习一些不足的东西。准备得比较充分,所以面试都比较顺利,也就成功地潜伏到了这家企业。</p>
<p>我很清楚,以下写的很多文字可能被同事看到,可这些都是不争的事实。尽管在码字的瞬间我自己都不觉得合适,但我还是决定记录下来。</p>
<p>在培训完成的时候,需要新员工写下评论,我在评论中含蓄地写道:代码不是很优雅。但我不清楚我写下的那些话是否真的有人去看过,猜测应该是没有。</p>
<p>13年结束,在14年过春节的前期,我们部门老大找我谈话,我说出了心中的想法,老大也鼓励我去做。过完年后,我便开始着手调整代码,把一些不用的东西删除,然后重新架构,其实那部分工作也并没有花费我很多的时间,以我的那种性格,在一个月内就完成了,后续基本是补充缺失的功能及修复一些bug。原本正常的策略应该是重新书写的,我没有那个勇气,因为里面的很多逻辑我根本不了解。由于存在种种的问题,那份新写的代码也没有在产品上应用,所以在某种程度上失去了乐趣。</p>
<p>14年五、六月份,部门来了一个新同事,一个在我们所做领域很有经验的同事。起先,我们的交流并不是很多,后来他基于我新整理的架构上开发应用,此后我们的交流变得多起来。我也好久没有去搭理那份代码,但也时而去瞧瞧,不经意间发现它已发生了很多的变化,而且一些隐藏的bug被这位新同事解决了。</p>
<p>今年3、4月份的时候,我们公司决定开发一款新的设备,当时的负责人咨询我们:是在老的代码上更改,还是在新的架构上写新的。我们的答案是一致的,就是在新的架构上重新书写。也就那时,我把之前写的那份代码重新架构了一遍,很多功能独立开来,变得更加清晰。我们的决定是正确的,在3个月的时间里,我们完成了产品的开发,当然包括了测试。后续的一款产品也是基于新的架构开发,如我们预料的那样,在比较短暂的时间里完成了开发。</p>
<p>不敢说那份代码没有bug,不过它变得比以往清晰了很多,也更容易维护。而且,现在我始终在重构那份代码,总觉得哪里并不是那么的满意,我想重构这个工作肯定是不会停的,我们始终坚持走在完美的道路上。</p>
<p>现在的东家有好的地方,当然也有不足的地方,在老大的带领下,我们也始终在改变,希望它变得越来越好。</p>
<h1>旅行</h1>
<p>毕业第一年,并没有玩得很多,也可以说没有玩,因为那时也没有这种概念,只是想着能够省一点钱,好方便以后买房之类的。最初的那一年,出去玩也是跟着公司一起,也要感谢第一家东家,在第一年里还是带我去了一些地方。</p>
<p>在杭州工作的头两年,也是没有出去玩,平时也只是宅在住的地方,那段时间似乎寻找不到活着的意义。</p>
<p>离开第二家东家的那个月,觉得自己不能够那样堕落下去,在网上买了一些必须品,随后就坐上了火车去长沙,紧接着是贵州的一个小县,那会头脑一发热又决定去拉萨,当然得从成都坐车,那个城市又玩了几天,幸好有同学在那里。那一趟旅行,就不多说了,回来之后都有详尽的描述。</p>
<p>回来之后,一切都发生了变化,从前的我再向我告别,我意识到自己应该多出去走走,看看风景,然后认识更多的人。对,没错,我真的那样做了,爬了很多的山,见识了不同性格的人,并结识了很多的朋友,整个人的世界完全变了。</p>
<p>现在的东家有户外组织,我也加入了其中,时不时也成为了领队,和他们在一起去丈量这个世界的大小,每一次出去都会变得更开心一点。</p>
<p>也因为自己变得更活跃,部门的工会活动就由我这边负责,在合理的预算开支下,每个季度换着不同的玩法带着部门的同仁去玩。我并没有把它当作是一种任务或是工作,更多是乐趣,看到他们玩得开心,心中也有一种满足感,这些就足够了。</p>
<p>我想我不会从此停步,我依然会选择在路上,去体验、感受这个世界。</p>
<h1>读书</h1>
<p>从毕业那刻起,我就没有停止过买书,头三年基本是技术方面的书籍,随后两年偏向于成功学之类的,而且很多厚厚的书都被我看完了,尽管还有很多书没有看。</p>
<p>虽然读书很慢,但书籍带给我的知识却是很充足的,它让我从其它的角度认识了世界,也有了全新的观念。</p>
<p>读书使人进步,这方面我也不能找任何理由放弃。</p>
<h1>写字</h1>
<p>毕业之后,也是一直写字的,只是断断续续,写得不是太多。开始认真码字是从13年开始的,从那之后也坚持着写,甚至给今年下了任务,但不知道能否完成了。</p>
<p>刚开始是没有什么效果的,大体是记流水帐,后来慢慢变得成熟起来,写的字也有30几万了。通过文章,也让更多的人全新认识了我。我写字并不是想表达自己有多文艺,而且我的字也表达不出文艺,只是在阐述个人的想法,希望得到共鸣。</p>
<h1>营销</h1>
<p>14年9月份那会,我觉得在公司售卖猕猴桃,就跟着前人的帖子模样写了一份,起先以为没有什么人定,可没想到还是有很多同事决定买了。当然我并不是简单的模仿,里面还是写了很多相关的介绍文字的。简单书写也不是我想做的,在内容里面我也时常加入有趣的东西来吸引眼球。</p>
<p>不仅有基本的宣传,时而也会加入一些活动,那一年的销售几乎出乎我意料的成功。虽然量上不会有那种专业售卖的成功,但它却做出了我的风格。</p>
<p>15年的时候,我继续在公司的论坛上售卖,很多同事也购买了。虽然今年的销量比去年差一点,但还是让人满意的。</p>
<p>答应过同事,要连续三年不涨价,给他们相同的低价。明年的变数还有很多,如果可以,我想我还是会继续做的,尽管可能只有一次。</p>
<h1>爱情</h1>
<p>知道很多人对这个话题会很感兴趣,但我并不准备怎么描述。感情的道路是坎坷的,有些事情说出来,我自己都觉得搞笑,而那时的我却那么傻乎乎地去做了。</p>
<p>目前,正在和一位姑娘在交往,祝我们好运吧!</p>
<h1>总结</h1>
<p>前五年,讲述的大部分是工作,但这本身就是生活中占比很大的一部分。没有随波逐流,虽然进步很缓慢,但对自己的选择并不后悔。后续的人生路还很漫长,需要好好思考接下来的路怎么走,下一个五年我又该写些什么,我内心应该是明了的。</p>
<p>告别过去,新的征程又该启程!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[谈谈关于培训和导师]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/06/tan-tan-guan-yu-pei-xun-he-dao-shi/"/>
<updated>2015-12-06T14:15:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/06/tan-tan-guan-yu-pei-xun-he-dao-shi</id>
<content type="html"><![CDATA[<p><img src="http://upload-images.jianshu.io/upload_images/15016-fb2eef2337209101.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240" alt="I want you!" /></p>
<p>之前和一个同事谈及培训的问题,提到很多人是不愿意担任导师的,而且也不会主动去教一些东西。这是一件很糟糕的事情,这样根本不能提升整个团队的实力,更别提想创造一个伟大的公司,想要从公司的成长中获取受益更是难上加难的事情了。</p>
<p>若是没有良好的培训,以下的事情是时常发生的,老人会经常抱怨新员工添加的代码不正确:明明有接口调用,干嘛还要写个新的;明明有更成熟的方法,为何还要创建一个让人难以看懂的方法。这些难道是那些新人的错误吗?难道我们有足够的理由去抱怨吗?答案是显而易见的,这不是他们的错,这些是我们一手造成的。不要试图想象一个新人在他的初始阶段就有高超的技能,而忘记了自己当初的状况,恰当的时候需要尝试站在他们的角度去思考问题,或许当初的我们跟他们相比还差得很远。</p>
<!--more-->
<p>古时有句话,就是“教会了徒弟饿死了师傅”,如今这话在当今高速发展的时代还适用吗?这种问题是不用思考的,显然不再适用。虽然在一个企业里,不完全教一个新人可以保留自己的重要性,但外部的人员始终在追赶,他们所在的企业或许会击跨我们。若是公司倒了,我们出去了还有能力战胜其它的对手吗?</p>
<p>细细教导的好处也是显而易见的,这样可以让更多的人了解到这个系统,在发现不完善的地方时能够提供更多的改善意见,从而创造出更完美的产品,进而在市场上更有竞争力。教会了一个新人,也会让团队的氛围更融洽、更上进。若是新人学会了现有的东西,老人本身也就存在了危机感,从而会学习更多的东西,或许那些新学习到的技能又能更进一步提升产品的质量。这样做,就会一个良性循环,团队的整体实力不提升才怪呢!</p>
<p>教会一个新人,有时往往能够收到意想不到的好处,他们有能力去修正现有的东西,而不至于在遇到问题的时候就跑来问老人,这样双方面的效率就提升上去了。这样做的好处也会让新人更具备创造力,他们也会变得更加有自信,也能够提出更多的建议。培训的力量是具有威力的,但我们往往忽视了它。</p>
<p>既然不愿意当导师的人数是居多的,那么就让这个工作不容易让人得到,需要做导师的人就必须通过申请。人们对不容易得到的东西往往存在很多的幻想,所以更能创造积极性。</p>
<p>这份工作不容易得到,那么它本身就必须具备吸引力,而最有效的手段就是物质奖励。对于一个新人,初到公司的第一年是不太具备创造力的。所以在第二年开始时对其工作效率及价值一个合理的评估,然后根据评估结果给老人适当的奖励,这种奖励按月或季度发放,而且这种奖励要持续两年,之后不再享受这种待遇,这样就可以鼓励老人后续带更多的新人。当然,若是中途新人想离职,那么导师就有必要第一个实施劝留,实在没有留住,那么相应的奖励也就跟着停止发放。</p>
<p>导师是工作,更是一种责任,公司信任我们的才干才把新人交给我们,那么我们就有责任为公司培养一个堪当大任的干将!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[《程序员修炼之道——从小工到专家》摘要]]></title>
<link href="http://txgcwm.github.io/blog/2015/12/02/cheng-xu-yuan-xiu-lian-zhi-dao-cong-xiao-gong-dao-zhuan-jia-zhai-yao/"/>
<updated>2015-12-02T22:35:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/12/02/cheng-xu-yuan-xiu-lian-zhi-dao-cong-xiao-gong-dao-zhuan-jia-zhai-yao</id>
<content type="html"><![CDATA[<p>要提供各种选择,而不是找借口。不要说事情做不到;要说明能够做什么来挽回局面。必须把代码扔掉?给他们讲授重构的价值。</p>
<p>一扇破窗户,只要有那么一段时间不修理,就会渐渐给建筑的居民带来一种废弃感——一种职权部门不关心这座建筑的感觉。于是又一扇窗户破了。人们开始乱扔垃圾。出现了乱涂乱画。严重的结构开始损坏开始了。在相对较短的一段时间里,建筑就被损毁得超出了业主愿意修理的程度,而废弃感变成了现实。</p>
<p>如果你发现自己在有好些破窗户的项目里工作,会很容易产生这样的想法:“这些代码的其余部分也是垃圾,我只要照着做就行了。”</p>
<p>大多数人都以为维护是在应用发布时开始的,维护就意味着修正bug和增强特性。我们认为这些人错了。程序员须持续不断地维护。</p>
<!--more-->
<p>系统中的每一项知识都必须具有单一、无歧义、权威的表示。</p>
<p>注释将不可避免地变得过时,而不可信任的注释比完全没有注释更糟。</p>
<p>处理这个问题的最佳方式是鼓励开发者相互进行主动的交流。</p>
<p>你不是在窥探——你是在向他们学习。</p>
<p>养成不断地批判对待自己的代码的习惯。寻找任何重新进行组织、以改善其结构和正交性的机会。</p>
<p>如果在代码中有着糟糕的封装、高度耦合以及硬编码的逻辑或参数,事情也许就是不可能的。</p>
<p>发现了他人的bug之后,你可以花费时间和精力去指责让人厌恶的肇事者。在有些工作环境中,这是文化的一部分,并且可能是“疏通剂”。但是,在技术竞技场上,你应该专注于修正问题,而不是发出指责。</p>
<p>如果有一个错误,就说明非常、非常糟糕的事情已经发生了。</p>
<p>死程序带来的危害通常比有疾患的程序要小得多。</p>
<p>无论何时你发现自己在思考“但那当然不可能发生”,增加代码检查它。最容易的办法是使用断言。</p>
<p>你的第一条防线是检查任何可能的错误,第二条防线是使用断言设法检测你疏漏的错误。</p>
<p>无论是谁分配的资源,它都应该负责解除该资源的分配。</p>
<p>最后,有一种技术可用于更进一步解除模块的耦合:提供一个“聚会地点”,各模块可以在那里匿名和异步地交换数据。</p>
<p>但“羞怯”的工作方式有两种:不向别人暴露你自己,不与太多人打交道。</p>
<p>很早以前我们就被教导说,不要把程序写成一个大块,而应该“分而治之”,把程序划分成模块。每个模块都有其自身的责任;事实上,模块(或类)的一个好定义就是,它具有单一的、定义良好的责任。</p>
<p>对象应该能进行登记,只接收它们需要的事件,并且决不应该收到它们不需要的事件。</p>
<p>不主动思考他们的代码的开发者是在靠巧合编程——代码也许能工作,但却没有特别的理由说明它们为何能工作。</p>
<p>注重时效的程序员批判地思考所有代码,包括我们自己的。</p>
<p>不要让已有的代码支配将来的代码。如果不再适用,所有的代码都可被替换。</p>
<p>当你遇到拌脚石——代码不再合适,你注意到有两样东西其实应该合并或是其他任何对你来说是“错误”的东西——不要对改动犹豫不决。应该现在就做。</p>
<p>时间压力常常被用作不进行重构的借口。但这个借口并不成立:现在没能进行重构,沿途修正问题将需要投入多得多的时间——那时将需要考虑更多的依赖关系。我们会有更多的时间可用吗?根据我们的经验,没有。</p>
<p>最勤勉的开发者如果被派到不在乎质量的团队里,会发现自己很难保持修正琐碎问题所需的热情。</p>
<p>事实上,好的项目拥有的测试代码可能比产品代码还要多。</p>
<p>匿名(尤其是在大型项目中)可能会为邋遢、错误、懒惰和糟糕的代码提供繁殖地。只把自己看作齿轮上的一个齿、在无休止的状况报告中制造蹩脚的借口、而不去编写优良的代码,那太容易了。</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[培养新人策略之我观]]></title>
<link href="http://txgcwm.github.io/blog/2015/11/28/pei-yang-xin-ren-ce-lue-zhi-wo-guan/"/>
<updated>2015-11-28T21:31:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/11/28/pei-yang-xin-ren-ce-lue-zhi-wo-guan</id>
<content type="html"><![CDATA[<p>一棵树刚长成参天大树,有经验的木匠一般是不会把它砍掉做家具的,因为它的木质疏松,做出来的东西不能使用得长久。等过上几年,才会把它用到合适的场合。</p>
<p>泥瓦工在培养徒弟的方法让我受益匪浅,值得深思。有经验的师傅一开始并不会让徒弟去看自己切的石头或是砖块多么的方正,而是让徒弟亲自去切一下,这样做有很多的好处:一、从实际操作中获取经验;二、让徒弟体会到他所看到的东西不是原本就那样或是可以简单办到,一切都需要付出汗水才能获得那种水准。如果一开始就让徒弟去看自己的成果,很多人会觉得那些东西就是那样,同时也会猜测自己做也很容易办到。</p>
<p>等到能够把砖或石头切得能够让彼此能够无缝衔接在一起的时候,师傅可能教徒弟怎样去拌水泥,告诉他如何配对水泥和沙子才能让那样砖头更紧密地结合在一起。等到一切看起来毫无联系的东西的时候,师傅就会教房子的整个架构及那些所学东西在这个框架中起到的作用。</p>
<!--more-->
<p>随后,等师傅觉得徒弟学得差不多的时候,就会把一些简单的任务交给他,当然这些任务是不太重要的,或者是对整个房子的安全性是没有影响的,在实际过程中师傅会看徒弟在操作中是否完成的良好,不好的地方随时指正。如果徒弟的长进不错,紧接着,又会分配一些其它相关性的任务。</p>
<p>等到徒弟各方面都学得差不多且得到实践后,师傅又会带徒弟重新了解一遍房子的架构和设计。经过一系列的学习,徒弟在此时对房子的认识必然提升到新的高度。再跟随师傅练习一段时间,想必也可以单独做事了。</p>
<p>想想要是一开始师傅就让徒弟去做工程中的某一个任务,那么肯定是没有保障的,若是房子建城了,主人住着也是提心吊胆。做的实在是太糟糕,那一切就得推到重来。</p>
<p>想想公司培养新人是不是也是和那些泥瓦工一样呢?答案是,不是。招进一个新人总是想着立马让他们去看代码,或者是交付一项艰巨的任务。做成也罢,做得不好就得推倒重来,耗费的就是更多的人力。</p>
<p>写代码的人都清楚一点,在整个系统中,按照架构中的框架去写部分代码是很容易的事情,而且逐步查阅代码之后也能清楚地说明系统架构。可是,让他们脱离原有的代码,单独开发一个和原来一样的架构体系,这时就会觉得很难很难。</p>
<p>如下培育一个新人,个人觉得合理的步骤如下:</p>
<p>1、将功能模块或者是技术上用到的特定知识细化,让新人开发一些小的功能或是使用某部分知识,这样便于了解其代码风格和基础的巩固程度;</p>
<p>2、把前期开发的一些东西,整合成一个统一的架构;</p>
<p>3、带新人学习产品的整个系统架构,讲解每个模块的功能;</p>
<p>4、细化所有的模块,根据难易程度逐一学习,且跟踪其执行流程;</p>
<p>5、所有模块学习结束后,重新带新人学习整个系统的架构;</p>
<p>6、新人根据学习到的东西进行一次分享,这样便于老人了解到他的学习情况,可以方便协助他补充不足的地方;</p>
<p>7、分配一些功能给新人,让其添加到系统中去,强化他对整个系统的认识。</p>
<p>人们的性格总是很难舍弃东西,所以一开始若是让新人加功能且质量不是很好,那么一般都不愿意删除那些代码,只是在那些功能上修复bug,可这是一件很糟糕的事情,越修改越乱,直到最后根本无法维护。</p>
<p>培养新人是一件很慎重的事情,不得不好好考虑考虑!!!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[《合伙人:如何发掘高潜力人才》摘要]]></title>
<link href="http://txgcwm.github.io/blog/2015/11/22/%3C%3Che-huo-ren-%3Aru-he-fa-jue-gao-qian-li-ren-cai-%3E%3E-zhai-yao/"/>
<updated>2015-11-22T20:06:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/11/22/<<he-huo-ren-:ru-he-fa-jue-gao-qian-li-ren-cai->>-zhai-yao</id>
<content type="html"><![CDATA[<p>要列出已知信息,并追问自己还需要了解哪些信息,才能确保身边的人都是最优秀的。</p>
<p>为什么解雇员工如此困难呢?三种强大的心理因素在和我们对抗:拖延、规避损失以及同情心。</p>
<p>即使知道身边的人不合适,我们还是会长时间地担忧开除这些人可能会损失什么,而非展开思路想想我们能获得什么。</p>
<p>最严重的错误不是选择了一个注定失败的投资项目,而是在其带来损失时,还不肯放弃。</p>
<p>如果某位同事达不到你的标准,要对他以诚相待,尽力帮他提高,或查看是否有其他工作或者职位适合他。但永远不要保持沉默。对身边的人坦诚相待、关心爱护是每位领导最基本的道德义务。</p>
<!--more-->
<p>毫不犹豫地让不合适的人离开。</p>
<p>相似的人以相似方式管理同一家公司,产生的结果自然没有多大的差别。</p>
<p>内部提升的另一个好处就是可以激励内部其他员工,这有助于让你的后备人才力量强大而充满活力。</p>
<p>全球化、人口变动趋势以及糟糕的后备人才力量必然会在未来几年导致优秀专业人才的严重匮乏。</p>
<p>在高度竞争的时代,不能留住顶级员工的公司将来的生存会很困难。</p>
<p>我常常把常规性的面试(并非正确的面试)看作“两个说谎者之间的对话”。</p>
<p>但是,他们会做三件事以降低失败的风险:检查器官健康状况,检查器官是否与身体相匹配,适时监控和支持移植前、中、后整个过程。</p>
<p>用人成功的前两个必备条件:找到合适的人选(健康的器官),并且保证他们与你的组织相适应(匹配)。第三个条件就是对他们与组织的融合给予支持。</p>
<p>不幸的是,我们大多数人都没有这么做,而是将自己选中的人置于无助之境。</p>
<p>有效融合会让企业及员工都受益匪浅。</p>
<p>许多公司和领导人不再做出艰难的选择,而是对所有员工一视同仁,或是让员工自荐以求发展。</p>
<p>如果信息完全公开,未被选中的人会大失所望,而选出的高潜力人才如果愿望未能满足也会精神沮丧。</p>
<p>重点培养三种能力:客户影响力、人才发展能力和变革领导力。</p>
<p>你的目标应该是培养一个能力均衡的团队,并且使每个成员独特的优势技能得到充分发挥。</p>
<p>金钱真正的优势在于让员工有一种充分发挥自身优势的内在动机。</p>
<p>当你给他们设置困难但是可以应对的挑战,并且消除分散其注意力的因素,他们就会沉浸于其中,工作效率达到最高水平,“流畅状态”也就产生了。</p>
<p>但要意识到金钱不会促使错误的人选把事情做好。相反,要激励所有你选中的适当人选:给他们机会,让他们在你的团队中独立完成任务,掌握技能,追求更大的团队目标、组织目标和社会目标。</p>
<p>在现在的知识经济时代,价值来自集体创造和信息的无间共享。不管领导的团队有多大,都要尽自己一切所能,确保对达到集体目标的奖励高于对个人的奖赏。</p>
<p>你需要内部人员和外部人员的合理组合。前者能为董事会提供重要的公司内部信息,而后者会提供不一样的视角。</p>
<p>当问及他们怎么能负担得起一直聘用新人的支出时,他们的回答很简单:“我们怎么承担得起不聘用新人的代价呢!”</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[浅谈营销文案]]></title>
<link href="http://txgcwm.github.io/blog/2015/11/21/qian-tan-ying-xiao-wen-an/"/>
<updated>2015-11-21T22:29:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/11/21/qian-tan-ying-xiao-wen-an</id>
<content type="html"><![CDATA[<p>现在非常流行“产品未出,营销先行”,这样做有很多的好处:一、可以提升产品本身的影响力;二、还能试探市场的反应,了解其需求度。好处是显而易见的,但只有好的文案才能达到理想中的效果。以下观点纯属个人的浅见,仅供看看。</p>
<p>提到文案,那么标题是至关重要的,一个好的标题决定着读者是否要点击进去查阅。标题的设定根据营销对象而定,比如针对那些果粉,若是要宣传iphone 6s,若是写《iphone 6s功能特性》肯定没有多少人愿意点击进去看,更改成《iphone 6s的十大新功能》则会吸引到一部分人,换成《iphone 6s,你所不知道的十大新奇功能》则能让人迫不及待地想去了解它。所以,即便内容一样,不同的标题对点击的吸引力是不一样的。</p>
<!--more-->
<p>文章的起始自然不能罗嗦,要直接切入主题,而且要有新意,人家进来就是想看真东西的,哪有那么多时间浪费在好没价值的事情上。</p>
<p>内容上也要循序渐进,不能有太大的跳跃,上文不接下文的内容,读者根本明白不了作者要表达什么样的观点。阅读对于一部分来说是消遣,所以不能让读者过份的费脑子,以一种欢乐的方式阅读当然是最好。读完之后会让人觉得有价值,即便他事后很快就忘记了。</p>
<p>营销文案当然是带着宣传目的的,提到产品部分不要太直白,人们只会厌恶,可以以趣味的方式提及,有时候自嘲也是一种不错的宣传手段。</p>
<p>有朋友说,现在的人都缺乏耐心,看图往往比看字效果要好。如果做不到全图宣传,那么尽量做到图文结合,这样读者也可以稍微休息一下再继续阅读。</p>
<p>写不下去了,目前只有这个水平,等学到更好的东西,再进一步分享!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[如何成为一个不可替代的程序员]]></title>
<link href="http://txgcwm.github.io/blog/2015/11/21/ru-he-cheng-wei-%5B%3F%5D-ge-bu-ke-ti-dai-de-cheng-xu-yuan/"/>
<updated>2015-11-21T21:44:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/11/21/ru-he-cheng-wei-[?]-ge-bu-ke-ti-dai-de-cheng-xu-yuan</id>
<content type="html"><![CDATA[<p>都说程序员是一个吃青春饭的职业,做到一定年龄就不适合了,一则思维不再那么活跃,二则新人在技术上很快追赶上来。那么如何才能成为一个不可替代的程序员呢?不是没有办法,这一切完全可以做到。不知道?没关系,我教你!</p>
<p>一个函数千万不要写的太明确,更不能写接口说明了,能写多长就写多长,只要你自己把逻辑理清楚即可。不同的功能也最好不要分开,一个函数里能挤下去,干嘛非得分成几个函数呢!</p>
<p>每个函数里还需要多写一些临时变量,即便不用也要写在那里,说不定哪天就可能用到了呢。而且变量的命名也要非常规,让他人知道变量的名字了岂不显得自己没有水准呢。不要管这种编译警告,stack还是够用的嘛。关键这种方法还能增加代码量,代码量不就是工作量的体现嘛。</p>
<!--more-->
<p>数据结构这东西也是关键,不能定义的太简单,这样也很容易让人看出端倪,最好定义得复杂些,那样其他程序员也就看不懂了。做到以下一种效果最佳,一旦要增加新的功能就要更改很多接口,要是能更改很多文件就更好了。那时,一般人肯定办不到,只有请你出马了才能解决一切。</p>
<p>多写几个源码文件也是不必要的事情,那样还有可能造成磁盘的碎片,所以一个项目所要的代码最好写在一个文件里就好。这样做有个最明显的优势,可以让老大直接看到你的代码量,否则上面的领导根本不知道你在做什么,尤其是在他们发现你只写了几百行代码的时候会觉得你对公司没有价值了。想想可能要被炒了,你会觉得这个建议是很靠谱的。</p>
<p>log这东西还是要写写的,但写了就存在一种隐患,就是别人可能看懂,然后把自己的代码更改掉。是不是就没有办法了呢?不对,还是有的。就是你要多写log,无论有必要还是没有必要,反正现在处理器的能力那么强,没有必要考虑性能相关的问题。在不同阶段,还需要重复调用某一功能接口,那样就会产生更多的log,绝对让那些不知情的人头晕,这样他们也就不敢去随意改了。有什么问题出现,到时还得乖乖来请你看。老大一看,每个地方都需要你,到时怎么可能轻易让你走呢!其他人都可以走,就你不能走,能达到这种效果,是不是就不可替代了呢?对,这不是明白着的嘛。</p>
<p>预定义也是一个绝招,凡是要加一个功能必定要加一个,这样的话可以实现定制化。要想达到更好的效果,可以让那些定义互相嵌套,如果这么做,要是某个定义不符合,让程序根本跑不起来。非此即彼的逻辑都要一起编译,否则又得让那群新人看懂了。</p>
<p>一些新人若是想找你要文档,可不要真写,问他哪里不明白直接跟他讲就好。真讲?不,你傻啊,那样岂不是要把你的位置给夺了。将几个经常跑到的代码接口就好,而且只能针对他遇到问题部分的逻辑讲,这样的话,即便他解决了当前的bug,整个逻辑还是不清楚的。</p>
<p>最后一点是至关重要的,就是要有一个态度。当那群新人不懂且要求你更改的时候,你就告诉他们你有新功能要开发,而且很急切,老大催着要,那么那群不懂事的家伙就会乖乖回到自己的位置,不再提这种不合理的需求了。</p>
<p>做到以上几点,你就可以成为一个不可替代的程序员了。到时你真的要走,身边的同事肯定不答应,因为他们已经离不开你了,没了你他们根本解不了bug,更不用说添加新的功能了。说不定到时领导都会拖着你的大腿请你留下呢!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[沙县遇地推]]></title>
<link href="http://txgcwm.github.io/blog/2015/10/31/sha-xian-yu-di-tui/"/>
<updated>2015-10-31T15:41:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/10/31/sha-xian-yu-di-tui</id>
<content type="html"><![CDATA[<p>中午在沙县吃饭,遇到了进来的地推,邀请老板加盟。男主人很有情致地听地推人员将活动规则及收费方式,而女主人则表现得不是很乐意,担心得很多,觉得对买卖不会有效果。或许这就是男女之间思维的差异性,男的具有冒险尝试精神,而女的则倾向于稳扎稳打。</p>
<p>地推人员向他们介绍,这条街很多店家已经加盟,而他们也只是少数还没加盟的其中一家。似乎也已说动了男主人,男主人也准备去取营业执照,进入厨房之后男女交谈了几句之后,男人就出来告诉地推人员目前不准备做,过段时间看看效果再说。女主人出来借口说她找不到营业执照了,这是多么低级的谎言。相比之下,我更倾向于男主人的做法,直接表明心中的疑虑。</p>
<p>加盟未必能够有什么成效,但不加盟或许就拒绝了部分出门不喜欢带现金的客户,毕竟虚拟货币交易定然是未来的趋势。</p>
<!--more-->
<p>假如你是决策者,那么会如何更有效得推广呢?</p>
<p>或许在某一区域扶植一个标杆店家不失为一种好策略,在短期内可以利用一些优惠措施让更多的客户去那家店铺消费。对,这些极有可能只是一些假象,但也足以触动其他商家的心弦。难道就不考虑后续的可持续性了吗?不,当有商家进来了,后面很多的事情就更有利于展开了,如何营销就看各家手段了。</p>
<p>商业竞争越来越激烈,等待不变的永远是消亡!</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[聊聊猕猴桃团购]]></title>
<link href="http://txgcwm.github.io/blog/2015/10/31/liao-liao-mi-hou-tao-tuan-gou/"/>
<updated>2015-10-31T15:10:00+08:00</updated>
<id>http://txgcwm.github.io/blog/2015/10/31/liao-liao-mi-hou-tao-tuan-gou</id>
<content type="html"><![CDATA[<p>转眼之间,这已是今年第四次组织公司的小伙伴向我的老同学那里团购猕猴桃了。这次的数据不是很漂亮,心中总有些不悦,情绪有些许的低落,因为去年的销售不错,也总想着超越。</p>
<p>从第一次起,虽然有几次漂亮的订购量,但总的趋势是在下滑。拿出去年的统计单看,每次的订购基本是稳定的数额。想要超越去年,只能从预定的次数上下功夫了,否则难以办到。去年一共组织了五次,而今年现在已是第四次,若是要在下次超越去年,那么第五次的预定量必须超过70箱,想想这也是不太可能的事情。</p>
<p>去年订购的都是公司内部的人员,而今年有小部分比例是外部人员,包括现东家的离职员工和同事的好友。若不是依靠外部的支援,销售数据不会太好看。不过这也不禁让人想起,做一个产品首先在局部范围内进行宣传销售,慢慢地将知名度提升,进而借用客户地口碑走向更广阔的市场。</p>
<!--more-->
<p>老罗在前不久的发布会上提到,产品周期性出货是很重要的。一方面客户知道什么时候会有货,另一方面可以更好地控制产能。翻阅销售日期表,10月份间断地太厉害,甚至会让人产生想象,是否今年不再有订购了。而去年不同,每隔两周都会有一批货到来。让客户不费脑,产生思维惯性,某种程度上可以保证产品地稳定销量。</p>
<p>去年的团购,也时常想着办一些小活动,似乎效果不是十分的明显,今年做的时候就觉得没有这个必要,但如今细想起来,这些活动还是有存在的意义的。余世维曾说过,有80%的广告是没用的,大家都明白,可为何还是有很多人砸下巨额的广告费呢,因为没有人知道哪20%是有效的。</p>
<p>看着订购的名单,是那般的熟悉,很多人的摸样都能在脑海中勾划出来,他们都已成了我的老客户。可看看去年的,很多熟悉的名字已经没有出现在今年的订购单上,他们在不经意间悄悄离开了这里。也因一些小小的变动,一些老同事已看不到团购的信息,见到我,而又恰巧想起了这事,才可能向我咨询这事。</p>
<p>提起猕猴桃,想起一些人和事,总是有那么点忧伤。去年已过,今年也将向我们告别,曾经约好了三年,明年你是否还在?不管怎样,我将在这里等你,兑现我的诺言!</p>
]]></content>
</entry>
</feed>