第三部分,未来职业生涯规划、家庭环境分析、例如经济状况,家人期望等。感谢您阅读《大项目、小项目都是程序员成熟之道[2]》内容,职场资讯网小编向您推荐一些职业规划知识,欢迎参考,希望能帮到你。

而我今天说的项目大小是从软件项目本身来确定的,与客户对项目大小的定义没有什么太大的关系。我认为项目大小可以从以下几个维度去考虑:资金、开发人月、项目复杂度。

1、 资金

我认为在当今物价状态下,5万以上50万以下为小项目。50万以上为大项目,500万以上为特大项目。

2、 开发人月

同理,2.5个人月到25个人月以下为小项目。25个人月以上为大项目。

3、 项目复杂度

软件项目的复杂度还可以用软件的用户使用人数、数据库中表的数量、表的记录数来衡量:

软件使用人数:10-1000人为小项目,1000人以上为大项目。

数据库表的数量:20-100张为小项目,100张以上为大项目。

表中的记录数:10万-1000万为小项目,1000万以上为大项目。

此外,项目运行能够给客户带来的收益大小、项目的业务逻辑的复杂度都可以成为项目大小考量的内容。

如果项目都不能达到小项目的水平,我们这里就不把它看作项目了,因为低于小项目的项目很多是个人编程,这与项目众人参与的特点有点不符。

所以我对程序员的建议是:

1、 要主动参加项目

无论大项目还是小项目程序员都要努力参加进去,因为只有做了项目自己的能力才能提高。不要静静待在那里,等待别人挑选,而是积极主动表示加入项目的愿望。在我负责过的项目过程中,我对主动要求加入项目的程序员往往给与更多的机会,因为这样的程序员具有主动性,工作更好开展。一个项目的出现就是一个机会的出现,把握项目就是把握机会。机不可失,时不在来。

2、 不要放过小项目

程序员不要以小而不为,只有做过若干个小的项目后,程序员才能去做大项目。那些想一步就做大项目的程序员,往往会失去小项目锻炼的机会,往往参加到大项目后,感到力不从心。项目虽小也同样可以锻炼人,程序员可以有更多机会体验项目负责人的脚色。学会从整体角度上来看待编程。

3、 要积极准备参加大项目

对于已参加过小项目的程序员,一定要把握机会,积极准备参加大项目,项目越大,越锻炼人。在大项目中要学会摆正自己的位置、虚心向团队其他成员学习。要在平时没有项目的时候,要多做些技术准备,多关注可能的大项目开发内容。在项目开发中,则可以把重点放在体会不同功能模块之间的关系上。学会从关联的角度上看待编程。

根据我的经验,我认为程序员要经过5-6个小项目的锻炼才能入门,而经历了3个以上的大项目的程序员才开始成熟。当然我们不能排除程序员的天才成分,有的程序员会再很短的时间达到一个很高的水平。但是,绝大多数程序员成长是必须通过项目来催化的,尤其是大的项目催化更加重要。说白了,项目如同阳光,程序员如同禾苗,关系就是那么简单。

延伸阅读

项目经理眼中的合格程序员


职业规划是对职业生涯乃至人生计划的过程,职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《项目经理眼中的合格程序员》内容,职场资讯网小编向您推荐一些职业规划知识,欢迎参考,希望能帮到你。

一、合作与团队精神及计划性

服从分配的工作,并在保证质量的前提下尽快完成任务。如果接到的新任务没有给出工作量估计,首先估计出完成任务所需要的工作量,并有责任向领导说明其估计的合理性,如果接到的新任务已经给出工作量,除非能提出充分的理由,否则必须接受该工作量估计。提前完成任务时,应该及时通知上级。在同时承担几个模块任务时应能根据优先级的变化及时调整自己的工作时间分配。

二、需求理解能力

在开发过程中,要在需求细节不明的情况下,有责任设法搞清楚,积极学习编程思想和方法,并在设计、编码工作中自觉应用,对有一些复杂程度的设计,主动申请设计审查。并能在开发用户界面之前,尽可能使用界面原型方法获取用户的确认。

三、测试意识

在工作负担允许的情况下,采用测试驱动的编码方式,及时把完成编码的部分提交测试,并及时排错。不断通过自己的测试来驱动程序质量的提升。

四、规范化,标准化的代码编写习惯

