A Good Developer is a Good Designer

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

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.