程序员遇到困难的时候怎么办

❶ 程序员的职业生涯通常会遇到哪些为人熟知的职业瓶颈该如何应对

会的。身边同事工资翻了一番，但自己跳槽加薪难，面试无回复，跳槽加薪不高;我想离开一线的开发工作，做一个技术管理的职位。我对自己的技术实力和项目管理能力没有信心。不愿意写一辈子的代码，想寻求职业突破(进入知名公司，拿高薪)却找不到方法，缺乏明确的职业规划。这类朋友还是比较多的，主要是想学但没有方向，这应该是广大程序员工作人群的困惑。

其实，刚开始的时候掘坦，我并不喜欢把自己的作品记录下来，更不喜欢把它写成微博，发布在公众号上。即使在公司里，我也嘲笑它，认为这只是形式主义。但在我被困住的那些年里，我一直在写作，让自己不去想那些事情。这次经历让我想到了用一种新的方式总结经验。乍一看，根据某一条目逐字逐句地输入你的工作经历似乎是在浪费时间。但在不断总结工作经验的过程中，我们对工作进行了更仔细的梳理。这实际上是一个思考的过程，在经验中寻找共性，并逐渐形成自己的工作方式。随着时间的推移，你会摆脱焦虑，找到一条适合自己的道路。

❷ 程序员在Bug面前的反应

开发应用程序过程中一定会遇到bug，这是很正常的事。程序员会有各种反应：生气，沮丧，郁闷甚至泄气，也有一些程序员会比较淡定。怎么修复bug，解决问题，也是一项技能。下面北大青鸟来分享程序员在bug面前反应情况。

当氛围变得紧张的时候，这些话就会显得轻松幽默。最终，bug也会修复成功，你将会继续下一个任务。我相信许多web开发人员和程序员在编程中都会遇到困难，而事后回想起来，会觉得很好笑。

程序员在bug面前反应情况

1、我不知道该删掉还是重写

看这些曾经的代码也别想重写，逻辑性差，冗余代码多，让人难以理解。B不过，如果功能没出现问题，千万别去修改。

2、一开始架构时就该查Github

Github上面每天都会发布的一些神奇的开源项目。所有语言的程序员都会肆粗利用网络，为已存在的项目创建分支，添加项目wiki描述，或者创建自己的代码库，这些都为各种各样的项目的插件和模板提供了丰富的资源。

3、为什么这个脚本要依赖这么多库

说到一些越宏悔来越被广泛使用的计算机语言，像Java和Objective-C，库文件的数量也不断增加。明显能看出，构建一个框架需要许多基础库，一些JavaScript插件也要大量的附加文件。

4、网上一定有解决办法

遇到困难时，第一反应是上网查资料，很多程序员会在论坛上发布他们的问题，最终这些问题都会被解决并存档。Google会很神奇地选择一些跟你的问题相关的关键字，就能够轻松得到一些有帮裂绝镇助的信息。不过，有时一些特定的问题，相关的信息并不多。

5、有这个功能的插件吗

何必多此一举，插件是扩展任何程序或者网站用户接口的很好的资源。另外它们还为开发者提供了一些定制及独特的选项。

6、对于网站项目，好担心InternetExplorer

使用IE渲染网页遇到的各种困难，我就不提了，从5。5版本到IE9-IE10，对于浏览器的支持问题的争议就一直不断。Web开发员很害怕网页调试，使用IE6进行渲染更是噩梦，幸好那已成为历史。

❸ 工作一到五年的Java程序员遇到瓶颈应该如何提升

工作了5年的Java程序员，该如何提升,做了3~5年Java开发，你已经积累了不少项目经验，扩宽了技术广度，也许已发力成为团队管理者。到了这个阶段，大家却常有这种感受：感觉自己卡在瓶颈进步缓慢，技术水平很难像早期一样实现大幅突破？
其实大家往往忽略了这一点——提升自己的架构认知（工作5年左右程序员必须重视架构认知的提升，这会很大程度上推动你今后的成长）。架构的本质在于面对业务场景给出优雅的解决方案，使得业务能够快速迭代和持续交付，从而达到降本增效的目标。提升架构认知高度，就像达克效应所描述的一样，要敢于从愚昧之巅跳到绝望之谷，通过爬升开悟之坡，从而达到架构认知的巅峰时刻。到达巅峰时刻也就掌握了架构背后设计的哲学，面对具体业务场景在架构层面你便能够轻松应对，以无招胜有招。
提升架构认知，要紧抓3个关键点：业务洞察力、技术视野、原创力（执行力）。
1.业务洞察力是技术战略层面的问题，在当下能够做出合理的判断，清楚公司做什么事情收益最大；

