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 :)