https://medium.com/@hilsoftinc/seven-habits-of-a-great-programmer-36682b736c83
http://netsmell.com/post/seven-habits-of-a-great-programmer.html
1. Good Time Management
http://www.javaworld.com/article/2597522/learn-java/what-i-wish-id-known-starting-out-as-a-programmer.html
http://netsmell.com/post/starting-out-as-a-programmer.html
8. For Zod's sake, learn to communicate. If you are unable to write properly in English (or the appropriate language for your community), take a writing course. If you are unable to give a talk, get over your stage fright, take a course, practice in front of a mirror, and/or attend some meetups and learn. This is probably as important as writing code.
5. Think in terms of a career, not a series of jobs. When I started I job-hopped for relatively dumb reasons: I didn't like that I was put in a cubicle, I could get an extra $5 per hour, and so on. This would come back to haunt me during the dot-bomb. At the same time, I usually failed to pick jobs for the best reason: What will help me progress in my career? Sometimes that means taking a job for less money but more responsibility or better opportunities. I probably still have put in my time at big companies -- then quit working for them sooner. It's relatively hard to make an impact from the inside of IT in a big company and opportunities are frequently limited.
6.你的努力和勤奋一定要让别人看的见
如果你的老板或上司看不到你的努力和勤奋，那么他们就不会给你更多的机遇。所以不要傻着自己偷偷的努力工作。
https://medium.com/@AlexDevero/7-soft-skills-every-freelance-web-designer-must-have-pt3-2d48dd75104d#.vwocphddo
http://tech2ipo.com/10029082
http://www.codeproject.com/Articles/1005428/Soft-Skills-are-so-important-to-Software-Engineers
http://www.chinarobots.cn/XingYeDongTai/376.htmlTip #1: Learn how to learn
Life long learning is huge.
Tip #2: Commit to a reading schedule
Life is too chaotic right now. I am not sure if I can commit to a reading schedule at this time. Maybe in the future. I learn a little better by taking courses and doing tutorials vs reading books.
Tip #3: Improve your health
Sleep and working out are important for optimal brain functionality. I need to stop using having young children as an excuse for not exercising as much as I should.
Tip #4: Practice interviewing
I agree with this one in a huge way. Interviewing is a skill and it is often rusty when you need it most. I also think doing the coding challenges like the ones you often have to do in job interviews is something to be practiced regularly.
Tip #5: Create a blog
You are reading my blog. So I have one but no one visits it because I don't publicize it or publish anywhere else. I am still working up the confidence in regards to does my voice matter at all in the software engineering world. A friend of my Daniele Rossi is coaching me how to make it better.
Tip #6: Find a mentor
I need to network more before I can even consider trying to find someone to act as a mentor. My career goals as a software engineer don't align with my peers so this can be difficult at times to even find people on a similar page as me.
Tip #7: Launch a side project
I never know what to create when ever this comes up. The most I tend to do is build platforms to play with new tech.
Tip #8: Wake up an hour earlier each morning
Good advice. I am an early bird by nature and am very productive in the morning. Once my youngest is a little older I think this may be possible.
Tip #9: Start tracking your time
This seems like a lot of work. I am not ready to make managing my career a job but maybe one day I will.
Tip #10: Watch less (or no) TV
This is a tough one for me. My TV watching is already pretty minimal. The time I do spend doing it often spent sitting with my wife after the kids are asleep. I suppose since she is a software engineer also we could cut down that some and have some quality time in other ways but we are often drained by the end of the day.
Tip #11: Work on your Soft Skills
Aren't all these tips primarily about soft skills?
Tip #12: Join the community
Easy for single people but hard for parents with young children... but this is something I should really just make time for. Maybe start with an online community.
Tip #13: Give a talk
I used to be in Toastmasters so public speaking isn't a problem for me despite the fact that I stutter. Joining a community, being at a company where lightning talks are done, and just making the time to put myself out there is where I should start. However the priority of this tip is a little lower for me because others are a prerequisite.
Tip #14: Be a mentor
I like mentoring. The challenge for me is finding someone to mentor. Well that and finding the time. See Tip #6.
Tip #15: Plan your year
Building your brand and skill set is something the can and should be planned. If you don't set goals how will you achieve them?
Tip #16: Learn a new technology
This is our life. This is our career. As a software engineer if you are not learning a new skill or mastering one you already are familiar with you are falling behind because things change daily.
Tip #17: Get to know your IDE better
This is a sneaky one but one that can really affect productivity. Knowing the short cuts and features of your IDE can really speed up development and decrease time spent debugging.
Tip #18: Have your resume professionally written
Wow! No thank you. I am not going to spend over $500 on having someone write my resume. I am sure they will do a better job than I can but I have had no issues with recruiters not beating down my door. This seems like a waste to me. I will stick with just running it by colleagues who see resumes for software engineer candidates and ask I stack up and how I could improve it.
Tip #19: Make connections now, not later
This is basically a repeat but a repeat for a good reason. Networking can be huge. I am not very good at it but that is no excuse for not doing it
Tip #20: Utilize a productivity technique
Productivity technique? Runaway!!!!! Just the very idea of this type of thing turns me off. Maybe I am not driven enough for it or don't have inspiring goals in mind.
Tip #21: Develop a routine
Good habits are important for sustainability. Not only that but if you do fall off track due to something unexpected that comes up or you just plain got lazy having a routine to revive and go back to will speed your recovery.
Tip #22: Upgrade your equipment
I don't really code too much for myself on my own gear. That is where I need to start vs getting a screaming machine.
Tip #23: Create a personal brand
Think of your career has a business. What is your brand? What makes you valuable to employers?
Tip #24: Specialize
I have been a full stack Java engineer my whole career. I have no specialty of particular talent other than I have always been in a position where I need to wear many hats. The desire to specialize is there but the opportunity to is what has held me back. Maybe focusing on personal learning and projects could help more here. Honestly I think I would like to specialize in something that isn't even a recognized strength right now. Is that strange?
http://www.funkysi1701.com/2015/07/23/7-warning-signs-that-youre-a-bad-programmer/
http://katemats.com/one-technique-to-being-awesome-you-arent-using-enough-questions/
http://simpleprogrammer.com/2015/05/18/7-mistakes-youre-making-in-your-programming-career/
Tight deadlines and rapid changes require mental stability, focus and self-motivation.
“Soft Skills: The Software Developer’s Manual”
https://medium.freecodecamp.com/how-to-level-up-as-a-developer-87344584777c
Level 1: REDUCE UNNECESSARY DISTRACTIONS
PUSH BACK ON MEETINGS
BE PREPARED TO DO SMALL TASKS
Real noise cancelling headphones cancel out background noise and muffle conversations in the immediate vicinity. After my interview with Michael Novati I bought the headphones he recommended and I honestly could not see my development process without them. It becomes so evidently clear how much background noise exists in offices once you have something to compare it to.
WORK WHEN PEOPLE CAN’T BOTHER YOU
REDUCE NOISY EMAILS/NOTIFICATIONS
DON’T LOSE STATE
Level 2: WRITE “BETTER” DIFFS
Good code can mean many things. It can be functional, easy to review, sustainable, etc.
Every engineer I interviewed stressed hard how splitting your code changes into logical modules made it easier for other people to understand and accept quickly. By reducing the cognitive load of the diffs they sent out, reviewers were more confident in accepting changes. Also, by reducing the size of the diffs, the changes were less intimidating for reviewers to look at, so the throughput was faster.
“Small, or at least easy to review, diffs. Not only are they easier and faster to review, they make me write better code because I think through what I’m doing one logical piece at a time, and I waste very little time debugging as a result. Also, expertise with stacked diffs to make the small diffs manageable”
“I use stacked diffs extensively. Beyond letting me stay unblocked while I’m waiting for code reviews, thinking about ways to split up code into smaller diffs often makes me think about the big picture of what I’m working on, and even simplify the architecture.”
Whether engineers used stacked diffs or worked on multiple diffs in parallel appeared to have little effect on their outgoing productivity, indicating that both methodologies allow engineers to be incredibly productive.
UNIT TESTING
“For trickier diffs, I will add a small number of appropriate reviewers, share the diff in appropriate groups. I’ll usually ping a diff once a day regardless, if it doesn’t get any action. If there is no action for a few days, I’ll ask people what they find intimidating about the diff and make changes to the structure. Finally I always communicate as much as I can in the title. I always start with “[product/tag]” — so people know vaguely what the diff is about, and if I expect a quick accept I’ll put something like “[product-ASAP]” or “[product-PUSHBLOCKER]””
If the diff will be reviewed by someone who doesn’t interact with you on a daily basis, you may want to include more context in the description and title than you normally would if you are just getting a review from a teammate. You can also comment on the sections of your diff that you really want people to double check you on, in case the logic gets a bit complicated.
Setting expectations early through design meetings may also ease the process of writing the code, building good APIs and structure in order to integrate systems can be a huge pain reliever further down the development line.
Don’t be afraid to ping reviewers on your diff. If they really don’t want to review your diff, they can resign, or suggest someone else. Diffs that stick around in queues forever are just asking for merge conflicts in the future.
Level 3: BEING A TEAM PLAYER
REVIEW OTHER PEOPLE’S CODE
BUILD TRUST WITH YOUR REVIEWERS/TEAMMATES
“I have a core group of engineers with whom I’ve built up a relative sense of trust, and we generally make an effort to review each other’s code quickly”
BE TRANSPARENT ABOUT WHAT YOU’RE WORKING ON
“Use RFC (Request for Comment) diffs when doing greenfield development. The churn of getting feedback on headers/proposed APIs is well worth the time saved compared to changing direction later.”
If people don’t know what you’re working on, the amount of information they’ll need process when reviewing a diff will be far more confusing. By keeping reviewers/teammates in the loop early, they can give feedback before large swathes of work are done, removing roadblocks down the line.
GIVE GOOD FEEDBACK
understanding the diff from a high level first. After the basic structure of the diff is understood, go into the code style and logical checking.
REQUEST CHANGES
“Use Request Changes frequently — the worst that can happen is they re-request review (encourage the author to, if they think your Request Changes was in error)”
encouraging better coding practices and validation are likely to pay off as engineers learn from their mistakes and improve.
ADMIT WHAT YOU DON’T KNOW
“If I don’t know much about a part of the codebase I won’t BS that part and I’ll admit it straight up.” — Michael Novati
You don’t really add much to a conversation by pretending to know something you don’t. Be up-front about your knowledge, and encourage people to seek engineers more knowledgeable about certain systems.
Level 4: ORGANIZE & HUSTLE
TODOS
FAIL FAST, ITERATE
“I try to turn around code fast when possible even if I’m not sure it’s optimal (to get comments) and prefer failing fast trying ideas over thinking through 100%"
Trying to create the perfect product off the bat can be intimidating and cause us to overthink problems. Getting into a habit of jumping into code without knowing exactly how it will turn out can allow us to iterate much faster and see results.
PARTING THOUGHTS
“Treat other people the way you want to be treated doesn’t get you far past kindergarten. You need to be the kind of engineer other people want to work with, and most of that is learned through feedback. Ask early and often, people who feel heard are people who feel valued”
http://blog.teamtreehouse.com/what-makes-a-great-programmer
People First
Appetite for Learning
Amazing programmers are ridiculously hungry for knowledge. They’re always telling you about something new or interesting. They tend to read a ton (whether online or offline) and they tend to love to try things out and learn from experiences as well. They’re not afraid of trying out new languages or new platforms.
Skillful at Problem Pattern Matching
Once you’ve been writing software for a while you start to see problems arise that look awfully similar to other problems you’ve dealt with. Being able to recognize those and transform past solutions to work in your current situation is a really valuable skill. Being able to improve on the solution each time is even better.
Note, though, that this doesn’t mean you blindly say that because a past solution could work it must work. That’s where skillfully applying problems pattern matching comes into play. You’ve got to have an eye for knowing when it’s right to apply a past solution and when it’s not.
A Little Bit Insane
Persistent
http://aestheticio.com/become-better-programmer-learning-understand-code/
http://www.codeceo.com/article/become-a-better-programmer-by-learning-code.html
Learn From the Best
Whatever You Do, You Might as Well Do It the Best You Can
Look for Patterns
Look for patterns in coding, solving problems, working with others, etc. The more patterns you can recognize and handle, the more complex problems you’ll be able to solve in the less amount of time
Maximize for Learning
Practice
They contribute to open-source projects, do part-time freelancing, work on startup ideas, read books, answer questions on stack-overflow, write blog posts, etc. Always look for opportunities to improve your skills and get more experience.
http://joshuakemp.blogspot.com/2014/02/how-to-know-if-you-are-cut-out-to-be.html
1) Attention to detail, especially the smallest of details.
2) Learning ALL the time.
3) Handle pressure, stress, and deadlines.
4) Organized
5) Extremely inquisitive
6) Self taught
7) People skills
http://kukuruku.co/hub/programming/do-not-learn-frameworks-learn-the-architecture
Do Not Learn Frameworks. Learn the Architecture.
It seems that a framework is something big and difficult to reproduce. But it’s just a set of standard patterns. For instance, the observer pattern is used in Backbone models, as well as in Angular and Knockout data binding
Studying frameworks, you have to relearn, moving to new solutions that appear all the time, and a part of your experience will be erased. But when you learn principles — they stay.
Patterns can be combined depending on the task, but they do not change.
http://juristr.com/blog/2012/03/sharpening-tools/
#1 Practise the basics
#2 Learn from other people - Beside stalking experts, following people on Twitter and reading blogs etc, he also mentions to read code from others. Just go and clone some GitHup repo and read through the code.
#3 Understand trends - Build a network of people you listen to. I'm doing that through RSS and Twitter preferably, an extremely powerful tools for keeping up with technology. Try out new things when there is the possibility to. You have to know just enough to be able to understand when you need a given technology needs further investigation. Do you know what you don't know?
#4 Share knowledge
#5 Maintain your toolbox - Some tools might be disposable, being no more useful, or technologically deprecated. Use the "clothing" rule to update your tools.
#6 Learn how to learn
http://henrikwarne.com/2012/08/22/top-5-surprises-when-starting-out-as-a-software-developer/
知识的偏见 - 读《暗时间》的思考
『如果你手里有把锤子，所有东西看上去都想钉子』
每种语言的开发者，对其所掌握的语言都会有一种无法抑制的执着。
『用合适的语言取做合适的事情』
TDD
『软件开发没有银弹，方法论同样也适用』
如果你对面向对象还保持着封装，继承，多态，教条的遵循 SOLID 原则，可能仅对 OOP，可能还需要更多的思考。
『OOP 不是万能的』
『Design Pattern 是我们重构代码时的参考，不是我们写代码的准则』
使用合适的语言解决合适的事情。
使用 DSL 处理特定的领域
http://www.lvoyee.com/archives/286.html
http://netsmell.com/post/seven-habits-of-a-great-programmer.html
1. Good Time Management
2. Thorough Understanding on Customer Requirement — a single user story phrase is not enough. A great programmer should have the diligence to understand and decompose it into detailed technical tasks and/or sub tasks for the project to have a close to accurate estimates.
3. Full Algorithm before Coding — use cases, pseudo codes and flow charts are very vital in software development. A great programmer should not be so excited to code right away instead he or she should complete the algorithm first. Coding in effect will only just be an encoding task.
4. Understands and Helps Define Acceptance Criteria — test scripts on a high level are defined by the product owner but a great programmer must be able to write technical test scripts and aware enough of the ramifications of skipping these.
5. Exhausts All Resources — what if you’re dead end? A great programmer is a resourceful person. One who is able to ask its co-member, or team leader. One who is skillful in searching the internet and who has the patience to try and try. Surrendering will never be an option.
6. Diligent in Acknowledging Correspondences — soft skills are a common problem for us programmers as introverts. But a great programmer is aware of this weakness and should be able to have the initiative to improve oneself and execute customer service philosophies of the organization.
7. Proactive — a good programmer is more proactive than reactive. He or she should have the initiative and concern to improve processes and enhance software development productivity tools such as SVN, agile apps or anticipated software bugs.
At the end of the day, whether you are employed or freelance, software development is customer service. A great programmer understands the business value of every tasks for one to feel authentic empathy in delivering any service.
http://netsmell.com/post/starting-out-as-a-programmer.html
8. For Zod's sake, learn to communicate. If you are unable to write properly in English (or the appropriate language for your community), take a writing course. If you are unable to give a talk, get over your stage fright, take a course, practice in front of a mirror, and/or attend some meetups and learn. This is probably as important as writing code.
5. Think in terms of a career, not a series of jobs. When I started I job-hopped for relatively dumb reasons: I didn't like that I was put in a cubicle, I could get an extra $5 per hour, and so on. This would come back to haunt me during the dot-bomb. At the same time, I usually failed to pick jobs for the best reason: What will help me progress in my career? Sometimes that means taking a job for less money but more responsibility or better opportunities. I probably still have put in my time at big companies -- then quit working for them sooner. It's relatively hard to make an impact from the inside of IT in a big company and opportunities are frequently limited.
6.你的努力和勤奋一定要让别人看的见
如果你的老板或上司看不到你的努力和勤奋，那么他们就不会给你更多的机遇。所以不要傻着自己偷偷的努力工作。
https://medium.com/@AlexDevero/7-soft-skills-every-freelance-web-designer-must-have-pt3-2d48dd75104d#.vwocphddo
http://tech2ipo.com/10029082
http://www.codeproject.com/Articles/1005428/Soft-Skills-are-so-important-to-Software-Engineers
http://www.chinarobots.cn/XingYeDongTai/376.htmlTip #1: Learn how to learn
Life long learning is huge.
Tip #2: Commit to a reading schedule
Life is too chaotic right now. I am not sure if I can commit to a reading schedule at this time. Maybe in the future. I learn a little better by taking courses and doing tutorials vs reading books.
Tip #3: Improve your health
Sleep and working out are important for optimal brain functionality. I need to stop using having young children as an excuse for not exercising as much as I should.
Tip #4: Practice interviewing
I agree with this one in a huge way. Interviewing is a skill and it is often rusty when you need it most. I also think doing the coding challenges like the ones you often have to do in job interviews is something to be practiced regularly.
Tip #5: Create a blog
You are reading my blog. So I have one but no one visits it because I don't publicize it or publish anywhere else. I am still working up the confidence in regards to does my voice matter at all in the software engineering world. A friend of my Daniele Rossi is coaching me how to make it better.
Tip #6: Find a mentor
I need to network more before I can even consider trying to find someone to act as a mentor. My career goals as a software engineer don't align with my peers so this can be difficult at times to even find people on a similar page as me.
Tip #7: Launch a side project
I never know what to create when ever this comes up. The most I tend to do is build platforms to play with new tech.
Tip #8: Wake up an hour earlier each morning
Good advice. I am an early bird by nature and am very productive in the morning. Once my youngest is a little older I think this may be possible.
Tip #9: Start tracking your time
This seems like a lot of work. I am not ready to make managing my career a job but maybe one day I will.
Tip #10: Watch less (or no) TV
This is a tough one for me. My TV watching is already pretty minimal. The time I do spend doing it often spent sitting with my wife after the kids are asleep. I suppose since she is a software engineer also we could cut down that some and have some quality time in other ways but we are often drained by the end of the day.
Tip #11: Work on your Soft Skills
Aren't all these tips primarily about soft skills?
Tip #12: Join the community
Easy for single people but hard for parents with young children... but this is something I should really just make time for. Maybe start with an online community.
Tip #13: Give a talk
I used to be in Toastmasters so public speaking isn't a problem for me despite the fact that I stutter. Joining a community, being at a company where lightning talks are done, and just making the time to put myself out there is where I should start. However the priority of this tip is a little lower for me because others are a prerequisite.
Tip #14: Be a mentor
I like mentoring. The challenge for me is finding someone to mentor. Well that and finding the time. See Tip #6.
Tip #15: Plan your year
Building your brand and skill set is something the can and should be planned. If you don't set goals how will you achieve them?
Tip #16: Learn a new technology
This is our life. This is our career. As a software engineer if you are not learning a new skill or mastering one you already are familiar with you are falling behind because things change daily.
Tip #17: Get to know your IDE better
This is a sneaky one but one that can really affect productivity. Knowing the short cuts and features of your IDE can really speed up development and decrease time spent debugging.
Tip #18: Have your resume professionally written
Wow! No thank you. I am not going to spend over $500 on having someone write my resume. I am sure they will do a better job than I can but I have had no issues with recruiters not beating down my door. This seems like a waste to me. I will stick with just running it by colleagues who see resumes for software engineer candidates and ask I stack up and how I could improve it.
Tip #19: Make connections now, not later
This is basically a repeat but a repeat for a good reason. Networking can be huge. I am not very good at it but that is no excuse for not doing it
Tip #20: Utilize a productivity technique
Productivity technique? Runaway!!!!! Just the very idea of this type of thing turns me off. Maybe I am not driven enough for it or don't have inspiring goals in mind.
Tip #21: Develop a routine
Good habits are important for sustainability. Not only that but if you do fall off track due to something unexpected that comes up or you just plain got lazy having a routine to revive and go back to will speed your recovery.
Tip #22: Upgrade your equipment
I don't really code too much for myself on my own gear. That is where I need to start vs getting a screaming machine.
Tip #23: Create a personal brand
Think of your career has a business. What is your brand? What makes you valuable to employers?
Tip #24: Specialize
I have been a full stack Java engineer my whole career. I have no specialty of particular talent other than I have always been in a position where I need to wear many hats. The desire to specialize is there but the opportunity to is what has held me back. Maybe focusing on personal learning and projects could help more here. Honestly I think I would like to specialize in something that isn't even a recognized strength right now. Is that strange?
http://www.funkysi1701.com/2015/07/23/7-warning-signs-that-youre-a-bad-programmer/
1) You fail to plan before you start coding
I am very guilty of this, I love to jump into the code before thinking. But I am slowly starting to see the advantages of sketching a few things out before I write any code.
3) You use bad variable names
4) You repeat your code
5) You struggle to understand your own code
6) You are selfish and don’t share
7) You work on multiple projects
Most everyone is comfortable asking questions when they’re new to a job, but over time many grow uncomfortable with the idea of asking for help when they’re stuck on a problem. Whether it’s pride or something else, reluctance to ask questions can actually make you less effective at your job.
asking questions gets you to a better solution faster and prepares you to handle similar situations on your own in the future.
Think about your questions before you ask them, and make sure you’re as concise as possible while still getting the information you need. Focus on actionable information and specific questions. Some of my favorite ways to ask for help are:
- Can you tell me where you would go to figure out ____________?
- Do you know where there is an example that solves this same problem I could look at? (this particularly works well if you aren’t sure where a certain method or implementation lives in a large code base)
- I have been struggling to figure out ______, could you point me in the direction of how you could solve it?
Working With A Team
Asking questions is a great way to make meetings and discussions productive, as well as avoid situations where everyone walks away without much accomplished.
Imagine sitting across a conference table from one of your peers who has just suggested a crazy new system to start tracking customer data. At first blush, their idea sounds expensive and overly complicated, but instead of saying “That won’t work”, asking them to clarify how this product will improve the current implementation and what the pros, cons and risks of this change.
Asking questions helps you keep an open mind and in turn, helps people around you keep an open mind too. If people feel their ideas were listened to and given credibility through questions, they’re more likely to do the same for their peers, which means more and better solutions to company objectives. Learning to do pause, take a deep breath, listen to the other person and pose my retort as a question was one of the most useful skills I have learned in the last few years.
Making the Most of a Mentor
If you’re successful in your organization but you have aspirations beyond your current role, seeking out a mentor relationship (either with your boss, a colleague within your organization, or an outside contact) is an essential part of taking the next big steps in your career.
Instead, a better question is “how did you handle transitioning into a management role?” or “what is the best way to give feedback to a team member?” These questions ask for specific answers.
a great way to become a good teacher is to ask questions that lead your employees to come up with solutions themselves instead of just giving them the answer. (Which, in turn, means they’ll bring fewer issues to your desk for you to handle in the long run.)
The point of your questions shouldn’t be intimidating your teammate or make you feel smart. Your questions should lead them naturally to working out a solution to their own problem, and your ego should take a back seat during this exercise.
This technique also works well when trying to persuade someone, or help reach consensus. In order for a person to embrace an idea, it needs to be meaningful for them, and each type of person has a different way of assigning meaning. By asking them questions you can lead them to your conclusion, or potentially uncover rationale that could convince you to change your position. Both outcomes are clearly positive for the organization and your relationship.
Keep your tone patient and make sure your questions lead them to answering their own questions through problem solving on their own. Make it a conversation, but resist the urge to tell them your opinion. The more you practice this skill, the easier it will become to ask the right questions to help your employee evaluate their situation and take effective action themselves.
Asking Good Questions
If you think in advance about what kind of information you really need before you start asking questions, you’ll be more effective and get better responses.
When you ask the right questions, you not only get the information you were seeking, but you also develop more effective relationships with your coworkers. Formulating the right question for the right time gives your question clarity and gives your coworkers the most information they need to help you, which makes the whole process easier for everyone. http://simpleprogrammer.com/2015/05/18/7-mistakes-youre-making-in-your-programming-career/
1. Not having a clear goal
If you want to have a successful career in software development, you need to know exactly where you are trying to go.
What I mean by this is, what is the primary thing you want to aim for, right now?
Once you hit this goal, you’ll select a new one, but for right now, what is it that you’d like to accomplish in your programming career?
2. Not investing in non-technical or “soft skills”
how important soft skills are to your programming career, rather than just those technical skills that so many programmers focus on.
We have to constantly deal with people, so people skills are a must.
Tight deadlines and rapid changes require mental stability, focus and self-motivation.
In an ever-changing environment full of so many possible things to work on, we have to learn how to prioritize and how to be as productive as possible.
And let’s not forget health and fitness as well as financial acumen, which if ignored can both lead to ruin.
regardless of what you are doing, soft skills are almost always more important than hard, technical skills—so make sure you learn them.“Soft Skills: The Software Developer’s Manual”
3. Not being part of the community
Being part of something larger than yourself, is a sure way to grow.4. Not specializing
It doesn’t mean that you can’t have a broad base of knowledge as well—I’m a big fan of being a polyglot—but, also pick one area to focus your efforts on and dive deep.
It’s very important, especially early on in your career, to be a specialist of some sort.
Specialists are always in much higher demand, they can get higher salaries and hourly rates, and they are able to build a reputation much faster.
5. Not investing in your personal brand
6. Not working on a side-project
7. Not having a plan for self-education
I personally devote at least 45 minutes a day, while I’m walking on my treadmill, to reading something that will help me further my goal of personal development.
Remember, little things add up over time. Just setting aside even 30 minutes a day, each day, can make a huge difference over a year or two.
Level 1: REDUCE UNNECESSARY DISTRACTIONS
PUSH BACK ON MEETINGS
BE PREPARED TO DO SMALL TASKS
There may be a time where you have just finished a task and now have 5–15 minutes before a meeting, or maybe you just started a test run that will take 1, 5, or 15 minutes. The common reaction is “I can’t get any significant work done in that amount of time”. Which seems logical, many tasks may take from 30 minutes to an hour of focused concentration, but not all tasks. Many of the engineers mentioned that they keep lists of small tasks that they can easily take care of in these slower moments throughout the day. Catching up on emails, diff reviews, responding to internal posts, or even small diffs/refactors can fill in these time slots in order to make you more productive and up to date throughout the day.
GET NOISE CANCELLING HEADPHONES
WORK WHEN PEOPLE CAN’T BOTHER YOU
REDUCE NOISY EMAILS/NOTIFICATIONS
DON’T LOSE STATE
Level 2: WRITE “BETTER” DIFFS
Good code can mean many things. It can be functional, easy to review, sustainable, etc.
Every engineer I interviewed stressed hard how splitting your code changes into logical modules made it easier for other people to understand and accept quickly. By reducing the cognitive load of the diffs they sent out, reviewers were more confident in accepting changes. Also, by reducing the size of the diffs, the changes were less intimidating for reviewers to look at, so the throughput was faster.
“Small, or at least easy to review, diffs. Not only are they easier and faster to review, they make me write better code because I think through what I’m doing one logical piece at a time, and I waste very little time debugging as a result. Also, expertise with stacked diffs to make the small diffs manageable”
“I use stacked diffs extensively. Beyond letting me stay unblocked while I’m waiting for code reviews, thinking about ways to split up code into smaller diffs often makes me think about the big picture of what I’m working on, and even simplify the architecture.”
Whether engineers used stacked diffs or worked on multiple diffs in parallel appeared to have little effect on their outgoing productivity, indicating that both methodologies allow engineers to be incredibly productive.
UNIT TESTING
“For trickier diffs, I will add a small number of appropriate reviewers, share the diff in appropriate groups. I’ll usually ping a diff once a day regardless, if it doesn’t get any action. If there is no action for a few days, I’ll ask people what they find intimidating about the diff and make changes to the structure. Finally I always communicate as much as I can in the title. I always start with “[product/tag]” — so people know vaguely what the diff is about, and if I expect a quick accept I’ll put something like “[product-ASAP]” or “[product-PUSHBLOCKER]””
If the diff will be reviewed by someone who doesn’t interact with you on a daily basis, you may want to include more context in the description and title than you normally would if you are just getting a review from a teammate. You can also comment on the sections of your diff that you really want people to double check you on, in case the logic gets a bit complicated.
Setting expectations early through design meetings may also ease the process of writing the code, building good APIs and structure in order to integrate systems can be a huge pain reliever further down the development line.
Don’t be afraid to ping reviewers on your diff. If they really don’t want to review your diff, they can resign, or suggest someone else. Diffs that stick around in queues forever are just asking for merge conflicts in the future.
Level 3: BEING A TEAM PLAYER
REVIEW OTHER PEOPLE’S CODE
BUILD TRUST WITH YOUR REVIEWERS/TEAMMATES
“I have a core group of engineers with whom I’ve built up a relative sense of trust, and we generally make an effort to review each other’s code quickly”
BE TRANSPARENT ABOUT WHAT YOU’RE WORKING ON
“Use RFC (Request for Comment) diffs when doing greenfield development. The churn of getting feedback on headers/proposed APIs is well worth the time saved compared to changing direction later.”
If people don’t know what you’re working on, the amount of information they’ll need process when reviewing a diff will be far more confusing. By keeping reviewers/teammates in the loop early, they can give feedback before large swathes of work are done, removing roadblocks down the line.
GIVE GOOD FEEDBACK
understanding the diff from a high level first. After the basic structure of the diff is understood, go into the code style and logical checking.
REQUEST CHANGES
“Use Request Changes frequently — the worst that can happen is they re-request review (encourage the author to, if they think your Request Changes was in error)”
encouraging better coding practices and validation are likely to pay off as engineers learn from their mistakes and improve.
ADMIT WHAT YOU DON’T KNOW
“If I don’t know much about a part of the codebase I won’t BS that part and I’ll admit it straight up.” — Michael Novati
You don’t really add much to a conversation by pretending to know something you don’t. Be up-front about your knowledge, and encourage people to seek engineers more knowledgeable about certain systems.
Level 4: ORGANIZE & HUSTLE
TODOS
FAIL FAST, ITERATE
“I try to turn around code fast when possible even if I’m not sure it’s optimal (to get comments) and prefer failing fast trying ideas over thinking through 100%"
Trying to create the perfect product off the bat can be intimidating and cause us to overthink problems. Getting into a habit of jumping into code without knowing exactly how it will turn out can allow us to iterate much faster and see results.
PARTING THOUGHTS
“Treat other people the way you want to be treated doesn’t get you far past kindergarten. You need to be the kind of engineer other people want to work with, and most of that is learned through feedback. Ask early and often, people who feel heard are people who feel valued”
http://blog.teamtreehouse.com/what-makes-a-great-programmer
People First
Appetite for Learning
Amazing programmers are ridiculously hungry for knowledge. They’re always telling you about something new or interesting. They tend to read a ton (whether online or offline) and they tend to love to try things out and learn from experiences as well. They’re not afraid of trying out new languages or new platforms.
Skillful at Problem Pattern Matching
Once you’ve been writing software for a while you start to see problems arise that look awfully similar to other problems you’ve dealt with. Being able to recognize those and transform past solutions to work in your current situation is a really valuable skill. Being able to improve on the solution each time is even better.
Note, though, that this doesn’t mean you blindly say that because a past solution could work it must work. That’s where skillfully applying problems pattern matching comes into play. You’ve got to have an eye for knowing when it’s right to apply a past solution and when it’s not.
A Little Bit Insane
Persistent
http://aestheticio.com/become-better-programmer-learning-understand-code/
http://www.codeceo.com/article/become-a-better-programmer-by-learning-code.html
Once you know that your ability to understand code is dependent on three things:
- Knowledge – The building blocks to solve the problem
- Links – The glue between the building blocks
- Hypotheses – The tools by which you form the links
Learn From the Best
Whatever You Do, You Might as Well Do It the Best You Can
Look for Patterns
Look for patterns in coding, solving problems, working with others, etc. The more patterns you can recognize and handle, the more complex problems you’ll be able to solve in the less amount of time
Maximize for Learning
Practice
They contribute to open-source projects, do part-time freelancing, work on startup ideas, read books, answer questions on stack-overflow, write blog posts, etc. Always look for opportunities to improve your skills and get more experience.
http://joshuakemp.blogspot.com/2014/02/how-to-know-if-you-are-cut-out-to-be.html
1) Attention to detail, especially the smallest of details.
2) Learning ALL the time.
3) Handle pressure, stress, and deadlines.
4) Organized
5) Extremely inquisitive
6) Self taught
7) People skills
http://kukuruku.co/hub/programming/do-not-learn-frameworks-learn-the-architecture
Do Not Learn Frameworks. Learn the Architecture.
It seems that a framework is something big and difficult to reproduce. But it’s just a set of standard patterns. For instance, the observer pattern is used in Backbone models, as well as in Angular and Knockout data binding
Studying frameworks, you have to relearn, moving to new solutions that appear all the time, and a part of your experience will be erased. But when you learn principles — they stay.
Patterns can be combined depending on the task, but they do not change.
http://juristr.com/blog/2012/03/sharpening-tools/
#1 Practise the basics
#2 Learn from other people - Beside stalking experts, following people on Twitter and reading blogs etc, he also mentions to read code from others. Just go and clone some GitHup repo and read through the code.
#3 Understand trends - Build a network of people you listen to. I'm doing that through RSS and Twitter preferably, an extremely powerful tools for keeping up with technology. Try out new things when there is the possibility to. You have to know just enough to be able to understand when you need a given technology needs further investigation. Do you know what you don't know?
#4 Share knowledge
#5 Maintain your toolbox - Some tools might be disposable, being no more useful, or technologically deprecated. Use the "clothing" rule to update your tools.
#6 Learn how to learn
http://henrikwarne.com/2012/08/22/top-5-surprises-when-starting-out-as-a-software-developer/
5. People Interaction
4. Writing Matters
It helps a lot to be able to write clearly in order to get your points across. To some extent, coding and writing are quite similar. In both cases you need to express your ideas clearly and unambiguously in a structured way. There are of course lots of e-mails that need to be written, but there is also documentation of the features you have developed, describing bugs in bug reports so that it is clear what the problem is, as well as writing good explanations for bugs you have fixed.
程序员的工具是编程语言，日常活动和主要工作包括设计（design）、建模（model）、编码（code）、调试（debug）、重构（refactor）、沟通（communicate）、学习（learn）和思考（think）。
抽象思维（abstract thought）。给定一个问题，抽象就是去掉纷繁芜杂的与计算无关的部分，用规约（Reduction）的方法还原到问题的本质。所谓本质即把原来的问题转换为一个或几个可以使用计算机描述并解决的问题，
分析（Analysis）。分析是上文提到的数学家所用思维方式中从一般到若干特殊情况的过程。面对一个问题，如果一下子描述不清楚或者表示不出来，可以先找出满足问题条件的几种特殊情况。通过仔细检查这几种特殊情况，求同存异，找出他们共同的规律或模式，并对这些模式或规律加以验证，就可以找出描述或表示问题的方法。这就是猜测加验证（guess-and-verify）的过程。项目需求分析时常见的应用案例分析（Use Case Analysis）方法，就是用一个个具体的使用案例将模糊的项目需求生动的表达出来。
分解（Decomposing）。把一个大问题分解为几个小问题，或者把一个复杂的过程分解为几个子过程，当然有助于问题的解决。这也是程序员常用的手段，如算法策咯中的分而治之（Divide-and-Conquer）和合并排序就是这方面的例子。
递归（Recursion）。对于初学编程的人，递归可能是一个比较诡异的较难掌握的概念。但是一个程序员如果不懂递归，很难再称之为程序员。因为很多稍微复杂的算法他都不可能理解，如回溯和动态规划，甚至于树的遍历。递归常常可以用简单的方法非常优雅的表达复杂的算法。
另外，有关计算思维的特有方法还有并行、异步 / 同步、模拟 / 近似、优化、分层、封装、解耦等等。程序员的思维艺术即计算思维不是一天两天短时间可以形成的，需要在实践中慢慢琢磨，不断提升，且永无止境。
严谨缜密。在软件开发中，任何事情在逻辑上原因和结果都是清晰明了的，不存在任何意义上的说不清道不明的神秘主义。程序员也是软件工程师，讨论问题时，当然应该使用工程师的语言，即用数据而不是猜测，用逻辑而不是臆断，来表达自己观点。
有两种情况可能造成自己表述时似是而非，模棱两可：第一，数据掌握的不够；第二，没有 “想的很明白”。例如，当我们讨论性能（Performance）时，一定要用响应时间（Response Time）或吞吐量（Throughput）这样有意义的参数，而不只是泛泛的讲 “这系统咋这么慢啊”，“计算机在干什么呢，等的时间太长了”，“简直受不了这样的程序了”。用户可以这样抱怨，而程序员则不可。
同样当我们讲到系统开销时，要用 CPU 占用率、内存这样定量的参数。因此，一个脑筋清楚的程序员不会把这样的话挂在嘴边，“太神奇了，不知道为什么”，“弄不清楚是否可以解决这个问题”，“先这样吧，以后再说”。一般地讲，智能和非智能并没有清晰的界限，因为我们并不知道如何严格地定义智能。
完美主义。我不了解完美主义的真实意义，也不大拿得准完美主义是褒义词和贬义词。我用这个词是为了强调程序员要坚持追求工作的完美。写代码时是要有洁癖，不允许有任何瑕疵，这样的代码才可能正确、易读、高效、简单、优雅。对一项任务，不仅仅是做完就算了，还应该仔细想想是否是否可以做的再好一点。对遇到的问题，即使看似解决了，也要从头至尾完全弄明白，不能似是而非，不求甚解。
面对变化。变化意味着在新的征程上，要面对许多未知的东西，加之对安定状态下的安乐窝（Comfortable Zone）的眷恋，让我们有着或多或少的畏惧和抗拒。我认为这些都是人之常情,无可厚非。
不幸的是，对程序员来说，变化就是家常便饭，如新的项目、新的应用领域、新的编程语言、新的技术架构、开发过程中新的问题、新的功能等，可以说不变的只有变化。其实，好逸恶劳是畏惧变化的根源。只有克服 “懒” 的思想，强迫走出自己的安乐窝，对新的事物充满好奇心和求知欲，才能适应永远的变化。
『如果你手里有把锤子，所有东西看上去都想钉子』
每种语言的开发者，对其所掌握的语言都会有一种无法抑制的执着。
『用合适的语言取做合适的事情』
TDD
『软件开发没有银弹，方法论同样也适用』
如果你对面向对象还保持着封装，继承，多态，教条的遵循 SOLID 原则，可能仅对 OOP，可能还需要更多的思考。
『OOP 不是万能的』
『Design Pattern 是我们重构代码时的参考，不是我们写代码的准则』
使用合适的语言解决合适的事情。
使用 DSL 处理特定的领域
我始终觉得视野很重要，每种语言，工具都能带来不同的思考方式。对同一个问题，不同语言有不同的的思路，了解这些不同的思路可以扩展自己的视野，让自己不会拘泥于某一中语言所带来的生态圈中。
2009 我作为 Java 程序员从一个非计算机的专业转到了计算机领域。在 2012 年，我做了一个很有意思的回顾，自己平均每年都会学习一门新的语言或者新的技术领域：
- 2009 精通CSS
- 2010 Groovy
- 2011 Ruby, node.js
- 2012 Objective C
由于每个技术领域都能带来新的思维方法，这也让我不由自主的保持了一年一门语言或者框架的习惯：
- 2013 Shell， improve ruby
- 2014 Lisp ( SICP, Scheme )
- 2015 Swift，Clojure，Rails
系统的学习CSS，让我懂得如何布局，如何使用CSS创建自己享用的 UI。做页面的时候也偏向于先用 HTML + CSS 构建原型，再完成实现。
接触 Groovy 是由于 Grails 这个类 Rails 的框架。Groovy 让我见识到了脚本语言的强大，之后使用 Groovy 作为胶水语言为项目设计了基于 Groovy 描述的工作流引擎。
学习 Ruby 是因为 Rails。非常喜欢 Ruby 社区的气氛，非常活跃，时刻都能拥抱最新的技术。由于对 Ruby 的热情，让我买了第一台 Macbook， 同时也让我有幸参加了 ShanghaiOnRails 和 2012 RubyConfChina 聚会。也是由于 Ruby，让我有机会加入 Thoughtworks，有机会跟 Ruby 社区活跃的开源贡献者 FredWu 有共事的机会。
学习 iOS 开发，让产品有机会跟上海的 SMG 广电集团有了一次合作，也让我步入了 iOS Developer 的行列。
2015 年初接触 Clojure，其中有一个 Memorization 的思想对函数运算进行缓存，这个思想激发了灵感。按照 Momorization 思想对项目中的校验引擎做了优化，性能提升了近 100 倍。
知识犹如我们手中工具，我们可以通过不断学习来丰富我们的『工具箱』。每当碰见问题的时候，怀着开放的心，从自己的『工具箱』中选出做顺手的工具来达成自己的目标，这样可以避免知识的偏见带来的副作用。
再回来思考一下本文开头的问题：『如何建一个网站卖化妆品？』
此时你会有什么想法？
http://36kr.com/p/5044048.html对于比较棘手的 diff，我会适当增加几个评审人，把 diff 共享到合适的群里面。不管有没有动作，我每天都会 ping 一个 diff 出来。如果好几天都没有动作，我会问评审的对 diff 有什么惊人的发现，然后对结构做出改变。最后我会尽可能跟对方多沟通。我总是以 “[产品 / 标签]” 作为标题开头—这样大家就能知道 diff 是做什么的，如果我想尽快得到接受，我会写上 “[product-ASAP]” 或者 “[product-PUSHBLOCKER]” 之类的东西。
— Michael Novati
这一点似乎显而易见，但是就 diff 评审进行沟通的方式有很多种。一般的经验法则是按 diff 来进行。如果审核你的 diff 的人平时不怎么跟你打交道的话，你可能要在描述和标题上面增加一些平时跟团队成员沟通时不需要的上下文信息。你还可以在需要别人重点审查的地方做批注，如果相关逻辑比较复杂的话。
在设计会议上就提出期望还可以简化写代码的过程，开发出好的 API 和架构等。
不要害怕提醒评审者注意你的 diff。如果他们不想审核你的 diff，他们可以退出或者建议其他人来做。如果让 diff 一直留着待审查队列，那无异于给将来埋下冲突。
第三级：具备团队精神
编码是一项团队运动，就像所有的团队运动一样，个人能实现的事情总是有限的。
评审他人的代码
快速扫描，通读，打补丁，测试，评论
http://www.lvoyee.com/archives/286.html
程序员的职责应该是解决问题。
当然在解决问题的过程中，常常会涉及到代码，但是这一部分所占的比例非常小，更多的是构建一些有用的东西。
在构建软件的过程中，我们需要知道如何进行迭代。迭代能让我们对问题有一个更深入的理解，一步步一点点完善产品，话说，那种吹嘘自己能一蹴而就、一次性搞定的家伙统统是吹牛。迭代的过程中需要的是验证功能，而不是写代码。因为事实证明，写代码所耗费的成本是你不能承受之重。
此外，拥有一种能用于测试、评估和筛选idea的系统也是极其重要的，因为如果没有的话，团队里面所有的开发人员只会“各自为政”，将自己所有的精力投入到自己认为可行的方法上去，一条道走到底，不撞南墙不回头。
写到这儿，不知道各位程序员明白了没有？
上面这些事情虽然和写代码没啥多大关系，但是却是打造一个成功产品最重要的组成部分。然而，很多开发人员更关心的是，能否找到一个在内存中搜索二叉树的最佳时间复杂度的解决方案。
这自然是好的，但是却并不重要。本人，在软件行业已经有着15年工作经验，从不需要去翻阅类似《计算机编程艺术》一类的书籍，借鉴某些东西，一次也没有。
1. 解决你自己的问题
从外面获取答案和自己解决问题、找到答案，这两种方式是有区别的。当你自己解决一个问题时，你不仅解决了这一个问题，也意味着解决了跟它类似的数百万问题。这是一个先投资后收获的过程。有时，你可能需要花2到3天的时间解决一个问题，这没什么；这是你的前期投资。
2. 从做小程序开始
3. 仿造软件
4. 每个项目都要学到新东西
每次项目都努力使用一些听到过但从未使用过的新东西。没有使用过Jquery，那下次项目中就使用它；没有试过测试驱动开发，下次项目就是你的实验品；你明白我的用意，对吗？
5. 说行
如果有人请求你为他做些什么东西，记得要说“行”――如果你从来没有给别人做过什么东西的话。我知道你可能会想，我自己还有无数的东西要做呢，但从经验来看，除了把主要时间花在自己有利可图的项目上外，你也应该花一些时间做一些慈善项目。这样做你会得到人们的认可，人们会想着你，如果有机会的会话，他们就会引荐你。
6. 交结程序员朋友
这是另外一个获得引荐机会的方法。总有机会，你的程序员朋友的盘子装满了，他们需要有人把多余的商业机会接下来。这时他们需要你出现。同样，当你的盘子装不下时，你也需要有人帮你把活接走。
7. 成为一个领域专家
广闻博识，同时要至少精通其中一项。编程世界很大，没有人能掌握所有东西，所以，要有一个专长。例如，成为一个本地应用或金融软件方面的专家。
一个高级开发者，不夸张地说，他能记住自己每次的错误。他们甚至能在设计或者编写代码的时候，就能预见到很多失败。他们会对错误进行非常敏锐地反馈，用一种诚实的方法去评估自己的成功和失败。身为高级开发者，他会更倾向于热爱复杂问题，但会痴迷于简洁地解决它。
高级开发者不会给其他开发者划分等级。与之相比，他更多的是懂得。因为懂得，所以理解每个人在每个阶段都有长处和短处。而他们也比别人更了解自己的长处和短处，力求把自己的优势最大化。
一个高级开发者会懂得，所有理论基础都有背景支持。他们不会执着于「对的方式」去搭造软件，而是把理论灵活运用于实际，理论可以变通用于为客户、团队和组织需要服务的工具。
高级开发者会在项目过程中，设身处地了解客户想要什么样的工作结果，以及他们的喜好。毕竟这些东西，比开发者个人的偏好和成功更重要。他们永远不会说「那不是我的工作」，也永远不会推搡任务和责任。
资深开发者会懂得一件事，那就是他们的工作是为了客户提供解决方案，而不是埋头写代码。而一位资深开发者永远会把自己团队能给顾客带来多少价值，放在考核标准。而不是把自己的努力和客户需求放在对等的 PK 赛场里。
诚然，因为这是一份工作，所以中间的过程总会非常枯燥和无聊。但资深开发者会退一步，思考怎么能解决和打破这些无聊的问题。他们会评估本源问题，直接解决它。或者他们会把枯燥情绪放在旁边，修复日常必须要面对的问题。
资深开发者也会懂得团队工作的高效。没有人能自己做一切工作，他们会致力于提升自己团队的效率。他们把提高团队效率所做的行为，视为提高自己软实力的一部分。
资深开发者懂得，领导力不仅仅只是权力，也不仅仅只是控制力。权力不是交通棒，而是一种服务意识。
如果你的团队中缺乏高级开发者，那这个项目基本都无一例外走向失败。拥有中级开发者能让你做事情非常快，但是在工作中你会发现，项目不仅仅只是搭造和维护程序。最终你只能关闭网站，或者用比预期中更高昂的价格维护它。只有高级开发者能选择技术和网站，而不是任由他们来伤害你。
很多需求很简单，但大多数简单需求后面，隐藏更复杂的需求。
而现实情况是，我自己很厌倦以工作时限来分类开发者。是的，工作经验能告诉你很多事情，但通常提供的都是无意义的信息。甚至于这些信息，也必须要结合很多背景来判断。
当一个开发者脱离菜鸟阶段成长为中级开发者时，他们能够在项目失败时反省整个过程（通常，他们会看自己所做工作部分）。而且会意识到，比起匆匆忙忙埋头苦干完成任务，应该在项目最初就建立起一些规矩。甚至于如果最开始有人指正他们，整个项目就能在最初避免走向失败。
而中级开发者还会体验另一个独特心理过程，那就是当他们回首一年前的工作。发现尽管当时认为「哎呦，自己做的还不错」，但现在会发现「这都什么玩意」啊。
一个中级开发者是有能力通过以往经验、文本资料、项目团队讨论等方式，摸索出「正确方法」做事的人。在这个阶段，学习构建软件的理论比学习构建代码更重要（后者应该在学校就掌握了）。
另一方面，中级开发者假如自作主张起来，造成的危害比初级开发者更大。初级开发者只会堆砌算法，一个好的中级开发者努力方向是「模式设计」和「范畴驱动设计」。这些技能是他们搭造 OO 系统的必备过程，学习完这些理论知识如果灵活运用，可以让他们更好地构造项目。但如果僵硬使用，也会危害整个项目。
有的时候，让一名中级开发者搭造系统，他耗费的时间可能比初级开发者更长，而且更糟的情况是他可能带整个团队走向迷途。很可悲的是，很多项目开发之所以走向失败，因为领队者自己只是一个中级开发者，他们缺乏和高级开发者工作的珍贵经验。团队领导自己，而且团队里其他人都没有意识到这点。
中级开发者很清楚自己在团队中起到的角色，能认识到他们给团队工作带来的价值。一个好的中级开发者知道代码是用来解决问题的，而不是用来终结问题的。然而，中级开发者总容易陷入一种认知上的金字塔，那就是他们会遵循一些「正确的方式」去解决问题。
一个好的中级开发者需要少而精的监管。他们在代码构造方向非常可靠，而且会在讨论设计的过程中发挥重要作用。中级开发者是团队中的「发动机」。但是，如果进一步的指导和更高级别的监管仍然是必不可少。
http://game-lab.org/posts/review201509-2/
程序员的世界，最讨厌的就是重复，重复的事情应该交给机器来帮你完成，而并非同样的事情手动敲了一遍又一遍。人脑最擅长的是通过思考总结、分析、抽象出模式，而机器最擅长的就是重复。机器执行重复的事情，准确性和效率要完胜手工
http://www.lvoyee.com/archives/390.html
程序员的世界，最讨厌的就是重复，重复的事情应该交给机器来帮你完成，而并非同样的事情手动敲了一遍又一遍。人脑最擅长的是通过思考总结、分析、抽象出模式，而机器最擅长的就是重复。机器执行重复的事情，准确性和效率要完胜手工
http://www.lvoyee.com/archives/390.html
最后我认为做技术的交流很重要，因为做技术是个永无止境的学习过程，而交流是一种更有效的学习方式。因为每个人的知识系统都是不同的，每个人掌握的东西不同，思维方式各异。
所以交流就是一个互相学习和促进的过程，当你把自己的想法与别人交流你就会收获更多新的想法。交流是一咱倍速增长的过程，前一段我写了一篇《当你开启一扇门的时候，很多扇门将为你开启》给我们的团队就是想表达这个想法。
交流有很多的，有线上的有线下的，大家都有上论坛的习惯，这是一种交流方式，但我认为线下交流更有效，语言的交流比文字的交流方式更直接和全面，所以我认为做技术的应该更开放一些，多参加类似PEA的这种交流。
交流一定要是开放的，所以在交流中应该是一种包容的心态去面对。也就是说我们是持有自己想法的时候也应该耐心倾听他人的意见，不能认死理。只有站在客观的角度去看问题才能把问题看的更透彻，只有不抵触才能让自己学到更多的东西。
在我们的技术团队中有定期的技术分享会，目的就是为了建立交流的平台，让大家都尝试表达自己的意见，锻炼自己的能力，并可以和更多的人去交流。
最后总结一下，多看，吸收别人的经验转化为自己所用，多写，全面性的锻炼自己的能力，多交流，利用众人的智慧。三多更多的就是去做。
程序员注重实效的特征，其实就是他处理问题、寻求解决方案时的态度、风格、哲学。在编程的漫漫长路上，程序员要越出直接的问题去思考，设法把问题放到更大的语境中，注意更大的图景。如果没有更广阔的视野，你如何明智地做出妥协?不做出妥协，如何取得实效?尤其是对于一个经验丰富的老程序员来说，实现功能已经没有什么障碍，唯有学会妥协和放弃，才能在编程中更上一层楼。
在长年开发中摸爬滚打的程序员，应该都能做到对每一件事情负责。因为负责，所以不可能坐视自己手底下的项目土崩瓦解。所以，我们必须在最短的时间内，把客户想要的东西呈现出来。惟如此，才能降低项目夭折的可能。真不知道我在行文这一刻，就有多少个程序员在为腰斩的心血而叹息。
越资深的程序员似乎越固执，至少我和我认识的同行朋友都有这个毛病。在这一行呆久了，就会发现自己很难接受新的变化，并开始擅长为这种抗拒找出很多新手们无法反驳的理由，然后，在这些理由中固步自封，顶着高手的名号做着完全参与不进市场机制的东西。
第一步：确定自己的品牌
1、自我定位：
如果你想建立一个比较有影响力的个人品牌，建议选择一个能够从自己专业技能中延伸出来的通用技能比较合适。比如你是一个iOS开发者，你最好将自己打造成iOS开发者圈子的专家、布道师；
如果你想建立一个比较有影响力的个人品牌，建议选择一个能够从自己专业技能中延伸出来的通用技能比较合适。比如你是一个iOS开发者，你最好将自己打造成iOS开发者圈子的专家、布道师；
2、统一头像、ID：
选择一个更加独特的头像（如果有可能的话找个朋友给你设计一个），名字最好取容易记住的英文；
选择一个更加独特的头像（如果有可能的话找个朋友给你设计一个），名字最好取容易记住的英文；
3、在每一个技术社区、博客、社交网站建立自己的个人主页；
建议覆盖以下所有社区：Github、简书、知乎/知乎专栏、微信公众号、微博、facebook、twitter、stackoverflow、Linkdin、medium、segmentfault、博客园、csdn博客、v2ex、开发者头条、稀土掘金、oschina，且有所重点的打造部分社交平台的粉丝数，我对以上平台的主次分类是：
（1）确认微信公众号、微博为重点打造的社交账号（关注数）；
（2）简书、知乎、github为次重点打造的社交账号（关注数）；
（3）segmentfault、博客园、csdn博客、V2ex、开发者头条、稀土掘金、oschina为内容分享的重要平台，利用这些平台来推销自己，同时也给平台方贡献最优质的内容，达到双赢局面；
建议覆盖以下所有社区：Github、简书、知乎/知乎专栏、微信公众号、微博、facebook、twitter、stackoverflow、Linkdin、medium、segmentfault、博客园、csdn博客、v2ex、开发者头条、稀土掘金、oschina，且有所重点的打造部分社交平台的粉丝数，我对以上平台的主次分类是：
（1）确认微信公众号、微博为重点打造的社交账号（关注数）；
（2）简书、知乎、github为次重点打造的社交账号（关注数）；
（3）segmentfault、博客园、csdn博客、V2ex、开发者头条、稀土掘金、oschina为内容分享的重要平台，利用这些平台来推销自己，同时也给平台方贡献最优质的内容，达到双赢局面；
第二步：推销自己的品牌
1、成为1%，分享你擅长或有经验心得的干货：对互联网来说，100个人中，只有1个人会创造内容，9个人会与其互动，而其他90个人仅仅是浏览。想要打造个人品牌你必须首先成为那1%创造内容的人,对于技术人员来说，我们可以从以下几方面作为突破口。
- 参与开源项目，比如：老赵、玉伯、Laruence、尤雨溪；
- 坚持原创精华技术文章，比如：阮一峰、简悦云风、老赵、左耳朵耗子；
- 翻译国外精华/行业分析技术文章/文档/书籍，比如：阮一峰、胡凯；
- 原创系列教程/书籍比如：罗升阳、stormzhang、罗力文；
- 整理/收集各种开发教程，方便开发者比如：脉脉不得语、Trinea；
- 开发者社区问题解答：如知乎上vczh、老赵、winter；
- 参与线下技术分享沙龙：几乎以上列出来的技术网红都参与过。
2、寻找合适的传播渠道：虽然互联网很大，但是对于技术人员来说圈子还是小到可以细数出来，无外乎就是我们上面说的那些平台，以下分享一些小技巧。
- 精品文章直接投稿开发者头条、稀土掘金、极客头条；
- 在简书发布，精品文章一定要记得首页投稿（方法）(插播一句，简书的写作体验对程序员来说简直是大大的好，而且简书正在快速发展中，跟平台一起成长将会快速个人品牌建立)；
- 微博、知乎发布@相关技术大牛：比如在知乎vczh特别乐于给好的东西点赞，一个点赞经常能够引来几千上万人关注；Android开发相关的@ @安卓大王子 @drakeet @胡凯me @googdev@Android笔记 @技术小黑屋 @代码家 @廖祜秋liaohuqiu_秋百万;iOS开发相关的@onevcat @唐巧boy @SwiftGG翻译组 @CocoaChina @叶孤城__ @github精选@SwiftLanguage @好东西传送门 等；
- 博客园头条的最多评论、最多推荐都是系统自动控制的，所以如果你文章够好，不妨厚脸皮邀请朋友们给你评论推荐；
- 在你的微信公众号没有获得很多关注的情况下，建议同时投稿其他的大号；
3、不断学习新东西：编程技术发展一日千里，不断涌现出新的技术，想成为技术圈网红，必须要时刻关心整个技术行业新技术的发展，同时将心得分享出来！
4、坚持下去：想在网络长期保持自己的个人品牌非常简单，但很少有人能做到，坚持长时间高质量输出原创文章。
5、扭正心态，迎接技术圈娱乐化：上周在diycode发布《GitHub 中国区前 100 名到底是什么样的人？》在技术圈引起非常大的讨论，到底该不该采用粉丝数去排名？！我想借用justjavac的话来回答这个问题“能进入榜单的大概有3种，要么技强，要么会经营，要么不仅技术能力强而且会经营。我们每个人无时无刻不在经营：经营我们的技术，经营我们的时间，经营我们的感情，……而经营我们的社区影响力，也是打造个人品牌的一部分。”
你写一篇文章爆红，是眼球不是品牌；你写一百篇文章，篇篇有人看，是积累也不是品牌；你每年写一百篇文章，坚持了七年，提起某个领域，大家首先就是想到你，这才是品牌。
欢迎大家一起评论区讨论或者加我微信探讨。
Use the source
Be persuasive
Be flexible
Go mobile
请谨记这一点，要懂得“自我规范”，也不能一旦代码“起效了”就立马置之脑后。如果所有的变量都命名错误，但是代码依然可以完美地运行，那么这些代 码绝对乱糟糟得让人不忍直视。将功能代码改进为简洁代码可能在短期内是看不到回报的：代码原本就可以工作，在清洁之后依然可以工作
http://blog.csdn.net/laner0515/article/details/43938579
1. 分享
尽可能地使用开源，并且如果有能力的话也可以把自己的成果分享给大家。整个社会的智慧结晶肯定比一些大公司自管自闭门造车要好。
2. 公平的心态
不要以为你的选择就是唯一能奏效的，试试其他技术、框架、方法和建议，也许其他的选择比你原先的好也未可知。要用开放的心态去对待任何方法和抉择。
3. 不可攻击他人
如第 2 条所言，不要因为别人恰巧使用的是 .Net、Java 或 PHP 这些技术就随意攻击他们(我在这方面有过教训)。有时，这些你看不上眼的技术或许要比你想象的更有用。只要你怀着一种平和的心态，你就可以从他们那里学到很多东西，殊不知，海纳百川，有容乃大。
4. 解决自己的烂摊子
自己的代码自己负责。永远不要指望 QA 能帮你找到所有的 bug。经常全面地测试自己的代码。
6. 如果伤害了别人要说对不起
代码审查是一个相当不错却又很少使用的主意。指导经验比你少的程序员，有助于整个团队的发展。但是切记不能公开批评他人。指导并不意味着贬低别人。在得到指导时，有的人会接受，有的人则不会。要记得有时候，从那些水平不及你的人身上，你也能学到很多东西。绝对不能门缝里看人——把人看扁了。
7. 有备而来
在正式开工写代码之前要先做个彻底的了解。做原型、从网上搜索实例、和其他也做这个的人讨论或者先练练手。什么都不知道就着手构建你从未尝试过或使用过的东西简直就是“自作孽不可活”。如果打一开始就有线索有思路，得到的结果可能会更好更有成效。
8. 拿得起放得下
不要畏惧替换、重写、重构甚至是直接删掉代码。有时候，如果碰到可留可不留的代码，直接扔掉就是了。不要对你的代码死缠烂打，不肯放手。
9. 舒适的工作环境
对，要想程序员能高效编程，一个好的工作环境是不可或缺的。一把舒适的椅子，一个安静的工作场所、一代高配置的电脑以及各种有助于编程的工具都应该配备齐全。经理避免一些琐事去打搅到手下的程序员。而作为一个程序员，也不必忍气吞声、给人做牛做马，如果老板对你不好，换个就是了。
10. 保持生活的平衡——学习、思考、绘画、唱歌、跳舞、工作、玩耍，每天都应该活得丰富多彩
我非常欣赏谷歌的工作方式，它会建议你花上 20% 的时间用来思考任何你认为值得做的事情。此外，谷歌还提供专门的休息室、游戏房和其他一些能用来放松自己的场所。因为编程是一种高强度的脑力活动，有时候你的大脑真的非常需要稍作休息。不要盲目地不管不顾自己的身体，“工作狂”绝对是不可取的生活方式。每周工作 80 小时，听上去很牛掰，但是你的工作效率肯定要打一个问号，甚至一不小心会犯个不可饶恕的小错误然后前功尽弃。
11. 下午打个盹
12. 不要闭门造车
交流对于我们相当有好处：读读博客、学学新语言和框架、讨论讨论话题、看看同行在做什么。自扫门前雪，绝对成就不了一个优秀的程序员。闭门造车型的程序员终将被时代的潮流所淘汰。
13. . 保持好奇心。我们就像一粒粒种子，因为有着对外面世界的好奇，才能从土壤中探出头来，亲眼见证这个世界。
每天我们都能看到有新鲜事物出现在编程世界里。带着“Why”去一探究竟。每天都学点新知识，扩宽自己的视野，刷新自己的技能，让自己跟得上时代前进的步伐。要是你觉得编程枯燥又乏味，那么也许你可以考虑换一行。
14. 所有事物都会逐步趋向衰退灭亡，谁都无法抵抗。
代码也会慢慢发旧直至死亡。这时候你能做的就是把它们埋葬，然后再重新写过。不要为了省钱而继续维护那些费力不讨好的代码！
15. 还记得《雌雄大盗》这本书吗，我们学到的第一件事就是——“看”。
如果你不自己亲自去试试，那么你永远也学不到东西。我在编程中学会的所有东西全都来自于我的亲身实践。每天早上，我会广泛浏览网站，看看我们的编程世界有什么新鲜事情发生。从 80 年代初我得到第一份工作开始，我就一直保持了这个习惯。（那个时候网络还没普及，我主要是看目录和杂志。）
