The Developer Health Check 2015 Edition Tod Thomson Senior Developer 

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

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

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

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 

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 

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 

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/ 

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/ 

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/ 

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 

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/ 

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/ 

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 

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 

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 

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/ 

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 

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 

Page Questions? © Tod Thomson 2015 20 

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