Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Good Developer is a Good Designer

A Good Developer is a Good Designer

Talk I gave at the Flatiron school about my experience of what makes someone a good developer.

Nicolae Rusan

August 16, 2013
Tweet

More Decks by Nicolae Rusan

Other Decks in Programming

Transcript

  1. e Design Process Model the Problem Recipe: -  Description of

    dish -  Photos of Food -  Ingredients -  Instructions User -  Profile Info -  Favorite Dishes Ingredient? ….etc.. Objects: Pages/Actions: What goes on each page? What are the core navigation pages? Browse Recipes -  By ingredient -  By food type -  Search for recipes User Profile -  Favorite recipes -  Profile Picture + Info ….etc..
  2. e Design Process •  Identify who you are designing for.

    •  Collect Requirements •  Identify and Questions Assumptions •  Modeling the problem •  Considers many different possible solutions •  Communicates process, and tradeoffs.
  3. Systems are designed. Systems evolve. Assumptions change. Abstractions & Groupings

    Tools & Materials Assumptions Requirements Constraints System
  4. C10K  problem   -­‐  Assump9ons  changed.  Context  Changed.    

      •  Why  do  we  have  non-­‐persistent  connec9ons?  
  5. Knows exactly what they’re going to code when they sit

    down – because they have designed it ahead of time.
  6. Your Future Interviews Bad Developer Starts coding right away Doesn’t

    ask any questions Doesn’t consider alternative solutions
  7. Your Future Interviews Bad Developer Starts coding right away Doesn’t

    ask any questions Doesn’t consider alternative solutions Doesn’t communicate their process.
  8. Your Future Interviews Bad Developer Starts coding right away Doesn’t

    ask any questions Doesn’t consider alternative solutions Doesn’t communicate their process. Doesn’t think about how to best model the problem domain.
  9. Your Future Interviews Good Developer Asks clarifying questions methodically. Identi

    es hidden assumptions, states them explicitly. Considers alternative solutions on paper or talking before diving in.
  10. Your Future Interviews Good Developer Asks clarifying questions methodically. Identi

    es hidden assumptions, states them explicitly. Considers alternative solutions on paper or talking before diving in. Focuses on the right details.
  11. Your Future Interviews Good Developer Asks clarifying questions methodically. Identi

    es hidden assumptions, states them explicitly. Considers alternative solutions on paper or talking before diving in. Focuses on the right details. Has a process.
  12. Low Fidelity High Fidelity Your Brain Paper Exploratory Code Specs

    Development Code Production Code (test cases etc.) Cost of exploring possibility space
  13. Low Fidelity High Fidelity Your Brain Paper Exploratory Code Specs

    Development Code Production Code (test cases etc.) Cost of exploring possibility space THROWAWAY!!"
  14. Empathize with your user.   Other developers reading your code

    Other developers interfacing with your code/service
  15. Empathize with your user.   Other developers reading your code

    Other developers interfacing with your code/service Future you.
  16. Don’t fuck yourself and others. Documentation" Test cases" Proper naming"

    No ‘special’ cases " No magic tricks only you know – should be obvious! "
  17. Don’t fuck yourself and others. Documentation" Test cases" Proper naming"

    No ‘special’ cases " No magic tricks only you know – should be obvious! " You will forget!"
  18. Where do old programmers go? age   Time  spent  coding

      Time  spent  doing   system  design  
  19. e Annoying Parts of Programming. Ø  Getting setup in the

    environment Ø  Getting random things working together
  20. e Annoying Parts of Programming. Ø  Getting setup in the

    environment Ø  Getting random things working together Ø  Not knowing how the internals work
  21. e Annoying Parts of Programming. Ø  Getting setup in the

    environment Ø  Getting random things working together Ø  Not knowing how the internals work Ø  Poor documentation
  22. e Annoying Parts of Programming. Ø  Getting setup in the

    environment Ø  Getting random things working together Ø  Not knowing how the internals work Ø  Poor documentation Ø  Random bugs you can’t Google
  23. e Annoying Parts of Programming. Ø  Getting setup in the

    environment Ø  Getting random things working together Ø  Not knowing how the internals work Ø  Poor documentation Ø  Random bugs you can’t Google Ø  One off typos that take you days to nd.
  24. If you design properly, you’ll hit fewer bugs – things

    will be cleaner. Don’t just dive in. is is how you avoid the things that break you.