• Save
The 10 habits of highly effective programmers
Upcoming SlideShare
Loading in...5
×
 

The 10 habits of highly effective programmers

on

  • 2,896 views

A short introduction to various Agile and Lean practices such as Test Driven Development, Technical Debt, Pair Programming, and more.

A short introduction to various Agile and Lean practices such as Test Driven Development, Technical Debt, Pair Programming, and more.

Statistics

Views

Total Views
2,896
Views on SlideShare
2,871
Embed Views
25

Actions

Likes
4
Downloads
0
Comments
1

3 Embeds 25

http://hunglethanh90.blogspot.com 18
http://www.linkedin.com 5
http://a0.twimg.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    The 10 habits of highly effective programmers The 10 habits of highly effective programmers Presentation Transcript

    • The 10 Habits of Highly Effective Developers
      Dennis Doomen | Principal Consultant | Aviva Solutions
    • Dennis Doomen
      About Me
      • 14 years IT experience
      • C++ originsbut C# since 2001
      • Specialities
      • .NET Architecture
      • Silverlight
      • Scrum/XP
      • ALM
      • Occasional Speaker
      • Public initiatives
      • SilverlightCookbook
      • C# CodingGuidelines
      • FluentAssertions
      • Internet
      • www.dennisdoomen.net
      • DZone MVB
      • @ddoomen
    • Communication Challenges
      Traceability
      Bridging IT and business
      Enforcingconsensus
      Understanding the domain
      Misinterpretations
    • Ubiquitous Language
      1 concept = 1 name
      Verbs & nouns
      Refactor!
      Native language
      No ambiguity
      Business proposes
      Beware of conflictingrules
    • RequirementsChallenges
      Scoping
      Estimability
      Traceability
      Purpose
      Whichstakeholders?
      Documentationis ambiguous
      PromoteCommunication
    • User Stories
      Product Backlog
      Storyotypes
      Placeholder
      Project value
      Estimable
      Negotiable
      Who, what, why
      Global unit of work
    • MaintabilityChallenges
      Lot of coupling
      Inconsistent naming
      Bad cohesion
      Incorrect usageof .NET
      Intention
      obscuringcode
      Inconsistent layout
      Procedural Code
      Bad maintainability
    • Coding Standards
      Definesubset
      Ghostdoc
      ReSharper or
      CodeRush
      Static Code Analysis
      Distribute cheat sheet
      Go towww.csharpcodingguidelines.com
    • QualityChallenges
      Architecturalinconsistencies
      Design skills
      Communication skills
      Bad hair days
      Misinterpretations
      10-50 bugs / 1000 lines
    • Peer Reviews
      Always!
      Ad-Hoc
      TFS vNext!
      ByPeers
      Chooseyour tool
      FormalProcess
      Record Comments
    • Team Challenges
      Compliancy
      Too manythings
      toremember
      Common mistakes
      Juniors
      UI choices
      Annoyingreviews
      Design choices
    • Checklists
      Short
      Concise
      Open
      Unambiguous
      Design choices
      Sign-off
      Online or offline
      CodingGuidelines
      Project-specific
    • Productivity Challenges
      Fixing the
      wrong
      problem
      Bugs
      Design
      flaws
      Building
      the wrong
      thing
      Late feedback
      Alternateinterpretations
      Lack of experience
    • Pair Programming
      Switchpairs
      Complexproblems
      Straightdesks
      Same
      level only
      Coaching
      Not the
      entireday
      Dual keyboard + mouse
    • ConsistencyChallenges
      KISS
      Requirements
      change
      YAGNI
      Oracles
      don’texist
      LDUF
      Utopianarchitectures
      don’texist
      Ubiquitous Language
      changes
    • Refactoring
      Single responsibility
      Small changes
      S.O.L.I.D
      Decrease
      coupling
      Continuous
      Increasecohesion
      Boyscout rule
      NOT Redesign
      ReSharper / CodeRush
    • Design Challenges
      Debugging hell
      Untestable
      Refactoring
      Too many
      responsibilities
      Regressions
      Insufficient
      design skills
      No cohesion
      Strong coupling
    • Test Driven Development
      Test-First
      Read, read, read
      > 90%
      Usefor
      peer reviews
      Design Process
      First-Class Citizens
      Includesrefactoring
      Avoid
      UI logic
    • Technical Debt
      Repetition
      causes
      repetition
      Repeatingfixes
      Qualityundefinable
      Suboptimal
      check-Ins
      Simple changes
      become complex
      Software rot
    • Wall of Pain
      Open
      PlanRedesigns
      Visible
      SmallSteps
      Wall of pain
      Regular Review
      Meetings
      PrioritizeByPain
      ConsiderCosts & Risks
    • Even More Challenges
      PainfulDeployment
      Code
      Analysis
      Unit Testing
      Testing on Real Server
      Code Coverage
      Redeployment
    • Automatic Builds
      Conflict
      Detection
      Code
      Analysis
      Unit Testing
      AutomaticDeployment
      ContinuousIntegration
      Team Responsibility
    • ?
      Emaildennis.doomen@avivasolutions.nl
      Twitter
      @ddoomen
      Blogwww.dennisdoomen.net