These tips come from a book that I finished reading yesterday. Its name is The Pragmatic Programmers: From Journeyman to master. It's very good for actually is a developer.

Tip 1: Care about your career

Tip 2: Think about your work

Tip 3: Provide options, don't make lame excuses

Tip 4: Don't live with broken windows

Tip 5: Be a catalyst for change

Tip 6: Remember the big picture

Tip 7: Make quality a requirements issue

Tip 8: Invest regularly in your knowledge portfolio

Tip 9: Critically analyze what you read and heard

Tip 10: It's both what you say and the way you say it

Tip 11: DRY - Don't Repeat Yourself

Tip 12: Make it easy to reuse

Tip 13: Eliminate effects between unrelated things

Tip 14: There are no final decisions

Tip 15: Use Tracer Bullets to find the target

Tip 16: Prototype to learn

Tip 17: Program close to domain

Tip 18: Estimate to avoid surprises

Tip 19: Iterate the schedule with the code

Tip 20: Keep knowledge in plain text

Tip 21: Use the power of command shells

Tip 22: Use a single editor well

Tip 23: Always use Source Code Control

Tip 24: Fix the problem, not the blame

Tip 25: Don't panic

Tip 26: Select isn't broken

Tip 27: Don't assume it, prove it

Tip 28: Learn a text manipulation language

Tip 29: Write code that writes code

Tip 30: You can't write perfect software

Tip 31: Design with contracts

Tip 32: Crash early

Tip 33: If it can't happen, use assertions to ensure that it won't

Tip 34: Use exceptions for exceptional problems

Tip 35: Finish what you started

Tip 36: Minimizing coupling between modules

Tip 37: Configure, don't integrate

Tip 38: Put abstractions in code details in metadata

Tip 39: Analyze workflow to improve concurrency

Tip 40: Design using services

Tip 41: Always design for concurrency

Tip 42: Separate views from models

Tip 43: Use blackboards to coordinate workflow

Tip 44: Don't program by coincidence

Tip 45: Estimate the order of your algorithms

Tip 46: Test your estimates

Tip 47: Refactor early, refactor often

Tip 48: Design to test

Tip 49: Test your software, or your users will

Tip 50: Don't use wizard code you don't understand

Tip 51: Don't gather requirements - dig for them

Tip 52: Work with a user to think like a user

Tip 53: Abstractions live longer than details

Tip 54: Use a project glossary

Tip 55: Don't think outside the box - find the box

Tip 56: Listen to nagging doubts - start when you are ready

Tip 57: Some things are better done than described

Tip 58: Don't be a slave to formal methods

Tip 59: Expensive too do not produce best designs

Tip 60: Organize around functionality, not job functions

Tip 61: Don't use manual procedures

Tip 62: Test early. Test often. Test automatically

Tip 63: Coding ain't done 'til all the tests run

Tip 64: Use saboteurs to test your testing

Tip 65: Test state coverage, not code coverage

Tip 66: Find bugs once

Tip 67: Treat english as just another programming language

Tip 68: Build documentation in, don't bolt it on

Tip 69: Gently exceed your users expectations

Tip 70: Sign your work

Later I will talk about these topics detailedly.

[]'s