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.

508cdde667137534cd7154a447e38e51?s=128

Nicolae Rusan

August 16, 2013
Tweet

More Decks by Nicolae Rusan

Other Decks in Programming

Transcript

  1. What makes a good developer?

  2. A good developer, is a good designer.

  3. Design is a way of thinking (of solving problems), along

    with a set of skills.
  4. Designs have a purpose.

  5. ∞ Possibilities

  6. ∞ Possibilities 1 Solution

  7. ∞ Possibilities 1 Solution Design Process

  8. Programming doesn’t exist in a vacuum. It’s aimed to solve

    a problem.
  9. NOM NOM FACTORY A recipe site.

  10. e Design Process Who are you designing for?

  11. e Design Process Collect Requirements.

  12. e Design Process Identify and Question Assumptions

  13. 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..
  14. e Design Process Consider many different possible solutions

  15. e Design Process Communicate process and tradeoffs    Benefits  

           Downsides     A     B    
  16. 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.
  17. Systems are designed. Systems evolve. Assumptions change. Abstractions & Groupings

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

      •  Why  do  we  have  non-­‐persistent  connec9ons?  
  19. A good developer builds less.

  20. Knows exactly what they’re going to code when they sit

    down – because they have designed it ahead of time.
  21. Understands their tools, and the context they were designed in

    – what were the assumptions?
  22. Is not married to their tools. Different contexts require different

    solutions.
  23. Your Future Interviews Bad Developer

  24. Your Future Interviews Bad Developer Starts coding right away

  25. Your Future Interviews Bad Developer Starts coding right away Doesn’t

    ask any questions
  26. Your Future Interviews Bad Developer Starts coding right away Doesn’t

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

    ask any questions Doesn’t consider alternative solutions Doesn’t communicate their process.
  28. 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.
  29. Your Future Interviews Good Developer

  30. Your Future Interviews Good Developer Asks clarifying questions methodically.

  31. Your Future Interviews Good Developer Asks clarifying questions methodically. Identi

    es hidden assumptions, states them explicitly.
  32. 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.
  33. 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.
  34. 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.
  35. Hill-Climbing – e Best Design

  36. Low Fidelity High Fidelity Your Brain Paper Exploratory Code Specs

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

    Development Code Production Code (test cases etc.) Cost of exploring possibility space THROWAWAY!!"
  38. Your codebase is your product.  

  39. Empathize with your user.  

  40. Empathize with your user.   Other developers reading your code

  41. Empathize with your user.   Other developers reading your code

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

    Other developers interfacing with your code/service Future you.
  43. Don’t fuck yourself and others.

  44. Don’t fuck yourself and others. Documentation"

  45. Don’t fuck yourself and others. Documentation" Proper naming"

  46. Don’t fuck yourself and others. Documentation" Test cases" Proper naming"

  47. Don’t fuck yourself and others. Documentation" Test cases" Proper naming"

    No ‘special’ cases "
  48. Don’t fuck yourself and others. Documentation" Test cases" Proper naming"

    No ‘special’ cases " No magic tricks only you know – should be obvious! "
  49. 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!"
  50. Immediate gains = Long-term pains

  51. Where do old programmers go? age   Time  spent  coding

      Time  spent  doing   system  design  
  52. A good developer has grit.

  53. Design – but also endurance.

  54. Fuck this SHIT!

  55. e Annoying Parts of Programming.

  56. e Annoying Parts of Programming. Ø  Getting setup in the

    environment
  57. e Annoying Parts of Programming. Ø  Getting setup in the

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

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

    environment Ø  Getting random things working together Ø  Not knowing how the internals work Ø  Poor documentation
  60. 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
  61. 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.
  62. You’re not a programmer until you waste days of your

    life over a semicolon.
  63. Stay positive.

  64. 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.
  65. Don’t Belly op!

  66. Proper Design -> Fewer bugs + cleaner code. = Avoiding

    getting broken.
  67. A good developer is

  68. A good developer is A good designer with a process,

  69. A good developer is A good designer with a process,

    Who has grit and discipline.
  70. A good developer is A good designer with a process,

    Who has grit and discipline.