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

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

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