API Design & Moving from Junior to Senior Developer


Published on

Talk given for @NashSoftware about API Design (How to consume, How to create). And, the process of moving from a Junior to a Senior Developer.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

API Design & Moving from Junior to Senior Developer

  1. 1. API Design&Junior ➪ SeniorChristopher Cotton @_cotton for @NashSoftware2012 Nov 29, christophercotton.com
  2. 2. The Past✤ 20+ years Programming✤ Been QA Tester, Junior Dev, Senior Dev, Technical Lead, Project Lead, Architect, Senior Member of Technical Staff 3 (What?!), CTO, Founder, Consultant and lots of random other jobs✤ javax.mail http://www.google.com/#q=javax.mail+cotton
  3. 3. The Now✤ iOS, Android, Ruby on Rails✤ @NashGameDev✤ @SpacewardHo✤ http://handstand.io✤ Teach Kids Programming (YSI) http://www.fssd.org/index.php? option=com_content&task=view&id=110&Itemid=207
  4. 4. My Version, Not “The Truth”Date
  5. 5. API stands for?
  6. 6. This does what? User.find_or_create_by_name("Bob")
  7. 7. API✤ Contract - documented, agreement, cause/effect✤ Interface - one service to another✤ GEM, Library, TCP, HTTP, etc.✤ Systems Integration
  8. 8. Lonely AppDate
  9. 9. API Here, API There, EverywhereDate
  10. 10. Version 2010/12/31 Current Architecture All rights reserved Handstand Scraper ContentDB Packager FileStorage Content Server Blogs/Websites Article List Article Package Market Task Device App Android Market Google Log Analytics Task Ad List Config Ads Builder Amazon Builder Amazon SQS S3 App.Handstand CustomerInternal SystemsDate
  11. 11. API - How to ConsumeDate
  12. 12. How to use? What would you do?
  13. 13. API - How to DesignDate
  14. 14. Lots of Other Resources✤ How to design RESTful APIs✤ CRUD✤ HTTP API
  15. 15. What is the point?
  16. 16. Who will use it?✤ Dell Digital Delivery - 10 million machines, more each year to download software✤ Cyberdog - other developers to implement new components✤ JavaSoft javax.mail - Developers implementing Services, or sending Email✤ Handstand - devices retrieving travel magazine
  17. 17. Document, Document, DocumentDate
  18. 18. Why Document?✤ Another programmer will need to know how it works, and trial and error sucks✤ Test Your API, write a client from your own docs✤ Keeps your code honest✤ Becomes a real API when a client is written by someone other than you from your docs
  19. 19. Find & Reuse Good APIs✤ Don’t reinvent the wheel✤ Find another similar, and expand or convert✤ Learn from bad APIs
  20. 20. Key Aspects✤ Versioned✤ Errors - was the request successful? invalid data? server blew up?✤ Consistent to itself - delete_book, friend_delete✤ Iteration✤ Design with a partner or isolation, not large groups
  21. 21. Iteration✤ High Level APIs✤ Data Model, Design Objects and Connections✤ Keep asking, what other actions need to be done? What other data?✤ Walk through the scenarios✤ retrieve library, log in, add book, delete book, post comment
  22. 22. Practice, practice, practiceDate
  23. 23. Q & A, Part OneDate
  24. 24. Junior ➪ SeniorDate
  25. 25. Characteristics of Bad Junior(or bad Senior)✤ Worried about how you look, or what you say✤ Focused on small parts, misses big picture✤ Makes changes without understanding repercussions✤ Not my part
  26. 26. Good Senior Developer(or Good Junior Developer)✤ Says, “I don’t know”✤ Takes responsibility✤ Continually Learning✤ Will “Take one for the team”✤ Given Any Problem, Can Invent a solution✤ Can learn needed skills✤ Goes beyond the basics
  27. 27. Basic Mistakes
  28. 28. Separate Concerns of Code✤ Putting code unrelated into one group/class✤ Networking code in the DB code✤ UI Controller Code, with Table Cell Display Code✤ Too many lines!✤ “Wasn’t sure where else to put it” Ask!
  29. 29. Cut & Paste Solutions✤ Found something on Stack Overflow, paste it in!✤ The Interweb is not always correct✤ Take the time to understand what it does, and why
  30. 30. Hard Coded Values✤ Just don’t do it. Use config, use Class definitions, or Statics
  31. 31. Reinvention, Bad idea✤ Calendar formatter✤ Network Library✤ Search, or ask. Know your domain
  32. 32. Warnings, Errors✤ Fix warning messages, they are usually there for a reason✤ If something fails, understand WHY it failed. Interested in making sure it doesn’t happen again✤ Know where to fix it, document your changes✤ Example: Cucumber test with TEXTAREA gave an extra ‘r’
  33. 33. Be sure to test✤ “I’m sure it must work in all those cases”✤ Take the time to think about your code
  34. 34. Too Focused on Small Parts✤ Focus on the most important parts. Don’t know? Ask!✤ iOS app, focused on getting a particular toolbar exact to the specifications, but those specifications would change✤ Optimizing before recording data, profiling
  35. 35. How will this change the app?✤ DB code, using “select statements” and adding in specific fields✤ Made it work in the short term, impossible to manage in the long term✤ Change one class, but not really understand how it is used elsewhere
  36. 36. How to ImproveDate
  37. 37. MentoringDate
  38. 38. Ask for Feedback, Code ReviewsDate
  39. 39. Read/LearnDate
  40. 40. Build Tools, APIs, LibrariesDon’t do the same thing over and overDate
  41. 41. Enjoy the processDate
  42. 42. What is your.... Q & A, Part DeuxDate