2013 codecraft breakout

Notes from clean coding breakout From Evernote: Code4Lib 2013 - Clean Coding

(The following is an edited version of notes taken by Megan Kudzia. Thanks to her for taking notes and sharing them.)

It started with Devon Smith talking about what motivated his thinking on this topic. After watching a video of a man making an axe he started thinking about whether or not his work was "craft" or if it should be. He wanted to go over what "code craft" is to him, why do it, and how to do it.

What?

• Improving first the code as a deliverable
• Then second improving the application derived from the code

Clean code is a gift to other coders and to our future selves.

Why?

• We all have limited time - putting shitty code out seems like a waste of that time
• Am I respecting myself and my limited time enough?
• If I'm not doing it better, I'm wasting my most precious resource

How?

• Trickier
• You have to do it a lot to get good. Mastery takes repetition.
• Revisit your code to see what you can improve
• Rewrite an application I've already written to learn new languages, experiment with new libraries, new storage systems, etc.
• Everything you do is an experiment - you will always be iterating.
• "We'll get to it later" doesn't happen unless you schedule time for it. Sometimes you have to do it for yourself later, too, if the project has moved on.
• Test-driven development (I'm writing tests constantly and throwing them away)
• Test unit folder? Integration test? Capybara.
• It makes others nervous to commit without tests to run against the code
• Testing may not actually improve the code, but it DOES improve the deliverable
• Documentation!
• Read other people's code to make your own code better.
• Have comment/test standards

There are people out there who don't want to improve.

Code reviews

• One place has a standard two-person team for every project; they also have standardized syntax across the organization. If the code doesn't meet the standard, it doesn't get a commit.
• Dan Chudnov - code reads at George Washington (external code).
• You write a better program when you understand the domain
• Code audits between people across one-person shops?
• Contribute to something open source to develop your skills
• Grant funding? People who have a stake in the code will care more. The challenge is finding people who have a stake but aren't actually writing it
• Git for code review?

Specs

• Do a write up/spec on your projects ahead of time to prevent scope creep
  • Project one-pager
  • A one-page wiki with some bullet points
  • Do we have a UX group? Can we put one together?
  • Document shared expectations!
• A spec is a good thing but it can't be a be-all end-all, as some things just aren't possible.

Testing

• English writing test writing thing called Cucumber
  • Relish builds documentation out of the Cucumber tests
• Story writing workshops with users and index cards - here's my test for your story, does it pass?
• One way to deal with extra crazy ideas is to put together a trade off list; a comprehensive list of proposed ideas with a list of how long it would take to implement each thing (if everything else stops) - managing expectations (Agile)
• You can probably not worry about testing front-end code; you'll hear about it if it doesn't work

Other ideas

• Have the courage to throw out your work! If you have time.
• Look for code contests to participate in
• It's important to understand upfront where the pain points are to prioritize
• Static analysis tools?