Beyond Bootcamp - Speaker Deck

Slide 1

Slide 1 text

Beyond Bootcamp 1

Slide 2

Slide 2 text

Me: before Detroit Labs (Jan 2014) ☞ Small, procedural programs (~100-200 lines; 1 ﬁle). ☞ Limited experience with IDEs (Xcode). ☞ No experience with version control (git). ☞ No idea how to bridge the gap between my projects and "big", "professional" projects. 2

Slide 3

Slide 3 text

Me: now ☞ Large, event-driven apps (~100k-200k lines; 1000+ ﬁles). ☞ Shipping Android & iOS apps to 100k+ users. 3

Slide 4

Slide 4 text

Goals of this talk ➀ Explain why professional app development is different. ➁ Explain how professional app development is different. ➂ Explain what those differences will mean to you as an individual developer. ➃ Provide examples and resources to help you bridge the gap. ➄ (Some iOS specifics.) 4

Slide 5

Slide 5 text

Caveats 5

Slide 6

Slide 6 text

The why 6

Slide 7

Slide 7 text

The constraints 7

Slide 8

Slide 8 text

❝Time is money❞ —Benjamin Franklin 8

Slide 9

Slide 9 text

❝Perfect is the enemy of good❞ —Voltaire 9

Slide 10

Slide 10 text

The compromises 10

Slide 11

Slide 11 text

The how 11

Slide 12

Slide 12 text

What do these constraints mean for companies? ➀ Customer timelines → developers work in teams. ➁ Formal training is (doubly) costly → hire adaptable developers who can learn on the job OR hire experts. 12

Slide 13

Slide 13 text

What do these constraints mean for you, as a developer? Capacity to contribute and grow as a pro developer is based on: ➀ Your communication skills. ➁ Your self-directed learning skills. 13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Overview: communication ➀ With colleagues. ➁ With clients & customers. ➂ In your code. ➃ Around your code. 15

Slide 16

Slide 16 text

Communicating with colleagues Resources ☞ [book] Thanks for the Feedback ☞ [book] Soft Skills: The software developer's life manual 16

Slide 17

Slide 17 text

Communicating with clients Goals ☞ "Basic hygiene" (capitalization; spelling; grammar; phrasing). ☞ Audience-appropriate (e.g. developer vs decision-maker). Resources ☞ [book] The Elements of Style ☞ [book] Soft Skills: The software developer's life manual (again) 17

Slide 18

Slide 18 text

Communicating in code: why? 18

Slide 19

Slide 19 text

❝New code becomes old code almost instantly❞ —Peter Hallam, Microsoft 19

Slide 20

Slide 20 text

Communicating in code ❝A huge amount of what a developer is doing is in their head. As we write code we need to keep a mental model of how parts of the application that have already been written and are yet to be written interact with the part that we are writing at that moment. We need to have a solid picture of exactly how the code is working as a whole and maintain that picture. It’s not easy, it requires a lot of concentration and has to remain in place while we think of creative and efficient ways to solve the problem at hand.❞ —Derek Johnson 20

Slide 21

Slide 21 text

Question What does this line of code communicate? var x = -17.7778; ☞ Some other code consumes the value represented by x. ☞ The initial (perhaps default?) value of x is -17.7778. ☞ The value represented by x may vary. ☞ The writer was probably an Objective-C programmer! 21

Slide 22

Slide 22 text

Question What does this line of code not communicate? var x = -17.7778; ☞ The value x represents (a length? a dollar amount?). ☞ The meaning of the assigned value (initial? default?) ☞ Whether the assigned value is rounded or exact. ☞ The intended scope of x. 22

Slide 23

Slide 23 text

Beware of communication by omission! 23

Slide 24

Slide 24 text

Communicate intentionally public let zeroDegreesFahrenheitInCelcius = -(160.0 / 9.0) ☞ Scope explicitly indicated. ☞ Constant nature explicitly indicated. ☞ Value represented (and its units) explicitly indicated. ☞ More accurate initial value used. 24

Slide 25

Slide 25 text

Communicate intentionally Always choose the appropriate: ☞ Scope ☞ Mutability ☞ Name ☞ Length (usually, short!) ☞ Location (DRY; SRP) 25

Slide 26

Slide 26 text

❝Leave this world a little better than you found it❞ —Robert Baden-Powell 26

Slide 27

Slide 27 text

Communicating around code: why? Sometimes we need to provide context: ☞ explain why code exists. ☞ explain when methods should be called (if not obvious). Note: code is still responsible for communicating how it works! 27

Slide 28

Slide 28 text

Communicating around code: how? Three main options: ➀ inline comments ➁ tests ➂ formal documentation (separated spatially; hard to maintain) 28

Slide 29

Slide 29 text

Inline Comments Example of a bad comment, used as a crutch: // This method applies a fix that prevents a crash. private func someObscureName() { // Non-communicative and overly-long code } 29

Slide 30

Slide 30 text

Inline Comments Example of a good comment, used to provide context: // This method fixes a crash introduced in v3.1.0. // It should always be called during application startup. // This code will be safe to remove once we update to v4.0.0. private func applyCrashFix() { // Communicative and succinct code, calling into several // shorter subroutines if needed. } 30

