Download to read offline
Programming the Programmer
- 1. P r io r i t i z e Demos Design Unlearn Integrate Requirements I m p l e m e n t a t i o n Data modelling Learn UX Manage Time Black box Reviews Code comments Estimate Prototyping Prioritize Refactoring Kick off W h i t e b o x Build Coding Deploy
- 2. programming {vipin the } programmer
- 3. v i pi n k u m a r software architect
- 4. » Pragmatic/Professional Programmer » Learn / Unlearn » Refactoring » Code Comments » Eisenhower matrix
- 6.
- 7. » responsible fortheir own career » doctors and lawyers
- 8. » responsible forthe code they write » expect QA to find bugs » do not make a mess » surgeon don’t come back and fix it later
- 9. » responsibility forthe output of the team » help one another, teach/learn from one another
- 10. » don’t toleratebig bug lists
- 11. » write codeas if you had to support it for the rest of your life » care for your code » avoid hacks » write discoverable/maintainable code
- 12. software Entropy andChange
- 13. » don’t livewith broken windows
- 14.
- 15.
- 16. » stay marketable– else become a dinosaur » take responsibility for your own education
- 17. » read books/ magazines – twitter feeds, websites, subscribe to blogs
- 18. » have amentor / virtual mentor
- 19. » know yourframeworks / libraries » teach or speak to someone » learn a new language every year – new tool
- 20. » join meetups » learn the domain to solve the business problems
- 21.
- 22. » open source » no free lunch
- 23. » be theNeo of the Matrix
- 24.
- 25. act with prudence » doing it right / doing it quick
- 26. act with prudence » technical Debt » keep track of technical debt » pay off at the earliest
- 27. before you refactor » take stock of existing code base
- 28. before you refactor » avoid rewriting everything
- 29. before you refactor » Make incremental changes
- 30. before you refactor » after each iteration, make sure existing plans pass
- 31. before you refactor » new technology is insufficient reason
- 32. » leave thecampground cleaner than you found it » little better than what you checked it out
- 33. » improve codeby removing it – less is more » keep the build clean - warnings » Simple - extra anything should be purged immediately
- 34. » think ofevery line of code as a message for someone in the future
- 35.
- 36. A theoretical puristwho believes everything he reads A battle-hardened veteran from the old school—a "real" programmer A senior programmer tired of big promises, just looking for a few practices that work A young, confident, hot-shot computer jock
- 38. effective comments »if it is hard to write, it should be hard to read » code should explain itself to the next programmer » know when not to write a comment » explain what the code is supposed to accomplish » comments that parrot the code offer nothing extra » comments should be treated as code – add value » code reviews – help identify if a comment is needed
- 39.
- 42. Routines » Doeseach routine's name describe exactly what the routine does? » Does each routine perform one well-defined task? » Is each routine's interface obvious and clear?
- 43. Data Names »Are variables used only for the purpose for which they're named? » Are loop counters given more informative names than i, j, and k? » Are well-named enumerated types used instead boolean variables? » Do naming conventions distinguish among type names, named constants, local variables, class variables, and global variables?
- 44.
- 45. the problem »infinite number of things to do » finite number of hours » want to feel good about what I am NOT doing
- 46. break up yourTODO list
- 47. two questions »is this important? » is this urgent?
- 48. What’s important? Whatpersonally you need to take care of
- 49. What’s urgent? Whatneeds to be taken care of SOON
- 50. Urgent Not Urgent Important Not Important
- 51. Urgent Not Urgent Important Not Important Do First
- 52. Urgent Not Urgent Important Not Important Schedule
- 53. Urgent Not Urgent Important Not Important Delegate
- 54. Urgent Not Urgent Important Not Important Don’t Do