良好的文档是正规研发流程中非常重要的环节,作为代码程序员,25%的工作时间写技术文档是很正常的。缺乏文档,一个软件系统就缺乏生命力,在未来的查错,升级以及模块的复用时就都会遇到极大的麻烦。

对正规的企业,会有完整的编码规定,代码的变量命名,代码内注释格式,甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定,良好的编写习惯,不但有助于代码的移植和纠错,也有助于不同技术人员之间的协作。代码具有良好的可读性,是程序员基本的素质需求。

五、总结与全局观

以项目全局为重,采取尽可能简捷的解决方案,把完美方案的设想提交设计人员,有问题时首先向同事们征求解决办法,不鼓励花大量时间解决难题,并鼓励给同事提供技术支持。项目结束,做出个人小结,以利个人和集体的改进。

从一名程序员过度到项目经理


1.从程序员到PM,是一条脱变的路,事实上程序员走的路最终不应该是项目经理。首先有一点需要明白的就是,一定规模的项目中,项目经理不需要太懂技术,他可以是一知半解。项目经理的任务不是在技术方面,技术相关的应该交给SA去做。项目经理更多地是做管理,沟通等工作,你如果可以的话到书店查看一下关于项目管理的书籍,你就会明白。当然对于小项目来说,有可能是PM,SA是同一个人,而这样的项目经理更多只是SA加上一些管理工作。要做项目经理,你就首先告诉自己不再去碰技术细节了。程序员并不是一个培养项目经理的好环境。所以没有什么从Coder到什么developer再到SA然后是PM的路,这是一条比较悲哀的路。在大公司,SA下一个目标不是PM,而consultant,然后是seniorconsultant,PM走的是另一条路,所需要的技能不是技术,技术给PM带来的能力提升是很少的。在项目中你最后能分清楚PM与SA的关系及各自在项目中的分工与用途。

2.其实我蛮同意gzlucky(Lucky)的看法的,确实是我们公司不少项经理就是不很能跟得上现在的一些技术,因为很多人都快年近四十,儿子都上高中了,要他们再学新技术真的难度比较大,他们的工作基本上就是天天找手下的程序员,布置这个任务,询问那个任务做的怎么样了。不过我的头倒是和我一样编程,他手下写代码的就我一个人,他自己也会ASP和JSP,但是可能对。NET不熟,就由我来主负责了。我觉得项目经理还是像他这样的好,自己也能懂不少技术,可以服人。但是我的头儿好像在沟通这一块不是非常出色,当然也有可能是俺太内向,不太与他沟通,所以他也只是在交待任务后就不再多询问,而不像别的项目经理天天追程序员后头问。我想问问各位,你们看哪种项目经理才是比较好的,像我的头儿这样的,还是像某些喜欢追程序员后面问进展的。

3.原来在一个小公司做过半年的DM,一年的PM,后来为了让自己的技术更扎实一些,离开了原来公司,现在在大公司做程序员,开始后悔了,在大公司里很难接触管理方面的东西,也很难晋升,个人认为在小公司做DM,PM,有经验后直接找大公司的PM,这样也是一条路。

或者考PMP之类的证书,然后直接找管理的工作。

希望过来人能给予更好的意见和建议,我也现在想往管理层发展。

技术很硬了再去做PM,这种想法是错误的,我就犯了这个错,边搞好技术(为了生计)边学管理知识(为了将来),慢慢向管理发展,不能等。有句话说的好,机会是属于那些有准备的人的。利用业余时间多学些管理方面的东西,所谓人的差异在业余时间。

要走向管理层,英语一定要学好。

沟通很重要,要做好管理者,先学会做人。多跟下属沟通,多为下属着想,而不要去巴解讨好上司。体谅下属,把项目计划做的尽量合理,不要让下属加班,给下属发展和晋升的空间,这样才能是下属有干劲,才能把项目做好,你才有更高的升迁机会。

只有把自己知道的不断的让你得力下属知道,只有提拔起一些得力的下属来,你才有时间和精力去向上爬,不然你抱着不放,就没有升迁的机会。

管理不是喝酒抽烟那么简单,那只是过去的那种不思上进,耽误自己前程。

吃尽苦中苦,方为人上人。

做PM不是混,是要把项目做好,这跟做人是一个道理,这也就是为什么做管理要先学会做人的道理。

pm的整个工作重点是什么?如果做为一个PM,技术不高怎么对付组里的牛人

