IT 顾问的读后感
一 摘抄
1. If all they needed was a code robot, it would be easy to hire someone in another country to do that kind of work. If you want to stay relevant, you’re going to have to dive into the domain of the business you’re in.
2. You might be “just a programmer,” but being able to speak to your business clients in the language of their business domain is a critical skill.
3. “Always be the worst guy in every band you’re in.”
4. Being the worst guy in the band brought out the same behavior in me as a saxophonist. I would naturally just play like everyone else.
5. So, I learned from this that people can significantly improve or regress in skill, purely based on who they are performing with. And, prolonged experience with a group can have a lasting impact on one’s ability to perform.
6. If you don’t have an active developer community nearby, use the Internet. Pick an open source project that you admire and whose developers appear to be at that “next level” you’re looking to reach.
7. For me, as a hiring manager, the first reason is that it shows that you’re interested. If I know you learned something for the sake of self-development and (better) pure fun, I know
8. you are excited and motivated about your profession.
9. Fear-driven career planning is more likely to land you in a cubicle farm for the rest of your life than on the path to greatness. Sure, it’s safe, but it’s no fun.
10. Take calculated risks with your career. Don’t let fear consume you. And if you’re not having fun, you’re not going to be excellent.
11. To muddy the waters of decision even more,
12. the Microsoft employment offer was juicy. Salary plus $300,000 over three years juicy.
13. If you want a recipe for restless sleep, I can give you one. Add one part “What will my wife think?”
14. When I’m old and dying, I plan to look back on my life and say, “Wow, that was an adventure,” not “Wow, I sure felt safe.”
15. The way to become a generalist is to not label yourself with a specific role or technology. We can become typecast in our careers in many ways.
16. the new world of onshore skeleton crews can benefit from a person who knows how to lead people and projects but can also roll up their sleeves and fix some last-minute critical bugs while the offshore team is sleeping.
17. “I’m sorry. I’m not getting you. Could you repeat the question, please?”
18. Too many of us seem to believe that specializing in something simply means you don’t know about other things.
19. Unfortunately, the software industry has churned out a whole lot of these shallow specialists, who use the term specialist as an excuse for knowing only one thing.
20. If so, take some time to learn about the internals of how your VM works. For Java, .NET, and Smalltalk, many books and websites are devoted to the topic. It’s easier to learn about than you think.
21. This guy wanted to build his career around a specific technology created by a specific company of which he was not an employee. What if the company goes out of business? What if it let its now-sexy technology become obsolete? Why would you want to trust a technology company with your career?
22. Somehow, as an industry, we fool ourselves into thinking market leader is the same thing as standard.
23. Even if you can’t or don’t want to make the case for using the open source solution in your workplace, use the open source option as the platform from which you can take a deep dive into a technology. For example, you may want to become an expert in how J2EE application servers work. Instead of focusing your efforts on the details of how to configure and deploy a commercial application server (after all, anybody can figure out how to tweak settings in a config file, right?), download the open source JBoss or Geronimo servers, and set aside time for yourself to not only learn how to operate the servers but to study their internals.
24. Try a small project, twice. Try it once in your home base technology and then once, as idiomatically as possible, in a competing technology.
25. This was the difference between me and my overeducated, underperforming colleagues at work. Passion.
26. Of course, natural talent plays a big role in ability. We can’t all be Mozart or Coltrane. But, we can all take a big step away from mediocrity by finding work we are passionate about.
27. What I do know is that I’m a serial opportunist. When I see something interesting and exciting to me, I jump in and do whatever it takes to succeed.
28. And I’ve never defined myself by my skills. Instead, I’ve always defined myself by what I have done and what I want to do next. Skills are just a way to get there.
29. Lao Tzu said, “Give a man a fish; feed him for a day. Teach a man to fish; feed him for a lifetime.”
30. Who wants to be at the mercy of someone else? Or, worse: if you were looking to hire someone to do a job for you, would you want that person to be at the mercy of the experts? I wouldn’t. I’d want to hire someone who is self-sufficient.
31. For example, code generators are what translate high-level C# code to byte codes that can run on the .NET runtime. You obviously wouldn’t want to have to write all those byte codes yourself. But, especially at the higher levels, letting the wizards have their way leaves your knowledge shallow and leaves you limited to what the wizards can already do for you.
32. Someone who is domain-ignorant will let silly mistakes slip through—mistakes that a basic knowledge of the business domain would have avoided. Furthermore, they’ll go slower (and ultimately cost the company more) than the equivalent developer who understands the business.
34. Without a role model, there’s no incentive to get better.
35. He came in to bail me out of a big problem with our campus NetWare network that was crippling the students who were trying to use our computer labs,
37. What’s important is that you have someone you trust and admire that can help give you career guidance and help you hone your craft.
38. We learn by teaching.
39. An online mentoring relationship can never compare to one that happens between two humans in the same place.
40. When you practice music, it shouldn’t sound good. If you always sound good during practice sessions, it means you’re not stretching your limits.
41. My code wasn’t completely devoid of brilliant moments.
42. An excellent place to find new code with which to practice is the open source community. Do you have any favorite pieces of open source software? How about trying to add a feature? Go look at the to-do list for a piece of software you’d like to practice with, and give yourself a constrained amount of time to implement the new feature (or at least to determine what it would take to implement it).
43. A great way to sharpen the mind and improve your improvisational coding skills is to practice with self-imposed constraints. Pick a simple program, and try to write it with these constraints.
44. TopCoder—TopCoder.com is a long-standing programming competition site. You can register for an account and compete online for prizes.
46. Studying the work of masters is an essential part of becoming a master.
47. How do other programmers solve particular problems algorithmically? How do others strategically use variable, function, and structure naming? If I wanted to implement the Jabber instant messaging protocol in a new language, how might I do it? What creative ways can I find to handle interprocess communication between UNIX and Windows systems? These are the type of questions you can answer through the study of existing code.
48. Commercial use of the Internet was beginning to hit its stride,
49. Living on the bleeding edge of technology was not always fun.
50. I did not realize until much later how important it was that they heard about us from a trusted source. The lesson here is that if you ever need to get in touch with a venture capitalist, work hard on getting a warm referral since it is the best way to get one’s foot in the door.
51. VCs in the future; see http://www.enterprisecorp.com/resources/assessment.htm). The skills that I picked up during that year at bCatalyst led me to my current job as the managing director of Enterprise Corp.
52. This identity observation creates some subtle problems, because our macro-goals may conflict with our micro-responsibilities.
53. You can’t avoid the boring work, and you know that you have to do it so quickly that nothing can get too boring.
54. Be the one who pushes. Don’t get comfortable.
55. Always be the one to ask, “But what can we do right now?”
56. Mind reading not only applies to your managers but also to your customers. If they’re giving you the right cues, you might be able to add features that they’re either going to ask for or would have asked for if they had realized they were possible.
57. People who can keep a project moving in the right direction without being given much guidance are highly valued and appreciated by their often overworked managers and customers.
58. It’s really easy to say “Make sure your goals and your work align with the goals of your business.” It’s really easy to say; it’s really hard to do,
59. However, truth be told, many of us just don’t have visibility into how we can do this at the level from which we’re grasping. We can’t see the forest for the trees.
60. How can you make the boring work more fun? The answer to that question might be more apparent if you flip it around.
61. Have you ever stopped to consider exactly how much you cost to the company you work for? I mean, you know your salary. That part is easy. What about benefits, management overhead, training, and all that other stuff that doesn’t necessarily show up on your paycheck?
62. Your presence on the job is, to the company, like a pebble in a bucket of water.
63. I heard it over and over again—is that you should never get too comfortable. He professed to waking up every day and intentionally and explicitly reminding himself that he could be knocked off of his pedestal any day. Today could be it, he’d say.
64. When the way you’ve always done it has always worked, you’re less likely to recognize a new way that might work better. You become arrogant, and with arrogance you develop blind spots. The less replaceable you think you are, the more replaceable you are (and the less desirable you become).
65. Feeling irreplaceable is a bad sign, especially as a software developer.
66. Everyone likes creating. That’s when we feel we are given the opportunity to really put our stamps on a piece of work.
67. Though software developers are typically creative, freedom-loving people, the programmer “society” is surprisingly caste-like. Programmers want to be designers, who want to be architects, and so on.
68. It also puts you in a prime spot for truly learning the inner workings of your business.
69. One of the many sources of controversy around the Extreme Programming movement is its initial assertion that team members should work no more than forty hours per week. This kind of talk really upsets slave-driving managers who want to squeeze as much productivity as possible from their teams.
70. Most projects last a long time. You can’t keep up the pace of a sprint and finish a marathon. Though your short-term productivity will significantly increase as you start putting in the hours, in the long term you’re going to crash so hard that the recovery time will be larger than the productivity gains you enjoyed during your eighty-hour weeks.
71. Budget your work hours carefully. Work less, and you’ll accomplish more. Work is always more welcome when you’ve given yourself time away from it.
72. Standing in front of a band on one side and an audience on another, the sound of a real stinker of a note is enough to freeze an amateur to the bone.
73. Speak in terms of concrete, predictable time frames.
74. The quickest path to missing your commitments is to make commitments that you know you can’t meet.
75. We are programmed to want to always succeed. And, saying we can’t do something feels like we failed.
76. If I have a team member who has the strength to say “no” when that’s the truth, then I know that when they say “yes,” they really mean it.
77. Don’t go overboard with the “no” game. Can-do attitudes are still appreciated, and it’s good to have stretch goals.
78. Like most skills, a great way to get good at it is to watch masters at work.
79. Most of the time, these things come in waves all together, never one at a time.
80. But looking back on literally every such disaster, not a single one has made a lasting, noticeable impact on me or my career. So, as panicked or depressed or upset as I’ve gotten over these seemingly disastrous situations, not one has been a true disaster.
81. If you’d just have the presence of mind to read the error message, the problem might be solved.
82. So, techies often overcompensate in our rebellion against perceived overplanning by constantly flying by the seat of our pants.
83. Natural talent had something to do with it, of course, but I’ve since held the belief that he planned and executed his way into the musical elite.
84. Having established a rhythm of plan and attack, you are ready to start thinking in terms of weeks and even months.
85. No manager in his or her right mind would be unhappy to receive a succinct weekly e-mail from an employee stating what was accomplished in the past week and what they plan to do in the next. Receiving this kind of regular message unsolicited is a manager’s dream.
86. The way to differentiate yourself is to address your mistakes or inabilities publicly and ask for help resolving them.
87. Creating and executing plans shows that you are not just a robot typing code, but you are a leader. It’s this kind of independent productivity that companies need as they reduce overhead.
88. Your leaders want you to have independence and ownership. Making, executing, and communicating plans will help you attain both.
89. So, especially given this movement towards web-based software, I think it’s important to actively seek out failure-prone projects.
90. If I’m a project manager, the quality of your source code is a lot less important to me than the quality of your communications. If I’m a fellow programmer, your raw ability and creativity drive my perception of you more than, for example, your follow-through. But, if I’m your manager, raw ability is ultimately meaningless to me unless you actually do something with it.
91. Perceptions are driven by different factors, depending on who the audience is.
92. They’re going to be looking for someone who can make them comfortable about the project they’re working on.
93. Your job is to be your customer’s tour guide through the unforgiving terrain of the information technology world. You will make your customers comfortable while guiding them through an unfamiliar place. You will show them the sights and take them where they want to go while avoiding the seedy parts of town you’ve encountered in the past.
94. You are what you can explain.
95. We had strained, late-night or early-morning phone conversations, made increasingly frustrating by background noise or unintended disconnections. I would write long, descriptive e-mails in an attempt to help close the distance and time zone gap, only to be ignored.
96. In addition to just telling a story about a bad manager, you can learn something from this experience. Physical proximity is an advantage in the workplace.
97. Remember, you need to make it personal, and to do that you have to remember the natural human tendency to want to work with other humans—not voicemail, e-mail, or instant messaging but actual people.
98. You might be carrying the torch for unit testing, driving test practices into the hearts of the unwashed masses of your company’s programmer pool.
99. Set your sights higher. Don’t think of yourself as a programmer at a specific company—after all, it’s not likely that you’ll be at the same place forever—but as a participating member of an industry. You are a craftsperson or an artist.
100. Our industry, like the music industry, is a big, complex web of people connecting each other. The more places you are attached to the network, the better your chances of connecting with that perfect job or career break. Limiting yourself to the company you work for places serious limits on the number of connections you can form.
101. More writing leads to more writing opportunities. And all of these lead to the opportunity to speak at conferences.
103. This entire part of the book is all about how to get both recognition and respect. Right here in this paragraph, what you need to understand is that the combination of the two is an asset worth building and guarding.
104. Imagine how much easier it would be to find a job if there were companies already relying on software you had written.
105. Although many of these contributing developers are just having fun and expressing themselves, some real incentives exist there. They are moving their way up the social chain of a community. They are building a name for themselves. They are building a reputation in the industry. They may not be doing it on purpose, but they are marketing themselves in the process.
106. If you create something really useful, you might even end up being famous. You could be famous in a small technical field—maybe famous among Rails people, for example. Or if you’re lucky, you could be really famous even outside the geek community like Linus Torvalds or…well, like Linus.
107. Equal weighting is put on each of the four categories.
108. Don’t let yourself just be the best in the bunch. Be the person and do the things that people can’t not talk about.
109. The problem is when many people in IT hear this phrase they focus on the word just. It makes them feel as if the business considers their request to be obvious, trivial, and easily accomplished.
110. So, the next time you hear that dreaded phrase, fight the urge to say “no.” Focus on the word we and confidently say, “Yes, we can add more developers to the project, but that wouldn’t be a good idea, and here’s why….” But don’t stop there. It isn’t enough just to explain your position. You need to dig deeper to find out what commercial constraints the business is operating under.
111. This part will show you how to avoid becoming a one-hit wonder.
112. Carve out weekly time to investigate the bleeding edge. Make room for at least two hours each week in order to research new technologies and to start to develop skills in them.
113. Don’t try to settle into the identity of a programmer. Or a designer. Or a tester.
114. You might not even change your actual work output, but you’ll see your work differently.
115. We’re so centered on the outcome that we forget to look at the scenery.
116. What most of us fail to realize is that the path is the end.
117. Focusing on the ending makes you forget to make the process good.
118. The next time you have to do a task like this, see whether you can find a way to focus on the task as you do it instead of anxiously rushing to finish it.
119. If Microsoft had considered Windows 3.1 done, we’d all be using Macintoshes right now. If the Apache developers had considered their web server done when they reached 1.0, they might not be overwhelmingly leading the market right now.
120. You’ll notice the same phenomenon with your career. Actually, you won’t notice it. That’s the problem. You might look at yourself in the metaphorical mirror each day and not see an ounce of change. You seem as well adjusted as before. You seem as competitive as before. Your skills seem to be as up-to-date as before.
121. Know your enemy—Pick the technology you hate most, and do a project in it. Developers tend to stratify themselves into competing camps. The .NET people hate J2EE, and the J2EE people hate .NET. The UNIX people hate Windows, and the Windows people hate UNIX.
122. The larger and more complex a project is, the less likely it is possible to imagine every feature in detail well enough to create a specification.
123. In theory, the idea of detailed planning and rigor sounds obviously right. But in practice, it does not work.
124. Set big goals, but make constant corrections along the way. Learn from the experience, and change the goals as you go. Ultimately, a happy customer is what we all want (especially when, as we plan our careers, we are our own customers)—not a completed requirement.
125. it’s possible to be enthusiastic about taking real, tangible steps toward a distant goal.
126. You might not be able to see a noticeable difference in the whole with each incremental change, though. When you’re trying to become more respected in your workplace or be healthier, the individual improvements you make each day often won’t lead directly to tangible results.
127. If every day you do a little better than yesterday toward improving yourself, you’ll find that the otherwise ocean-sized proposition of building a remarkable career becomes more tractable.
128. In this way, a big company makes a wonderful place to go and semi-retire for a while if you’re burned out. But if you’re striving to be remarkable (which you are!), a big company is a hard place to find the right groove in the same way a bakery is a bad place to try to work off your love handles. The solution? Go independent!
二 初读感受
一百多句摘抄，可以说每一句都给我很深的感触。第一遍扫下来有几点印象最深刻。
2.1 Business Knowledge
如果能早读到这本书我估计之前做项目的时候我的关注点，看问题的角度都会不同。大多数时候的我都停留在解决技术问题的快感，忽略了于客户的沟通，没有把握住真正的需求。和人沟通的技能没有得到较大提高，还有项目的管控，方法论等等。就像Oliver说的，我是一个decent developer，not a consultant。今后做项目我要试着把注意力放在人的方面，business请我们来是解决他们的业务问题，不是让我们来玩技术的。很多技术上很难的问题其实在业务上都可以变通的解决。比如上次在新希望项目上，杨经理找Ray想要BW把ERP的一个难搞的程序接下来，那Ray的说法是我们可以做，但是现在没有时间做，另外这个太detail，要做也是放在后面做。
所以接下来我的一个目标就是读完《MBA十日读:美国著名商学院课程精要(第3版)》，在2014年内能看懂财报。
2.2 方法论
刚进公司的时候又一个IDEA方法论的培训，觉得很扯淡。现在感觉又有所不同，方法论其实就是如何做一件事情前人经验的总结，对做项目而言至关重要。有了这个东西你知道现在项目的状况是什么，我们现在在哪里，如果想成为项目经理或者做事情有章法的人看看方法论对你肯定有提高。
接下来我会对做项目的项目节点格外关注，另外复习下IDEA方法论。
2.3 做更好的自己
这部分我觉得写的比7 Habits更具体一些，还是没逃离7 Habits那些东西。用我自己的话概括就是不要偷懒，不要给自己设定任何限制。自然会越来越强，心灵的肌肉不要给自己设限制，到一定年纪可以和普通人拉开不小的距离。
1. If all they needed was a code robot, it would be easy to hire someone in another country to do that kind of work. If you want to stay relevant, you’re going to have to dive into the domain of the business you’re in.
2. You might be “just a programmer,” but being able to speak to your business clients in the language of their business domain is a critical skill.
3. “Always be the worst guy in every band you’re in.”
4. Being the worst guy in the band brought out the same behavior in me as a saxophonist. I would naturally just play like everyone else.
5. So, I learned from this that people can significantly improve or regress in skill, purely based on who they are performing with. And, prolonged experience with a group can have a lasting impact on one’s ability to perform.
6. If you don’t have an active developer community nearby, use the Internet. Pick an open source project that you admire and whose developers appear to be at that “next level” you’re looking to reach.
7. For me, as a hiring manager, the first reason is that it shows that you’re interested. If I know you learned something for the sake of self-development and (better) pure fun, I know
8. you are excited and motivated about your profession.
9. Fear-driven career planning is more likely to land you in a cubicle farm for the rest of your life than on the path to greatness. Sure, it’s safe, but it’s no fun.
10. Take calculated risks with your career. Don’t let fear consume you. And if you’re not having fun, you’re not going to be excellent.
11. To muddy the waters of decision even more,
12. the Microsoft employment offer was juicy. Salary plus $300,000 over three years juicy.
13. If you want a recipe for restless sleep, I can give you one. Add one part “What will my wife think?”
14. When I’m old and dying, I plan to look back on my life and say, “Wow, that was an adventure,” not “Wow, I sure felt safe.”
15. The way to become a generalist is to not label yourself with a specific role or technology. We can become typecast in our careers in many ways.
16. the new world of onshore skeleton crews can benefit from a person who knows how to lead people and projects but can also roll up their sleeves and fix some last-minute critical bugs while the offshore team is sleeping.
17. “I’m sorry. I’m not getting you. Could you repeat the question, please?”
18. Too many of us seem to believe that specializing in something simply means you don’t know about other things.
19. Unfortunately, the software industry has churned out a whole lot of these shallow specialists, who use the term specialist as an excuse for knowing only one thing.
20. If so, take some time to learn about the internals of how your VM works. For Java, .NET, and Smalltalk, many books and websites are devoted to the topic. It’s easier to learn about than you think.
21. This guy wanted to build his career around a specific technology created by a specific company of which he was not an employee. What if the company goes out of business? What if it let its now-sexy technology become obsolete? Why would you want to trust a technology company with your career?
22. Somehow, as an industry, we fool ourselves into thinking market leader is the same thing as standard.
23. Even if you can’t or don’t want to make the case for using the open source solution in your workplace, use the open source option as the platform from which you can take a deep dive into a technology. For example, you may want to become an expert in how J2EE application servers work. Instead of focusing your efforts on the details of how to configure and deploy a commercial application server (after all, anybody can figure out how to tweak settings in a config file, right?), download the open source JBoss or Geronimo servers, and set aside time for yourself to not only learn how to operate the servers but to study their internals.
24. Try a small project, twice. Try it once in your home base technology and then once, as idiomatically as possible, in a competing technology.
25. This was the difference between me and my overeducated, underperforming colleagues at work. Passion.
26. Of course, natural talent plays a big role in ability. We can’t all be Mozart or Coltrane. But, we can all take a big step away from mediocrity by finding work we are passionate about.
27. What I do know is that I’m a serial opportunist. When I see something interesting and exciting to me, I jump in and do whatever it takes to succeed.
28. And I’ve never defined myself by my skills. Instead, I’ve always defined myself by what I have done and what I want to do next. Skills are just a way to get there.
29. Lao Tzu said, “Give a man a fish; feed him for a day. Teach a man to fish; feed him for a lifetime.”
30. Who wants to be at the mercy of someone else? Or, worse: if you were looking to hire someone to do a job for you, would you want that person to be at the mercy of the experts? I wouldn’t. I’d want to hire someone who is self-sufficient.
31. For example, code generators are what translate high-level C# code to byte codes that can run on the .NET runtime. You obviously wouldn’t want to have to write all those byte codes yourself. But, especially at the higher levels, letting the wizards have their way leaves your knowledge shallow and leaves you limited to what the wizards can already do for you.
32. Someone who is domain-ignorant will let silly mistakes slip through—mistakes that a basic knowledge of the business domain would have avoided. Furthermore, they’ll go slower (and ultimately cost the company more) than the equivalent developer who understands the business.
34. Without a role model, there’s no incentive to get better.
35. He came in to bail me out of a big problem with our campus NetWare network that was crippling the students who were trying to use our computer labs,
37. What’s important is that you have someone you trust and admire that can help give you career guidance and help you hone your craft.
38. We learn by teaching.
39. An online mentoring relationship can never compare to one that happens between two humans in the same place.
40. When you practice music, it shouldn’t sound good. If you always sound good during practice sessions, it means you’re not stretching your limits.
41. My code wasn’t completely devoid of brilliant moments.
42. An excellent place to find new code with which to practice is the open source community. Do you have any favorite pieces of open source software? How about trying to add a feature? Go look at the to-do list for a piece of software you’d like to practice with, and give yourself a constrained amount of time to implement the new feature (or at least to determine what it would take to implement it).
43. A great way to sharpen the mind and improve your improvisational coding skills is to practice with self-imposed constraints. Pick a simple program, and try to write it with these constraints.
44. TopCoder—TopCoder.com is a long-standing programming competition site. You can register for an account and compete online for prizes.
46. Studying the work of masters is an essential part of becoming a master.
47. How do other programmers solve particular problems algorithmically? How do others strategically use variable, function, and structure naming? If I wanted to implement the Jabber instant messaging protocol in a new language, how might I do it? What creative ways can I find to handle interprocess communication between UNIX and Windows systems? These are the type of questions you can answer through the study of existing code.
48. Commercial use of the Internet was beginning to hit its stride,
49. Living on the bleeding edge of technology was not always fun.
50. I did not realize until much later how important it was that they heard about us from a trusted source. The lesson here is that if you ever need to get in touch with a venture capitalist, work hard on getting a warm referral since it is the best way to get one’s foot in the door.
51. VCs in the future; see http://www.enterprisecorp.com/resources/assessment.htm). The skills that I picked up during that year at bCatalyst led me to my current job as the managing director of Enterprise Corp.
52. This identity observation creates some subtle problems, because our macro-goals may conflict with our micro-responsibilities.
53. You can’t avoid the boring work, and you know that you have to do it so quickly that nothing can get too boring.
54. Be the one who pushes. Don’t get comfortable.
55. Always be the one to ask, “But what can we do right now?”
56. Mind reading not only applies to your managers but also to your customers. If they’re giving you the right cues, you might be able to add features that they’re either going to ask for or would have asked for if they had realized they were possible.
57. People who can keep a project moving in the right direction without being given much guidance are highly valued and appreciated by their often overworked managers and customers.
58. It’s really easy to say “Make sure your goals and your work align with the goals of your business.” It’s really easy to say; it’s really hard to do,
59. However, truth be told, many of us just don’t have visibility into how we can do this at the level from which we’re grasping. We can’t see the forest for the trees.
60. How can you make the boring work more fun? The answer to that question might be more apparent if you flip it around.
61. Have you ever stopped to consider exactly how much you cost to the company you work for? I mean, you know your salary. That part is easy. What about benefits, management overhead, training, and all that other stuff that doesn’t necessarily show up on your paycheck?
62. Your presence on the job is, to the company, like a pebble in a bucket of water.
63. I heard it over and over again—is that you should never get too comfortable. He professed to waking up every day and intentionally and explicitly reminding himself that he could be knocked off of his pedestal any day. Today could be it, he’d say.
64. When the way you’ve always done it has always worked, you’re less likely to recognize a new way that might work better. You become arrogant, and with arrogance you develop blind spots. The less replaceable you think you are, the more replaceable you are (and the less desirable you become).
65. Feeling irreplaceable is a bad sign, especially as a software developer.
66. Everyone likes creating. That’s when we feel we are given the opportunity to really put our stamps on a piece of work.
67. Though software developers are typically creative, freedom-loving people, the programmer “society” is surprisingly caste-like. Programmers want to be designers, who want to be architects, and so on.
68. It also puts you in a prime spot for truly learning the inner workings of your business.
69. One of the many sources of controversy around the Extreme Programming movement is its initial assertion that team members should work no more than forty hours per week. This kind of talk really upsets slave-driving managers who want to squeeze as much productivity as possible from their teams.
70. Most projects last a long time. You can’t keep up the pace of a sprint and finish a marathon. Though your short-term productivity will significantly increase as you start putting in the hours, in the long term you’re going to crash so hard that the recovery time will be larger than the productivity gains you enjoyed during your eighty-hour weeks.
71. Budget your work hours carefully. Work less, and you’ll accomplish more. Work is always more welcome when you’ve given yourself time away from it.
72. Standing in front of a band on one side and an audience on another, the sound of a real stinker of a note is enough to freeze an amateur to the bone.
73. Speak in terms of concrete, predictable time frames.
74. The quickest path to missing your commitments is to make commitments that you know you can’t meet.
75. We are programmed to want to always succeed. And, saying we can’t do something feels like we failed.
76. If I have a team member who has the strength to say “no” when that’s the truth, then I know that when they say “yes,” they really mean it.
77. Don’t go overboard with the “no” game. Can-do attitudes are still appreciated, and it’s good to have stretch goals.
78. Like most skills, a great way to get good at it is to watch masters at work.
79. Most of the time, these things come in waves all together, never one at a time.
80. But looking back on literally every such disaster, not a single one has made a lasting, noticeable impact on me or my career. So, as panicked or depressed or upset as I’ve gotten over these seemingly disastrous situations, not one has been a true disaster.
81. If you’d just have the presence of mind to read the error message, the problem might be solved.
82. So, techies often overcompensate in our rebellion against perceived overplanning by constantly flying by the seat of our pants.
83. Natural talent had something to do with it, of course, but I’ve since held the belief that he planned and executed his way into the musical elite.
84. Having established a rhythm of plan and attack, you are ready to start thinking in terms of weeks and even months.
85. No manager in his or her right mind would be unhappy to receive a succinct weekly e-mail from an employee stating what was accomplished in the past week and what they plan to do in the next. Receiving this kind of regular message unsolicited is a manager’s dream.
86. The way to differentiate yourself is to address your mistakes or inabilities publicly and ask for help resolving them.
87. Creating and executing plans shows that you are not just a robot typing code, but you are a leader. It’s this kind of independent productivity that companies need as they reduce overhead.
88. Your leaders want you to have independence and ownership. Making, executing, and communicating plans will help you attain both.
89. So, especially given this movement towards web-based software, I think it’s important to actively seek out failure-prone projects.
90. If I’m a project manager, the quality of your source code is a lot less important to me than the quality of your communications. If I’m a fellow programmer, your raw ability and creativity drive my perception of you more than, for example, your follow-through. But, if I’m your manager, raw ability is ultimately meaningless to me unless you actually do something with it.
91. Perceptions are driven by different factors, depending on who the audience is.
92. They’re going to be looking for someone who can make them comfortable about the project they’re working on.
93. Your job is to be your customer’s tour guide through the unforgiving terrain of the information technology world. You will make your customers comfortable while guiding them through an unfamiliar place. You will show them the sights and take them where they want to go while avoiding the seedy parts of town you’ve encountered in the past.
94. You are what you can explain.
95. We had strained, late-night or early-morning phone conversations, made increasingly frustrating by background noise or unintended disconnections. I would write long, descriptive e-mails in an attempt to help close the distance and time zone gap, only to be ignored.
96. In addition to just telling a story about a bad manager, you can learn something from this experience. Physical proximity is an advantage in the workplace.
97. Remember, you need to make it personal, and to do that you have to remember the natural human tendency to want to work with other humans—not voicemail, e-mail, or instant messaging but actual people.
98. You might be carrying the torch for unit testing, driving test practices into the hearts of the unwashed masses of your company’s programmer pool.
99. Set your sights higher. Don’t think of yourself as a programmer at a specific company—after all, it’s not likely that you’ll be at the same place forever—but as a participating member of an industry. You are a craftsperson or an artist.
100. Our industry, like the music industry, is a big, complex web of people connecting each other. The more places you are attached to the network, the better your chances of connecting with that perfect job or career break. Limiting yourself to the company you work for places serious limits on the number of connections you can form.
101. More writing leads to more writing opportunities. And all of these lead to the opportunity to speak at conferences.
103. This entire part of the book is all about how to get both recognition and respect. Right here in this paragraph, what you need to understand is that the combination of the two is an asset worth building and guarding.
104. Imagine how much easier it would be to find a job if there were companies already relying on software you had written.
105. Although many of these contributing developers are just having fun and expressing themselves, some real incentives exist there. They are moving their way up the social chain of a community. They are building a name for themselves. They are building a reputation in the industry. They may not be doing it on purpose, but they are marketing themselves in the process.
106. If you create something really useful, you might even end up being famous. You could be famous in a small technical field—maybe famous among Rails people, for example. Or if you’re lucky, you could be really famous even outside the geek community like Linus Torvalds or…well, like Linus.
107. Equal weighting is put on each of the four categories.
108. Don’t let yourself just be the best in the bunch. Be the person and do the things that people can’t not talk about.
109. The problem is when many people in IT hear this phrase they focus on the word just. It makes them feel as if the business considers their request to be obvious, trivial, and easily accomplished.
110. So, the next time you hear that dreaded phrase, fight the urge to say “no.” Focus on the word we and confidently say, “Yes, we can add more developers to the project, but that wouldn’t be a good idea, and here’s why….” But don’t stop there. It isn’t enough just to explain your position. You need to dig deeper to find out what commercial constraints the business is operating under.
111. This part will show you how to avoid becoming a one-hit wonder.
112. Carve out weekly time to investigate the bleeding edge. Make room for at least two hours each week in order to research new technologies and to start to develop skills in them.
113. Don’t try to settle into the identity of a programmer. Or a designer. Or a tester.
114. You might not even change your actual work output, but you’ll see your work differently.
115. We’re so centered on the outcome that we forget to look at the scenery.
116. What most of us fail to realize is that the path is the end.
117. Focusing on the ending makes you forget to make the process good.
118. The next time you have to do a task like this, see whether you can find a way to focus on the task as you do it instead of anxiously rushing to finish it.
119. If Microsoft had considered Windows 3.1 done, we’d all be using Macintoshes right now. If the Apache developers had considered their web server done when they reached 1.0, they might not be overwhelmingly leading the market right now.
120. You’ll notice the same phenomenon with your career. Actually, you won’t notice it. That’s the problem. You might look at yourself in the metaphorical mirror each day and not see an ounce of change. You seem as well adjusted as before. You seem as competitive as before. Your skills seem to be as up-to-date as before.
121. Know your enemy—Pick the technology you hate most, and do a project in it. Developers tend to stratify themselves into competing camps. The .NET people hate J2EE, and the J2EE people hate .NET. The UNIX people hate Windows, and the Windows people hate UNIX.
122. The larger and more complex a project is, the less likely it is possible to imagine every feature in detail well enough to create a specification.
123. In theory, the idea of detailed planning and rigor sounds obviously right. But in practice, it does not work.
124. Set big goals, but make constant corrections along the way. Learn from the experience, and change the goals as you go. Ultimately, a happy customer is what we all want (especially when, as we plan our careers, we are our own customers)—not a completed requirement.
125. it’s possible to be enthusiastic about taking real, tangible steps toward a distant goal.
126. You might not be able to see a noticeable difference in the whole with each incremental change, though. When you’re trying to become more respected in your workplace or be healthier, the individual improvements you make each day often won’t lead directly to tangible results.
127. If every day you do a little better than yesterday toward improving yourself, you’ll find that the otherwise ocean-sized proposition of building a remarkable career becomes more tractable.
128. In this way, a big company makes a wonderful place to go and semi-retire for a while if you’re burned out. But if you’re striving to be remarkable (which you are!), a big company is a hard place to find the right groove in the same way a bakery is a bad place to try to work off your love handles. The solution? Go independent!
二 初读感受
一百多句摘抄，可以说每一句都给我很深的感触。第一遍扫下来有几点印象最深刻。
2.1 Business Knowledge
如果能早读到这本书我估计之前做项目的时候我的关注点，看问题的角度都会不同。大多数时候的我都停留在解决技术问题的快感，忽略了于客户的沟通，没有把握住真正的需求。和人沟通的技能没有得到较大提高，还有项目的管控，方法论等等。就像Oliver说的，我是一个decent developer，not a consultant。今后做项目我要试着把注意力放在人的方面，business请我们来是解决他们的业务问题，不是让我们来玩技术的。很多技术上很难的问题其实在业务上都可以变通的解决。比如上次在新希望项目上，杨经理找Ray想要BW把ERP的一个难搞的程序接下来，那Ray的说法是我们可以做，但是现在没有时间做，另外这个太detail，要做也是放在后面做。
所以接下来我的一个目标就是读完《MBA十日读:美国著名商学院课程精要(第3版)》，在2014年内能看懂财报。
2.2 方法论
刚进公司的时候又一个IDEA方法论的培训，觉得很扯淡。现在感觉又有所不同，方法论其实就是如何做一件事情前人经验的总结，对做项目而言至关重要。有了这个东西你知道现在项目的状况是什么，我们现在在哪里，如果想成为项目经理或者做事情有章法的人看看方法论对你肯定有提高。
接下来我会对做项目的项目节点格外关注，另外复习下IDEA方法论。
2.3 做更好的自己
这部分我觉得写的比7 Habits更具体一些，还是没逃离7 Habits那些东西。用我自己的话概括就是不要偷懒，不要给自己设定任何限制。自然会越来越强，心灵的肌肉不要给自己设限制，到一定年纪可以和普通人拉开不小的距离。
有关键情节透露
- 作者: Chad Fowler
- 出版: Pragmatic Bookshelf
- 定价: USD 23.95
- 装帧: Paperback
- 页数: 232
- 时间: 2009-6-7