Code of conduct and work ethics for professional programmers

A practical approach for apprentices and journeymenCode of conduct and work ethics for professional programmersAmateur vs ProfessionalAmateur

Doesnt take responsibility for the job they doIf he makes an error, someone else has to clean the messExpects that someone will take care of their careerBelieves that knowing one technology will sufficeDoesnt practice on a regular basisProfessional

Knows that his career is his responsibilityIs accountable for his mistakesIdentifies himself with his employer/customerLearns continuouslyPractices his craft and keeps his skills sharp

AmateurIs introvert and prefers to work aloneThinks in terms of code not in terms of business and added valueConfuses I will try with I commitHas an incomplete Definition of Done

ProfessionalCollaborates and works together with his team Understands the business for which he writes softwareKnows when to commit and knows people rely on his workWhen his task is done it means it is DONE

The 10 crafts of software professionalsCommittingSay it. Mean it. Do it.Lack of commitment: need/should, hope/wish, I will tryTrue commitment: I will finish this by TuesdayWhen you rely on person X, commit to actions that bring you closer to your target: Discuss with X to have a better understanding of your dependenciesAbstract your dependency from the other teams infrastructureCreate your personal build that runs your integration tests6Committing When you jus cant make it:Change the expectations ASAPRaise a red flagThe sooner you raise the flag the chance increases to take actionsWhen you dont know if it can be done:Commit to find a solutionBreak the task into smaller tasks and commit on thoseProfessionals dont need to say yes to everything, they work to find creative ways to make yes possibleThey use the language of commitment so that there is no doubt about what theyve promissed

EstimatingFor the business, estimates = commitmentFor developers, estimates = guessDevelopers suck at estimatingAn estimate is not a number, its a distribution

EstimatingA fair estimate needs to describe the whole distribution and business needs to make plans based on thisPERT: (O)ptimistic - Everything goes incredibly well(N)ominal The estimate with the greatest chance of success(P)esimistic Everything goes haywire. Nuclear wars includedExpected durationStandard deviation Software professionals are very careful to set reasonable expectations despite the pressure to try to go fast

EstimatingAlways take into account your team. Dont make estimates on your own.Team estimation techniques:Flying Fingers Planning Poker Affinity Estimation Trivariate Estimates The Law of Large Numbers: break up a large task into many smaller tasks and estimate them independently, the sum of the estimates of the small tasks will be more accurate than a single estimate of the larger task. Errors in estimates tend toward underestimation

CollaboratingSoftware is created by teams. Loners out, team players in.We didnt become programmers because we like working with people Programmers vs Employers:As a professional you need to deeply understand the businessCollaborate with managers, BA, QA and other team membersYou need to keep the business floatProgrammers vs Programmers:Forget about owned codeCollective ownership is far betterPair-Programming helps with: problem solving, knowledge sharing, code review

CodingYour code :Must workMust solve the problem set by the customerMust fit well into the existing systemMust be readable by other programmersAvoid:3 AM codeWorry codeFlow zone codeDefine Done and respect itRefactoring is a continuous processAim to have 100% test coverageDont write any line of production code until you have completely understood the businessAnyone should be able to understand your codeUse comment to describe a use case not your implementation

PracticingSharpen your skillsUse some kind of coding kataParticipate in open source projectsLearning is a continuous processTry a new framework once in a whileTry to implement your favorite project in different languagesStay in touch with the latest changes in paradigmsDoes Scala, Go, Erlang, Haskell, Grails, Clojure, D sound familiar to you?Dont let a change in industry software to leave you Test Driven DevelopmentThe 3 laws of TDD:No production code until you have a failing unit testDont write more of a UT than is sufficient to fail not compiling is failingDont write more production code than is sufficient to pass the currently failing UTThe 2 code streams grow simultaneouslyBenefits: Certainty, Defect Injection Rate, Courage, Documentation, DesignYou can still write bad code even if you write tests firstNever leave a bug without a testAcceptance testingA collaboration between stakeholders and programmers in order to define when a requirement is doneProfessional DoD: automated acceptance testWork with stakeholders and QA that the automated tests are a complete specification of donePurpose: communication, clarity and precisionALWAYS automatedIts not extra work, its specifying the system.Work with the test author. Help in improving test casesNot unit tests. Written by the business for the businessTime managementMeetings cost $. Meetings are necessary. Meetings are huge time wasters. Have an agenda and a goal. Leave when the you reached your goal.Standups:What did I do yesterday?What am I going to do today?Whats blocking me?Focus-Mana is limited => Make the best out of itUse time boxing => the Pomodoro techniqueAvoid blind alleys, swamps and other messes

MentoringLearn from the people that have more experience than youPass the knowledge you have to the ones that are at the beginning of their pathThe 3 layers of software apprenticeship:Apprentices/Interns Closely supervised by JourneymenJourneymen make sure they know design principles, design patterns, disciplines, processes, TDD, refactoring, estimationThey get assigned readings, exercises and practicesJourneymenThey need to learn to become team leaders and work well in a teamSupervised by mastersMasters Minimum 10 years of experienceProficient designers and architectsAct as a role model for your peers

ToolingThe must haves:Source code control: branching, git workflow modelsMaster your IDEIssue tracking softwareContinuous build toolsUnit testing toolsUI testing toolsIntegration testing toolsUML, Sequence diagrams, Use case diagrams, Data flow diagramsDesign, code, test, repeat