Pragmatic programmer
- 2. Early/fast adapter Inquisitive How does offline data collection work? What is underlying architecture of SWEP? Critical thinker Why rebase and why not merge? Jack of all trades Care about your craft Think! About your work Never run on auto-pilot What makes a Pragmatic Programmer
- 3. The Cat Ate My Source Code The greatest of all weaknesses is the fear of appearing weak Take responsibility Be accountable for your responsibility Be proud of your abilities but be honest about your shortcomings – your ignorance as well as your mistakes Do your personal best and also analyze the situation for risks that are beyond your control Don’t blame someone or something else, or make up an excuse
- 4. Provide Options, Don’t make lame excuses I have been trying for 10 mins but no one picked the phone Oh sorry… I was on another call Xyz is not under me. Pls call the station near u Fire broke out in my house at XYZ location. Pls send urgent help But my shift has ended. Pls call after some time I am already in trouble and don’t have the number. Pls send urgent help.
- 5. Provide Options, Don’t make lame excuses Product is in bad shape, we should implement TDD I permit additional time for writing test cases Refactor the methods Ohh.. the methods are so huge, this is not possible Use DBUnit Nope. TDD is not suitable for this product. It involves a lot of DB We are already missing deadlines, this will be an overhead
- 6. Software Entropy(Software rot) Most important reason is the psychology, or culture at work Broken Window Theory – crack down on small stuff in order to keep out the big stuff One broken window – a badly designed piece of code, a poor management decision that team must live with, a poor piece of code is all it takes to start the decline Remember the Stone Soup story
- 8. Solumina – A Stone Soup Onion & Carrot - Agile methodology Sliced Potatoes - TDD Salt & Pepper – All the technological upgradation Cabbage suggested by the old lady – Just a matter of time for all of us to actively contribute Be a Catalyst for Change
- 9. Learning – A continuous & ongoing process An investment in knowledge always pays the best interest – Benjamin Franklin Steps to build your Knowledge (Investment) Portfolio Invest Regularly Diversify – Do not put all eggs in one basket Balance portfolio between conservative & high-risk, high reward Buy low, sell high Review and rebalance
- 10. Some suggestions… Goals to set for yourself Learn a new language every year Read a book each quarter Read nontechnical books, too Take classes Participate in local user groups Experiment with different environments Stay current Get wired
- 11. Communicate It is better to be looked over than to be overlooked Ideas to help communicate Know what you want to say Know your audience Choose your moment Choose a style Make it look good Involve your audience Be a listener Get back to people
- 12. Pragmatic Approach Avoid Duplication Orthogonality Reversibility
- 13. How Does Duplication Arise??? Imposed duplication Inadvertent duplication Impatient duplication Interdeveloper duplication
- 14. Imposed duplication Multiple representations of information Documentation in code Documentation and code Language issues
- 19. Interdeveloper duplication Audit for Y2K compliance found 10,000 programs, each containing its own version of SSN validation Have well-understood division of responsibilities within the design Encourage active and frequent communication between developers Setup newsgroups to allow developers to exchange ideas and ask questions Have a central place in source tree where utility routines and scripts can be deposited Read other people’s source code and documentation Finally, foster an environment where it’s easier to find and reuse existing stuff.
- 20. Orthogonality (Decoupling) Eliminate effects between unrelated things Increased productivity and reduced risk Isolates diseased sections of code Easier to test
- 21. Orthogonal Project Teams Teams organized with lots of overlap and members confused about responsibilities Every change needs a meeting of entire team Each major infrastructure (database, communications interface, middleware layer, etc.) to have its own subteam The larger the number of people involved in discussing each change required, the less orthogonal the group
- 23. Orthogonal Coding Keep your code decoupled Avoid global data Avoid similar functions
- 24. Orthogonal Testing If it is difficult to write unit test for a module, it is not orthogonal Ideal system is where unit tests are performed automatically with each build If you have to drag in a large percentage of rest of the system to get a test to compile, the module is not well decoupled. You must refactor and decrease the coupling If fixing a bug in one part of code causes mysterious issues in some other part Tag bug fixes when you commit the code. Run reports analyzing trends in number of source files affected by each fix.
- 25. Orthogonal Documentation The axes for documentation are content and presentation You should be able to change appearance dramatically without changing the content
- 27. Which will lead to a more orthogonal design: modeless or modal dialog boxes
- 28. Reversibility Nothing is more dangerous than an idea if it’s the only one you have Requirements, users and hardware change faster than we can get software developed There are no final decisions It is possible to change a stand alone system into client-server system and vice- versa with few configuration changes. Hide a third-party product behind well-defined, abstract interface. It makes it easier to replace that library.