我们经常会因为公司里的顶尖人才、个性化太强,不能与其他人合作而感到棘手,要解决这一问题其实也是有法可寻的。

一、在肯定其价值和优势的前提下,明确地制定改进的目标;

二、顶尖人才能够面对中肯的,明确及一对一的批评作正面反应,所以要加强与他沟通的力度;

三、可以根据具体情况调整考核目标,加强与其他员工合作的内容;

四、把顶尖人才调到相对能独立发挥其才能的岗位,减少与别人发生矛盾的机会。

程序员你真的只是程序员吗[2]


或许上面写的比较偏激,但真的是很普遍,我想告诉你们,你们虽然只是负责一个模块,但无论如何,请要知道你的项目到底是什么,如何运转,哪些地方好,哪些地方不好,因为这是对你自己的一个提升,也是对公司的一个负责。说到负责,我不得不说责任感,很多人就是缺少了责任感,以为完成了任务就可以了,但你要知道,你的公司或许等的不是你的完成呢?

请您拿到项目需求的时候,分析一下您要做的东西,用你敏捷的思维想一下,该如何去做,还请您多想想下一步,如果扩展了,我要改哪些地方,最重要的是,请您想想,这个任务对公司是否有利,或许你会说你只是个程序员,我没有权利去改变任务,没有错,你是个程序员,首先请你完成你的任务,在完成任务的同时,想想任务的完成对公司的运营是否起到反作用,因为有时你会比你的老板更了解项目对公司的利弊。如果你真的觉得不太好,不要怕,提出你的观点,但一定要想好你观点的描述,尽可能的表达清楚,让你的老板知道你的意思,因为老板他不一定懂技术,所以一定要白话一点。如果你的观点是正确的,你们老板也听明白你的意思了,那样你们老板会更加的器重你,而不会不可理喻的让你完成他所要的东西了。毕竟这是对他好的建议,也是对公司发展好的建议,如果你的观点不好,那样老板也会给你一定的提点,何乐而不为呢?

下班后,请你抽空想想公司的发展吧,因为你是公司中的一员,公司发展前景好也代表着你的发展前景好,如果你的想法给公司带来了好的前景,那也是对你能力的一种肯定。

最后说说面试,我也经历过很多面试,同样也面试过很多人,刚开始也会为工作着急,到处找面经,但最好的面经是无法从其他地方找来的,因为面试是一个展示自己的机会,而不是一再的ctrl+v 。刚开始我也会紧张,但马上,我调整了自己,每次面试就当自己一种磨练,一种交流、沟通、展示的机会,随后的几次面试都比较成功,再随后的几年,我回到了老公司进行面试,显然他们对我的能力已经是一个肯定了,最后我还是没有选择他们,因为我回去面试只是为了看看公司的发展进行的如何了,因为这一切也有着自己的一份努力。最好玩的是一次邮件面试,对方给了很多题目,大多是网上都有的,我也没有baidu,用自己的想法回答了所有的问题,并提出了很多意见,没想到对方回错了邮件,把他给人事的邮件发给了我,貌似是说面试还可以,就是工资高了点之类的话,我也懒得继续往下看,回信给对方,发错邮件了。过后不久收到对方的面试通知,更确切的说是offer,不过在他电话中我直接给回绝了,因为我已经在一家自己喜欢的地方就职了。

我爱我的公司,我爱我的程序,我也爱我的老婆和家人,因为他们给了我快乐,也给了我支持,让我能更全身心的去投入到代码之美中,我更相信公司能异军突起,成为IT界的领军人物,因为我看到了一群为公司孜孜不倦,辛苦能力的同事,我很爱这种氛围,我相信我们的努力一定会给自己带来收获,就算没有收获,我也没有任何怨言,因为我沉醉了,因为我快乐,因为我是个快乐的程序员。

如何从优秀的程序员成为伟大的程序员[2]


4、对代码的信任

作为项目管理者,你怎么相信他们的代码。有些程序员,你可以对他们说:我星期五就要结果.--星期五到了,你收到了这样的Email:代码我都已经检查过了,现在就等着测试了。你很放心,只会有很少的瑕疵在质量确保的团队被查到。当然,还有些轻率的例子,一些程序员在邮件里是这样说的:我还没弄完,星期一上午我会最先完成它.你不太确信这东西,发现很多Bug,很长时间基本上不能用。又得花上几个星期清理代码中的Bug.

