"The pragmatic programmer" book has all these tips highlighted and are mentioned in Quick Reference Guide.
- Care About Your Craft
Why spend your life developing software unless you care about doing it well? - Think About Your Work
Turn off the autopilot and take control. Constantly critique and appraise your work. - Provide Options, Don,t Make Lame Excuses
Instead of excuses, provide options. Don't say it can't be done: explain what can be done. - Don't Live With Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them. - Be a Catalyst for Change
You can't force change on people. Instead, show them how the future might be and help them participate in creating it. - Remember the big picture
Don't get so engrossed in the details, that you forget to check what's happening around you. - Make quality a requirement issues
Involve your users in determining the project's real quality requirements. - Invest regularly in your knowledge portfolio
Make a learning habit. - Critically analyze what you read and hear
Don't be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project. - It is both what you say and the way you say it
There is no point in having great ideas if you do not communicate them effectively. - DRY-Don't Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. - Make it easy to reuse
If it's easy to reuse, people will. Create an environment that supports reuse. - Eliminate effects between unrelated things
Design components that are self-contained, independent, and have a single well-defined purpose. - There are no final decisions
No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change. - Use tracer bullets to find the target
Tracer bullets let you home in on your target by trying things and seeing how close they land. - Prototype to learn
Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons. you learn. - Program close to the problem domain
Design and code in your user's language - Estimate to avoid surprises
Estimate before you start. You'll spot potential problems up front. - Iterate the schedule with the code
Use the experience you gain as you implement to refine the project time scales. - Keep knowledge in plain text
Plain text won't become obsolete. It helps leverage your work and simplified debugging and testing. - Use the power of command shells
Use the shell when graphical user interfaces don't cut it. - Use a single editor well
The editor should be an extension of your hand: make sure your editor is configurable, extensible, and programmable. - Always use source code control
Source code control is the time machine for your work - you can go back. - Fix the problem, not the blame
It doesn't really matter whether the bug is your fault or someone else's -- it is still your problem and you still need to fix it. - Don't panic when debugging
Take a deep breath and Think! about what could be causing the bug. - "select" Isn't broken
It is rare to find the bug in the OS or the compiler or even the third-party product or library. The bug is most likely in the application. - Don't assume it, prove it
Prove your assumption in the real environment -- with real data and boundary conditions.
- Learn a text manipulation language
You spend a large part of each day working with text. Why not have the computer do some of it for you? - Write code that writes code
Code generators increase your productivity and help avoid duplication. - You can't write perfect software
Software can't be perfect. Protect your code and users from the inevitable errors. - Design with contracts
Use contracts to document and verify that code does no more and no less than it claims to do. - Crash early
A dead problem normally does a lot less damage than a crippled one. - Use assertions to prevent the impossible
Assertions validate your assumptions. Use them to protect your code from an uncertain world. - Use exceptions for exceptional problem
Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things. - Finish what you start
Where possible, the routine or object that allocates a resource should be responsible for deallocating it. - Minimize coupling between modules
Avoid coupling by writing "shy code" and applying the Law of Demeter. - Configure, don't integrate
Implement technology choices for an application as configuration options, not through integration or engineering. - Put abstractions in code, details in metadata
Program for the general case, and put the specifics outside the compiled codebase. - Analyze workflow to improve concurrency
Exploit concurrency in your user's workflow. - Design using services
Design in terms of services -- independent, concurrent objects behind well-defined, consistent interfaces.
- Always design for concurrency
Allow for concurrency, and you'll design cleaner interfaces with fewer assumptions. - Separate views from models
Gain flexibility at a low cost by designing your application in terms of model and views. - Use blackboards to coordinate workflow
Use blackboards to coordinate disparate facts and agendas, while maintaining independence and isolation among participants. - Don't program by coincidence
Rely only on reliable things. Be aware of accidental complexity, and don't confuse a happy coincidence with a purposeful plan. - Estimate the order of your algorithms
Get a feel for how long things are likely to take before you write code. - Test your estimates
Mathematical analysis of algorithm doesn't tell you everything, try timing your code in its target environment. - Refactor early, refactor often
Just as you might weed and rearrange garden, rewrite, rework, and re-acrchitect code when it needs it. Fix the root of the problem. - Design to test
Start thinking about testing before you write a line of code. - Test your software, or users will
It's the best way to gain insight into how the system will really be used. - Don't use wizard code you don't understand
Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project. - Don't gather requirements-Dig for them
Requirements rarely lie on the surface. They are buried deep beneath layers of assumptions, misconceptions, and politics. - Work with the user to think like s user
It's the best way to gain insight into how the system will really be used. - Abstraction lives longer than details
Invest in the abstraction, not in the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies. - Use a project glossary
Create and maintain a single source of all the specific terms and vocabulary for a project. - Don't think outside the box, find the box
When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done this way? Does it have to be done at all?" - Start when you are ready
You have been building experience all your life. Do not ignore niggling doubts. - Some things are better done than described
Do not fall into the specification spiral -- at some point, you need to start coding. - Don't be a slave to formal methods
Don't blindly adopt any technique without putting it into the context of your development practices and capabilities. - Costly tools don't produce better designs
Beware of vendor hype, industry domain, and the aura of the price tag. Judge tools on their merits. - Organize teams around functionality
Do not separate designers from coders, testers from data modelers. Build the team the way you build code. - Don't use manual procedures
A shell script or batch file will execute the same instructions, in the same order, time after time. - Test early, test often, test automatically
Tests that run with every build are much more effective than test plans that sit on a shelf. - Coding ain't run till all the test done
You can not claim that the code is usable until it passes all of the available tests. - Use saboteurs to test your testing
Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them. - Test state coverage, not code coverage
Identify and test significant program states. Just testing lines of code is not enough. - Find bugs once
Once a human tester finds a bug. It should be the last time a human tester finds that bug. Automatic tests should check for it from them on. - English is just a programming language
Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on. - Build documentation in, don't bolt it on
Documentation created separately from code is less likely to be correct and up to date. - Gently exceed your users' expectations
Come to understand your user's expectations, then deliver just that little bit more. - Sign your work
Craftsmen of an earlier age were proud to sign their work. You should be, too.
