Recap of Pragmatic Programmer

08/24/18 • 40 min

Pragmatic Programmer in Practice

Welcome to Iteration - A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.

In this more casual episode, we recap some of our favorite tips from the Pragmatic Programmer in the context of our recent projects and lessons. We talk though caring about your craft, not leaving any broken windows and more.

Picks:

John - http://www.hemingwayapp.com/

JP - better touch tool

Pragmatic Programmer in Practice

Welcome to Iteration - A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.

Picks:

John - http://www.hemingwayapp.com/

JP - better touch tool

Previous Episode

Sign Your Work

Chapter 8 - Pragmatic Projects

Season 2 - Episode 14 - Chapter 8 Part 2

John: Welcome to Iteration: A weekly podcast about programming, development, and
design through the lens of amazing books, chapter-by-chapter.

JP: This is part 2 of Chapter 8 - THE FINAL CHAPTER!

65 - Test state coverage, not code coverage

Identify and test significant program states. Just testing lines of code isn't enough

JP: Even if you test every single line of code - that's not what matters. What matters is how many different permutations of your app's state you have covered. drops mic

John: Coverage tools are nice - but they only give you a window into the state passed into it. If you can extract state out into separate objects or methods to be able to test them decoupled from time.

66 - Find bugs once

Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

JP: We don't have time to find a bug more than once... "We have to spend our time writing new code - and new bugs"

John: Step one of debugging - write a test that's failing. I broke this pattern this weekend. :(

67 - English is just a programming language

Write docs as you would write code: honor the DRY principle, use metadata, MVC, auto-generation and so on

JP: don't dread writing docs. it's part of your application. I think this tip is phrased in such a way to appeal to engineers. think of documentation writing as writing code, not writing literature

John: I like this in theory - I'm having trouble getting tooling in place for this that makes sense. I really want to dynamically generate, external API docs, internal docs and user guides totally automatically. Super struggling to get anything moving in rails.

68 - Build documentation in, don't bolt it on

Documentation created separately from code is less likely to be correct and up to date

JP: sometimes you need documentation. obviously, name your variables well, but sometimes explain what a function does or why it does it. at OL we'll sometimes write include the GitHub issue number for a weird quirk or to explain why a test is testing for certain functionality. treat docs like code. part of the code, not separate from it

John: I feel like this is a bit outdated. If written well modern languages really can be self-documenting. Basecamp really doesn't "do" code comments or internal docs - Per DHH - If there is a comment explaining a method or model I break it up further until it doesn't need explaining. I worship in the church of Henninger-Hansen.

69 - Gently exceed your users' expectations

Come to understand your users' expectations, then deliver just that little bit more.

JP: "Never lose sight of the business problems your application is intended to solve".

John: One of my favorite parts of the job is delivering features users get super jazzed about.

7- - Sign your work

Craftspeople of an earlier age were proud to sign their work. You should be, too

"Anonymity, especially on large projects, can provide a breeding ground for sloppiness, mistakes, sloth, and bad code. [...] We want to see a pride of ownership. Your signature should come to be recognized as an indicator of quality. A really professional job. Written by a real programmer. A Pragmatic Programmer"

JP: lol, git blame

John: Take pride in what you do.

Picks

JP: https://github.com/sindresorhus/refined-github
John: LG 22MD4KA-B UltraFine 4K Display 21.5" UHD 4096x2304 4xUSB-C

Next week: Pragmatic Programmer in Practice - Book recap in the context of our real-life development work.

Next Episode

Growing Applications

Growing Rails Applications in Practice: Part 1/3: New Rules For Rails

Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter
An Inconvenient Secret: Large applications are large

This book is about scaling your codebase. The amount of pain you feel should be logarithmic, not exponential.

This is not about revolutionary design patterns or magic gems that make all your problems go away. Instead, we will show you how to use discipline, consistency, and organization to make your application grow more gently.
Beautiful Controllers

Should functionality go into the model or the controller?!
"Less business logic in our controllers, the better"
The authors argue for a standard controller design for every single user interaction. that is to say, it should only handle HTTP requests
EVERYTHING is CRUD
example of a stripped-down controller where Note controller never talks to the model directly.
"Every controller action reads or changes a single model. even if an update involves multiple models, the job of finding and changing the involved records should be pushed to an orchestrating model"
controllers should contain the minimum amount of glue to translate between the request, your model, and the response

Relearning Active Record

Data integrity with callbacks -> later in the book, we'll talk about how to not use so many callbacks
bad:

class Invite < ActiveRecord::Base
def accept! (user)
accepted = true
Membership.create!(user: user)
end
end

invite.update(accepted: true) # => circumventing the accept! method
better:

after_save :create_membership_on_accept

private

def create_membership_on_accept
if accepted && accepted_changed?
Membership.create!(user: user)
end
end
User interactions without a database

Not all user interactions need an active record model.
Example: sign in form that uses sessions. when the form is submitted, you don't end up inserting a row in a table in your db
start taking your controllers from hell -> putting that logic in your model (models from hell?)
you know things are a pain when you have to use form_tag and can't use form_for
one thing to note is that the example sends notifications (i.e. SMS, email) in their model and not their controller