Recommended
Recommended
More Related Content
Similar to Writing Code Like Poetry
Similar to Writing Code Like Poetry (20)
Recently uploaded
Recently uploaded (20)
Writing Code Like Poetry
- 1. Writing Code Like a Poet Applying creative writing techniques to writing code
- 2. Prerequisite Who Am I Slide Brandy Foster • Android App Developer at Detroit Labs • Diversity and Inclusion Coach • Mother of two boys • Facebook Poet
- 3. Table of Contents • Background • Speaking Words • Coding Poetry • Summary
- 5. Two roads diverged in a yellow wood… And sorry I could not travel both.
- 7. Pre-Writing • Brainstorming • What is the story I want to tell? • What value should this story provide to the audience? • Research • Are there similar stories I can leverage?
- 10. Drafting Define Who is my audience? How should I tell this story? Gather What do I need to tell this story?
- 12. Define the best way to tell the story
- 13. Gather resources to help me tell the story
- 14. Writing and Revising • Find the First Line • What comes to me when I think of this story? • Edit as You Go • Does it all make sense together? • Does this line break the rhythm? • Stay in the Current Line • Am I rushing this line? • Does this line belong here and now or somewhere else later? • Each Line is a Poem • How much context is needed to understand each line?
- 15. Start at the beginning
- 16. Keep the rhythm
- 17. Don’t rush ahead
- 18. Each line should be able to stand alone
- 19. Publishing • Get Feedback from Non-Poets • Does a non-poet understand what my poem is about? • Is my piece unnecessarily complex? • Get Feedback from the Poet in the Mirror • Does my body language, tone, inflection, and volume add to the piece? • Get Feedback from a Poet • What criticisms does a fellow poet have? • Get On Stage • How did the audience react to the piece? • How can I improve my performance next time?
- 20. Elicit feedback from anyone who will listen
- 21. Face the mirror
- 22. Take it to a professional
- 23. Take it to the stage
- 24. Then took the other, as just as fair… And having perhaps the better claim, because it was grassy and wanted wear.
- 25. Writing clean code is like writing any great literature
- 26. My Simple Quote Generator App
- 27. Inspiration Comes in Many Forms
- 28. Pre-Writing Refinement • Brainstorming • What is the user story? • What value will the feature provide to the user? • Research • What is the code currently doing? • Is there existing code I can leverage? • Am I doing something unfamiliar that I need to learn more about?
- 29. Research the code base
- 31. Drafting Planning • Define • How should I implement this feature? • Gather • What resources do I need to complete this feature?
- 32. Define how to implement the feature
- 33. Gather together what you know you’ll need
- 34. Writing and Revising Coding • Find the First Line • Where is the entry point for the feature? • Edit as You Go • Do I have a test for any logic I’ve added? • Does the code I’ve added match the standards/styles of the code base? • Do I need every line I’ve added? • Stay in the Current Line • Am I coding for this feature or the next? • Each Line is a Poem • Do my naming choices make sense alone or only within the context of the code base? • How dependent is each line/method/class on other parts of the code base?
- 35. Find the entry point for the feature
- 37. Add your tests classes as you go
- 40. Only work on the code you need to complete the task you’re on
- 47. Review your naming conventions
- 49. Run it one more ’gain
- 50. Publishing Releasing • Get Feedback from Non-Developers • Could a non-developer understand what my code is doing? • Is my logic unnecessarily complex? • Get Feedback from the Developer in the Mirror • If this were not my code, would I still be able to follow the logic? • Get Feedback from a Developer • What comments does my developer neighbor have about my code? • Get On Stage • What comments do the larger team have about my code? • How can I improve my code quality next time?
- 51. Review your code like a non-developer
- 52. Face the developer in the mirror
- 53. Put up that PR
- 55. tb;do Too boring; Drifted off
- 56. How to Code Like a Poet: Abridged Know your story Research unknowns Review what exists already Pull together your resources Create a game plan Start at the beginning Treat each line as if it stands alone Stay in the present Write, Revise, Repeat Get feedback from everywhere Carryover learnings
- 57. The End
Editor's Notes
- Writing poetry for a long time Carthartic Open mic Spoken word was different Son was learning writing process Adapted this process to increase self reflection as I created a piece by asking myself questions to help me organize my thoughts and create with purpose
- In this section we’ll use the process to create a spoken word piece
- This is a real article Somewhere in the article it mentions them being threatened with not attending prom Instead of word vomit of how upset I am, will use the process
- I want to tell the story of these girl who show up to school feeling good about themselves, and then finds themselves being discriminated against I want the audience to feel their pain and anger, to remember that discrimination is happening still today and maybe even be motivated to raise their own awareness so something like this couldn’t happen in their space
- I sadly found out this is happening a lot
- There were even more articles but these slides are already overflowing
- Knowing who you're writing the piece for is important because you don't want to make a lot of references your audience can't relate to because then they'll lose interest in your story or never connect to it My audience today is you, and so I have to keep that in mind that many of you may not have life experiences that resemble the girls in the article
- Knowing your audience is an important part of figuring out how to tell the story I want to evoke emotions so 3rd person is out. In this instance, you are my audience so telling this story in second person may not relate well Selected 1st person narrative/character portrayal I imagine a girl feeling good about having her hair done and showing up to school Math class
- Add math references and historical references most people can relate to I keep my research near by for easy reference A thousand tabs are always open
- I start at the top each time, adding a line or two as I go
- Edit as you go: Does this all make sense together? Does this like break the rhythm As I add a new line, I start at the top and say it all together I make small revisions each pass
- Stay in the current line: Am I rushing this line? Does this line belong somewhere else? Sometimes it can be hard to be patient when you can see the whole plot It’s important you tell the story organically Some lines just don’t belong even if they’re great
- Each line is a poem: How much context is needed to understand each line? The poem itself? This came from a poetry workshop and while I can’t say every line I write is a poem onto itself, it’s something I strive for
- Get feedback from non-poets: Does a non-poet understand what my poem is about? Is my piece unnecessarily complex? I start sharing pieces of my pieces with friends as soon as I feel like I have something Are my word choices poet elitist? Sometimes you can do interesting things with word play that end up harming the piece
- Get feedback from the poet in the mirror: Does my body lanuage, tone, inflection and volume add or detract from the piece? I practice and practice even as I add and edit. I use the voice recorder on my phone or pretend like my kitchen is a stage
- Get feedback from a poet: What criticisms do they have? I reach out to friends who are poets or lovers of poetry for poetry specific critique
- Get on stage: How did the audience react to my piece? How can I improve my performance next time? After performing a piece for the first time I seek out feedback from audience members Confession: I rarely perform the same piece twice
- Came into development through the apprenticeship Writing code wasn’t hard but writing clean code was My first solo PR got torn apart but the feedback helped me see I needed to work on my performance
- I decided to use my adapted writing process to help me write cleaner code
- I have an app that will generate a random quote when the user opens the app The only problem is that in order to get a new quote a user must background and foreground again, not very user friendly
- This user story is pretty straight forward, give the people a button! The value will be giving the user control over generating a new quote on demand
- Review any existing code to understand what the application is currently doing Look for classes/objects that you can use to complete your feature so you don’t accidentally reinvent the wheel
- We all know that the most important skill a developer needs is google-foo. I’ve never added a button to a constraint layout, so I wanted to get some insight into how to do that before I tried it. Save me time.
- Depending on the size and complexity of the feature it can be vital to create a game plan of how you will implement the feature. Use task lists, whiteboarding or sticky notes… whatever works to help you envision the feature in it’s entirety and organize the path to completion
- I keep my research handy for easy reference while I’m working
- Find the first line: What is the entry point for this feature Find the place where the input is changing This feature will require a refactor so that is the starting point
- It's important that as we add code we respect and follow current architecture.
- Edit as You Go: Do I have a test for any logic I’ve added? Does the code I’ve added match the standards/styles of the code base? Do I need every line I’ve added? I like to add my test class as soon as I create a new logic class. Android Studio makes this really easy.
- I add mocks for the objects I think I will need in my presenter to complete the class. This helps me to stay organized and respect the vision while also keeping my changes small and focused. This means that sometimes I add things that don't exist yet.
- Next I add the real objects to the class. I use my test class as the framework. This cuts down on adding unnecessary code because I’m only going to add what my test needs to be green If this was a larger project as I was building out my presenter I would check to ensure my presenter followed the pattern of other presenters and their tests in the code base.
- Stay in the current line: Am I coding for this feature or the next? While the feature of the story I pulled was to add the button, the refactor was the first step. As hard as it can be when you're doing clean up work, it's important to treat the refactor as the new shiny part.
- Before going too far along, it's important to add a simple test of any refactored changes to your classes
- Write the code to pass the test. We have to wire our new presenter up to communicate with the Main Activity through our new interface.
- After simple changes are tested, you should refactor your test class to reflect the scope of the class I personally use a test name format of: method that I am testing, what should happen when it's called, when conditions are met. I know some people prefer testing each end result separately but in my mind if any one thing of many fail, then it's a failure so it's okay to group them. I group by condition
- I have no experience with constraint layout so I had to open up my resources to figure out how to move my button into the center
- Now that our refactor is finished we can write a test for our new feature. I'm a copy and paste gal myself
- Once our test has been added we can write the code we need to pass that test. Again, staying present as I'm adding the logic for my button I can see that the code to make the sdk call is living inside my onResume method. I don't want my button to call that method because the naming isn't intuitive. The button is not resuming the app. So, refactor of my refactor is in order.
- Each Line is a Poem Do my naming choices make sense alone or only within the context of the code base? How dependent is each line/method/class on other parts of the code base? Would a rose by any other name smell as sweet? No. Naming is important. You're going to appreciate your careful naming conventions in 6 months. It's better to take the time now than to cuss your past self out when you can't easily find a class or variable because you named it aVariable in a rush to finish your task. This sample app doesn’t have dependencies but beware in larger code bases.
- I do one final review/touch up on my code before I call it "done". I wanna make sure before I call this draft final that I’ve respected the code base. I’m following established patterns, my naming conventions make sense, I don’t have unnecessary or unused code, my code isn’t overly dependent on other classes, which for this really small app wasn’t likely but for larger applications again, you wanna ensure that your code doesn’t have dependency issues. Odds are that if your class needs another class to do all it’s work, your code belongs in that other class. Lastly ensure my unit tests are all passing
- After all my unit tests are passing, I make sure to run the app to make sure that's still working too. Confession: It wasn't. I had to go back and make some code changes to fix the text padding.
- Remember when you couldn't read java? Well, go back in time and review your code. Even without understanding the syntax could you understand the logic? Well written code should read like a story of app functionality. With common language and descriptive naming conventions the purpose of the code will be plain and the need for context will be less. If only a senior developer would understand your code, then odds are you've not only over architected but you're code is probably hiding bugs that only a senior developer will be able to find. Refactor!
- I'm a naturally critical person. I'm hyper self-critical so this is easy for me. Step back from your code, disassociate if you need to, and look at it with fresh-ish eyes. If you hadn't written it, would you still understand what the logic is doing? If one of your team mates had submitted this code for review, what comments would you make? Remember this isn’t your code… it belongs to the code base.
- Most teams have some sort of code review agreement they follow before allowing code to be committed to master and released into the wild. If you don’t, when you get home… get one. You can not take in critical feedback when it feels personal, so remove any feelings of attachment and ownership. Remember you are not your code Respond to comments that will require code changes that you acknowledge them. If you can give an ETA on the changes, give that too. Respond to comments that you disagree with, by first acknowledging their opinion then be clear that you will not be taking their suggestions and be clear why. Most importantly, requests for changes or not, thank your team for taking the time to review your PR. Appreciation is appreciated and it helps encourage feedback in the future. Note, you should pay good reviews back in kind by giving great reviews of your own. That might be another talk
- You should view every story you complete as a chance to learn something new about your language, your code base, your developer skills and yourself. Take what you’ve learned and apply it to the next story you play Hint, if you’re like me and you have CRS, then take notes of pitfalls you climbed out of with the resources you used. Those kinds of artifacts are also great to share with the larger team and spread the knowledge.
- Ok, in case anyone dozed off I’m going to end with the main ideas