2. 技术视野即技术选型能力，是技术战术层面的问题，在清楚做什么事情后，需要进一步解决怎么做的问题，也就是能够给出合理的技术选型方案：是完全基于开源的方案，还是基于开源二次开发的方案，还是完全自研的方案；
3. 原创力（执行力）是技术落地执行层面的问题，一旦技术设计方案确定后，需要能够快速Rush完成。
这3点层层递进，最重要的是先把技术战略问题思考清楚，然后再进一步解决技术战术问题，最后是快速落地执行的问题。
工作5年左右的程序员，在原创力（执行力）层面比较有竞争力，往往欠缺技术视野以及业务洞察力。后面2点更加重要，这2点解决的是架构设计哲学问题，是架构师能够持续拥有竞争力和影响力的立身之道。

举个场景的例子来详细说明：一提到分布式锁问题，大多数人想到的方案是基于Redis的Master-Slave模式来实现。这个实现方案行不行？分布式锁本质是一个CP需求，基于Redis的实现是一个AP需求，乍一看基于Redis的实现是无法满足的。脱离业务场景来谈架构都是耍流氓。
从技术战略的需求层面来看，如果分布式锁在极端情况下获取锁的不一致，社交业务场景能够接受，那么基于Redis的实现是完全可行的。如果业务是交易场景，分布式锁在极端情况下获取锁的不一致性无法接受，那么基于Redis的实现方案是不可行的。在锁强一致性的场景下，需要采取基于CP模型的etcd等方案来实现。

❹ 程序员遇到很难的技术问题是怎样的感觉

昨天刚领一个线上P0级重大事故，持续时间1小时，影响范围全站 ！准确的时间点是下午17点开始，具体问题定位且听我下文细细道来。

先说感觉，那感觉真是太刺激了，本来下午五点，昏昏沉沉的，瞬间一个激灵就清醒了（想象一下高中课堂，你在打瞌睡，突然老师走到你面前给你一下子的感觉），原本准备再过一小时吃晚饭了，吃完晚饭再摸鱼到21点就可以下班了呀，别问我为啥到21点，问你就不是程序员！

带着无比紧张且颤抖的心情开始定位问题，先来个错误日志尝尝鲜：

整个事情的发酵是这样的：

1、下午五点开始有少量的慢sql报警，没有人当回事，因为这种事情总发生，虽然大家都知道在实际开发中如何避免慢sql，但是整个团队要想完全避免慢sql却很难；

2、五点十分左右，开始零星有用户反馈指定功能不可用，SLB开始报警，技术开始介入排查；

3、十五分左右，客服部门电话开始爆炸，用户密集反馈指定功能不可用，技术部开始重视；

4、二十分左右，所有服务大面积出现接口无法响应，整体服务不可用；

5、我们一开始定位觉得是MySQL的问题，因为前面有mycat的慢SQL报警，后来定位并不是MySQL，因为MySQL的内存、连接数、流量这些指标都很平稳；

6、最终在五点三十分的时候我们定位到是ES出问题了，因为所有的Java服务不可用最终都指向上面的错误日志，bbo提供的服务线程池满了，再有请求进来直接拒绝了，查看这个服务的代码，最终查询的是ES，此时的ES进程已经处于假死状态。

那接下来大家说怎么办？如何快速的恢复线上服务？

重启！

是的，只有重启大法此时是最快的解决办法，你不可能说保留ES事故现场，让我用arthas之类的工具来现场分析jvm内存情况。

然而重启之后服务依旧是不可用，接口还是无法响应， 大家知道这个时候是什么原因吗？为什么重启了ES服务还是不行？

后续继续重启报错bbo日志的相应服务，当这些服务全部重启完毕后，我们的服务终于恢复访问了，这个过程持续了十几分钟，确切的说，直到17点五十多分，我们的所有服务才恢复了访问。

接下来就是事故总结、相关责任人、产生问题的原因、接下来的优化方案，全公司邮件通报！

你说这个难不难？本身并不难，难的是事情紧急且重要，这个时候你慌了啊，乱手乱脚的，大家你一言我一语的，如何冷静提取有效信息然后尽可能快的解决生产的重大故障才是最难的！

最后，当一切都恢复平静的时候，你会发现：“卧槽，好累啊！”。

虚脱的感觉！

