Merge pull request #177 from eweng/pragmatic_programmer

Pragmatic programmer

inspired/individual_notes/weng_edward.markdown

@@ -0,0 +1,104 @@
+Chapter 3
+7 skills that characterize great project managers: sense of urgency, framers, clear thinking, data driven, decisiveness, judgment, attitude
+
+Chapter 4
+You can get away with outsourcing some of the user experience design, but you can't outsource the interaction designer role, aka the person that knows your customers.
+
+Chapter 5
+Allocate 20% of your bandwidth to rewrites; if you neglect this, then engineers will likely ask for total rewrites which has proven to be disastrous
+
+Chapter 6
+A great product manager will have integrity, confidence, the right attitude and skills; he will know how to apply technology, have focus, have good time management skills; lastly, he will have good communication skills and will have the right blend between business and engineering skills.
+
+Chapter 7
+Net promoter scores, which are calculated as promoters less detractors, could be a good way to measure product manager performance.
+
+Chapter 8
+The more latitude you can give your engineers and user experience designers in coming up with the solutions to the problems you are trying to solve, the more likely they will come up with something that customers will love.
+
+Chapter 9
+Great minds are scattered in a company, but once found, can offer profound and insightful advice on how to make your products better.
+
+Chapter 10
+Managing your manager is possible but you need to be able to present the facts, separate out your opinions, and learn when you should pull them in for extra firepower.
+
+Chapter 11
+Sometimes the solution isn't to build a new product, it's to redesign the old.  Fix the checkout process or re-engineer the design of the website.
+
+Chapter 12
+As a product manager, make sure there is a shift in thinking between discovery and execution. Additional discovery late in the game can be disruptive to the release.
+
+Chapter 13
+A good set of product principles serves as the basis or foundation for inspiring product features.
+
+Chapter 14
+Preliminary cost estimates of small, medium, or large should be made at opportunity assessment time, followed by a detailed estimate that accompanies the final product spec.
+
+Chapter 15
+A charter user program is a program to find six users that will be your evangelists and help you identify kinks in the initial stages. It is a great way to get a deep insight into target customers and have a set of great reference customers by launch time.
+
+Chapter 16
+Focus groups can be bad because you might get skewed representation influenced by the most articulate or vocal attendees. Additionally, it is hard to get useful data about a product idea unless customers can actually interact with the product.
+
+Chapter 17
+Creating a persona of your target user can be helpful for determining which features should be included in which releases. Releases should be geared toward a specific persona so that you don't try to please everyone and end up pleasing no one.
+
+Chapter 18
+Instead of massive specs, consider building a high-fidelity prototype. High-fidelity prototypes often speed up the engineering process because it removes almost all ambiguity on how the product behaves.
+
+Chapter 19
+User experience design and implementation have to happen sequentially. If they are forced to run in parallel, disastrous results ensue.
+
+Chapter 20
+Have engineers in the design process so they can help the product manager and designer understand the relative costs of the various product ideas and stop dangerous situations early.
+
+Chapter 21
+Validate ideas through feasibility, usability, and value testing in order to figure out if an idea is worth pursuing before handing the spec over to the engineering team.
+
+Chapter 22
+During user testing, keep your users out of "critique mode." Misguided testers will ask for the user's opinion, but unless the user is an interaction designer, it shouldn't matter. If users knew what they really wanted, software would be a lot easier to create.
+
+Chapter 23
+When you're trying to improve an existing product, don't gather subjective feedback and chase features. Instead, focus on relentlessly pursuing your metrics by studying live use and working the numbers in the right direction.
+
+Chapter 24
+Be sensitive to change. User's need the opportunity to learn the differences in versions when they have time. Prepare for backlash if you give no warning before a major release.
+
+Chapter 25
+With every release comes issues. What is important is how quickly you can address these issues. Make sure to set up a rapid response period after a release to help fix these outstanding issues.
+
+Chapter 26
+In an Agile team, let engineering break up springs into whatever granularity they prefer. Functionality in a prototype might be finished in one sprint or many.
+
+Chapter 27
+The three main concerns with the waterfall approach is as follows: validation occurs too late in the process, changes are costly and disruptive, and it's hard to respond to the market.
+
+Chapter 28
+The typical startup approach of hiring an engineer building a prototype over the course of 6 months is flawed. Get a design team in place to turn out many version of the prototype in order to discover the winning product.
+
+Chapter 29
+Innovation can be generated through non traditional routes: 20% rule, skunk works, observation, user experience, acquisition
+
+Chapter 30
+Big companies are typically risk averse because they have the most to lose. Tailor the right approach to getting your tasks accomplished. "Most people wander around in the dark and bitch about it being dark, instead of learning where the light switches are."
+
+Chapter 31
+Connect your product to an emotion so that it can't be compared to other products of its class.
+
+Chapter 32
+Specials are dangerous because your job is to meet the needs of a broad range of customers. This is the only thing separating you from a custom software shop.
+
+Chapter 33
+Doing something big could simply mean refactoring old software or making previous products even better than they are currently.
+
+Chapter 34
+People buy and use products largely for emotional reasons. Enterprise purchases are based on fear and greed. Consumer purchases are based on personal emotions. Your real competition is someone that might be able to replicate the same emotion that customers get while using your software.
+
+Chapter 35
+Irrationals can teach you the value of your product all the way down the line because their emotions are magnified vs. the other groups of people.
+
+Chapter 36
+Sites need to be both usable as well as appealing. Companies need both user experience designers as well as interaction designers. It's difficult to find a person who can do both and even harder to find a product manager to fill these design roles.
+
+Chapter 37
+Usability is key and the number one thing to focus on. If the user experience is bad, no one is going to use your product. There is no single user. You have at least several important types of users, so consider each of their motivations for using your product.

pragmatic_programmer/individual_notes/weng_edward.markdown

@@ -0,0 +1,25 @@
+# Ed Weng - Pragmatic Programmer Ch. 1-4
+
+## Chapter 1 - A Pragmatic Philosophy
+* Keep your code clean. Technical debt has a snowball effect where a little becomes a lot really quickly.
+* Tips:
+  * Invest in your knowledge portfolio. Technology changes all the time and very rapidly, so in order to keep up, you need to constantly be reading.
+  * Be smart about presentation. Pick an opportune time to present someone with a good idea.
+
+## Chapter 2 - A Pragmatic Approach
+* There are right ways to code and wrong ways to code. By coding in the right way, you keep the maintenence of your code possible.
+* Tips:
+  * The less you code (code size), the easier it will be to change.
+  * Don't repeat yourself (DRY). When it comes time to change your strucutre, there will be fewer pieces of your program that you will need to alter.
+
+## Chapter 3 - The Basic Tools
+* People who use an IDE should try using the shell and vice versa. There are advantages to both and great power and flexibility in the shell.
+* Tips:
+  * Don't get caught up in formats that will eventually change. Make your program flexible.
+  * Debug your own code first in order to find bugs faster.
+
+## Chapter 4 - Pragmatic Paranoia
+* No software is ever perfect, but there are ways to minimize errors and their impact.
+* Tips:
+  * Refrain from using global variables and don't couple methods (don't use inter/intra module calls).
+  * Use exceptions for exceptional cases, times where there is an immediate, nonlocal transfer of control.