I’ve been in the IT industry for almost 8 years working in 4 different companies. During this time I had a chance to work with a couple of dozens of programmers. They were different. I observed some of them successfully developing their career; some were satisfied with their position and continued working many years for the same company performing similar tasks; a few have been fired. Based on my observations I came up with a list of tips, which, in my opinion, can help programmers to succeed at their current workplace. Here it is:
1) Don't Hesitate to Ask Questions
I noticed that some programmers hesitate to ask for help from the very first days in the company, e.g. when they encounter problems with the project environment set up or when they work on a task but don’t fully understand the business flow behind it. It’s not a big deal – just ask for assistance or clarification. Otherwise you’ll waste a lot of time struggling with a typical project-related problem or guessing what should be the correct application behavior in this or that particular case.
Another problem is hesitation to ask questions even when you’re expected to do so. For example, last year a lead developer and a manager of our company were visiting our regional office to get to know us (developers) in person and to give a few presentations. They asked us to prepare a list of topics and questions we’d like them to present and clarify to us. I was surprised to see that only a few people contributed to this list, although the range of possible questions was unlimited, from “why are we using a NoSQL database in that particular module” to “what features of the application are the most popular among our clients”. Don’t be afraid to ask questions, especially in such cases.
2) Search for a Niche
It often happens that several company projects or project modules lack resources. This means that either when you just start working for a company or finish your current project, there’s a chance that you’ll be able to choose or at least let your manager know about your preference project- and task-wise. Many people tend to join the newest project or feature. Some prefer to join a team, where a few of their close colleagues already work.
In my opinion, it’s better to do the opposite – choose a project or a feature that’s not known by many other fellow developers. When I had such choice, I’ve chosen a task from a module only 1 person specialized on. Initially I had to spend more time getting familiar with the business flow and existing code. But later, when I already knew the module well enough, it turned out there’s a lot of new stuff to be implemented in it. More and more new features have been requested by the managers. Not surprisingly, I was asked to implement many of them as well as was one of the first points of contact for developers, who started getting involved in this module after me.
3) Get Familiar with the “Big Picture” of the Application
Nowadays almost all of the enterprise applications are fairly complex and consist of many modules that might be using completely different technologies. For instance, the current application I work on consists of 3 parts:
- a module that interacts with social networks and collects data;
- a module that processes all the collected data;
- a UI module
Each of the modules is developed and maintained by a separate team of developers. The modules are different technology-wise but related business-wise. This means that whenever a new feature is introduced, it affects in most cases all the 3 modules.
There aren’t that many people, though, who understand the whole business flow. So, whenever a new feature is discussed, the managers tend to involve people who can make a top level assessment of changes that will be required in each of the modules. So, if you know the big picture, you have a better chance to get involved in such discussions.
Besides, when you know the big picture, you understand the kind and complexity of tasks that are being performed in each of the modules. Thus, there’s a chance that some tasks and technologies, used in one of the modules, will become particularly interesting for you. Remember that it’s much easier to switch to a new technology within the company where you’re already considered a senior developer, than to start searching for a new job.
4) Do What You Need to Do, Not What You Like to Do
Some very talented programmers suffer from a serious issue – they have a specific field of interests and whenever they’re asked to do something different, they show poor performance and quality, because they can’t concentrate on the stuff they don’t like to do. For instance, people might love experimenting with Scala, but have to deal with Hibernate or native SQL; they might love concurrency, but have to assist with the front end-related work.
If you’re one of such programmers and have to permanently deal with the technologies that you can’t stand – you probably need to change the job. Otherwise, if you just temporarily need to help other developers in the areas you don’t really like – you have to show the professionalism and do a good job anyway. Just remind your managers about your preferences, so that they don’t ask you to work on that stuff too often.
The same is applicable to the tasks with different priorities. It might sound obvious, but remember: you have to pick up the one with the higher priority, even though the one with the lower priority looks way more interesting to you. Be a professional!
5) Share Your Knowledge and Help Your Colleagues
Have you ever encountered colleagues who are way more productive when working alone? This might be an indicator of poor communication skills. Sometimes it gets even worse – believe it or not, some developers don’t really want to share their knowledge. Kind of a selfish attitude, eh? Such people wish either to be irreplaceable or to make sure their colleagues face all the issues they had to face to make their life as hard as their own. No wonder that such behavior gets noticed fairly quickly by fellow developers and managers and doesn’t give any credit to such “lone wolfs”.
Moreover, when you’re working in a regional office, remember: if one of your colleagues doesn’t do his job well, the whole office suffers in terms of reputation. So, if you can help your colleague – just do it, it’s a win-win solution.
This was the first part of the blog. In the next part I’ll describe another 5 tips that can help you to stand out at work. Stay tuned!
文章作者 Yuriy Lopotun有着8年的IT工作经验，分别在4家不同的公司。在这期间有幸和一些程序员一起共事，他们都很特别：有的人在这个行业里取得了成功；有的人对自己的现状很满意，就一直在一家公司一个岗位上干了很多年；还有一部分人被炒鱿鱼了。基于作者自己的所见所闻所想，于是列出了下面的能够帮助程序员在工作岗位上取得成功的建议。（以下是编译内容）
1. 大胆的提出问题
有些新的程序员在进入公司的第一天很犹豫是否要去向别人寻求帮助，比如：当程序员在项目环境设定上遇到问题或者是他们不明白这个项目的商业流程的时候，他们很犹豫，不知道该不该问出这个问题。其实这都不是什么大的问题——尽管寻求帮助，或是向别人澄清一下你的想法。否则的话将会在和项目有关的问题上纠结、浪费时间。
还有一种情况就是，当领导让你自己提出根本没有任何限制的问题的时候，很多程序员对自己的口才很吝啬。千万不要害怕问问题，尤其是在大的环境下。
2. 找准自己的定位
在很多项目或者项目模块里缺少资源，这就意味着在你开始工作的时候或是完成目前项目的时候要让你的领导知道你的偏好项目和执行能力。许多人常常是喜欢加入一个新的有特色的项目，而有的人喜欢加入一个有熟人的开发团队。
不过，最明智的选择是挑选一个没有多少同行的开发者知道的项目，只有你一个人在这方面擅长。只不过在刚开始的时候需要花大量的时间去了解熟悉它的运作模式和现有的代码；当一切事项都已掌握之后，就可以向管理层自我推荐，领先于别人，就是超越了自己。
3. 熟悉App的“蓝图”
现如今大多数的企业App都是比较复杂的，使用不同的技术完成的模块来组成的。作者展示了他现在的工作就是由3个部分组成的：
- 一个和社交网络和收集数据互动的模块。
- 一个处理收集的所有数据的模块。
- 一个UI模块。
每一个模块都是由不同的开发者团队开发并操控的。这些模块在技术上没有什么联系，但是在商业流程上是相互联系的，也就是说，无论什么时候想要引入一个新的功能的时候，都会影响到这3个模块。
事实上并没有多少人理解整个App的商业流程，当讨论一个新功能的时候，经理常常会要求在行的人对软件程序的更改最初最好的评估，评估结果可能会用在每一个模块里。所以如果你这道这个App蓝图的话，你就能参与到这个讨论中。
4. 做你需要做的事，而不是做你喜欢的事
一些非常有才能的程序员经常会遇到很严重的问题——他们有自己的特别之处或者说是感兴趣的方向，一旦被要求去做其他的不一样的事情的时候，能力和做事质量就下降了。因为他们不能集中注意力在不感兴趣的事情上，这是很致命的短板。你如说：人们可能想要测试Scala，但必须先处理Hibernate或原生SQL；他们可能想要并发性，但是必须要协助与前端开发相关的工作。
如果你需要长期处理你自己根本不擅长的技术问题/工作，那么你最好换工作。否则如果你是临时帮助别人处理你不擅长的问题，最好表现的专业一点，把事情做好。
5. 善于分享，乐于帮助
估计很少有人单枪匹马的情况下还能有很高的产量吧，这只能暗示在交流上的贫乏。自私是团队合作的最大障碍，最后也只能是整个团队停滞不前的结果。这样的“孤狼”也基本上得不到团队的信任。
此外，如果你在一个区域办事处工作，而你的同事没有把任务做好，你最好去帮助他，因为团队荣誉至关重要，这也是一个双赢的决策。
6. 尽量给出现实的评估
给出太乐观的评估对于程序员来说是比较困难的，作者站在自己的立场给出两大主要原因：
A. 我们经常忽略将要花费的时间：
- 在实施阶段处理预料之外的问题。
- 在开发环境上测试实现的功能。
- 编写单元测试和集成测试。
- 分散时间和精力到其他高优先级任务上。
B. 有时在给出真正的评估之后会让我们觉得不舒服，因为经理看到这样的评估之后表情会很吓人。在这种情况下，我们通常会把特点划分成几个子任务，以至于总的评估看起来不是那么可怕。
太乐观的评估在大多数情况下会有悲惨的结局：
你必须把任务移到QA在一个buggy状态下，通过思考来证明它：“通常QA会返回所有开发功能列表的备注资料给开发人员，所以我仍然会有机会解决所有的bug”。但是在现实的评估条件下情况就不会是这个样子了。
7. 测试，测试，再测试！
许多程序员因为错误评估而被迫转入QA环节，有些程序员在交货期来临之前停止了任务，转入测试阶段，只是想证明他们的高效能。当然了，这是一个好的意图，但是并不似所有的掉头检查都能带来好的结果。总之，中途检查要比从头开始好得多。
再次强调一下单元测试和集成测试的重要性。它们是回归分析的第一个指标：一个打破现有功能的机会。不幸的是,有些人编写测试只有一个目的——避免漏掉代码覆盖率而带来的责任。这样的代码在代码审查过程中需要被捕获并拒绝，这是提高代码质量的另一个好方法。
8. 记住：谁都会犯错误的。
有谁希望和一个出现bug就喜欢批评别人的的人一起工作呢？估计没人愿意，但事实是我们大多数人看起来就是那个样子，只是自己没意识到。下面列举了一些避免出现这些状况的建议：
如果你和同事一起构建一些功能，而他有稍微慢了一些，与其去责怪他还不如去帮助他，至少应该到经理那去争取更多的时间。既然需要共同的按时交付产品，那么两个人对这项功能的完成都是有责任的。
当你修复了一个bug或者是发现了一个bug，即使你知道是谁的缘故导致这些bug的出现，也没必要通过网络电话渠道让公司里的每个人都知道这件事。犯错误是在所难免的，有的时候你会遇到“ugly code”模块，同上，不需要让更多的人知道它的制造者。
如果你对一个同事有什么不好的意见，都没必要向你的上级反映，除非上级向你询问。首先你要确保你的上级是一个开明人士——知晓他所管理的团队里队员的强项和弱项，这样才能处理好队员之间需求。
恰恰相反，我们应该经量多的向大家包括领导反映同事做的一些好事。比如，数周之前我的一个同事在早上7点钟的时候临时驾车到公司来试运行App模块，所以他应该得到大家的赞美之词。
9. 在社交网站上宣传公司的强项。
现如今，基本上每个程序员都在使用社交工具。你可以关注朋友们的公司，也可以在网上介绍自己所在公司，不管是好事还是坏事，都可以在网上贴出来：有的时候会组织技术峰会、赞助商会议、商业论坛、发布会、寻找新的开发者等等，社交工具对于一个程序员来说是有很大的用处的。除此之外，有很多的网站上都有公司人员对公司的评论，任何人都可以写，当然，只要是你喜欢的内容，没必要撒谎。
在国外，想要和公司CTO或者是CEO进行交流的最简单的方式是通过Twitter，在国内可使用的交流工具也是各种各样啊！
10. 小建议和小技巧。
接下来的是一些能够让你获得领导或者同事的赞美的建议和技巧：
A. 适应老板的时区
许多来自欧洲和印度的程序员都是从美国那边接受发自总部的指令的。在这种情况下，如果程序员能够在晚上的时间段和美国总部进行交流讨论工作上的事情，肯定比在下午5点钟下班时候和总部进行交流所获得的工作效率要高得多。
B. 如果有需要，任何时候都要帮助公司做事。
身边的例子：公司的生产系统需要全天候的监视着，因为任何时候都有可能出现问题。通常情况下是区域的程序员参与监视，但是去年的新年假期期间我们被要求留下来值班，我被安排在大年三十那天，我本来可以要求调整一下的，但是我服从了公司的安排，很幸运，那一晚上基本上没什么问题出现，我在一个很正常的环境下度过了我的新年，但是至少公司知道我随时愿意为公司付出。
C. 在公司的指引下参加应聘面试
如果你有机会以面试官的身份参加面试，一定要好好利用这一机会，因为这是无价的经验。首先，这能发挥出你的口才能力，很多程序员都缺乏这样的技能。其次，你可以认真听一听别的面试官（你的同事）都问了哪些问题。最后，你对求职者的观点将会纳入参考范围，这关乎到这个应聘者最后能不能加入到这个公司里。
221
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
