Pragmatic programmer - what I've learned

What I learned from:

Most things in this book is way beyond what CS students learn. At the same time these things are absolutely essential to become a programmer. This is good for self-tought programmers: we have a chance ;)

• Do care about your work quality
• Think about you work, how and why you do things
• Individual mastery does metter
• Think Kaizen, little steps towards perfection

Pragmatic philosophy

• Never say 'impossible' - find solutions. Responsibility instead of excuses.
• Poor excuses and lies are unprofessional
• One broken window (smelly code) dooms and destroys stronges projects
• Small, carlesly accepted scope changes lead to huge project failure.
• You don't have to be perfect, you just need to be good enough.

Your assets

• The best investment is always the knowledge
• Knowledge depreciates with time. Fast.
• Invest regularly. Read about your craft. Learn programming languages. My advice: start with lisp.
• Stay in touch with other programmers and exchange views, knowledghe and code
• If you don't know or understand something that just came up, do check it. Use every excuse to learn something new.

Approach to programming

• DRY: don't repeat yourself. My comment: be lazy and automate or generate everything
• Copy&paste is a sign to start thinking
• Make your code easy to reuse but don't try to predict
• Orthogonality. Get rid of links between unrelated modules or badly defined relationships
• Expect orthogonality in project roles. If multiple people do simmilar tasks, those tasks are never done properly. My comment: Fuzzy responsibility is always a warning sign for a professional.
• Be ready for a change in code (this is now called Agile Programming) or architecture. This is where you need to cunningly predict and overestimate a little.
• Develop a system so that progress is easly visible. Ask for feedback early and often. My comment: If you are forced to develop and present whole system at once (waterfall) - you know managers are incompetent. Run!
• DSLs - invent your own vocabulary. My comment: use monads and have every method return something (preferably this/self)

Estimating and harmonograms

• Use adequate measure - if it takes 17 days, say 3 weeks.
• Write down your estimates and compare to what happened. Take notes.
• Harmonogram is always changing - do not let anyone force any date on you, unless no scope changes are possible. Watch out for managers that promise "no more changes" and later the same day ask for new features. Stop delivering any estimates to them. Try not to work with such people.

Toolbox

• Descriptive variable names, natural language as values even when sending/storing data, text files as data source -> these are good things always and everywhere.
• Use Linux and know your shell
• Learn to use powerful text editor. My comment: Vim or Emacs. Eclipse only wastes your time. As for me, touch typing, knowing shell and mastering text editor are crucial programmers skills
• Master text processing in python, perl, sed or awk. My comment: definately python
• Understand what RTFM means. Learn newsgroups culture (now sadly extinct). Try saving other people time.

Fixing bugs

• Don't panic. My comment: Chad Fowler says that professionals never panick.
• Start with your code, assume you are the one to blame. No, that's not JVM bug. That's your bug.
• Proove your theories by provoking a crash. Do not assume, make it crash.

Programming techniques

• Have contracts in your code. My comment: basically try to have preprocessor or compiler warn you about changes in outer code. Ignore orthogonality here - you can delete uneeded contracts if decoupling/reusing.
• Throw runtime execeptions (and let them fly)
• Use asserts, especially in production code
• Minimalise connections/bindings between modules
• Use metadata to change local, specific behaviour

Coding

• Accidential coding, programming by luck, "I don't know why this works" <- don't do this
• Understand whole project and all used concepts
• Do refactor code. My comment: never ask for permission, instead ask for forgiveness when caught refactoring
• Do not use manual procedures. My comment: manual (step by step with printed instructions) procedures do not work. If it cannot be automated to a script, real person will make a mistake
• Make sure that bug once found, never again happends

Pragmatic projects

• Test your work before end users do
• Slightly exceed expectations every time
• Sign your work, be proud of your mastery

This book is a corner stone and a basic requirement to be any good in programming industry.