Refactoring Yourself as a Developer

2,202 views
2,047 views

Published on

SapientNitro's Ryan Taylor presented Refactoring Yourself As A Developer at Cocoa Camp on September 25th.

Cocoa Camp is a conference event on everything related to the iPad, iPhone, iPod touch and Mac. This event brings people together who are working to make mobile technology a more important part of Southeast’s future.

The event fosters discussion and collaboration among a diverse set of people, including technologists, designers, marketers, media professionals, angel investors, and venture capitalists.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,202
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
46
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Refactoring Yourself as a Developer

  1. 1. Refactoring Yourself As A Developer Ryan Taylor | Cocoa Camp | September 25, 2010 © COPYRIGHT 2010 SAPIENT CORPORATION | CONFIDENTIAL
  2. 2. Kaizen Japanese philosophy Focus upon continuously making small improvements Change (kai) to become good (zen). High-level cycle: Identify and eliminate waste and inefficiency Clean up and reorganize after the changes Standardize the resulting improvements © COPYRIGHT 2010 SAPIENT CORPORATION
  3. 3. Self Relevance © COPYRIGHT 2010 SAPIENT CORPORATION
  4. 4. “ An investment in knowledge always pays the best interest.” – Benjamin Franklin © COPYRIGHT 2010 SAPIENT CORPORATION
  5. 5. Grow Your Knowledge Portfolio Our knowledge of current technology is an expiring asset Be diverse, don't limit yourself to one technology When the willingness to learn and evolve ends, so does your career © COPYRIGHT 2010 SAPIENT CORPORATION
  6. 6. Set Personal and Career Goals Setting yearly goals is a healthy practice Challenge yourself to: Earn a promotion Reach a financial landmark Contribute to a book Speak at a conference Learn a new technology © COPYRIGHT 2010 SAPIENT CORPORATION
  7. 7. “ Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler © COPYRIGHT 2010 SAPIENT CORPORATION
  8. 8. Be Passionate About Your Craft Software development is both an art and an engineering discipline Technology will change, but craftsmanship is timeless © COPYRIGHT 2010 SAPIENT CORPORATION
  9. 9. Be Passionate About Your Craft Take pride in your code Always seek to improve your architecture Push for self-documenting, well commented code Maintain consistency and readability Sign your work Challenge yourself on new projects Mentor your peers © COPYRIGHT 2010 SAPIENT CORPORATION
  10. 10. Are you a better developer now than you were six months ago? © COPYRIGHT 2010 SAPIENT CORPORATION
  11. 11. Software Maintenance © COPYRIGHT 2010 SAPIENT CORPORATION
  12. 12. “Everything should be made as simple as possible, but not simpler.” – Albert Einstein © COPYRIGHT 2010 SAPIENT CORPORATION
  13. 13. Keeping Things Simple Complexity is easy to achieve Keeping a design simple can be surprisingly difficult Only design for "real" requirements Never add functionality before it is scheduled Only 10% of the extra stuff will ever get used, so you are wasting 90% of your time © COPYRIGHT 2010 SAPIENT CORPORATION
  14. 14. Managing Software Entropy Software Entropy Defines the measure of disorder in software systems A few laws have been suggested: A computer program that is used will be modified When a program is modified, its complexity will increase Complexity leads to: Software that is more difficult to maintain An increase in the total cost of ownership © COPYRIGHT 2010 SAPIENT CORPORATION
  15. 15. Watch for “Broken Windows” One broken window leads to many broken windows... Crack down on the little stuff to prevent the big stuff Take immediate action to prevent further damage © COPYRIGHT 2010 SAPIENT CORPORATION
  16. 16. Code Refactoring The process of improving code without changing its overall result Refactoring is not: Adding new features Fixing bugs Good times to refactor: As requirements begin to change After a code review © COPYRIGHT 2010 SAPIENT CORPORATION
  17. 17. Code Refactoring Targets for refactoring: Code duplication Poor architecture Outdated knowledge/logic Performance issues Leverage unit tests and test harnesses to prevent new bugs from being created © COPYRIGHT 2010 SAPIENT CORPORATION
  18. 18. Communication © COPYRIGHT 2010 SAPIENT CORPORATION
  19. 19. Justifying Maintenance How do you justify allocating time for software maintenance to a project manager or client? Explain that risk and cost increase when proper maintenance is not performed Use the surgery analogy Catch it early = simple surgery Catch it late = dangerous surgery and costly © COPYRIGHT 2010 SAPIENT CORPORATION
  20. 20. “The problem with communication is the illusion that it has occurred.” – George Bernard Shaw © COPYRIGHT 2010 SAPIENT CORPORATION
  21. 21. Best Practices In general: Use email so there is a paper trail Avoid hallway conversations Respond to messages promptly A quick “I'll get back to you later" response is better than nothing at all Keep your audience in mind © COPYRIGHT 2010 SAPIENT CORPORATION
  22. 22. Best Practices With your development team: Assign a platform lead to coordinate communication Create a wiki to track wireframes, specs, and issues Leverage a version control system Include a detailed message with each commit Configure it to send out change notification emails Schedule regular status meetings © COPYRIGHT 2010 SAPIENT CORPORATION
  23. 23. Best Practices Actively seek feedback: At minimum, request a code review after each project Approach people that you have worked closely with and ask them to be honest Maintain an open mind Your critics are never 100% wrong Debate is healthy if both sides are open to change Take responsibility: Admit your mistakes Offer options, not excuses © COPYRIGHT 2010 SAPIENT CORPORATION
  24. 24. Time Management © COPYRIGHT 2010 SAPIENT CORPORATION
  25. 25. Estimating Tasks Crucial part of software development Helps prevent surprises down the road by forcing you to think about things up front When asked for an estimate, always respond with “I’ll get back to you.” Explicitly declare assumptions © COPYRIGHT 2010 SAPIENT CORPORATION
  26. 26. Estimating Tasks Unit of measurement is important in expressing accuracy 6 months vs 26 weeks vs 130 days vs 1,040 hours Rough Precise Leave your ego out of the equation: Don't try to impress others with a low number and then drop the ball Give good, honest estimates Add some padding to be safe © COPYRIGHT 2010 SAPIENT CORPORATION
  27. 27. Work/Life Balance It is very important to balance your professional and personal lives The best developers find a way to sustain balance and avoid burnout © COPYRIGHT 2010 SAPIENT CORPORATION
  28. 28. “If one oversteps the bounds of moderation, the greatest pleasures cease to please.” – Epictetus © COPYRIGHT 2010 SAPIENT CORPORATION
  29. 29. Thank you. Ryan Taylor | rtaylor@sapient.com | www.boostworthy.com © COPYRIGHT 2010 SAPIENT CORPORATION | CONFIDENTIAL

×