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/

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?
    tod.thomson@readify.net
    

    View Slide