https://dev.to/mokkapps/my-definition-of-a-senior-developer-3k8l
http://markm208.blogspot.com/2013/08/the-biggest-challenge-to-being-software.html
http://www.vaikan.com/the-biggest-challenge-to-being-a-software-developer
The main point that I am trying to make is that our peers and colleagues have to become our teachers, and our companies must support developers' teaching, learning, and experimentation. Teaching and learning should be an in-house activity. Luckily, all of this teaching and learning can easily be quantified and used as a performance measurement. If you are not actively learning from others and not making the people around you better, then you are not fully contributing to the team.
- Make learning a part of the culture. In your company, make teaching to, and learning from others a measured performance goal.
- Hire people who are good problem solvers and let them learn what they need to know on the job.
https://github.com/ahangchen/How-to-Be-A-Programmer-CN
How to Stay Motivated
To be trusted you must be trustworthy. You must also be visible. If no one knows about you, no trust will be invested in you. With those close to you, such as your teammates, this should not be an issue. You establish trust by being responsive and informative to those outside your department or team. Occasionally someone will abuse this trust, and ask for unreasonable favours. Don't be afraid of this, just explain what you would have to give up doing to perform the favour.+
Don't pretend to know something that you don't. With people that are not teammates, you may have to make a clear distinction between 'not knowing right off the top of my head' and 'not being able to figure it out, ever.'
How to Balance Brevity and Abstraction
How to Learn New Skills
Humans learn by doing. Book-reading and class-taking are useful. But could you have any respect for a programmer who had never written a program? To learn any skill, you have to put yourself in a forgiving position where you can exercise that skill. When learning a new programming language, try to do a small project in it before you have to do a large project. When learning to manage a software project, try to manage a small one first.
A good mentor is no replacement for doing things yourself, but is a lot better than a book. What can you offer a potential mentor in exchange for their knowledge? At a minimum, you should offer to study hard so their time won't be wasted.
Learn to Type
by the time you are an intermediate programmer you will probably spend a lot of time writing natural language to your colleagues and others.
How to Do Integration Testing
Ideally you should organize a project so that there is not a phase at the end where integration must explicitly take place. It is far better to gradually integrate things as they are completed over the course of the project
Communication Languages
UML is a rich formal system for making drawings that describe designs. Its beauty lies in that it is both visual and formal, capable of conveying a great deal of information if both the author and the audience know UML. You need to know about it because designs are sometimes communicated in it.
Heavy Tools
Relational Databases,
Full-text Search Engines,
Math libraries,
OpenGL,
XML parsers, and
Spreadsheets.
How to analyze data
How to Manage Development Time
How to Manage Third-Party Software Risks
It is unwise to be merely sceptical of a software company's promise to release a certain product with a certain feature at a certain date; it is far wiser to ignore it completely and forget you ever heard it. Never let it be written down in any documents used by your company.
How to Communicate the Right Amount
Carefully consider the cost of a meeting; it costs its duration multiplied by the number of participants. Meetings are sometimes necessary, but smaller is usually better. The quality of communication in small meetings is better, and less time overall is wasted. If any one person is bored at a meeting take this as a sign that the meeting should be smaller.
Everything possible should be done to encourage informal communication. More useful work is done during lunches with colleagues than during any other time.
How to Disagree Honestly and Get Away with It
Disagreement is a great opportunity to make a good decision, but it should be handled delicately. Hopefully you feel that you have expressed your thoughts adequately and been heard before the decision is made. In that case there is nothing more to say, and you should decide whether you will stand behind the decision even though you disagree with it. If you can support this decision even though you disagree, say so. This shows how valuable you are because you are independent and are not a yes-man, but respectful of the decision and a team player.
Sometimes a decision that you disagree with will be made when the decision makers did not have the full benefit of your opinion. You should then evaluate whether to raise the issue on the basis of the benefit to the company or tribe. If it is a small mistake in your opinion, it may not be worth reconsidering. If it is a large mistake in your opinion, then of course you must present an argument.
Usually, this is not a problem. In some stressful circumstances and with some personality types this can lead to things being taken personally. For instance, some very good programmers lack the confidence needed to challenge a decision even when they have good reason to believe it is wrong. In the worst of circumstances the decision maker is insecure and takes it as a personal challenge to their authority. It is best to remember that in such circumstances people react with the reptilian part of their brains. You should present your argument in private, and try to show how new knowledge changes the basis on which the decision was made.
Whether the decision is reversed or not, you must remember that you will never be able to say ‘I told you so!’ since the alternate decision was fully explored.
How to Tradeoff Quality Against Development Time
Remember that a good design will be resilient against poor code implementations. If good interfaces and abstractions exist throughout the code, then the eventual rewrites will be far more painless. If it is hard to write clear code that is hard to fix, consider what is wrong with the core design that is causing this.
How to Decide if Software is Too Immature
Is it vapour? (Promises are very immature).
Is there an accessible body of lore about the software?
Are you the first user?
Is there a strong incentive for continuation?
Has it had a maintenance effort?
Will it survive defection of the current maintainers?
Is there a seasoned alternative at least half as good?
Is it known to your tribe or company?
Is it desirable to your tribe or company?
Can you hire people to work on it even if it is bad?
How to Make a Buy vs. Build Decision
How well do your needs match those for which it was designed?
What portion of what you buy will you need?
What is the cost of evaluating the integration?
What is the cost of integration?
Will buying increase or decrease long term maintenance costs?
Will building it put you in a business position you don't want to be in?
but do not invest in a solution bigger than your own business without conscious thought.
How to Grow Professionally
Assume responsibility in excess of your authority. Play the role that you desire. Express appreciation for people's contribution to the success of the larger organization, as well as things as that help you personally.
If you want to become a team leader, instigate the formation of consensus. If you want to become a manager, take responsibility for the schedule. You can usually do this comfortably while working with a leader or a manager, since this frees them up to take greater responsibility. If that is too much to try, do it a little at a time.
Evaluate yourself. If you want to become a better programmer, ask someone you admire how you can become like them. You can also ask your boss, who will know less but have a greater impact on your career.
Plan ways to learn new skills, both the trivial technical kind, like learning a new software system, and the hard social kind, like writing well, by integrating them into your work.
How to Manage Software System Dependence
How will you fix bugs in the component?
Does the component restrict you to particular hardware or software systems?
What will you do if the component fails completely?
It is always best to encapsulate the component in some way so that it is isolated and so that it can be swapped out. If the component proves to be completely unworkable, you may be able to get a different one, but you may have to write your own. Encapsulation is not portability, but it makes porting easier, which is almost as good.
Having the source code for a component decreases the risk by a factor of four. With source code, you can evaluate it easier, debug it easier, find workarounds easier, and make fixes easier. If you make fixes, you should give them to the owner of the component and get the fixes incorporated into an official release; otherwise you will uncomfortably have to maintain an unofficial version.+
How to Know When to Apply Fancy Computer Science
Is it well encapsulated so that the risk to other systems is low and the overall increase in complexity and maintenance cost is low?
Is the benefit startling (for example, a factor of two in a mature system or a factor of ten in a new system)?
Will you be able to test and evaluate it effectively?
If a well-isolated algorithm that uses a slightly fancy algorithm can decrease hardware cost or increase performance by a factor of two across an entire system, then it would be criminal not to consider it. One of the keys to arguing for such an approach is to show that the risk is really quite low, since the proposed technology has probably been well studied, the only issue is the risk of integration. Here a programmer's experience and judgement can truly synergize with the fancy technology to make integration easy.
How to Talk to Non-Engineers
You should assume that you will miscommunicate and watch carefully to find this miscommunication. Try to get them to summarize or paraphrase what you are saying to make sure they understand. If you have the opportunity to meet with them often, spend a little bit of time asking if you are communicating effectively, and how you can do it better. If there is a problem in communication, seek to alter your own practices before becoming frustrated with theirs.
How to Utilize Embedded Languages
The real question to ask oneself before embedding a language is: Does this work with or against the culture of my audience? If you intended audience is exclusively non-programmers, how will it help? If your intended audience is exclusively programmers, would they prefer an applications programmers interface (API)? And what language will it be? Programmers don't want to learn a new language that is narrowly used; but if it meshes with their culture they will not have to spend much time learning it. It is a joy to create a new language. But we should not let that blind us to the needs of the user. Unless you have some truly original needs and ideas, why not use an existing language so that you can leverage the familiarity users already have with it?+
- Have passion for what you are doing
- Be a "problem solver"
- Learn the fundamental basics of your programming language and frameworks
- Be a mentor and have a mentor
- Keep yourself up-to-date
- Leave your comfort zone
- Fight for your opinion
- Be social
- Focus on soft skills as well
http://markm208.blogspot.com/2013/08/the-biggest-challenge-to-being-software.html
http://www.vaikan.com/the-biggest-challenge-to-being-a-software-developer
The main point that I am trying to make is that our peers and colleagues have to become our teachers, and our companies must support developers' teaching, learning, and experimentation. Teaching and learning should be an in-house activity. Luckily, all of this teaching and learning can easily be quantified and used as a performance measurement. If you are not actively learning from others and not making the people around you better, then you are not fully contributing to the team.
- Make learning a part of the culture. In your company, make teaching to, and learning from others a measured performance goal.
- Hire people who are good problem solvers and let them learn what they need to know on the job.
Looking for an expert problem solver. Candidates should come in ready to learn new things and teach others what you have learned over the years.
You don't know <hot new technology>, but you just spent the last several years working on an awesome product? No problem, <hot new technology> isn't that hard. If you were awesome on your last project you will be awesome on our project.https://www.gitbook.com/book/braydie/how-to-be-a-programmer/details
https://github.com/ahangchen/How-to-Be-A-Programmer-CN
How to Stay Motivated
- Use the best language for the job.
- Look for opportunities to apply new techniques, languages, and technologies.
- Try to either learn or teach something, however small, in each project.
Finally, if possible, measure the impact of your work in terms of something that will be personally motivating.
How to be Widely TrustedTo be trusted you must be trustworthy. You must also be visible. If no one knows about you, no trust will be invested in you. With those close to you, such as your teammates, this should not be an issue. You establish trust by being responsive and informative to those outside your department or team. Occasionally someone will abuse this trust, and ask for unreasonable favours. Don't be afraid of this, just explain what you would have to give up doing to perform the favour.+
Don't pretend to know something that you don't. With people that are not teammates, you may have to make a clear distinction between 'not knowing right off the top of my head' and 'not being able to figure it out, ever.'
How to Balance Brevity and Abstraction
Beginning programmers in their enthusiasm often create more abstraction than is really useful. One sign of this is if you create classes that don't really contain any code and don't really do anything except serve to abstract something. The attraction of this is understandable but the value of code brevity must be measured against the value of abstraction. Occasionally, one sees a mistake made by enthusiastic idealists: at the start of the project a lot of classes are defined that seem wonderfully abstract and one may speculate that they will handle every eventuality that may arise. As the project progresses and fatigue sets in, the code itself becomes messy. Function bodies become longer than they should be. The empty classes are a burden to document that is ignored when under pressure. The final result would have been better if the energy spent on abstraction had been spent on keeping things short and simple. This is a form of speculative programming.
How to Learn New Skills
Humans learn by doing. Book-reading and class-taking are useful. But could you have any respect for a programmer who had never written a program? To learn any skill, you have to put yourself in a forgiving position where you can exercise that skill. When learning a new programming language, try to do a small project in it before you have to do a large project. When learning to manage a software project, try to manage a small one first.
A good mentor is no replacement for doing things yourself, but is a lot better than a book. What can you offer a potential mentor in exchange for their knowledge? At a minimum, you should offer to study hard so their time won't be wasted.
Learn to Type
by the time you are an intermediate programmer you will probably spend a lot of time writing natural language to your colleagues and others.
How to Do Integration Testing
Ideally you should organize a project so that there is not a phase at the end where integration must explicitly take place. It is far better to gradually integrate things as they are completed over the course of the project
Communication Languages
UML is a rich formal system for making drawings that describe designs. Its beauty lies in that it is both visual and formal, capable of conveying a great deal of information if both the author and the audience know UML. You need to know about it because designs are sometimes communicated in it.
Heavy Tools
Relational Databases,
Full-text Search Engines,
Math libraries,
OpenGL,
XML parsers, and
Spreadsheets.
How to analyze data
How to Manage Development Time
Make sure your plan includes time for: internal team meetings, demos, documentation, scheduled periodic activities, integration testing, dealing with outsiders, sickness, vacations, maintenance of existing products, and maintenance of the development environment. The project plan can serve as a way to give outsiders or your boss a view into what you or your team is doing. For this reason it should be short and up-to-date.
How to Manage Third-Party Software Risks
It is unwise to be merely sceptical of a software company's promise to release a certain product with a certain feature at a certain date; it is far wiser to ignore it completely and forget you ever heard it. Never let it be written down in any documents used by your company.
How to Communicate the Right Amount
Carefully consider the cost of a meeting; it costs its duration multiplied by the number of participants. Meetings are sometimes necessary, but smaller is usually better. The quality of communication in small meetings is better, and less time overall is wasted. If any one person is bored at a meeting take this as a sign that the meeting should be smaller.
Everything possible should be done to encourage informal communication. More useful work is done during lunches with colleagues than during any other time.
How to Disagree Honestly and Get Away with It
Disagreement is a great opportunity to make a good decision, but it should be handled delicately. Hopefully you feel that you have expressed your thoughts adequately and been heard before the decision is made. In that case there is nothing more to say, and you should decide whether you will stand behind the decision even though you disagree with it. If you can support this decision even though you disagree, say so. This shows how valuable you are because you are independent and are not a yes-man, but respectful of the decision and a team player.
Sometimes a decision that you disagree with will be made when the decision makers did not have the full benefit of your opinion. You should then evaluate whether to raise the issue on the basis of the benefit to the company or tribe. If it is a small mistake in your opinion, it may not be worth reconsidering. If it is a large mistake in your opinion, then of course you must present an argument.
Usually, this is not a problem. In some stressful circumstances and with some personality types this can lead to things being taken personally. For instance, some very good programmers lack the confidence needed to challenge a decision even when they have good reason to believe it is wrong. In the worst of circumstances the decision maker is insecure and takes it as a personal challenge to their authority. It is best to remember that in such circumstances people react with the reptilian part of their brains. You should present your argument in private, and try to show how new knowledge changes the basis on which the decision was made.
Whether the decision is reversed or not, you must remember that you will never be able to say ‘I told you so!’ since the alternate decision was fully explored.
How to Tradeoff Quality Against Development Time
Remember that a good design will be resilient against poor code implementations. If good interfaces and abstractions exist throughout the code, then the eventual rewrites will be far more painless. If it is hard to write clear code that is hard to fix, consider what is wrong with the core design that is causing this.
How to Decide if Software is Too Immature
Is it vapour? (Promises are very immature).
Is there an accessible body of lore about the software?
Are you the first user?
Is there a strong incentive for continuation?
Has it had a maintenance effort?
Will it survive defection of the current maintainers?
Is there a seasoned alternative at least half as good?
Is it known to your tribe or company?
Is it desirable to your tribe or company?
Can you hire people to work on it even if it is bad?
How to Make a Buy vs. Build Decision
How well do your needs match those for which it was designed?
What portion of what you buy will you need?
What is the cost of evaluating the integration?
What is the cost of integration?
Will buying increase or decrease long term maintenance costs?
Will building it put you in a business position you don't want to be in?
but do not invest in a solution bigger than your own business without conscious thought.
How to Grow Professionally
Assume responsibility in excess of your authority. Play the role that you desire. Express appreciation for people's contribution to the success of the larger organization, as well as things as that help you personally.
If you want to become a team leader, instigate the formation of consensus. If you want to become a manager, take responsibility for the schedule. You can usually do this comfortably while working with a leader or a manager, since this frees them up to take greater responsibility. If that is too much to try, do it a little at a time.
Evaluate yourself. If you want to become a better programmer, ask someone you admire how you can become like them. You can also ask your boss, who will know less but have a greater impact on your career.
Plan ways to learn new skills, both the trivial technical kind, like learning a new software system, and the hard social kind, like writing well, by integrating them into your work.
How to Manage Software System Dependence
How will you fix bugs in the component?
Does the component restrict you to particular hardware or software systems?
What will you do if the component fails completely?
It is always best to encapsulate the component in some way so that it is isolated and so that it can be swapped out. If the component proves to be completely unworkable, you may be able to get a different one, but you may have to write your own. Encapsulation is not portability, but it makes porting easier, which is almost as good.
Having the source code for a component decreases the risk by a factor of four. With source code, you can evaluate it easier, debug it easier, find workarounds easier, and make fixes easier. If you make fixes, you should give them to the owner of the component and get the fixes incorporated into an official release; otherwise you will uncomfortably have to maintain an unofficial version.+
How to Know When to Apply Fancy Computer Science
Is it well encapsulated so that the risk to other systems is low and the overall increase in complexity and maintenance cost is low?
Is the benefit startling (for example, a factor of two in a mature system or a factor of ten in a new system)?
Will you be able to test and evaluate it effectively?
If a well-isolated algorithm that uses a slightly fancy algorithm can decrease hardware cost or increase performance by a factor of two across an entire system, then it would be criminal not to consider it. One of the keys to arguing for such an approach is to show that the risk is really quite low, since the proposed technology has probably been well studied, the only issue is the risk of integration. Here a programmer's experience and judgement can truly synergize with the fancy technology to make integration easy.
How to Talk to Non-Engineers
You should assume that you will miscommunicate and watch carefully to find this miscommunication. Try to get them to summarize or paraphrase what you are saying to make sure they understand. If you have the opportunity to meet with them often, spend a little bit of time asking if you are communicating effectively, and how you can do it better. If there is a problem in communication, seek to alter your own practices before becoming frustrated with theirs.
How to Utilize Embedded Languages
The real question to ask oneself before embedding a language is: Does this work with or against the culture of my audience? If you intended audience is exclusively non-programmers, how will it help? If your intended audience is exclusively programmers, would they prefer an applications programmers interface (API)? And what language will it be? Programmers don't want to learn a new language that is narrowly used; but if it meshes with their culture they will not have to spend much time learning it. It is a joy to create a new language. But we should not let that blind us to the needs of the user. Unless you have some truly original needs and ideas, why not use an existing language so that you can leverage the familiarity users already have with it?+
https://dzone.com/articles/5-skills-a-software-developer-should-have-to-be-a
http://www.codeceo.com/article/5-skills-be-smart-developer.html
一个程序员的顿悟:理想的程序员只比你多了6个一点点
http://www.codeceo.com/article/5-skills-be-smart-developer.html
- Ability to be focused and goal oriented: It starts with introspection and planning for your career. You can think of an approach as you take for your code:
- Keep it modular - Personal, professional - both aspects need to be well-thought of and your TODOs (like in code), needs to be taken care of on regular basis.
- Keep it clean & comply with rules - As we follow coding compliance rules, some rules for yourself and keep your objectives very clean and measurable
- Keep it loosely coupled - Like your code, don't couple many objectives together - keep it simple and flexible so that they can vary independently.
- Keep it measurable - Like your code performance SLA, keep your objectives SLA based and measure it every fortnightly/monthly/quarterly/yearly as frequent as possible.
- Ability to market and sell your idea
- This is the most ignored aspect and the most difficult part. As you grow, your ideas need to be told and to be executed and in order to that, first thing is you need to sell your ideas to people.
- Storytelling is a well-known technique to convey your thoughts in a way anybody can understand.
- SapientNitro has redefined Storytelling to Storyscaping, which is a new way to tell powerful stories with connected experiences (used in marketing). This can be applied in usual storytelling as well.
- Ability to increase your productivity
- By reading blogs from leading tech companies (Netflix Tech Blog,Oracle OTN, AWS Blogs, IBM Emerging Tech Blog, DZone, TechGig, TechCrunch),
- Through developer websites of tech companies (such as Facebook for Developers, Twitter Developers, Amazon AWS)
- Asking questions on question-answer websites (such as Quora, Stackoverflow)
- Learning through MOOC sites (Coursera, Udemy etc.) or Youtube channels
- Finally, by following key technology people/companies on social media channels (Twitter, LinkedIn, etc.).
- Ability to keep a healthy mind, body, and soul
- The most important one as it keeps up the spirit and make sure we have fresh & healthy mind to counter any challenge and come up with innovative ways to do things.
理想的程序员与平庸的程序员只有一墙之隔。两者的差距只有 6个一点点,而人与人的差距,正是在这日积月累的一点点中,被永远拉开了。有意思的是,我发现这 6个一点点都和意识有关,也就是程序员和其他一切新兴产业的工种一样,只需要意识加上时间的锤炼,人人皆可达到理想的阶段。理想的程序员必然也是一个优秀的problem-solver。
第 1 个一点点:专注眼下
见过太多心猿意马的程序员,我不得不把「专注眼下」作为天字第一条。他们往往有各式各样的小梦想,比如做个小茶农、做个小鹅贩、做产品、做销售、做投资,却被程序员的高薪或是没有转行的魄力「耽误」了,而因为不专注,他们不在意做好自己的本分,不在意锤炼自己的技能,不在意学习新兴的技术。不可否认,这世界上存在着伟大的产品(像乔老爷)、伟大的销售(像埃里森)、伟大的投资客(像彼得菲),而他们毫无例外都是程序员出身。可你听说过巴菲特评价盖茨的话么,比尔盖茨如果转行去卖狗,那他一定是全世界最大的狗贩。我坚信除了少数的天才外,冥冥众生均可以在多个领域取得成功,只要保持足够的专注。而哪怕你下一年就想卖狗去,程序员的经验仍然能训练你强大的逻辑、谨慎和耐心,放在哪个行业都是相当可观的竞争力。
第 2 个一点点:思考力与推动力
我认为处理bug、崩溃、调优、入侵等突发事件比编程本身更能体现平庸程序员与理想程序员的差距。当面对一个未知的问题时,如何定位复杂条件下的核心问题、如何抽丝剥茧地分析问题的潜在原因、如何排除干扰还原一个最小的可验证场景、如何抓住关键数据验证自己的猜测与实验,都是体现程序员思考力的最好场景。是的,在衡量理想程序员的标准上,思考力比经验更加重要。
有时候小伙伴跑过来,问我「提交了一个任务被卡住了,怎么办」的时候,我总觉得他可以做得更好。比如,可以检查试验别的任务,以排除代码自身的原因;可以通过 Web UI 检查异常(如果没有账号,可以让我提供);可以排查主机日志或删除缓存,再不济,总应该提供任务 ID和控制台日志给我。理想的程序员永远不会等事情前进,他们会用尽一切方法让事情前进。
第 3 个一点点:Never Say No
记得从前厂离职之前,找老板谈话,他说我最大的优点就是从来不和他说这个做不到。后来我发现在很多团队里,都存在一种技术和产品的对立,程序员往往以「技术上无法实现」来挡产品的需求,而产品也往往以「Facebook可以为什么我们做不到」来奚落程序员。这两句话应该属于禁语,从根本上都不利于程序猿和产品狗的相亲相爱。
一句「技术上无法实现」是容易出口,可有多少人在说出这句话的时候,心里是100%肯定的?如果不肯定,为什么不能回去谷歌一下再回答?原本我以为程序员是充满想象力,在因为有想象力,才能诞生那么多改变我们生活的软件和互联网产品。见识多了,才了解大部分程序员已经在与bug的对抗中变得保守而不愿担当风险,与此同时许多团队也不愿意宽容失败。于是「Say No」变成一种习惯性的抵触,还记得曾国藩为什么解散湘军么?他说那支军队已「暮气渐深」,不能打仗了。要做理想的程序员,就不能给自己滋生暮气的机会,如果面对不合理的需求,可以把时间成本摆出来,把曲线救国方案亮出来,简单粗暴「Say No」是不可取的。
第 4 个一点点:投资未来
程序员是一个非常残忍的职业。你所学所用的语言、框架、模式,很可能在数年内就成昨日黄花了;你现在嘲笑的另一群程序员,可能马上就能转身来嘲笑你了。所以理想的程序员除了做好自己的本分,还要花费时间来投资未来。什么是「投资」?投资就是你现在投入的时间,在未来会以更多的时间或者金钱(看看早几年学习iOS的程序员现在的薪酬!)回报你。举我自己的领域 — 数据挖掘为例,08年左右Hadoop开始兴起,一时「大数据」概念火热,Hadoop工程师万金难求,各互联网公司纷纷把数据统计、数据分析和数据挖掘的业务切换到分布式平台上。这几年眼看 Hadoop 还在不断迭代,Spark又异军突起,一举刷新了 Hadoop 保持的排序记录,以内存存储中间数据带来的性能优势和丰富的数据结构让人爱个不停,各种奇异的小 bug和陡峭的学习曲线又让人打退堂鼓。那么,明眼人都知道 Spark 是未来的趋势(内存会越来越便宜),在主业务放在 Hadoop的条件下,就可以适当把一些小模块切换到 Spark 上,同时留意 Spark 社区的发展。很快从 Spark 获得的性能收益就能把之前投入的学习时间挣回来。
第 5 个一点点:善用工具
善用工具可以分为 4 个层面:
搜索引擎
不相信重复
代码片段
自动化
搜索引擎
不相信重复
代码片段
自动化
我刚入行那会,一个计算机专业却当了公务员的朋友问我,你一点都没学过编程,平时怎么写代码?我说,谷歌,于是遭到无情的耻笑,以至于我在哪里的账号都叫2shou,告诫自己是一个无耻的二手程序员。这是一个笑话,但如果现在问我,我还是要回答谷歌。程序员的成长就像膨胀的圆饼,外面是无边无际的大海,圆饼越大,与大海接触的面也越大,懂的越多,不懂的越多,而计算机科学又是一门更新换代异常迅速的学科,同时也是知识互联网化最好的学科,很难利用传统的科班式有教有学的方法,相反通过搜索引擎则很容易获取到最新的知识。
不相信重复,大师的话叫DRY原则(Dont repeat yourself),代码写多了,会有人为的直觉判断好的和烂的代码,我的标准是简洁和规范,简洁并不是美感上的标准,重复越少,给自己出错的机会也越少,后期维护的成本也越少。
如果你不幸丢了三周前的代码,也许你能凭着过人的记忆力把脑子里残余的片段复写出来,但如果丢的是三个月前的代码,恐怕就没有那么好的运气了。理想的程序员会着力找寻有效的资料保存方式,把工作里灵光闪现写下的代码、脚本、配置、 经验等短的片段保存起来,以便任何时候都能复查。
理想的程序员必须懒惰。对他们来说,重复的步骤和重复的代码一样丑陋,如果意识到一项工作有可能长期要重复,那么自动化的时间总是越早越好。
第 6 个一点点:管理时间
之所以管理时间会对程序员这个行当特别重要,是因为在完成任务时你必须像荒野里的狼一样,「独行」。没有外界约束的情况下还能稳定控制自己,保证能高效率地工作和学习,那么日积月累你肯定会变得比一般人厉害。
程序员干的是高强度的脑力活,一般每天集中4-5 个小时应对本职工作就足够了,但工作之外,一定要安排时间用于学习。除了学习,留点时间放空自己也是必要的,利用泡茶或者喝咖啡的间隙,把弥足珍贵的时间留给自己,往前想往后想,事半功倍。
说了这么多,想必有人会问,费劲心思成为一个理想的程序员,又有什么用处?会有高薪吗?不。能升职吗?也不见得。迎娶白富美呢?不如去卖狗。
作为一个程序员该如何去学习
话说“活到老,学到老”,其实不只是程序员这个职业是这样,只要你想进步,想做得更好,学习是你最好的途径。然后我们很多时候是学而不得其法,半途而废的人自古都不少;也有的时候,你会觉得很累,因为你经常遗忘,不会知识迁移,抑或是你把自己局限在了一个小笼子里,久了自然觉得乏味。因此,学习并不是靠蛮力的,不是你投入了多少时间就得有多少产出,学习是需要方法的。虽然每个人的情况都未必一样,但有一些意识,你应该去想想。
1.知识框架化
Invest regularly in your knowledge portfolio.框架(framework)是一个基本概念上的结构,用于去解决或者处理复杂的问题。如果你的知识是零散的,那么他们都是脆弱的,是极其容易遗忘。知识的框架化,要求你把自己所学的知识分类整理,梳理成框架,相互之间的联系要清晰。如此,不仅灵活运用所学成为可能,更有助于你对知识的理解,当然也就更容易知识迁移,学习新知识也就更简单点。
2.比较思考
比较思考是你认识一门学科或者一个问题或者一个知识点时的有效方式。通过比较,才知优劣与长短,才能更加清楚联系与区别。自然也是一个理解的过程,记忆也会更牢固。
3.善于积累
小学时就学过“拣了芝麻丢了西瓜”的故事。其实这个学习的一个大忌,我们尽可能做到的是“拣了芝麻西瓜也不丢”的境界。学习是一个积累的过程,如果只是“走马观花”,啥都没有记下来,那除了浪费时间还有什么益处呢。在学习上永远不要怕“知道得太多”,只有你知道得越多,你才有可能解决更多的问题。
4.书宜杂读,业宜精钻
5.探索事物的本质
不管你从事的是哪一行,都应该清醒的知道“自己在干嘛?自己做的事有什么价值?自己处在社会分工链的哪一层?所处行业的发展前景怎么样?”。如果这些问题你有些答不出来,说明你对现在的处境并不清楚,自然也很难在行业创业上崭露头角。