关键:你对一个开发人员越有信心,他离成为一个伟大的程序员的距离就越近。想象你是你的管理者,如果他并不担心你的代码,会给你多少信心和勇气!

5、对方案的信任

和对代码的信任是一回事--如果你手上有伟大的程序员,你就会对解决方案有信心。这些程序员同时也是伟大的建筑师。他们剖析整个问题,指出问题需要怎样去解决。这就不只是用伟大的代码编程的问题了,很大程度取决于你怎样构筑解决方案。这是关键,而且会让你在软件世界里出类拔萃。

6、满足客户需求

一天下来,你写出了最棒的代码、用了最好的框架和最好的解决方案,但这真的能迎合用户的需求吗?恐怕根本不是那么回事儿。你搞砸了。尽管现在多次失手,一个伟大的程序员还是会正中靶心,找出客户需要的,给用户逐步展示他们所需要的无bug的最终版本。需求正中靶心的同时,用户满意了。

7、不断升级

伟大的程序员会积极主动地把自己的技术升级。他们对知识的态度就像饿猫见着了牛奶,他们从不用上级催促给自己设定目标、不用经理要求他们完成任务,因为他们自己就已经安排OK了。

他们发现自己想要参加的大会就会给公司写Email本人非常想参加今年的Tech-Ed大会。我将用心研习,并对作出贡献。我预计这可节省金钱/其他原因.如果可行,不知公司是否帮我支付此行?如果我收到这样的邮件,我不仅会帮他支付参会费用,他的路费我也会全程买单。

伟大的程序员们永远会关注例如。net用户组或Java用户组的所有用户群体。他们参加本地的技术会议,并从中汲取知识。你会看所有最新博客和最新的杂志吗?现在列出你最喜欢的前5个开发博客。你能做到吗?你应该像参加基督教青年会那样轻松做到。做到这些,可以很好的帮助你延伸你的思路!你将会不断获得更好的点子!你会得到更好的回报!

充满荆棘的专家程序员之道


职业规划怎么写,相信很多朋友们对这个问题很感兴趣,下面给大家介绍一下。第一部分,前言即总论;第二部分,自我分析,包括业余爱好、性格、价值观、专业技能等;

国外程序员常常遇到这样一种困惑,即他们的老板认为资深的程序员是可以通过培训菜鸟程序员来生产的。老板把菜鸟程序员扔给资深的程序员,或者扔到一个短期培训班中,希望能够像镀一层金一样的生产出一个又一个编程高手。然而这其实是很不现实的,本文作者在自己的这篇博文中类比阐述了这个观点。

在过去的几个星期里,我作为父亲一直在教自己年轻的孩子开车。对于新手司机来说,学习控制汽车的整个过程(把握方向盘、使用各种踏板、换挡、看后视镜,等等)是比较伤脑筋的。但是所有这些都是相对简单的事情,大部分年轻驾驶员都能掌握,不会有太大的问题。

新手司机在经过一段时间的锻炼之后,当他们跟其他的司机一样外出上路时,真正难受的经历才开始。这时才是真正学习开车的时刻,因为仅仅能控制汽车并不能够成为好司机,虽然这是重要的前提条件。相反,能够预料和避免一些意外的情况才能成为一个好司机。不幸的是,你不可能教给他这些技巧。

你可以告诉他们一些潜在的问题。你可以描述这些问题,并告诉他们在那些情况下应该怎样做。你甚至可以进行一些实地演习。但是,每个新手必须亲自经历过很多普通的驾驶危险之后(而且要幸存下来)才能预料类似的情况,然后采取措施避免这些问题。

遗憾的是,优秀程序员的成长也需要经历一个这样的过程。咱们来看一下开发一个应用程序,功能是在一个文件中存储一些数据,每次用户启动这个应用程序的时候都调用这些数据。

◆新手程序员(已经学过在文件中读取和写入数据的语法)面对这个问题只会简单的写几行能够读取和存储数据的代码。

◆如果他们已经有过一段时间的编程经历,他们可能会写一个测试程序来确保代码读取和写入的数据是正确的。因为所写的代码工作了,初学者就认为可以了,他们会认为已经自己完成了任务,也符合规格,并且还对他们的工作进行了测试。

