######DeveloperUG 13 October 2015
######Paul:
###Balance Love what you do
###Communication Choose your medium - you do not write in the same style on slack/skype than how you would in a formal e-mail.
A personal call/face-to-face is in most cases better than an angry email
Is it worth dying over? Not everything is a life or death situation - compromise.
Confrontation is not about who's right, but agreeing on which path to take forward.
###Awareness We can work better together by understanding how each team member thinks, and what their goals are. And to have awareness of not only what and how you are doing what you are doing, but also _why_ you are doing it in that way.
######Mark: ###Safe refactoring Take the time to learn your tools (R#)
Smaller changes is safer than big changes but more cumbersome
Use tests as safety net
Kata to practise refactoring: Gilde Rose Kata
###Technical Debt ####4 quadrants:
####Top Left - Reckless:
"We don't have time for design"
####Top Righ - Prudent:
"We must ship now and deal with consequences"
####Bottom Left - Inadvertent :
"What is layering"
####Bottom Right - Responsible, but inexperienced:
"Now we know how we should've done it"
###Developing a Coding Mindset
Choose timeless books over technology specific books
Good books:
- Code complete 2
- Clean Code
- Soft Skills
- The Pragmatic Programmer
Learn VIM
###TDD ####RED -> GREEN -> Refactor
Tiny steps
Keep Tests Simple
Use finer granularity testing when you feel less confident, or want to be certain of crucial business logic.
Prefer State Verification to Behaviour Verification
By practising TDD Kata's, you learn to write testable code, even though not always practical in real world.
Ideas to get the most out of a Kata: Practice makes permanent, not perfect. Practicing is only effective if you do it with intent to improve.
Adding constraints to your kata helps you to improve in that area,
Examples:
- a time limit to motivate you do work quickly
- No mouse rule to motivate learning VIM & shortcuts.
- No for loops to motivate using LINQ .
- No void methods to motivate learning functional thinking.
Acceptance tests often more valuable than finely grained Unit tests.
###The Hardest thing
There are only two hard things in Computer Science: cache invalidation and naming things. - Phil Karlton
Nonsense -> Accurate -> Precise -> Meaningful
Laziness or ignorance push us towards the left end of this specturm, with dillegence we can move to the right - Joe Rainsberger
###What is legacy? Code you don't have confidence in.
Do you take pull requests from code not upto standard? Yes, if it does the job. Make sure the public API is well thought out, layerd and consistent, this will hide the "crappy" code.
Contribution is more important than perfect code
Your perfect code Today, is your crappy code in 6 months time.