1. Development
1.1. Coding Professionalism
1.1.1. Your code must work
1.1.1.1. Never write 3am code: It's crap even if it works, and that crap will be copied and pasted everywhere
1.1.1.2. Never write code when distracted with personal thoughts
1.1.1.2.1. Same analogy for driving, driving needs your focus, don't drive when distracted
1.1.1.2.2. Learn how to manage your time with those problems. Spend some blocks of time throughout the day working on both to ease your mind and allow you to code
1.1.1.3. Avoid the 'zone'
1.1.1.3.1. True the zone will allow you to write more code however that's not an indicator your more productive
1.1.1.3.2. The zone causes tunnel vision and causes you to lose sight of the big picture
1.1.1.3.3. Pair programming makes it near impossible to enter the zone
1.1.1.3.4. Avoid listening to music and headphones - this doesn't usually help you code, it helps you stay in the zone which is undesired
1.1.1.3.5. The zone causes you to be rude to interruptions - extremely unprofessional to be rude
1.1.1.4. Writers Block
1.1.1.4.1. Pair Program
1.1.1.5. Reduce debugging time to a minimum
1.1.1.5.1. Do this with TDD
1.1.1.5.2. Layers constantly retrying cases, surgeons re-opening up patients are unprofessional
1.1.1.6. No False Delivery
1.1.1.6.1. Worst unprofessionalism of all
1.1.2. Your code must solve the problem set for you by the customer
1.1.2.1. Not the requirements given, it is up to you to negotiate with the customer the true solution to their problem
1.1.3. Your code needs to follow solid engineering principles
1.1.4. Your code must be readable by other programmers (clean code)
1.1.5. Help
1.1.5.1. Help Others
1.1.5.1.1. your responsibility to be available to help each other
1.1.5.1.2. unprofessional to sequester yourself in a cubicle and refuse the queries of others
1.1.5.1.3. If needed - set office hours
1.1.5.1.4. Offer to help, don't wait to be asked
1.1.5.2. Accept Help
1.1.5.3. Mentor junior developers personally
1.2. Test Driven Development
1.2.1. It just works!
1.2.1.1. Surgeons don't have to defend hand-washing
1.2.1.1.1. Developers don't have to defend TDD
1.2.2. 3 Laws
1.2.2.1. You are not allowed to write any production code until you have first written a failing unit test
1.2.2.2. You are not allowed to write more of a unit test than is sufficient to fail -- and not compiling is failing.
1.2.2.3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test
1.2.3. Benefits
1.2.3.1. Certainty
1.2.3.1.1. tens of unit tests written a day makes me certain the code works when I wrote it and still works today
1.2.3.2. Defect Injection Rate
1.2.3.2.1. Proven to reduce the amount of bugs dramatically
1.2.3.3. Courage
1.2.3.3.1. Bad code is scary to fix without unit tests so often it doesn't get fixed
1.2.3.3.2. When developers lose their fear of cleaning, they clean
1.2.3.4. Documentation
1.2.3.4.1. Each unit test defines how the system should be used
1.2.3.4.2. Implicit, constantly updating, constantly added documentation
1.2.3.5. Design
1.2.3.5.1. Following the laws forces you to be able to test your code
1.2.3.5.2. If tests are written after the code is written, it's written defensively and will force the implementation to work
1.2.4. TDD is NOT
1.2.4.1. Religion
1.2.4.2. Magic Formula
1.2.4.3. Does not guarantee the benefits and you can still write bad code with it
1.2.4.3.1. You can even write bad tests
1.2.4.4. Always be practical or appropriate
1.2.4.4.1. professionals should never follow a discipline when that discipline does more harm than good
1.3. Practicing
1.3.1. Kata
1.3.1.1. a precise set of choreographed movements that stimulates one side of a combat
1.3.1.1.1. Attempt to practice so much to reach perfection
1.3.1.2. Practicing over and over how to solve a particular problem
1.3.1.2.1. You already know the solution, but practicing the problem solving motions of TDD is the goal
1.3.1.3. Examples
1.3.1.3.1. The Bowling Game
1.3.1.3.2. Integer Square Root
1.3.1.3.3. Prime Factors
1.3.1.3.4. Word Wrap
1.3.2. Wasa
1.3.2.1. Two-man kata
1.3.2.1.1. Ping-pong pair programming pattern
1.3.2.1.2. When you both really know the kata
1.3.2.2. Switch it up and add constraints in the tests
1.3.2.2.1. speed & memory
1.3.2.2.2. Make it competitive and fun
1.3.3. Randori
1.3.3.1. free-form combat
1.3.3.2. Wasa with more than 2 people
1.3.3.2.1. People rotate through while the code is projected on the wall
1.3.3.2.2. Can go in order, people can skip, move around, etc no specific rules just with more people
1.3.4. Broaden Your Experience
1.3.4.1. Open Source projects
1.3.4.2. Practice on your own time, its not your employers responsibility to keep you sharp
1.4. Acceptance Testing
1.4.1. Premature Precesion
1.4.1.1. Business wants to know exactly what they are going to get, programmers want to know exactly what they are supposed to deliver
1.4.1.1.1. Both want a precision that simply cannot be achieved
1.4.1.2. Uncertainty principle
1.4.1.2.1. requirements when implemented often aren't really what is desired in the end
1.4.1.3. Estimation anxiety
1.4.1.4. Late Ambiguity
1.4.2. Automated
1.4.2.1. Always
1.4.2.1.1. why?
1.4.3. Who writes them?
1.4.3.1. Ideally - stakeholders and QA
1.4.3.2. realistically - business analysts and QA
1.4.3.2.1. analysts test happy paths
1.4.3.2.2. QA tests unhappy paths
1.4.3.3. If developers are forced to write them
1.4.3.3.1. Should not be the same developer who implemented it
1.4.4. When to write?
1.4.4.1. Should be written before the implementation begins
1.4.4.2. Mid-sprint should have all the acceptance tests written and failing
1.4.5. Negotiate
1.4.5.1. It is your professional responsibility to negotiate with whom has written the test and make a better test when necessary
1.4.5.2. NEVER be passive-aggressive
1.4.5.3. Example:
1.4.5.3.1. X has to run in under 2 seconds
1.4.5.3.2. Negotiate on average 2 seconds
1.4.5.3.3. "not what requirements say"
1.4.5.3.4. realistically though it's the only way
1.4.5.3.5. run test 15 times and average is less than 2 seconds
1.4.6. NOT unit tests
1.4.6.1. not redundant
1.4.6.1.1. test things very differently
1.5. Testing Strategies
1.5.1. QA
1.5.1.1. Should never find any bugs
1.5.1.1.1. But probably still will
1.5.1.2. Should be a part of the team
1.5.2. Test Automation Pyramid (coverage %)
1.5.2.1. 5% Manual Exploratory
1.5.2.1.1. NOT automated, nor scripted
1.5.2.1.2. NOT written test plan of this kind of testing
1.5.2.1.3. Some teams will have a specialist do this, others will declare a day or two of 'bug hunting' to bang on the system
1.5.2.2. 10% System tests
1.5.2.2.1. Ultimate integration tests across the entire system
1.5.2.2.2. NOT test business rules
1.5.2.2.3. written by system architects and technical leads
1.5.2.3. 20% integration tests
1.5.2.3.1. choreography tests - how well the assembly of components dances together
1.5.2.3.2. NOT test business rules
1.5.2.3.3. Written by system architects or lead designers of the system
1.5.2.3.4. typically not executed as part of CI
1.5.2.4. 50% component tests
1.5.2.4.1. Acceptance tests of specific components
1.5.2.4.2. Written by QA and business with assistance from development
1.5.2.4.3. apart of continuous integration suite
1.5.2.5. 100% unit tests
1.5.2.5.1. written by programmers for programmers
1.5.2.5.2. as close to 100%, generally in the 90s of true coverage
1.5.2.6. Image
1.6. Collaboration
1.6.1. With Employers
1.6.1.1. First responsibility is to meet the needs of your employer
1.6.1.2. understand business goals
1.6.1.2.1. collaborate with managers, business analysts, testers and other team members to understand
1.6.1.2.2. understand the business and keep it afloat
1.6.2. With Programmers
1.6.2.1. owned code
1.6.2.1.1. Programmers should never own a piece of code
1.6.2.2. Collective Ownership
1.6.2.2.1. Break down all walls of code ownership and have the team own the code
1.6.2.3. Pairing
1.6.2.3.1. Many programmeres dislike the idea
1.6.2.3.2. clearly the most efficient way to solve the problem
1.6.2.3.3. Professionals Pair
1.6.3. Cerebellums
1.6.3.1. Need to be close to team members
1.6.3.1.1. need to hear frustrated mutters, serendipitous communication
1.6.3.2. Need to communicate as a unit
1.6.3.3. Some may work better alone for just themselves but that doesn't mean the team works better when you work alone
1.6.3.3.1. And its unlikely you work better when you work alone
2. Behavioral Professionalism
2.1. Professionalism
2.1.1. Do no harm
2.1.1.1. Don't lookout for yourself, lookout for the project and the customers
2.1.1.2. We must not create bugs
2.1.1.2.1. Impossible?
2.1.1.2.2. QA Should Find Nothing!
2.1.1.2.3. All code should be covered with automated unit tests
2.1.1.3. Delivering function at the expense of structure is a fool's errand
2.1.1.3.1. You must be able to make changes without exorbitant costs
2.1.1.3.2. Merciless refactoring
2.1.2. Work Ethic
2.1.2.1. 168 Hours per week
2.1.2.1.1. 40 hours to solve your employers problems
2.1.2.1.2. 20 hours on your career
2.1.2.1.3. 56 hours for sleep
2.1.2.1.4. 52 hours for everything else
2.1.2.2. Minimal list Software Professional should be conversant with
2.1.2.2.1. Design patterns
2.1.2.2.2. Design principles
2.1.2.2.3. Methods
2.1.2.2.4. Disciplines
2.1.2.2.5. Artificats
2.1.2.3. Continuous Learning
2.1.2.4. Practice
2.1.2.4.1. Kata
2.1.2.5. Mentoring
2.1.2.6. Know your domain
2.1.2.6.1. Read a couple books on the new topic
2.1.2.6.2. Spend some time with the experts and try to understand their principles and values
2.1.2.7. Identify with your employer
2.2. Saying No
2.2.1. Professionals speak truth to power, and have the courage to say no to their managers
2.2.2. Being a Team Player
2.2.2.1. Telling the truth, committing to realistic estimates and not backing down is best for everyone
2.2.2.1.1. Don't allow anyone to lie to try to make the team sound better, its not beneficial to anyone, the project, the company or the customer
2.2.3. Trying
2.2.3.1. Admitting you can try harder implies you have not been trying hard
2.2.3.1.1. It applies you and your team to a new commitment that no one really thinks is plausible
2.2.3.2. Don't accept you need to try to meet a date that is not agreed upon by the team
2.2.3.2.1. A professional is already trying, there is no magic pixie dust to make us work better on demand
2.2.3.2.2. Say no to trying
2.2.3.3. Response: I could try to levitate, but I promise you I won't
2.2.3.3.1. I could try to change lead in to gold
2.2.3.4. Don't stop by washing your hands and saying no
2.2.3.4.1. If your boss is not taking 'no' seriously, make it clear his/her boss needs to be told the truth, or you will tell them
2.3. Saying Yes
2.3.1. Language of Commitment
2.3.1.1. Making a Commitment
2.3.1.1.1. Say you'll do it
2.3.1.1.2. Mean it
2.3.1.1.3. Actually do it
2.3.1.2. Most communicated commitments are never real commitments
2.3.1.2.1. "Yeah, we really need to get some new routers"
2.3.1.2.2. Ask a team members to run tests -> "Sure. I hope to get to it by the end of the day"
2.3.1.2.3. Management to the team -> "We have to move faster"
2.3.1.3. Recognizing Lack of Commitment
2.3.1.3.1. Signs of non commitment
2.3.1.4. How to Commit
2.3.1.4.1. "I will... by..."
2.3.1.4.2. Bad Excuses
2.3.1.4.3. Don't allow vagueness
2.4. Time Management
2.4.1. Meetings
2.4.1.1. Truths
2.4.1.1.1. Necessary
2.4.1.1.2. Huge Time Wasters
2.4.1.1.3. ~$200/hr/attendee
2.4.1.2. Declining
2.4.1.2.1. need to use your time wisely
2.4.1.2.2. don't accept meetings unless it is a meeting for which your participation is immediately and significantly necessary to the job your doing now
2.4.1.2.3. Your management should help keep you out of unnecessary meetings
2.4.1.3. Leaving
2.4.1.3.1. When the meeting gets boring, leave
2.4.1.3.2. remaining in a meeting that has become a waste of time for you and you can no longer significantly contribute is unprofessional
2.4.1.4. Have an Agenda and a Goal
2.4.1.4.1. When invited, try to get the details of agenda and how much time is alloted for them
2.4.1.4.2. When meeting gets side tracked ask the new topic be tabled and the agenda be followed
2.4.2. Arguments/Disagreements
2.4.2.1. Data is the best way to argue, not relentless arguing
2.4.2.1.1. Run experiments or do some simulation or modeling
2.4.2.2. Sometimes flipping a coin is best
2.4.2.2.1. If one path works out great, otherwise you can go down the other path
2.4.2.2.2. Pick a time frame in which to decide if path's need to change
2.4.2.3. Passive aggressive behavior is unprofessional
2.4.2.3.1. 'This is how he wants it so this is how he will get it'
2.4.2.4. If an argument must truly be settled, ask each of the arguers to present their case to the team in 5 minutes
2.4.2.4.1. have the team vote
2.4.3. Focus-Mana
2.4.3.1. Good nights sleep
2.4.3.2. Moderate caffeine
2.4.3.3. Recharging
2.4.3.3.1. long walk
2.4.3.3.2. conversation w/ friends
2.4.3.3.3. meditate
2.4.3.3.4. power nap
2.4.3.3.5. listen to podcast
2.4.3.4. Muscle focus
2.4.3.4.1. bike riding
2.4.3.4.2. carpentry
2.4.3.4.3. building models
2.4.3.4.4. gardening
2.4.4. Pomodoro Technique
2.4.4.1. 25 minute timer
2.4.4.1.1. politely decline all interruptions to get back to them within 25 min
2.4.5. Avoidance
2.4.5.1. Priority Inversion
2.4.5.1.1. Convincing yourself something else is more important to avoid doing the real work
2.4.5.1.2. Unprofessional - Don't do!
2.4.6. Blind Alleys
2.4.6.1. technical pathways that will lead no where
2.4.6.2. The Rule of Holes: When you are in one, stop digging
2.5. Estimation
2.5.1. What Is an Estimate?
2.5.1.1. Business sees them as Commitment
2.5.1.1.1. Commitment
2.5.1.2. Developers sees them as Guesses
2.5.1.2.1. Estimate
2.5.1.3. A Guess
2.5.1.3.1. no commitment is implied
2.5.1.3.2. Missing an estimate is not dishonorable
2.5.1.3.3. An Estimate is a probability distribution
2.5.2. Program Evaluation and Review Technique
2.5.2.1. PERT
2.5.2.1.1. Trivariate analysis
2.5.2.1.2. Expected duration
2.5.2.1.3. Standard deviation
2.5.2.1.4. Example
2.5.2.1.5. Sequence Calculations
2.5.3. Wideband Delphi
2.5.3.1. Team of people assemble, discuss a task, estimate the task, and iterate the discussion and estimation until they reach agreement
2.5.3.1.1. Flying Fingers
2.5.3.1.2. Planning Poker
2.5.3.1.3. Affinity Estimation
2.5.3.1.4. Trivariate Estimates
2.5.4. Law of large numbers
2.5.4.1. break up tasks into smaller tasks and estimate them independently
2.6. Pressure
2.6.1. analogy
2.6.1.1. Don't want your surgeon to stop best practices while under 'dead'lines
2.6.2. Avoid Pressures
2.6.2.1. Commitments
2.6.2.1.1. avoid committing to deadlines we can't meet
2.6.2.1.2. help the business meet goals set by others but don't take ownership of the commitment
2.6.2.2. Stay Clean
2.6.2.2.1. "quick and dirty" is an oxymoron
2.6.2.3. Crisis Discipline
2.6.2.3.1. How you behave in crisis shows what you truly believe in
2.6.2.3.2. Choose the methods you feel comfortable following in a crisis, then follow them all the time.
2.6.3. Handling Pressure
2.6.3.1. Don't Panic
2.6.3.1.1. Don't stay up all night, sit and frett, or rush, none of these things will help solve the problems
2.6.3.1.2. Slow down and think the problem through
2.6.3.2. Communicate
2.6.3.2.1. Let your team and superiors know you are in trouble
2.6.3.2.2. Discuss the best plans to get out of trouble, ask for their input
2.6.3.2.3. Avoid creating surprises for anyone
2.6.3.3. Rely on your disciplines
2.6.3.3.1. TDD more
2.6.3.3.2. Refactor harder
2.6.3.4. Get Help
2.6.3.4.1. Pair Program!
3. Management / Mentorship
3.1. Teams & Projects
3.1.1. Does it Blend?
3.1.1.1. No such thing as a half of person
3.1.1.2. Gelled Team
3.1.1.2.1. takes time for a team to form
3.1.1.2.2. Magical about a gelled team
3.1.1.3. Which came first, Team or the Project?
3.1.1.3.1. Team should not be formed around availability to work on a project
3.1.1.3.2. Team should be first class decesion
3.1.2. Teams are harder to build than projects
3.2. Mentoring
3.2.1. Manuals
3.2.1.1. Good books, manuals, api's are great mentors that can reach lots of people
3.2.2. Working with someone
3.2.2.1. learning how they work, their tricks, the best that they know of how to do things
3.2.3. Hard Knocks
3.2.3.1. learning everything on your own
3.2.3.1.1. most developers progress this way
3.2.3.1.2. very slow, very hard, not fun
3.2.4. Apprenticeship
3.2.4.1. Masters
3.2.4.1.1. 10+ years of experience
3.2.4.1.2. lead of multiple projects
3.2.4.1.3. coordinate multiple teams
3.2.4.1.4. Maintain technical role by reading, studying, practicing, doing and teaching
3.2.4.2. Journeymen
3.2.4.2.1. Trained, competent and energetic
3.2.4.2.2. Learn how to work well in teams and become team leaders
3.2.4.2.3. Knowledgeable about current technology but typically lack experience w/ many diverse systems
3.2.4.2.4. Teachers
3.2.4.3. Apprentices/Interns
3.2.4.3.1. Graduates start here
3.2.4.3.2. Closely supervised by journeymen
3.2.4.3.3. Need intense pair programing
3.2.4.3.4. Ought to last a year
3.2.5. Craftsmanship
3.2.5.1. definition
3.2.5.1.1. someone who works quickly, but without rushing, who provides reasonoable estimates and meets commitments
3.2.5.1.2. knows when to say no, but tries hard to say yes
3.2.5.1.3. a professional
3.2.5.2. Convincing People
3.2.5.2.1. can't convince people to be crafstmen
3.2.5.2.2. can't convince them to accept craftmanship
3.2.5.2.3. Acceptance is not so much rational as much emotional
3.2.5.2.4. Make craftsmanship observable
3.3. Tooling
3.3.1. What Bob Martin Uses
3.3.1.1. Source Control
3.3.1.1.1. Open Source tools are usually your best option
3.3.1.1.2. Enterprise controls usually suck
3.3.1.1.3. 2008 switched to GIT
3.3.1.2. IDE
3.3.1.2.1. VI
3.3.1.2.2. EMACS
3.3.1.2.3. Eclipse/IntelliJ
3.3.1.3. Issue Tracking
3.3.1.3.1. Start small, grow as needed
3.3.1.3.2. Bob is using Pivotal Tracker
3.3.1.4. Continuous Builds
3.3.1.4.1. Jenkins
3.3.1.4.2. If the build fails, stop the presses and resolve the issue
3.3.1.5. Unit Testing Tools
3.3.1.5.1. JUnit
3.3.1.5.2. RSPEC foro Ruby
3.3.1.5.3. NUnit for .Net
3.3.1.5.4. Midje for Clojure
3.3.1.5.5. CppUTest for C(++)
3.3.1.6. Component Testing Tools
3.3.1.6.1. FitNesse (written by Bob)
3.3.1.6.2. Others
3.3.1.7. UML/MDA
3.3.1.7.1. Not worth it
3.3.1.7.2. Assumes the problem is code/design
3.3.1.7.3. No great diagramming language today that solves real problems