◆一个专家级的程序员,当面临同样的情况的时候,他知道这不是一件简单的事情。当然,写几句在文件中读取或者存储数据的代码非常简单这只是当一切都顺利的时候。但是如果要让应用程序能够处理所有可能出错的情况,这就不是那么简单了,就算是这种简单的操作也一样。因为,文件可能不存在,硬盘可能满了,文件可能损坏了,用户可能没有权限去读取文件,这个文件可能正在被使用。如果文件不在本地磁盘,程序可能都接触不到这个文件。

当然,不是所有这些问题都会同时发生在某个特定的时刻,但是那些已经把应用程序交付给很多用户的开发人员都知道,经过足够长的时候,所有的这些问题都会发生,这是迟早的事。

一个专家可以告诉初学者去检查这些可能出现的情况,那么对于这些特定的问题,不是专家的开发人员只能对其进行编码,而只有专家才能预料并避免他们。就像开车一样,一个好的程序员不仅要能够解决已经发生的问题,而且还应该能够预料一些没有发生过的问题。不幸的是,专家是靠犯错误才学到这些本领的,这对于人类来说是件伤心的事情。每一代想要成为专家的人只有在经历过上一代人所犯的所有错误之后才能成为专家。Neils Bohr解释说,专家就是在一个非常窄的领域内犯过所有可能的错误的人。

但是当你跟一个新手驾驶员坐在同一辆汽车上的时候,你可能就会更加欣赏P. J. Plauger的这个版本了,我对任何领域中专家的定义是一个对什么是真正可怕的事情知道得足够多的人。

5年程序人生路 从新手到项目管理[2]


工作渐渐展开之后,就是平静如水的生活,每天上班,吃饭,睡觉,日子也过得很快。刚开始,由于懂得东西少,所以每次任务下来后,都是积极的去完成,因为害怕自己做不完。但是渐渐的,当自己清楚该怎么做的时候,人会产生疲倦,因为每天都做一些差不多的劳动。慢慢的,做事情就喜欢拖拉了。当分配一个任务后,自己先估量一下这个工作自己大概需要多久,一般老板给的时间会多很多。所以喜欢把工作先放着,去看看网页,逛逛论坛什么的,等到剩下的时间差不多了,需要开始工作了,就懒洋洋的进入工作状态,但是往往完成工作质量都不怎么好,很多提交后会有些BUG。不过我也没怎么在意。因为和老板关系好嘛,像我这样,再怎么说也属于元老级别的。就这样慢慢的工作了几年。因为小公司什么都要做,技术也积累了很多。包括各种主流数据库的用法,。NET,CSS,JAVASCRIPT,PHP,JAVA,perl,FLASH, 等等,其间,自己独立开发项目的时候,总想找出一种架构,加快自己下一个项目的开发进度。但是每次开发完后,发现上次设计的架构真垃圾。开发过很多项目,每次都想了一些新的架构方法。到现在沉淀下来的还值得用的架构思想也没多少。记得在做JSP的时候,感觉JSP里面服务端代码和HTML混在一起,很难看。不如。NET的事件驱动好用。就去写个模块,让JSP也实现事件驱动的模式。结果写到后来,也没得到什么好处,并且感觉有点不伦不类,后来项目慢慢做大了,才渐渐明白面向对象的用意。当一个项目很小,逻辑很简单的时候,用面向对象的方法设计用处不大,反倒是组件用处更大。因为项目小,基本上都是建几张表,改改HTML的工作。但是项目一大,逻辑变复杂了,如果你要理清楚逻辑,这里就需要一种方法论。我一开始写算法的那种方法有点不适用了。原来那种是从顶层开始,向下细分。是一种至上而下的设计方法。而面向对象不是,它是一种由点及面的设计方法。面向对象是先找出一个个对象点,然后再找出每个点之间的关系。在实际的项目中,你很难从上至下的设计。因为项目需求往往刚开始很不全面,很多项目后来改得都是面目全非。从上至下的设计不适合这种平凡的修改。并且当需求很大时,他涉及东西太多,你也很难从一个俯视的角度去全面的看这个系统。所以从上至下的设计不能满足要求。打个比方,记得一个项目已经做了80%,结果客户觉得用得不方便,要改一下。很多原来做的功能都不需要,并且提了几个新功能。但这几个功能也只是对原来的功能稍加改动。但是逻辑上看却是大相径庭。人脑不是电脑,如果想着这个代码,去改那个代码,势必到后来让自己也搞糊涂了。所以需要抽象出几个对象出来,是按照客户的思维方式。然后抽象出来的对象里面包含原来的功能。这样做起来就事半功倍。