最后祝大家程序员节日快乐，今年可是程序员的本命年哦

2020 = 1024 + 996 = 404 + 404 + 404 + 404

这种感觉能难受，很压抑。

技术难题，对于程序员来说，是经常有的事，关键是如何面对吧。

说下我的事情，虽然也会写点代码，但并不是以此为正业，所以对于真正的程序员来说，可能说法会有点偏颇。

遇到难题时，一般都在网上搜索解决方法，一般来说，都有很优秀的程序员分享他的劳动成果，所以一般都能解决问题。但也真正碰到难的问题，一个就是循环的问题，无限极菜单问题，当时都是找了很久，看了很多遍才明白过来，当时自己是几天都不太开心，也不太想说话，总是在测试着程序。挺烦也挺不开心的。只是最后做出来了，心情就好多了。

这是我的一些经历，当然，如果全职程序员，可能压力就更大了。

如何形容这种感觉呢？焦躁，紧张，失落，无助，亚历山大...

再多词可能都描述不清楚。本人在工作中经常遇到难题，有些问题一两个月都搞不定。遇到这种问题，估计只有下面这张图的表情能描述此时此刻的心态了。

程序员遇到的难题其实分为两种，一种是没有办法定位清除的问题，另外一种是定位清除了，但是没办法，或者很难解决的问题。

难定位的问题

所谓难定位的问题，其实就是你根本不知道这个问题是什么。比如系统突然挂掉了，你从现有的信息根本不能确定问题在哪。这个时候你剩下的可能只有满脑子的问号了。

如果系统只挂了一次，后面不再出问题，那就很难找出问题的根源了。不过这样也有好处，那就是问题的影响的程度相对较轻，毕竟不容易出现。所以在软件开发中通常不是什么问题都解决的，因为不是所有问题都能搞清楚是什么问题，谈何解决呢！

难解决的问题

难解决的问题是问题搞清楚了，但是基于现有架构很难，或者没法搞定。遇到这种情况，通常先是很高兴，兴奋，然后就只剩下无奈了。

当然，从技术层面来说并不是完全解决不掉。只是如果要解决需要涉及架构调整或者其它方面的改动，修改调整的内容太多。这种情况下就要考虑利弊得失了。

如果改动太大，可能会引入很多新的问题，可能得不偿失。因此，遇到此类问题可能会采取一些规避方案。

当然，在开发和运营当中遇到各种问题是很正常的，关键是遇到不同的问题采用不同的策略。首先保证的是业务的正常运行，然后是考虑是否需要彻底解决。这样慢慢调整，心理压力会小一些。

作为一个工作多年的老码农，在工作也遇到过一些艰难的技术问题，就以切身体会谈谈对这个问题的看法。

首先需要明确一下，问题是否困难除了取决于问题本身之外，还在于解决问题的人的水平，也许对你很难的问题，在别人看来不过是小菜一碟。明白了这一点，那么这些技术问题也就成了考察程序员水平的试金石，有些人可能会因此气馁，甚至放弃；而有些人则通过解决问题学到了很多新的技术，也让自己进一步成长。

记得多年前看工作中要用到一款开源库，那时候刚学完C++不久，自以为对面向对象了解甚深，然而学习这个库时却是一头雾水，最后在经过泡论坛，然后又认真的学习了面向对象设计模式，后来不但能使用那个库，更重要的是对面向对象编程有了更深的认识！

后来还有很多类似的事情，刚开始时感觉无比困难，但是通过自己的努力，或求助他人、或查阅资料，当最终问题解决时，你会发现自己又牛逼了一些，然后再遇到一些新的问题，如此循环……

其实编程也是一个学习的过程，就如同爬山一样，每一阶段都会有一些山头，只有当你爬上山头才能欣赏美丽的风景，但是当你爬上一座山头的时候，就会发现更高山峰！只有当你爬上最高峰，才能“一览众山小”，可是到那时，你可能会向往地球之外的天地！

很难解决一般就是遇到某些瓶颈了，不同瓶颈的感觉是不一样的，但无非可以归结为下面几类。

成本原因
不让马儿吃草，还想让马跑。这个是有些不太理解互联网的一些领导的错误观念，他们会给你安排一个老旧台式机，想要让你承载几万、几十万并发的秒杀系统，你当然很难解决。
外界的评论可能是，“这帮程序员是吃干饭的么？这系统也太垃圾了！”
老板的评论是，“我这台式机也不少钱呢。”
程序员的评论是，“这抠门老板不会是个傻子吧。哎，再优化优化吧。”