Slide 31

Slide 31 text

Tests: why? Help us maintain app stability while moving fast. 31

Slide 32

Slide 32 text

Tests: why? Act as living documentation of the code (forced to update). 32

Slide 33

Slide 33 text

Tests: stuff you should know ➀ There are different types for different levels of abstraction. ➁ Testing elicits strong opinions! ☞ How much is enough? ☞ When should you write your tests? ➂ Keep test code clean. ➃ Express external requirements through your tests. 33

Slide 34

Slide 34 text

Communicating in/around code: summary ☞ Write code with future readers in mind. ☞ Consider every inclusion/exclusion carefully. ☞ Use comments and tests to provide context. 34

Slide 35

Slide 35 text

Communicating in/around code: resources ☞ [book] Clean Code ☞ [book] The Pragmatic Programmer ☞ [book] Eﬀective Unit Testing (Java) ☞ [blog] Martin Fowler ☞ [website, long form articles] objc.io 35

Slide 36

Slide 36 text

Overview: self-directed learning ➀ Short term ☞ Balance productivity with investment in learning. ➁ Long-term ☞ Address your weaknesses. ☞ Steer your career. 36

Slide 37

Slide 37 text

Deﬁning self-directed learning ☞ Individuals take initiative and responsibility for learning. ☞ Individuals manage and assess their own learning activities. ☞ Mentors provide framework and context. ☞ Peers provide collaboration. 37

Slide 38

Slide 38 text

Measuring your knowledge 38

Slide 39

Slide 39 text

Measuring your knowledge Hypothesis: "I understand (a class, language construct, etc.) X" Tests: ➀ "I can reliably use X in my own code without looking it up" ➁ "I can explain the details of how X works in general" ➂ "I can place X in context and explain factors in its design" ➃ "If I had to, I could write my own implementation of X" 39

Slide 40

Slide 40 text

❝What I cannot create, I do not understand❞ —Richard Feynman 40

Slide 41

Slide 41 text

Tracking your progress ☞ Sense of accomplishment. ☞ Great for performance reviews/raises! ☞ Helps you gain a better sense of your overall strengths/ weaknesses and plan accordingly. 41

Slide 42

Slide 42 text

Tracking your progress: how? I like using Trello. Easy prioritization. 42

Slide 43

Slide 43 text

Expanding your knowledge 43

Slide 44

Slide 44 text

Leveraging your client work ☞ If you can, request the tasks that will let you learn things you want to/need to know, even if you're slower at them. ☞ Pair with experienced developers on cards. ☞ Observe experienced developers, asking questions as you go (more available brain power than standard pairing). 44

Slide 45

Slide 45 text

Leveraging your mentors ☞ Don't expect them to have time to teach you. ☞ Do expect them to be able to provide answers and context when you are stuck. 45

Slide 46

Slide 46 text

Leveraging your mentors How to ask a question when you're stuck: ❝Hi! I'm trying to accomplish [goal]. So far, I've tried [thing1] and [thing2] but neither of them worked. My current hypothesis is that [your current best guess], but that doesn't seem to make total sense because [some annoying obstruction]. What am I missing?❞ 46

Slide 47

Slide 47 text

Leveraging your mentors How to follow-up when a mentor answers a question: ❝That makes a lot of sense now, thanks! What were the clues that led you to this solution?❞ 47

Slide 48

Slide 48 text

Self-directed learning: summary ☞ Measure and track your progress. ☞ Try to assess your strengths and weaknesses scientiﬁcally. ☞ Utilize mentors' experience and high-level view of the world. 48

Slide 49

Slide 49 text

Self-directed learning: resources These are hard to ﬁnd. I'd love any recommendations you have! 49

Slide 50

Slide 50 text

The well-rounded iOS developer ➀ Become comfortable with both Objective-C and Swift. ➁ Know how to write unit tests. ➂ Learn some shell scripting (for building apps outside of Xcode). ➃ Understand app distribution (non-trivial!). 50

Slide 51

Slide 51 text

Objective-C & Swift ☞ Swift is structurally inﬂuenced by Objective-C. ☞ iOS frameworks are still written in Objective-C. Resources ☞ [book] Objective-C Programming (Big Nerd Ranch) ☞ [website, long form articles] objc.io (again) ☞ Apple docs (switch between Objective-C and Swift modes) 51

Slide 52

Slide 52 text

Unit tests ☞ XCTest (default) is a great place to start. Resources ☞ Apple docs on testing basics ☞ [long form article] objc.io #15 (yet again) 52

Slide 53

Slide 53 text

Shell scripting ☞ Used when building iOS apps outside Xcode. ☞ Also insanely useful for a bunch of random tasks. ☞ So powerful it should come with a health warning → 53

Slide 54

Slide 54 text

App distribution ☞ Apple security requirements make this a pain. ☞ First step is to understand digital signing: [book] Understanding Cryptography ☞ Then understand the "ﬂow of signatures": [blog post] Ray Wenderlich: iOS Code Signing: Under The Hood 54