在工作的磨练中,慢慢的发现了普通的程序员与优秀的程序员的一些差别:

1, 普通的程序员遇到问题喜欢张口就问别人,问之前没经过大脑想想。这是一个不好的习惯。其一,自己都没仔细想想,就算别人帮你把问题解决了,你自己不多久就会忘记。下次遇到,照样是不会。因为这个问题你没有经过大脑。其二,能够回答你问题的人,多半是有一定经验了。他们或许很会安排好自己的事情,管理好自己的时间。如果时常去打断他们,他们会觉得你很烦。

优秀的程序员多半会先到网上查找一下相关问题,看看网上有没有相关解决方法。经过一翻查找,他会把这个问题记得比较牢。

2,在一个项目的合作开发中,普通程序员往往只了解自己开发那方面的东西。项目做完后往往对整个项目有哪些功能都不太清楚。可能会有人抱怨,自己工作都做不完,哪有时间去了解整个系统。但现实多半是,花大量的时间去网上闲逛,却不愿花时间去增进知识。 如果总认为项目的设计是设计者的工作,自己没必要去了解。那么这样的程序员只能是手工劳动者。

优秀的程序员会对整个项目有认识,对一些自己感兴趣的功能会去做一下了解,更优秀一点的,会去对整个项目的架构设计做一下了解。自问如果他是项目设计者该怎么做? 去学习项目设计的优秀之处,去发现设计的不足之处。触类旁通,把优秀的地方用在自己将来的工作当中。

3,普通程序员往往有很大的惰性。不能自觉的去学习知识,增进能力。所以每天耗费大量的时间在一些消遣状态中。所以时间往往白白的浪费掉。

优秀的程序员往往会安排好自己的工作和学习。在工作中学习,在学习中工作。能够感觉到自己每天都向着自己的目标在前进,状态佳,动力足。他们因为每天工作情绪很高,所以研究的东西也多,时间比较宝贵。因此他们会善于利用一些工具来操作自己的电脑,大大来的减少琐碎的电脑操作时间。更有胜者,会开发一些符合自己的操作习惯的小程序,来提高自己的效率。说不定这些小程序放到网上共享,可能还会有意想不到的收获。

我现在做项目管理,看着手下的程序员,时常也让我想起原来做程序员时候的坏毛病。比如,上班迟到啊,工作时间上网闲逛啊,交上来的程序BUG成堆啊!看到这些,我时常都是会心的笑笑,可以理解! 不过我也时常提醒他们,如果你们想将来成为IT界的精英,而不是等到30岁感觉自己无路可走,那么请你们珍惜自己的时间。如果你们自己都不珍惜自己的时间,那么别人更不会去珍惜你的时间。

今天花了两个多小时,写了一篇短篇自叙。感觉值得,把自己五年多的光阴回顾了一遍。从前的故事历历在目。写下来过五年后再来回顾一下,说不定会是另一番感受。

程序员如何踏上社会[2]


不过,这里提示大家一点。任何东东,价格和价值是不等的,价值取决与这个东东本身值多少钱,价格则更多地取决与市场需求。大家可以想象一下,目前100个培训班,90个都在教Java,这意味着什么?是不是以后Java程序员暴多。暴多的结果是什么?肯定是跌价啦,因此,我曾经推论,Java程序员以后的薪情堪忧。

反过来,C和C++,如果我们自己肯钻研,钻出成绩来,前景还是很可观的。我们要坚信,C和C++的市场需求还是有的,在游戏业,在通信业,在很多嵌入式场合,C和C++语言都有不可替代的作用,程序员少而市场大,大家知道意味着什么吗?薪水高是不?呵呵,这是肖老师自己YY,乱讲的,大家可以自己想。

反过来说,C和C++的培训班少,我们找不到,清华北大的同学出来,是不是也找不到?这是不是说,在C和C++这条路上,我们和他们又站在一个起跑线上了?呵呵,可能有人会说,那些名校毕业,不需要培训班,当然。但是,名校毕业,我想也不会成为大师,他们工作一开始,还是得老老实实地学,大家说是不?

最后一个问题,去深圳发展。我的建议是不要去了,深圳目前已经比较成熟了,相对来说,机会比起刚刚改革开放时,已经少多了,我们贸然过去,期待有个好的工作,这是不了解导致的幻想。深圳工资高,相对物价也高,大家找工作,不要单纯比较工资绝对值,好好比较一下两地的房价,会发现,深圳的工作,性价比不高的。

