KEMBAR78
12 Things Every Programmer Should Know | PDF
12 Things Every Programmer
       Should Know
      by Samnang Chhun



                         Barcamppp 2010
About Me
•   samnang.chhun@gmail.com
•   @samnangchhun
•   http://wowkhmer.com
•   Ruby and Rails Developer
•   .NET Developer (MCTS)
•   Yoolk Inc.
•   Share Vision Team Core Member
1   Be Passionate
          •   Love what you are doing
          •   Be creative
          •   Want to do it best
          •   Better than yesterday

“Programmers are a subset of creators have the
    responsibility to shape the new world”,
         @steveklabnik and @judofyr
2
Love Your Codes
    • Write codes for human, but bad
      programmers write codes for machine
    • Every programmer loves to work with
      Clean Code
3   Version Control
      •   Backup your codes
      •   Tracking changes (who, what, when)
      •   Work in parallel
      •   Commit often
      •   Never commit when your build fail
4   Read Codes
     • Before you become a good writer,
       you have to be a good reader
     • Day and day programmers working
       hours: 70% reading and 30% writing
     • Take notes on ideas or tricks of the
       author
5   Practice, Practice,
       Practice
      •   Small exercises, isolated problems
      •   Practice on outside company projects
      •   Do your best as you can(no pressure)
      •   Practice to become a master
      •   CodeKata, Pair with Me, Fixing bugs in
          an OSS that you are using
6   Refactoring
     • Improve quality of your codes, without
       changing system behavior
     • Make it easy to understand, maintain,
       and extend
     • “Always check a module in cleaner than
       when you checked it out”, Uncle Bob
     • Intension-Revealing Names, Small
       Method, Compose Method, …
7
 Follow Patterns
and Best Practices

    •   Object Oriented Design Principles
    •   SOLID
    •   GRASP
    •   DRY
    •   KISS
    •   Don’t Tell Us
    •   Design Patterns
8   TDD/BDD
    • Tests are specifications what the system
      does
    • Tests are your first user
    • Short development iteration
    • Is a design process
    • Write just enough codes to pass the
      tests
9   Automation
     • Make your manual tasks are
       automatable
     • Command line are your friend
     • Make a shortcut of your repeated tasks
     • Continuous Integration
     • Automation Deployment
Understand
10   Your Domain
     • Domain-specific won’t be outdate soon,
       but technologies will
     • “You can’t creatively help a business
       until you know how it works.” Chad
       Fowler
Continuous
11     Learning
     • You need to keep learning to stay
       marketable
     • “Be the worst,” Chad Fowler
     • Read books, blogs, Twitters feeds, and
       websites
     • Listen to podcasts
     • Sharpening your tools
Participate in
12   Communities
     • A good way to learn something is to
       teach or speak about it
     • Join or start a study group or a local
       user group for a language, technology,
       or discipline you are interested in.
     • Contribute to OSS
+1
         What I have
         leanred
     • Be Prepared To Unlearn
     • Validate assumptions about your skillset
     • Do less reading about what others are
       doing, and more doing of things that
       others may want to read about
     • Good Artists Copy, Great Artists Steal
References
Q&A

12 Things Every Programmer Should Know

  • 1.
    12 Things EveryProgrammer Should Know by Samnang Chhun Barcamppp 2010
  • 2.
    About Me • samnang.chhun@gmail.com • @samnangchhun • http://wowkhmer.com • Ruby and Rails Developer • .NET Developer (MCTS) • Yoolk Inc. • Share Vision Team Core Member
  • 3.
    1 Be Passionate • Love what you are doing • Be creative • Want to do it best • Better than yesterday “Programmers are a subset of creators have the responsibility to shape the new world”, @steveklabnik and @judofyr
  • 4.
    2 Love Your Codes • Write codes for human, but bad programmers write codes for machine • Every programmer loves to work with Clean Code
  • 5.
    3 Version Control • Backup your codes • Tracking changes (who, what, when) • Work in parallel • Commit often • Never commit when your build fail
  • 6.
    4 Read Codes • Before you become a good writer, you have to be a good reader • Day and day programmers working hours: 70% reading and 30% writing • Take notes on ideas or tricks of the author
  • 7.
    5 Practice, Practice, Practice • Small exercises, isolated problems • Practice on outside company projects • Do your best as you can(no pressure) • Practice to become a master • CodeKata, Pair with Me, Fixing bugs in an OSS that you are using
  • 8.
    6 Refactoring • Improve quality of your codes, without changing system behavior • Make it easy to understand, maintain, and extend • “Always check a module in cleaner than when you checked it out”, Uncle Bob • Intension-Revealing Names, Small Method, Compose Method, …
  • 9.
    7 Follow Patterns andBest Practices • Object Oriented Design Principles • SOLID • GRASP • DRY • KISS • Don’t Tell Us • Design Patterns
  • 10.
    8 TDD/BDD • Tests are specifications what the system does • Tests are your first user • Short development iteration • Is a design process • Write just enough codes to pass the tests
  • 11.
    9 Automation • Make your manual tasks are automatable • Command line are your friend • Make a shortcut of your repeated tasks • Continuous Integration • Automation Deployment
  • 12.
    Understand 10 Your Domain • Domain-specific won’t be outdate soon, but technologies will • “You can’t creatively help a business until you know how it works.” Chad Fowler
  • 13.
    Continuous 11 Learning • You need to keep learning to stay marketable • “Be the worst,” Chad Fowler • Read books, blogs, Twitters feeds, and websites • Listen to podcasts • Sharpening your tools
  • 14.
    Participate in 12 Communities • A good way to learn something is to teach or speak about it • Join or start a study group or a local user group for a language, technology, or discipline you are interested in. • Contribute to OSS
  • 15.
    +1 What I have leanred • Be Prepared To Unlearn • Validate assumptions about your skillset • Do less reading about what others are doing, and more doing of things that others may want to read about • Good Artists Copy, Great Artists Steal
  • 16.
  • 17.