当然，有些情况也是能够理解的，公司明白需要更好的设备，但是由于成本控制，不得不在某些方面节省。但换句话说，设备成本是占不了一个大头的，可能有其他方面的成本更加需要收紧。

如果是因为成本原因，我们的心情可能是无奈，又有些不能施展拳脚的束缚感。

历史 原因
举个例子，系统用了5年了，迭代了N个版本，在面对新的需求的时候，就会出现需求限制于系统的情况，常常会有程序员说，这个实现不了，那个不符合现在系统规则。其中很大一部分是这些年的积累，欠下的技术债造成的。俗话说，大船难调头。

这种情况更多的出现在刚创业之后的几年，由于一开始的快速迭代，追求先把业务流程跑通，先生存再规范，会让一开始的软件开发流程并不那么规范，如果在1-2年内没有进行重构，那么积攒的3-5年的技术债就会慢慢把你压得喘不过气来。

解决这种情况，一是需要时机，给出足够的空间和时间让技术团队重构，二是需要魄力，你得有成功的把握，不能干着干着说不行了，咱们还是回到原来吧。

如果是因为 历史 原因，我们的心情可能是期待和渴望，又有些对现状的无奈。

能力原因
虽然说专家很厉害，但说白了，大部分企业需要的研发人员，还到不了需要专家的级别。所以，一般而言，没有什么技术是攻克不了的。如果真的遇上了，那就说明你的公司已经到达了一个新的层次，从而需要那个层次的人员来解决，可以通过外聘或者顾问的方式，引进新的技术。

如果是因为能力原因，我们的心情虽然有些力不从心，但又为公司在新的台阶而高兴。

不管怎样，程序员是一群追求美好的人，不管是外部限制还是内部限制，不能解决的难题对于技术人员来说总是很憋屈的。

不能着急，慢慢分析，找到问题点，没有解决不了的问题

程序员的技术问题，排除架构师技术选型错误以外，都是程序员的功夫不到家所致。

1,面向网络的程序员会第一时间问度娘，各大社区求助大神。

2,面向源码的程序员会第一时间查看源码实现，查找api文档，思考解决方案。

3,不管技术如何发展，架构如何延伸，不变的是基本功，再先进的组件都是由基础语法书写出来的 。

练武不练功，到老一场空，共勉！

首先说下这个很难的技术定义，个人认为在你知道之外的知识都是很难的，一旦你深入了解其使用方式，原理，甚至阅读了他的源码，你会觉得有的时候会恍然大悟。程序员是一个不断要学习的岗位，就要面临很多从未知到已知技术的时候，每当遇到这样的情况时候，总有种不解决了这个问题，睡不着觉的感觉，心里不踏实，总是想尽各种办法去解决这个问题。甚至可以一直追查这个问题。也许这就是一种执拗吧

我老公最近就遇到一个大石头需要敲碎，我作为一个旁观者，都挺心疼他。

他还在读博，最近遇到的问题是他一个项目上的问题，也跟他的毕业设计相关。他刚读博的时候确定了一个方向，去年开题的时候他觉得这个方向没有什么前景，真的是考虑了好久要不要换，如果不换，就是安稳的毕业，换的话接下来的一年多时间他会很艰难，很多新的问题需要一一克服，最后他决定换了，他说他读博就是为了提高自己，还是想挑战一下。

年前，系统板设计好了，然后最近做好回来了，开始调试，说这个板子跟个石头一样，不工作。本来就是礼拜一到礼拜六待在学校不回来，周日是休息的。现在放假回来都是在啃变压器的东西，早上起的很早，晚上又很晚。真的挺心疼的，他还安慰我说，他又要进步了。挺担心他的身体的，我特别希望时间能快点过去，能顺利毕业。他却不希望，总觉得时间过的太快，没有时间搞研究。

今年的生日愿望，希望他科研顺利，身体 健康 。

以我的从业经历，说说遇到很难的技术问题是什么感觉吧： 兴奋、充满挑战性 。尤其是在开发中遇到了技术难题，很多情况下真有种可遇不可求的感觉。

我认为能遇到技术难题，至少证明这个工作是有价值的。 这种价值体现了两个方面，一是你的工作在整个产品开发中占据重要地位，甚至是核心地位。二是你的认知和经验，仍然有成长的空间。如果你的工作一直没有遇到难题，轻而易举地就解决了一切，那么很可能是你没有机会深入重要的核心部分，或者你的工作性质可替代性很高，简单重复性很高。

