20 Things every Programmer should know (Kevlin Henney)

I recently visited the W-JAX conference in Munich. Today I heard a really interesting talk about the twenty most important things every programmer should know. I’d like to share the list with you:

  • Do Lots of Deliberate Practice (Jon Jagger)

    • repeat until you master things

    • you repeat to master the task, not to complete the task

    • message: focus on mastery, not on task completion

  • Know Your Next Commit (Dan Bergh Johnsson)

    • break bigger task into smaller tasks

  • Learn to Estimate (Giovanni Asproni)

    • estimate is an approximate calculation and therefore can not be to precise

    • eliminate hope and feelings from the estimate

    • estimate in days, not in hours

  • Put the Mouse Down and Step Away from the Keyboard (Burk Hufnagel)

    • if you get stuck, take a step back, do somethings different and try again

  • Code Reviews (Mattias Karisson)

    • the purpose of code reviews should be to share knowledge among team members and not to blame bad code

  • Comment Only What the Code Cannot Say (Kevlin Henney)

    • don’t write apologies for bad code, just improve the code

  • Code in the Language of the Domain (Dan North)

    • choose method / variable names so that the code speaks in the language of the domain

  • Convenience Is Not an -ility (Gregor Hohpe)

    • method signature should also look nice from the outside for others to consume

  • Prefer Domain-Specific Types to Primitive Types (Einar Landre)

    • ints, lists etc. should be captured within domain-specific types

  • The Boy Scout Rule (Robert C Martin / Uncle Bob)

    • try to leave the code a little cleaner than when you found it

  • The Longevity of Interim Solutions (Klaus Marquardt)

    • quick fixes ofter live (much) longer than intended

  • The Road to Performance Is Littered with Dirty Code Bombs (Kirk Pepperdine)

    • if you have to gain performance by cleaning dirty code, the time saving gained on initial writing will be eradicated. In addition it will take much longer now.

  • Know Your Limits (Greg Colvin)

    • look out for stupid algorithms which waste much CPU time and eliminate them

  • Interprocess Communication Affects Application Response Time (Randy Stafford)

    • IPC communication often adds up to significant amounts, decreasing response time for the user

    • eliminate chit-chat protocols to eliminate unnecessary overhead

  • Testing Is the Engineering Rigor of Software Development (Neal Ford)

    • Testing in software is cheap compared to other field (e.g. construction industry), so just do it

  • Write Tests for the People (Gerard Meszaros)

    • Write tests for the person to understand your code

  • Don’t Be Cute with Your Test Data (Rod Begbie)

    • test data should be as close to production data as possible

  • Ask „What Would the User Do?“ (You Are Not the User) (Giles Colborne)

    • The best way to find out how a user thinks is to watch one

  • Read the Humanities (Keith Braithwaite)

    • Keep the background of others in mind if you communicate with them to avoid misunderstandings

  • Ubuntu Coding for Your Friends (Aslam Khan)

    • If the code of other is not good, maybe this holds true also for yours (lookup)

 Let me know any suggestions in the comments section :)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.