The Developer’s code
Hullo friends and fellow developers; i got this interesting email from a friend of mine recommending an online book for developers.
I have found this very interesting and i would like to to read it.
To read the book click HERE, or check bellow for contents.
Table of Contents
- Introduction
- Metaphor
- #1: Be wary of metaphors in web development
- #2: Plan enough, then build
- #3: Understand launch and Version 2.0
- #4: The “Ivory Tower” Architect is a myth
- #5: Specialization isn’t mandatory
- #6: Metaphors can hurt both ways
- Motivation
- #7: Motivation starts with the opportunity to build something well
- #8: Begin where you love to begin
- #9: Be imperfect
- #10: Stop programming
- #11: Test your work first thing in the morning
- #12: Don’t work in your bedroom
- #13: Don’t let bad first impressions of your work unravel you
- #14: Never underestimate the emotional value of finishing
- Productivity
- #15: Just say “no” to the pet project
- #16: Set a deadline, even if it’s arbitrary
- #17: Constrain your parameters
- #18: Cut the detail out of the timeline
- #19: Make your product better in two ways everyday
- #20: Invest in good hardware
- #21: Establish “off-time” and let your co-workers do so too
- #22: Keep a personal to-do list
- #23: Write code as a last resort
- Automation
- #24: Separate human work from robot work
- #25: Take advantage of a machine’s strengths
- #26: Think automation
- #27: Know the ingredients of a good code generator
- #28: Avoid touching generated code with bare hands
- #29: Writing a code generator makes you a better programmer
- #30: Speak, think, and write code in a ubiquitous language
- #31: Generated code makes errors obvious and small modifications powerful
- #32: Address the naysayers
- #33: Automating software is not like fast-food
- Complexity
- #34: Snuffing out bad complexity
- #35: The simplicity paradox
- #36: Complexity as a game of pick-up sticks
- #37: Complexity underneath the surface != Complexity at the surface
- #38: Hard to code might mean hard to use
- #39: Design patterns and the danger of anticipation
- #40: Programming Cadence
- Teaching
- #41: An expert coder doth not an expert teacher make
- #42: Prevent the “Curse of Knowledge” from creeping into your teaching
- #43: Teach with obvious examples
- #44: In the beginning, go for blanket statements over the truth
- #45: Encourage autonomous thought
- Clients
- #46: Difficult clients are not uniquely our problem
- #47: Teach clients what programming actually is
- #48: Define the goals of your application, seriously
- #49: Make your work interesting
- #50: Be forgiving and personable
- Pride
- We have a marketing problem
- Lessons from the cooking industry