分解法。 把技术难题拆分，尽量的单元化、模块化，这样有利于逐步攻破，逐步解决。主要是降低技术难度，寻找真正的难点所在。如果问题无法拆分，就是那么一个点，那么需要逆向思维，可以先把问题扩大，看看涉及面有哪些，然后再缩小范围，锁定关键之处。

刨根法。 把技术难题抽象化，理论化，从根本的源头去解决。很多技术问题，从基础理论的角度去看，其实真的不难，只要你能定位到相关的技术点，困难点，知识点，就很容易进行快速解决。解决的终极办法就是从理论上彻底解决，做到知行统一。

讨论法。 三人行，必有我师。很多情况下，所谓的技术难题，在别人的眼中，也许并不是难题。很多情况下，小组讨论，交换意见，方案互补，就可以解决难题。有些情况下，还需要和供应商一起讨论，主要是补充信息的错漏。经常出现的芯片问题，很多情况下供应商都更加有经验。因为供应商有更多的使用客户，有很多解决问题的经验。最主要的是，芯片是他们设计的，他们更加清楚缘由。

没有绝对的技术难题，有的只是尚未解决的技术难题。

❺ 程序员编程时心力交瘁，失去工作热情怎么办

心力交瘁中

导读：程序员在编程的时候因为心力交瘁，从而失去工作热情的现象并不罕见。很多文章都可以成为这一方面的证据，证明这已经是IT行业一个普遍现象。因为我已经有处理过职业倦怠的经验，所以我想要更深入地探索这个问题，帮助大家解决甚至预防它。

倦怠发生的原因

程序员比其他领域的专业人士更容易产生职业倦怠。至于为什么会出现这种情况，我也没有一个明确的答案，但我认为有四个主要原因

第一个是生理原因。每天坐在办公桌前，面对着电脑，是不健康的，会让人更加无精打采、昏昏欲睡。嗜睡还可能导致其他不良的生活习惯，如吃零食，抽烟，熬夜等。然后最终导致郁结于心，产生倦怠感。

第二个原因是，编程是认知高度密集并且压力非常大的工作，会导致心理疲劳和损伤。

第三，有可能你现在已经精疲力竭了，因为正在做的工作耗尽了你的力量，并且收获甚微。对此，唯一的解决办法是离开一段时间，好好反省下――如果不考虑钱的因素，你希望做什么样的工作。

第四个原因不是我想出来的，是我在《Hacker News》的评论部分发现的。有一个人准确地描述了，“职业倦怠是由反复做大量牺牲，或努力完成高风险问题最后却以失败告终而导致的。这是伏隔核(nucleus accumbens)负面预测落差的结果。你的大脑需要理智地应对失败。这一条说得真的太对了。在创建软件的过程中，基本上没有一天不是处在各种失败和挫折中。

我本身也经历过好几次职业倦怠。虽然我没有一次放弃编程，但偶尔我也会怀疑我选择的职业是否正确。所以，从那时起，我开始注重策略化的工作方法，以保持长效的动力和生产力。我将在这篇文章中介绍我的一些开发习惯，以及一些可以预防或甚至消除倦怠的技术手段。

先从基本的开始。

吃好。不要以为做个素食主义者就万事大吉了。试着逐渐用白开水代替苏打，低糖饮食，多吃蔬菜，不要吃得过饱。还有最重要的是要持续下去。

睡好。这包括良好的睡眠质量和充足的睡眠时间。更好的睡眠环境，能够让我们一觉醒来倍感清爽。具体的一个技巧就是减少会让人彻夜难眠的蓝光照射。这可以通过安装Flux，来调整计算机显示器的色彩。

不要劳累过度。已经有很多证据表明，生产效率，即输出，会在经过4个小时聚精会神的工作之后，急剧降低。像程序员这类认知高度密集的职业，要想长期保持高效，那是不可能的。

番茄工作法。这对于既要保持生产力，又要获得一些必要休息的程序员，是一个既简单又有效的方法。番茄工作法，即集中精神工作25分钟，然后休息5分钟，然后循环。如果在每次的工作时间都有一个特定目标，效果会更好。理想情况下，在休息时间里，应该去做一些远离计算机的活动。如散步，俯卧撑等。当然你还可以在三次番茄工作法后，休息个30分钟，效果也很好。

