$30 off During Our Annual Pro Sale. View Details »

Developer Health Check - 2015 Edition

Developer Health Check - 2015 Edition

For the 2015 Edition of the Developer Health Check I'll be presenting and facilitating a group discussion on the skills and behaviours I've observed over the years in successful software developers and together we'll ponder what we can learn from reflecting on them.

Please come equipped with your insights and experiences so that we can all benefit from them in a friendly atmosphere of listening and sharing. I'll be putting my ideas "out there" and encouraging you to put your ideas out there as well. Hope to see you there.

As presented at: http://www.meetup.com/Brisbane-Software-Improvement-Group/events/220574022/

Tod Thomson

April 13, 2015
Tweet

More Decks by Tod Thomson

Other Decks in Technology

Transcript

  1. The Developer
    Health Check
    2015 Edition
    Tod Thomson
    Senior Developer

    View Slide

  2. Page
    “No one… is the
    suppository of all wisdom”
    © Tod Thomson 2015
    2
    Hon Tony Abbott MP
    Disclaimer

    View Slide

  3. Page
    Agenda?
    Soft Skills
    &
    Hard Skills
    © Tod Thomson 2015
    3

    View Slide

  4. Page
    Agenda?
    Softer Skills
    &
    Harder Skills
    © Tod Thomson 2015
    4

    View Slide

  5. Page
    Softer Skills
    › The Myth of the Rockstar Programmer
    › Remember the Prime Directive
    › Estimates or #NoEstimates?
    › Pssst... We're not "doing agile", we're agile!
    › Always Fail Forward
    › You see a problem and have a problem with it? Now I have two problems ;(
    › The goal is working software that meets a business need
    › The #1 Skill
    › Zed Shaw’s Law
    › The Cavalry
    › Apprentice, Journeyman, Master
    › Net Positive Developers Please
    © Tod Thomson 2015
    5

    View Slide

  6. Page
    The Myth of the
    Rockstar
    Programmer
    The Myth of the Rockstar
    Programmer is just that, a
    myth.
    It's an unfortunate myth for a
    number of reasons.
    › It sets an unreasonable
    expectation for regular
    folks.
    › Calling out rockstars
    demotivates the team.
    › Telling someone they are a
    rockstar may cause them
    to actually believe it.
    © Tod Thomson 2015
    6
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx

    View Slide

  7. Page
    Remember the
    Prime
    Directive
    “Regardless of what we
    discover, we understand and
    truly believe that everyone did
    the best job they could, given
    what they knew at the time,
    their skills and abilities, the
    resources available, and the
    situation at hand.

    © Tod Thomson 2015
    7
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html

    View Slide

  8. Page
    Estimates
    or
    #NoEstimates?
    › Estimating is hard and in
    my experience we’re not
    getting any better at it
    › Even with estimates
    projects tend to run 50%
    to 100% over estimates
    (over budget or over time)
    › Programmer value should
    be an order of magnitude
    above programmer cost
    › Should we begin projects
    where the return on
    investment is so low that
    estimate overruns will kill
    profitability?
    © Tod Thomson 2015
    8
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/

    View Slide

  9. Page
    Pssst...
    We're not
    "doing agile",
    we're agile!
    › Agility is “the power of
    moving and changing
    direction quickly and
    easily; nimbleness”.
    › Agile is not a “framework”
    it’s a “state of mind”.
    › We want to be agile, not
    just be “doing agile”.
    › As we make decisions in
    our day to day work we
    must constantly ask
    ourselves “does this make
    me / the software more or
    less agile?”.
    › Agile Manifesto
    © Tod Thomson 2015
    9
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/
    http://agilemanifesto.org/

    View Slide

  10. Page
    Always
    Fail
    Forward
    › Focus on future successes,
    not on past failures
    › Roll forward not rollback
    › Problem with this release?
    Fix it / do another release.
    › Lean on your tools they
    will help you here.
    © Tod Thomson 2015
    10
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/

    View Slide

  11. Page
    You see a
    problem and
    have a problem
    with it?
    Now I have two
    problems ;(
    © Tod Thomson 2015
    11
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/
    › Never be the problem
    › Always be the solution
    › How to win friends and
    influence people

    View Slide

  12. Page
    The goal is
    working software
    that meets a
    business need
    › Anyone who tells you
    otherwise is lying to you
    › Consider your overheads,
    do they provide more
    value than they cost you?
    › Is your codebase in a
    working state right now?
    › Can you ship it to your
    customer tomorrow
    morning (providing value)
    and then shut the project
    down?
    › Minimum Viable Product
    © Tod Thomson 2015
    12
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/
    http://www.roysivan.com/best-way-develop-mvp/

    View Slide

  13. Page
    The
    #1
    Skill
    Learn how to be good at
    learning new things
    › The best skill you can have
    as a software developer is
    being really good at
    learning new things
    › Ours is the fastest moving
    industry there is (the times
    they are a-changing) so we
    need to be able to adapt if
    we want to survive
    › But how?
    © Tod Thomson 2015
    13
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/

    View Slide

  14. Page
    Zed
    Shaw’s
    Law
    You're not a link in an
    "autistic" chain gang (so don't
    act like one)
    › We’re not pigeons in
    holes, we are software
    developers
    › We’re “normal” people
    with partners, mortgages,
    kids, et al who don’t need
    to be “managed” by failed
    programmers in order for
    us to work effectively
    towards a common goal
    › So let’s act like it! 
    © Tod Thomson 2015
    14
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/
    http://bit.ly/1DVruxy

    View Slide

  15. Page
    The
    Cavalry
    © Tod Thomson 2015
    15
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/
    An ethos for all developers

    View Slide

  16. Page
    Apprentice
    Journeyman
    Master
    › It's just Journeyman!
    › Know what you don't know
    › You can actively operate
    (switch between) all three
    modes.
    › Remember that there will
    always be someone who
    knows more about a subject
    than you do
    › Do not be lazy and pass up
    an opportunity to share
    your knowledge
    © Tod Thomson 2015
    16
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/
    https://pragprog.com/the-pragmatic-programmer

    View Slide

  17. Page
    Net Positive
    Developers
    Please
    › Have you head the term
    “net negative developer”?
    › I have and I really hate it
    › But to get rid of this
    pejorative term from our
    collective vocabularies we
    need to make sure we’re
    all net positive
    › What are good developer
    habits?
    › What are bad developer
    habits?
    © Tod Thomson 2015
    17
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
    http://www.retrospectives.com/pages/retroPrimeDirective.html
    http://www.retrospectives.com/pages/retroPrimeDirective.html http://noestimatesbook.com/

    View Slide

  18. Page
    Harder Skills
    › Git or ?
    › GitHub or ?
    › SCM: All The Things!
    › NPM, Bower, Grunt, Gulp...
    › Programming in the Large vs Programming in the Small
    › Be the Change You Want To See (in the code)
    › Design Patterns: A solution in need of a problem?
    › We know CI, but is it CD[eployment] or CD[elivery]?
    › The 2 Step Program: `git clone "url" && reset-the-world-and-run-app.ps1`
    © Tod Thomson 2015
    18

    View Slide

  19. Page
    Harder Skills
    › Have the best computer and tools money can buy that you can afford
    › Quality & Correctness (Crockford's Law)
    › Code must be Simple, Clean, DRY, SOLID and Easy to Understand (to fix).
    › The Power of Plain Text
    › Know Your Tools
    › Fix Broken Windows (fix the bugs first)
    › Structured Logging (making sure it will be useful later)
    › Your code base should become more "insert good thing here" over time
    › UX is not UI, it's all about the empathy
    © Tod Thomson 2015
    19

    View Slide

  20. Page
    Questions?
    © Tod Thomson 2015
    20

    View Slide

  21. Thanks for putting
    up with me! 
    Feedback?
    [email protected]

    View Slide