深圳还好点,北京上海,就更过分,房价高不说,把个户口看得跟什么似的,外地人过去,很难在当地买房,落户,扎下根来的,会有很多看不见的杠杠在阻碍你。我是这么看的,打工者和城市是互动的,诚然,打工者需要城市提供的环境赚钱,而城市也需要打工者增加税收和消费,进一步增加城市收入。一个城市把自己看的太高傲,不是好的合作伙伴,也不是适合长期呆的地方。我自己就是这么看的,从成都出来,没有选择那些一线城市,选择了西安,主要就是看城市的包容度,基本的物价指数。

嗯,还有个很具体的问题,就是找对象结婚。大家不要笑啊,人之常情,谁也不想一辈子当和尚。 据我所知,越是大城市,北京、上海,甚至成都、西安也有,很多女孩,很浮,看重表面的东东,看不起外地来打工的人。这也没办法,这个社会随着商品化思维的加深,每个人都有一种交易心态,女孩希望嫁好一点,无可厚非。但是,由于她们这个心态,一般都看重一个男人有什么,而不是很细心地观察这个男人的潜力如何,因此,大家就算专业技术再有优势,但只要手边没有现金,没有房子,车子这些硬件,恐怕过去找媳妇,也很困难。大家刚毕业可能感觉不明显,不过,我想过几年,大家就有感觉了。

当然,有人说,我大学里面有女朋友,或者说,我过去也找打工的。完全可以,不过,两个人都是打工的,处于一个陌生的环境,奋斗起来,可能会比较艰难一点。建议大家做好思想准备。

这个话可能某些同学不爱听,不过我放在这里,欢迎PK.

因此,我最后的建议:人一生是很复杂的,和邓大爷一样,三起三落不到头,现在我们看到的,不一定就是一生中最重要的。仔细去看一些最古老的道理,有时候反而更有用。

关键是,这辈子给自己一个目标,定一个计划,只要能坚持走,最后一般都能成功。这个计划,可能很小,比如我一定要成为C和C++的高手,也可能很大,我要成为某方面的专家,我要成为北京人,上海人,甚至我要出国等等,都可以。

关键是,你现在准备做什么?你能坚持多久?

程序员的时空定理[2]


营销法略的法,将产品营销拆解为面向机构客户采用一目标(CUTE)、二手段(建网10-30-60法则、达情1-3-6法则)、三宗案(赖式、袁式、牟式)的国情式流程,面向大众客户采用美式营销的普遍真理(6大要素、经典8P、当今新法)与中国市场的具体实际(本土特征、本土各P)及IT特殊的鸿沟现象相结合的差异定位专业式流程,以及不收客户的钱还能赚钱的出奇守正的第三方流程。

关于为将者的产品人修炼,智(坐知立行)、信(合作共赢)、仁(客户至上)、勇(勇于创新)、严(品质保障)五大素养,在成就企业产品的同时,也成就自我人生的成功。

程序员第二定理,不妨俗称为看远定理,或时间定理,即程序员应就职涯之世论技术之时.古人云,不谋万世者不足以谋一时,这个世就是职业生涯的全景,这个时就是当前的技术实现。反映到程序员需要做的心智模式的第二个战略转变是就职涯(世)论技术(时).

程序员可以选择职业路径,始终做工程技术,其职涯大致的到达路径是研发、技术方面的首席技术官CTO或工程、项目管理方面的工程管理副总VP Engineering;也可以选择职业路径二,从技术端向商业端走,其职涯大致的到达路径是首席产品官CPO、首席营销官CMO或销售副总VP of Sales.一般情况下,这几个职务中能到达CEO的只有从CPO、CMO或VP of Sales上去,从CTO和VP Engineering一般上不到CEO,即CEO更偏向商业,这大抵也是商业驱动技术的写照,美国的CEO九成以上是从有过销售经验的营销或产品人员中产生。

长江后浪推前浪,创新的技术、产品和企业不断涌现,IT行业最大的敌人是周期性的创新衰减,或曰创造性毁灭,即你可以通过创新毁灭别人,新企业也同样通过创新来毁灭你,如微软之于IBM、Google之于雅虎,以及现在打得火热的微软和Google.