保持活性，保持前进。我本来想说的是――运动，但很多人有一种误解就是，认为运动必须包括去健身房，或其他。但是在现实中，保持活性也可以通过用爬楼梯代替乘电梯，或者将汽车停放在一角，而选择骑车上班，总之，其他在日常中就能运动的方式更易于实现，而不是让人整天沉溺在电脑前。

更具体化的要点

实验，玩，学，原型。这些事情能让你在短期内获益匪浅，并且迅速输出。例如，以同样的你惯用的方式，不断地建立网站。但是，随着时间的推移这会逐渐变得乏味，让人提不起一点兴趣。编程有部分也是工程，需要使用经过充分验证的技术用于生产软件。但它也可以让你玩乐、实验和尝试新想法。将20%的时间消磨在技术上是避免职业倦怠最有效的策略之一。所谓消磨在技术上可以是尝试新的库，也可以是创造一些有趣的但与工作无关的东西，又或是学习一些自己以前不曾涉猎的内容，如函数式编程。

参加聚会，会议和收听播客。编程会让人感到孤单。和其他开发人员碰面，或在播客上听他们的经验，能让你更在意和注重自己的工作。没有人喜欢抱怨，但是分享或聆听来自于其他程序员的奋斗经历，以及他们如何克服困难的过程，能够激励你继续前进。

打造良好的工作环境，千万不要在工具上吝啬。能快速编译的PC，能让你的时间不必浪费在没有必要的等待上。确保有一个舒适的椅子、桌子和显示器以及设置。如你在嘈杂的环境中工作，那么买一个高品质的耳机，将噪音隔离开来。

掌握工具。良好的工具可以使得编程更加愉快，掌握这些工具能让工作更加高效。这是众所周知的一点，但我还是要再重复一遍。了解工具，如编辑器，操作系统，命令行中的所有快捷方式，可以为你节省很多时间。自动化日常任务可以加快进程，进一步远离倦怠。

休息，涉猎其他方面。除了编程之外，还有许多有趣的活动。例如：体育运动，文化活动，sex，阅读，乐高积木，社交活动，钓鱼，烘焙，摄影等。如果你总是持续做一件事，如编程，那么总有一天你会不可避免地心力交瘁。所以，做一些看似无关但实际可以重新点燃激情的工作，这些工作或许还能激发你新的想法和思路，就像那位传奇的诺贝尔奖获得者理乍得费曼学习板摆动一样。

考虑更换工作或启动一个不同的项目。职业倦怠也有可能是因为你总是在做无趣，又耗费心力的工作，如整天微调现有的代码库。也有可能是因为你现在工作的项目已经不符合你的兴趣，或你的价值标准。此外，如果你发现编码再也激发不了你的激情，那么也可以考虑相关领域，如信息架构，系统管理等，也许可以再次点燃你的激情。

将那些你可以顺利完成的工作，整合为日常任务。这些工作包括测试代码，写注释，改善变量命名等等，这些都可以释放内啡肽，有助于恢复工作行为。这条技巧意在让我们的大脑对我们做的工作更有积极性。

结论

世上并没有治愈职业倦怠的仙丹妙药，而且每个人的情况都不尽相同。所以，希望我上面列出来的这些我觉得有效的小贴士也能为你所用。

诚然，我们需要时间来培养新的习惯。但是吃得好，睡得好，锻炼和好好照顾自己，能让你感觉更好，从而帮助你在完成工作的时候做得更好，并保持对编程的热爱。

❻ 程序员都会遇到一些职业瓶颈，程序员该如何规划自己的职业生涯

我也有工作上的困难，就我自己的经验来说吧，我是如何渡过的！工作上的困难和体重的困难都有一个共同点，那就是，紧张会让你的情绪变得很糟糕。情绪的高低直接关系到个人的心态，在开心的情况下，工作起来会很放松，而在情绪低落的时候，就像是一年那么漫长。情绪低落大多是因为家庭的事情，人脉，压力。这就要求我们去处理和缓解我们的紧张情绪。让我谈谈如何缓解你的紧张情绪。

亲戚朋友，把自己的情况告诉亲戚和亲戚，让他们帮你解惑，如果你在这个地方，可以和你的好朋友或者家庭成员聊聊工作上的困难，大家一起努力，总要有一个好的办法。要么就是和他们一起工作，然后在外面走走，或者找个时间出来玩一玩，让自己有个放松的机会。

❼ 程序员，感觉技术停滞了怎么办

你是一名程序员，感觉技术停滞了。那你就去深造呗，就是你可以选择各种的程序任务去做。哦！针对自己有弱点的地方，然后去学习。活到老，学到老。