企业如斯,人亦如是。IT业人的最大的敌人是因年龄增长引发的激情与创新的衰减,随着年龄的增大,谈婚论嫁、成家生子,你会发觉刚毕业时整晚都可以呆在电脑前的激情逐渐消失了,曾经被自己嘲弄的没有志向的朝九晚六之人,现在又多了一位,而在你心有旁骛之时,长江后浪滚滚而来,就要把你拍死在沙滩之上。

企业应对周期性衰减有三类方法,第一类是依靠技术性垄断延长生命,如微软;第二类是阶段性自我颠覆,如IBM的老沃森、小沃森、郭士纳等领导的三次战略转型;第三类是通过兼并完成自我重塑,如思科。

IT业人亦然,第一种,用人单位就只有你能搞定这个产品或技术,地球离开你就不转,你就是微软,号令天下,莫敢不从,倚天不出,谁与争锋;第二种,跟着新技术潮流,不断学习,与时俱进,完成阶段性的自我颠覆,如原来在DOS下编程,后来Windows,再后来。Net、SOA、云计算等;第三种,从技术领域通过兼收并蓄其他领域的知识和技能,完成自我重塑,如成为PM、成为产品经理、成为营销业务人员。

不谋全局者不足以谋一域,不谋万世者不足以谋一时,这就是程序员的时空定理。

程序员应建立商业意识[2]


玩技术还有一层含义,就是迷恋最新出现的技术,一旦有了新的进展,就要下载尝试一下,或者安装一下玩玩。曾经有一次我们被某公司邀请参加他们的一个技术研讨会。会上有两组开发的团队,一组是原有的技术开发团队,另外一组是最新组建的,而且要准备以.NET技术进行开发,当时.NET还是一个新兴的技术,有人给老师推荐了一位工程师,这位工程师号称对.NET技术很精通。然而,当在会议上这位工程师讲述了自己准备用.NET做产品的构想时,原有的开发团队问到了很多系统设计层面的内容,这位工程师几乎无法应对,因为他只是玩了.NET技术,对于这样的技术在商业上的应用却没有经验。会后,老师也表示:尽管他对.NET技术有一定的了解,但的确经验还缺乏很多。后来这位工程师发展的还不错,进入了微软开发合作部,专门用来讲述微软最新出现的技术,想来这也与他自己的爱好挂上了钩,也是一个不错的选择。不过,这样的职位毕竟只是少数,对大多数程序员来说,玩技术并不能给他带来更高的价值。

前两天,这位工程师又在自己的blog上提到,他用微软最新开发平台内置的屏保程序制作了一个自己的屏保,演示给同事看,同事感觉很新奇。当我看到这条Blog,感到一丝苦笑:玩技术而已!玩技术的另外一个后果便是容易迷失方向。在Dos时代,技术的种类很少,程序员面前的技术方向也很少,玩也容易玩出深度。但随着Windows平台,尤其是网络出现后,各种技术层出不穷,即便是水平再高的程序员也很难兼顾几种技术领域。如果不能够对技术发展的来龙去脉有深入的了解,就很容易限于技术的表面理解,也就很容易造成程序员不知道如何选择要继续下去的技术,丢了西瓜,拣了芝麻。于是会出现论坛中到底是什么技术好,到底应该选择那种语言的疑问。按照大部分过来人的解释,其实只要选准一条技术路线,真正的钻进去,自然会取得好的效果,因为不同的技术之间是相通的。微软工程师孙展波在回答程序员做技术到底应该做深还是做广?的疑问时,毫不犹豫的表示:应该做深,而在广度的方面每周抽出一些时间了解一下就足够了。尤其是在现在互联网如此方便,网上信息量如此庞大,专业类网站密布,检索极其方便的情况下,想要获得任何资源都是一件并不复杂的事情。

而且玩技术还有一个结果,就是容易忽略用户的需求。技术酷是一件很棒的事情,但这并不能保证持续的生存。尽管硅谷曾经以看哪个公司做的技术最酷而吸引程序员的关注。比如最初的是苹果的技术最酷,后来出现了Netscape这种做浏览器的公司给人感觉技术很酷,随后SUN公司推出Java语言的兴起,Java技术变得很酷,但现在,Google搜索引擎成为了最酷的技术。因此,技术本身仅仅注重酷的感觉是远远不够的。

以上《大项目、小项目都是程序员成熟之道[2]》一文,由编辑精心撰写而成,希望对您的职业规划有所帮助,更多精彩请访问“程序员个人简历模板”专题!

相关文章

最新更新