Welcome to Iteration, a podcast about programming, development, and design.

• John Intro — My name is John and I am a software developer for a home services startup.
• JP Intro — Hi, I'm JP and I am a software developer.

What makes a good 1:1 (IC perspective)?

• JP a manager who listens
• JP clear action items for problems

What makes a good 1:1 (Manager perspective)?

• John When reports are honest about motivations (I want more money, etc)
• John Clear feedback about my management

What makes a bad 1:1?

• JP when 1:1s just become another medium for standup updates
• JP when 1:1s become a way for your manager to micromanage

Format

What do you talk about?

Basic framework John follows:

• private running doc between manager and report, either party can always add to it, reviewed on a regular cadence. I've found every 2 weeks to be really effective.
• This meeting is for building trust, context, sharing progress on goals, professional development things like that.
• Principles / concepts
  • Focus on the report — 1:1's are primarily for the report, the employee, not for the manager or the company.
  • 70/30 — Manager should be 70% listening less than 30% talking.
  • Honesty — be direct. Forbidden conversations.
  • Objective — Do the work to find objective examples, provide numbers and letter grades.
  • Flexible — Don't overthink or over structure, let it flow, let report guide conversation
• Moneyball firing clip

Picks

• John: https://www.chia.net/
• JP: Tailwind is coming out with official React support!

Welcome to Iteration, a podcast about programming, development, and design.

• John Intro — My name is John and I am a software developer for a home services startup.
• JP Intro — Hi, I'm JP and I am a software developer.

Context:

John ran an agency for a couple years with a few developers + Designers, now runs a team of 12(ish) developers + Designers

Few Topics

IC vs Manager

• Code on the side only to show things
• Not coding for production
• Code outside of your core code

Right sizing a team

• Systems Thinking "Stocks + Flows" (Slack)

Mythical Man Month

• False premise: More heads = faster results

Remove bottlenecks

• Break up the work
  • Kitchen Metaphor
• Context + Documentation

Safety + Empowerment

• Permission + Trust
• Access

Leading by example

• "Law of the lid"

Don't scar on the first cut

Forbidden Conversations / honesty

Picks

• John: https://handmirror.app/
• JP: https://freezingcam.com/

John has been asked:

• When I perform a google search, what happens? Be as specific and accurate as possible including every layer of technology.
• Can you tell me what Indexes are and what they do?
• What is CORS?

Questions JP has been asked:

• What is the difference between something like SQL and Mongo - what are the trade offs?
• How does the JS bridge work in React Native?
• Describe what Redux is for and how you'd implement it in a React project

Maybe some from our own?

• If you could add one feature or change to the Rails framework what would it be?
• How do feel about testing? How do you think about testing? When does it make sense to write tests?
• If I have a really huge model, let's say 500+ lines, how would you go about refactoring it? Example link: https://github.com/discourse/discourse/blob/master/app/models/post.rb

Picks

JP: https://tuple.app/

• I used this to pair with Joe and it was SICK

John: YNAB (https://www.youneedabudget.com/)

• Different approach to budgeting that sucks less

> Welcome to Iteration, a podcast about programming, development, and design.

* John Intro — My name is John and I am a software developer for a home services startup.

* JP Intro — Hi, I'm JP and I am a software developer.

# Questions

* What is your testing philosophy?

* Why work on that team specifically? Why are you interested in this job?

* What kind of problems he like's to work on?

* What are some challenges with maintaining a public api?

* If I was your manager, what can I do to get the most out of your contribution? What do you need from me to succeed as a developer?

### Picks

* John M1 MacBook — So throughly impressed

* JP - [https://github.com/procore/handcuffs](https://github.com/procore/handcuffs)

Welcome to Iteration, a podcast about programming, development, and design.

https://www.planview.com/resources/guide/introduction-to-kanban/kanban-vs-scrum/

AGILE!!! SCRUM!!! KANBAN!!!

Different Tools

• Jira
• Trello John
  • Asana John
  • Github (issues + projects) John
• Zenhub John
• Pivotal Tracker
• Notion John
• Special mention: Canny.io → https://main-street.canny.io/admin

New Blood

• Linear App: https://linear.app/
• Height App: https://height.app/ (private beta)
• Monday? I always see ads for this on youtube: https://monday.com/
• BASECAMP

Picks

• JP: https://martinfowler.com/articles/feature-toggles.html
• John: https://supabase.io/ (Open Source Firebase)
• https://elainewherry.com/2012/06/26/the-recruiter-honeypot/

John: Welcome to Iteration, a podcast about programming, development, and design.

• John Intro — My name is John and I am a software developer for a home services startup.
• JP Intro — Hi, I'm JP and I am a software developer.

What is e-commerce?

Build vs. Buy (roll your own vs. e-commerce software)

Nitty-Gritty

• How to model purchases
• Model Payments
• How to test payments
• Gotchas when building e-commerce
• Discounts
• Sales
• Coupons
• Refunds
• Inventory vs digital goods
• Headless vs “full stack”

Stacks / Services

Inventory and More (full stack)

• Shopify
• BigCommerce
• Magneto
• Solidus
• Spree

Simple / digital only

• Instagram + Paypal
• Gum road

Saas Solutions

• Stripe Checkout
• Paddle
• Fast Spring
• Chargify
• https://recurly.com/

Picks

• JP: https://hotwire.dev/ (hehe)
• John: https://linear.app/

References

• Acts as shoping cart gem
• Pay gem
• Foundation

• Severless (Lambda functions)
• PWA (progressive web apps)
• Headless (Ecom / cms)
  • Contentful
  • Shopify

Tech Trending Upwards

• E-commerce (up 37% from last year)
• Artificial Intelligence
  • (AWS sagemaker, GPT-3)
• Voice search
  • 66million smart speakers - 1/3 27% of mobile searches are voice based
• AMP'd
• Apps will continue to ruin the internet
• Chatbots
  • JP: I personally hate these things. Just get me to a customer service rep ASAP

Picks

JP: https://baratza.com/grinder/encore/

John: A conversation with GPT-3

John: Welcome to Iteration, a podcast about programming, development, and design.

• John Intro — My name is John and I am a software developer for a home services startup.
• JP Intro — Hi, I'm JP and I am a software developer at a small analytics startup

Our 2020 Goals Episode → Link

✅ 2020 Developer Goals

2020 Review

JP

• Goal 1 (JP): Build Elixir App: (C+)
  • I did build a really quick proof of concept Rust API that spits out some JSON
  • I also followed a tutorial for a full stack Golang app
• Goal 2 (JP): System Design (F)
  • Did not read the books that I wanted to read
• Goal 3 (JP): Algorithms - (C+)
  • Just haven't had the time - but I have reviewed some array based algorithms FWIW

John

• Goal 1 (John): Blog More (C+) (12+ posts)
• Goal 2 (John): (F) System Design (Nope)
• Goal 3 (John): JavaScript (B+) 2 Courses, built way more shit in JS Stimulus Mainly
• Goal 4 (John): Focus 💯 (Closed agency, no more clients, doubled down on what I am good at)

Top 2020 Trends (From John)

• Remote Work 😷
  • Remote jobs used to have a requirement of having remote experience... now everyone has this experience
• Commercialization of Open source 🤑
  • "Open source" that's also a product / company
  • https://www.gatsbyjs.com/
  • https://nextjs.org/ (Vercel)
  • https://www.cypress.io/
  • https://www.sanity.io/
  • https://github.com/mperham/sidekiq
  • Even Microsoft acquisition of Github and continued changes there VS Code → Atom
• "Niche" frameworks 🍾
  • https://svelte.dev/
  • https://github.com/alpinejs/alpine
    • This is Tailwinds' go-to for a JS solution
    • bridgetown
• "Hey" made server rendered sexy again 👋
• JavaScript continued to eat the world 🍽️
  • Vue 3 added a composition API that's very similar to React Hooks
• Low Code / No Code ✨
  • https://bubble.io/
  • https://pipedream.com/
  • https://stacker.app/
• Data warehousing 🤓
  • https://www.tableau.com/
  • https://mode.com/
  • https://looker.com/

Picks

JP: https://www.rrauction.com/preview_gallery.cfm?Category=449

John: Rails starters:  https://jumpstartrails.com/ — https://bullettrain.co/

John: Welcome to Iteration, a podcast about programming, development, and design.

• John Intro — My name is John and I am a software developer for a home services startup.
• JP Intro — Hi, I'm JP and I am a software developer at a small analytics startup

https://macwright.com/2020/05/10/spa-fatigue.html

Topics / Guiding Questions

What's a SPA?

From the article

1. The main UI is built & updated in JavaScript using React or something similar.
2. The backend is an API that that application makes requests against.

The more techincal one:

https://developer.mozilla.org/en-US/docs/Glossary/SPA

An SPA (Single-page application) is a web app implementation that loads only a single web document, and then updates the body content of that single document via JavaScript APIs such as [XMLHttpRequest]() and Fetch when different content is to be shown.

This therefore allows users to use websites without loading whole new pages from the server, which can result in performance gains and a more dynamic experience, with some tradeoff disadvantages such as SEO, more effort required to maintain state, implement navigation, and do meaningful performance monitoring.

Why do developers choose SPAs?

Do end-users care about SPAs?

What SPAs have you worked on / maintained?

• 0 —

When should you reach for a SPA?

• That's the right use case: Desktop app to the web.
  • Spotify, Figma, photopea.com
• Breaks REST might be a good time to consider
• Community

What's wrong with this SPA's?

Increased complexity — Development and deployment

• Often times: 2 repositories, 2 languages or frameworks
  • (Rails + Vue)
  • (Node + Angular)
  • (Rails + React)

SEO + Speed — Have to do "Server Side Rendering"

• This reminds me of the light switches for "Smart" light bulbs. You've increased the complexity by a factor of 10 to get the exact same results.

Maintainability? Stability?

If not a SPA then what? (Is this a different Episode?)

What's good about server rendered?

• How much you get for free
• Async fetching
• State management
• URL's just work
• Strong Conventions
• Stable minimal maintenance

What's bad about Server Rendered?

• Page Reload
• Can feel clunky
• Less Reactive
• Mobile App — Now what? SPA lays a stronger groundwork

What's good about SPA's

• Benefits are for the user
• Developer Ego's
• Data foundations
• Breaks CRUD
• Community
• Pushing technology forward is a good thing.

What's bad about SPA's

• How much of a pain in the ass it is to Manage URL's
• Complexity — Front end + Back end
• Authentication
• Image Upload
• Multiple API endpoints for a single page
• State is way harder in a SPA
• Debugging

Closing Thoughts

• SPA's are great when you are breaking "REST / CRUD"
• SPA's are great when you need multiple consumers of the same data
• This is highly personal, you gotta go with what you love.
• WiFi

Picks

• John — Distraction Free Phone from the book Make Time
  • Mobile: Uninstall all "Infinity Pools" put "Parental controls" on for the rest. 3.5 hours down to 1 hour screen time. So much time back. Switched out twitter for Kindle.
  • Other tip: Instagram Threads — only the shit you care about with no ads
  • Desktop: https://selfcontrolapp.com/ —
• JP - https://railsnew.io/

JP: Welcome to Iteration, a podcast about programming, development, and design.

• JP Intro — Hi, I'm JP and I am a software engineer at an analytics startup. Today, I am joined by John:
• John Intro — My name is John and I am a software developer based in Los Angeles CA

Today's topic

The "Codeless" movement, otherwise known as "Low Code / No Code"

Said another way: Is Bubble and GPT-3 coming to take all of our jobs?

We aren't talking about "Serverless" (Ex: Firebase / Aws Amplify / Parse) — Could be a good future episode.

NOT tools like Auth0 or Twillio

This is a "Full Stack" — No code app development framework in the cloud.

WYSIWYG for "Apps"

This isn't software!

Popular Codeless tools

Full "App" Development

• https://bubble.io/ (Most Powerful, widely used)
• https://www.appsheet.com/
• https://www.glideapps.com/
• https://thunkable.com/

Internal Tool replacements — Kind of mini-modern salesforce or filemaker clones

• Airtable
• Retool
• Smartsheet
• Notion
• Quickbase

Domain Specific Codeless

• Shopify ← eCommerce
• Sharetribe ← Build a Marketplace App
• Substack ← Paid Newsletters
• Mighty Networks ← Paid Communities
• Podia ← Sell online courses
• So so many more

Upsides of Low Code

• Low Code / No Code is an incredible tool for going from 0-1.
• All Notes

Downsides of Low Code

• Low Code / No Code is most ideal for basic CRUD or internal simpler tools. Reading, updating and managing listings of data. Or — Very Domain specific (Shopify for eCommerce)
• It can be very hard to maintain, since you don't "own" your stack.
• Very very expensive to scale (Still cheaper than a team of Devs)
• Tons and tons of gotchas

John's Opinion:

• Prototype + Build V1 of everything you can with no-code or off the shelf systems. Get things in customers hands.

Biggest Issue — Low Code doesn't fix the Hard Part of Software

• Notes

Other thoughts regarding of Low code

• Non tech sees code as "Barrier" not "Force Multiplier"
• Often times the time saved is actually due to the compromises made with a low-code / no code tool.
  • Examples of compromises include:

Recommendations for Using Low Code Tools

• Accept the limitations
  • Spending too much time trying to solve for nit-picky edge-cases is likely to be a time suck here. Low-code / no-code will likely have rough edges and performance issues. Just embrace the hackyness.
• Don't ignore best practices of user interviews, research and domain design.
  • Just because your not "coding" doesn't mean you shouldn't do your homework and have confidence before building. It's very easy to waste time building the wrong thing.
• Think about the data and lock in
  • Where does data live? Is it secure? is it backed up? Is it in a silo? Can it be migrated / exported?

Popular Codeless Resources

• https://www.nocode.tech/ (Community and resource list)
• https://zeroqode.com/ (Templates — Literally Buy an Airbnb clone for $300)

Good Articles / Podcasts on Low code / no code

• Ryan Hoover: The Rise of No-Code
• Podcast: Going Codeless: Is this the way of the future?
• Forbes: The Low-Code/No-Code Movement: More Disruptive Than You Realize

Picks

• John — Lighthouse Chrome Dev Tools
• JP - https://github.com/kelseyhightower/nocode

John's blog post on the topic

Picks

• JP: Siema Slider
• John: Rough Notation JS

This week we talk through the most common abbreviations in software. 

For a whole complete list and discussion — visit this link

Picks

• John: Teladoc
• JP: https://github.com/scenic-views/scenic

Links 

• JP on Twitter
• John on Twitter

Onboarding into a new codebase

As a new hire / contractor for a freelance project

From JP:

• Reviewing other people's PRs on a new codebase
• Submitting your first PR
• Understanding how data flows through the app
  • I've found that the organization of the code and the quality of abstractions makes or breaks this point
• Ramping up complexity of feature stories that you can tackle. How do you get there?

From John:

• First — Understand the domain, talk with team, read books, use competitor software, language in that domain.
• Then — Understand the software
  • Read the Docs, all that you can get your hands on
  • Review closed issues / tickets, try to understand the language /culture of the team
  • Review the tests, this is a good place to start if there is any, especially integration or feature tests that are higher level
  • Find the "God" objects if you can.
  • Write docs as you go, great way to get it into your head

Onboarding someone else onto a new codebase

From JP

• Hiring contractors for a project
• Onboarding new hires
• Reviewing new hires' pull requests **it's own episode maybe? Code Review?**
• How do you onboard someone else?
  • I think domain context is important

From John

• Support the advise given above! It's just the reverse
• First: Domain Context
• Then —
  • Provide Docs
  • Tests
  • Simple first issue
• Pair on the onboarding Dev's first PR VS sink or swim
• Try to demonstrate what tools and process you use in a project

Picks

JP: https://apps.apple.com/de/app/meeter-fast-call-initiation/id1510445899?l=en&mt=12

John:

• Rails View Components
• It's a new pattern in rails to produce reusable front end "Partials" but more abstracted and re-usable.
• This pattern plus stimulus.js is really magic.

Welcome to Iteration, a weekly podcast about programming, development, and design.

• JP Intro — Hi, I'm JP and I am a full stack developer. Today, I am joined by John:
• John Intro — My name is John and I am a software developer for a home services startup.

What are soft skills? Why are they important? Are they important?

Wikipedia defines "soft skills" ...

Soft skills are a combination of people skills, social skills, communication skills, character or personality traits, attitudes, career attributes, social intelligence and emotional intelligence quotients, among others, that enable people to navigate their environment, work well with others, perform well, and achieve their goals with complementing hard skills.

tldr; people skills

Hard skills, also called technical skills, are any skills relating to a specific task or situation. It involves both understanding and proficiency in such specific activity that involves methods, processes, procedures, or techniques

Conversation is loosely based on this book, the author is famously kind of a dick. Doesn't mean there aren't some solid takeaways, using it as a framework for conversation.

• Link to summary of "Soft Skills"
• Another summary

Section 1: Career

Few tips to improve your career:

• From SS: Specialize, don't generalize.
• From SS: "Fake it till you make it"

John

• Always be working on yourself: "Luck is when preparation meets opportunity"
• Meet lots of people, be helpful and friendly
• Do a lot of interviews.
• Confidence and enthusiasm — "Being enthusiastic is worth 25 IQ points."

JP

• The importance of friendliness. How does this work for introverts?

Recommended Career Books

• Linchpin
• Startup of You
• JP: Crucial Conversations

Section 2: Marketing yourself

• From SS: See yourself more as offering a service and not as a employee.
  • Less about Salary and work hours, more about the uniqe "Features and beniftis" you bring to the table, you solve problems, you are an investment not an expense.

John

• Blog, be vocal — Share what you learn, don't be afraid to look dumb.
• Teach others when you can
• Take speaking and presentation gigs (Was a speaker at GA and got work out of it, you never know)
• Again — Specialize

JP

• I love this idea around you being a service. EAAS: Engineer as a service
• I have mixed feelings about marketing yourself. I go back and forth on whether or not I want a bigger online presence

Section 3: Learning

From SS: "Learn you want? Teach you must."

John:

• Be consistent. 1 hour a day for 12 days is way better than a single 12 hour day.
• Try to understand the concepts, not the syntax.
  • Concepts and fundamentals you can take anywhere. Good domain design, testing, clean code. All these concepts work in any language / framework.

JP:

• Deliberate practice. I just hammer concepts into my brain until it sticks.
• Honestly, just keep writing code but more importantly keep READING code
• Whiteboard, talk about problems from a domain perspective

Section 4: Productivity

From SS: Focus

• John: +1 (20% done isn't worth anything. 5 tasks 20% done, or 1, 100% done)

From SS: Pomodoro Technique

From SS: Kanban

John:

• Getting Things Done
• Break down the work.
• 80/20 — Pareto principle
• Eat that Frog

JP:

• I'm currently giving Pomodoro a shot. I'm trying to figure out how to effectively context shift
• How do you eat an elephant?

Sections 5 and 6 — Financial and Fitness

Section 7: Spirit

From SS: power of positive thinking

From John:

• Mental space, day off, unplug sometimes.
• Confidence + enthusiasm

JP:

• I could use some tips from this section...

BONUS From John: Communication

• This one probably goes at the top of my list.
• #1 — Learn to be a better writer.
  • Book: On Writing Well
  • Tool: Hemingway Editor
  • Headline writing — Most important things first
• Learn how to explain complicated topics. ELI5

Picks

• John: Naps
• JP: Loom screen recording

Welcome to Iteration, a weekly podcast about programming, development, and design.

This week — javascript frameworks

What is a JavaScript Framework? How would you explain it?

• John:
  • Concept of a framework, is essentially a collection of best practices and starting points.
  • When you build a fence, you could literally cut down trees and make boards, make nails out of raw iron
    • At Lowe's the other day, they had pre-assembled fence sections. This is what a framework is.
  • Some frameworks offer really prescriptive and complex components, others offer really basic ones. (2x4's vs pre-built fence sections)
  • in JS — It's basically a pre-existing library and collection of JavaScript code you can use to do other things with.
• JP: wrappers around document.querySelector + some sort of state management
  • Programing is all about abstractions —
  • Shared abstractions

Framework vs Library

• Line is blurry here, example: JQuerry, lodash underscore are closer to libraries. These are more collections of useful utilities and functions. Frameworks are more comprehensive. Offer a more end to end solution for back end, front end or both.

JP JavaScript Ecosystem is Frustrating

• https://www.zdnet.com/article/another-one-line-npm-package-breaks-the-javascript-ecosystem/
• This one line change in an npm package broke deploys for one of my sites

The 4 most Popular Frameworks (in order of creation date)

There are SO MANY JS frameworks, feels like new ones every day.

• JQuery:

  • The "Original Gangster". Oldest and biggest project, not the most modern, still heavily used worldwide. Not really a "Framework" with modern JavaScript, it's not really needed, especially if you use one of these other frameworks, it's definitely not needed in my opinion.
  • Github Stars: 53k
  • Initial Release: 2006
    • From JP: https://mootools.net/

• Angular

  • Github Stars: 60k
  • Initial Release: 2010
    • John: It's been years since I've worked in an angular project. It was a previous version of Angular, but it was close to writing HTML, using Vue reminds me of Angular at it's best.
    • JP: Never bothered to touch it! I don't have any opinions on it

• React

  • Github Stars: 148k
  • Initial Release 2013
    • John: I've written a good chunk of react native and react. I've never fallen in love. It's a lot of boiler plate, I don't like JSX and the whole thing just doesn't work the way my brain works. A lot of my projects are perfectly fine with simpler server rendered pages. So I generally don't work in it.
    • JP: On the other hand, I love writing React - I guess as much as any Rails developer can love writing JavaScript. That's right, I said it, I'm a Rails developer.

• Vue.js

  • Github Stars: 164k
  • Initial Release 2014
    • John: I really like Vue because you can just extend existing HTML elements. Handles the data binding and event handling for you. It's lightweight and be brought into all kinds of back ends. Really great for "sprinkles". Don't need a whole SPA but some drag and drop would be good here, or this chat interface needs live reloading.
    • JP: Currently learning Vue and it breaks my brain a little. Let me tell you why...

honorable mentions

• Meteor / Ember / Backbone

Frameworks of Frameworks:

• Next js — New up and coming —  Blitz
  • Gatsbty
  • Sails JS

Last Mention

• Stimulus (Mostly for Rails)
  • Initial release 2019
  • John uses heavily, it's like a lightweight Vue customized for Rails.

Tips for Using a JS Framework

• JP: Learn Vanila JavaScript first
• John: Go all in

JP's Pick

https://www.instagram.com/archipics.ig/

John's Pick

Getting back to Basics Beginner JavaScript (Wes Bos Course)

• I'm halfway through a Beginner JavaScript course, 80% of it is really really easy, the other 20% is such good missing pieces.
  • Destructing
  • Methods in JS Objects
  • Understanding Hoisting

Welcome to Iteration, a weekly podcast about programming, development, and design.

JP Layoffs

• Let's talk about layoffs!
• https://techcrunch.com/2020/04/15/softbank-backed-opendoor-has-announced-a-massive-layoff-cutting-35-of-its-employees/
• 600+ employees
• I got laid off on my birthday! The response has been overwhelmingly supportive and I've talked to dozens of startups in the last two weeks. (It's been exactly two weeks at the time of the recording)
• Sometimes you have to realize how incredibly privileged we are to be in the tech industry. I can't imagine people in the food service industry, for example, getting the same kind of attention
• Collab tools:
  • vid streaming is hot now
  • https://github.com/jeanpaulsio/action-cable-signaling-server

John Layoffs

• C19 forced our company to extend our runway, laying off half our team.
• 7 of 11 got laid off
• This has been hard to adapt, created a lot of work and pushed out our timelines.

Interviews?

• Phone Screens over a dozen
  • Leads from personal network + spreadsheets
  • Hot tip: If you are in high demand set up a calendly
  • Hot tip: Block out time in your calendar so it's not wall to wall meetings
    • 30 minutes is bad 25 minutes and 55 minutes
• Interviews 4 or 5 technical interviews

State of tech

• Restaurants with awkward apps

John Bad IRS Site

• The new IRS website to get stimmy money breaks every single UI best practice. It’s a perfect case study usability 101
  • Validations aren't until after submission
  • Not responsive
  • Only supports firefox (Officially)
  • Very strange validations - money with no coma or $
  • ST vs Street with no previous notice.
    • Reddit thread

JP Government Websites are just kind of funny in general

• I filled out the Census 2020 form yesterday (I know, I procrastinated)
• Why are the options in the form of questions?

save for another convo? vvv Yea for sure — Going too long.

Let's wrap

• Future Topics

Picks

• John - Notion Pro — Notion Examples - Progress bars, advanced formulas Dependent tasks. A lot of fun tips / tricks / hacks

  

• command + k for links!

• Shift + Enter for new lines JP -

• JP: Really cool PBS series - Crash Course Comp Sci

Links + References

• JP's Action Cable Signaling Server Repo
• OpenDoor Layoffs announcement

Welcome to Iteration, a weekly podcast about programming, development, and design.

Article that inspired the episode

Quick notes from this article:

• problem statement: interviewing can be annoying because it's an interruption from deep work
• problem statement: after you've done a ton, it can be boring
• two critical skillsets: attracting talent (making candidates want to work with you) + spotting talent (accurately assessing whether you want the candidate to work with you)
• then it goes on to talk about beginner, competent, proficient, and expert interviewers
• read this article to see where you are in both attracting and assessing talent

Context

How many interviews have you conducted?

JP: At 2 years of Opendoor, I have conducted somewhere between 30-40 interviews. I wouldn't consider this a lot, but my last 10 have definitely been an improvement from my first 10.

John: Pre-tech I did around 50+ interviews. In tech I've done as well 30-40 interviews

What type of interviews do you conduct? Behavioral? Technical?

JP: I've only ever conducted technical interviews

John: I cover mostly behavioral/cultural and cover technical as well.

Take me through your interview process:

what should a candidate expect if they were to be interviewed by you?

JP: I set expectations really early on and give candidates a whole layout for the entire interview. The basic format for my interview is:

1. quick intros, try to keep this to a maximum of: 3 minutes
2. introduction to the question + planning before execution: 5 minutes
3. pair programming: 45-50 minutes
4. closing questions: the remainder

John: I always over-communicate and try to "do" as little as possible during the interview. I prioritize "Async" interviews as much as possible.

• More recent process:
  • Job Listing Job listing with very clear compensation listed
  • Applications Applicants Apply (150+ for last open position)
  • Shortlist Pick the top 10 (or so) I am interested in ignoring name or email address (Hide the columns) and look at the objective experience, read their writing (because we are remote)
  • Code Challenge Email that top 5-10 and offer $100 to do a code challenge, takes anywhere from 2-4 hours. Last time it was implementing an API, they get the $100 when they submit a PR for review. Again set expectations on the start date, role, compensation etc. Set expectations for a review. It's a small test to see how we work together.
  • Async Code Review Sr Developer and I leave comments, ask questions about the implementation Async.
  • Real-time interviews — Then pick the top 2-3 from that phase and do real-time interviews.
    • Re-iterate the position, compensation and expectations
    • We talk background, career goals and motivations for applying to this job
    • They walk me through their code challenge, why they wrote it the way they did.
    • Then I allow time for them to ask me questions about the position.

What would it take for someone to pass your interview?

• JP: We have to fill out a form after we conduct interviews so there is some grading criteria. i.e. code quality, tests, communication, algorithm speed, etc. I try not to nit pick language specific, trivia-like things. For example, it doesn't matter to me if a candidate doesn't know off the top of their head the syntax of setTimeout if they've spent the last year coding mostly in Python.
  • Things are obviously different for hiring a new grad vs. a senior engineer. The bar varies
• John: Core things I am looking for: effective communication (written and spoken), self-motivated individuals (managers of one), skilled learner, Very competent in at least one language or framework (not even my own stack).

Hot tips / Things to keep in mind

JP

Don't let a candidate spin their wheels - try to unblock them. See what working with them would actually be like.

John

My interview style is a bit different.

• Honest — Never set any kind of false expectation, be yourself
• Unpretentious — No trick questions or techno-bable
• Real — Try to communicate and work with candidates as you would in the job.
  • You'd never toss out a question "just to stump" a coworker

Picks

JP: https://github.com/ayu-theme/ayu-vim - I've moved away from Dracula

JP: https://whimsical.com/

John: Book: Every Tool's a Hammer by Adam Savage — Yes, Mythbusters guy but also incredible maker and leader of technical teams building really complex things

• so many great similarities to tech.
• Planning, Working, Creativity, burnout, estimating,
• plus a whole chapter on types of glue and random stories from his special effects days.
• I've really dug this book, doing the audiobook, will be buying a physical copy.

Welcome to Iteration, a weekly podcast about programming, development, and design.

First, some fun questions:

1. 👍or 👎 on writing CSS?

2. What do you love about CSS, what do you hate?

3. To this day, what are some of the things you don't understand?

   • JP: CSS Grid, Floats (kind of. I always forget what the clearfix thing is for)

Frameworks

WTF ?— Here is a set of components you can build, pre-defined styles, gives you a starting point. Pre-buit UI.

Popular Ones

• Boostrap — Pre-defined class "Components" card shadow

• Tailwinds — Much more like Tachyons md:flex g-white rounded-lg p-6

• Material UI

• Foundation

• Atomic CSS / Tachyons

• Skeleton

Pros / Cons

• Tailwind

  • Pro: Using tailwind for side project. Wrote 0 css

    • Tailwind components (Basically a better looking bootstrap)

  • Con: Output is derivative

    • JP's argument — you could design anything you wanted

    • It's more of a function of what the docs provide.

  • Pro for Tailwind — Tailwind doesn't come with baked in components

• How do we overcome derivative sites?

  • Could be tools

  • But I think it's more about pushing the design side more

  • Thinking in terms of "Bootstrap Components"

  • Think more first principle

  • Strong designer to push you too break the bounds of these frameworks

Frameworks - Pros and Cons of Each

• Boostrap

  • John: My top choice. I know it better than any other framework. I don't think it's "The best"

• Tailwinds

• Tachyons

  • John: Worked with it a lot, had some client projects use their own fork. Really powerful but it starts just feeling like "inline styles" SO MANY Classes

    • bg-dark-green ba bw5 dshadow2 br2 pb3

    • It's like ok ok calm down.

• Material UI

• Skeleton

  • Nice for quick projects. Super lightweight. Our agency site was built in Skeleton

Implementation

• Customizing it

  • Tailwind

    • Example: H1's — identifying patterns

    • Take a set of classes and use the "apply" function

    • Single set to define your custom classes.

    • You throw those into a single class called "Heading"

  • Bootstrap

    • Starts with customizing variables

    • These variabels are used in the

Picks

JP: https://thoughtbot.com/blog/running-specs-from-vim

John:

• "Copy css" from sketch

• Css in Figma

• Re-pick: https://refactoringui.com/ (Same guy behind Tailwind)

• Referenced: https://a.singlediv.com/

• My name is JP, I am a software engineer at Opendoor. Today I am joined by John
• John Intro — I build and maintain Web Apps for startups.

Developer roadmap 2020

• Web search "Developer roadmap 2020" and you'll find this Github repo
• https://github.com/kamranahmedse/developer-roadmap
• You can also find it at https://roadmap.sh/
• Its a set of charts demonstrating the paths that you can take and the technologies that you would want to adopt in order to become a frontend, backend or a DevOps.
• Looking at a chart with hundreds of "Nodes" each representing potentially hundreds of hours and their own specialties all-together

Looking at this for 2 reasons

1 — If you are new to development, this helps you make sense of all the resources, languages and frameworks. These roadmaps cover everything that is there to learn. Don't feel overwhelmed, you don't need to learn it all in the beginning if you are just getting started, focus on the core and the rest comes over time

2 — If you are experienced it helps you identify and organize gaps in your knowledge.

The two Paths

• Front End — "Everything the user sees"
• Back end
• Dev ops

John: What about Mobile? This is called the "Web Developer Roadmap" but there is a lot of overlap

Basics

Web Dev 2020

• Front end + back end + dev ops
• Pre-reqs:

John: How does someone choose a path?

• JP: It depends — what interests you? Everything is biasing toward the front end.
• John: When in doubt pick front-end, especially in 2020. Serverless, GraphQL etc

Front End Roadmap

"Everything the user sees"

https://roadmap.sh/frontend

• JP: Honestly, I don't know how DNS works. I should really do a google search for what happens when you do a google search
• JP: Surprisingly, I know a lot of the stuff up until it drops down into PWA stuff.
• JP: mmm... do you really need to know GraphQL? This might be one of those things where I'm old man shaking fist at cloud

Back-end Roadmap

"Everything that the user doesn't see"

https://roadmap.sh/backend

JP: I wonder why javascript is the personal recommendation for back end language

John: Web: JavaScript, Ruby, Go or PHP seem to be good choices in today's landscape. Mobile of course is C# or Java

DevOps Roadmap

"The equipment it all runs on" — The boiler room in titanic

https://roadmap.sh/devops

JP and John are least experienced in this bucket.

JP: Learn heroku lol

• "Get some administration knowledge in some OS"

Wrap Up

Picks:

• Cloud App — Way easier way to share screenshots + gifs
• https://www.onsched.com/ - Appointment API

• John: Hi I'm John a software engineer at a tech start up — Joined by JP
• JP: I'm JP, I'm a software engineer at a tech start up

Today we're going to be talking about something that's frequently discussed on the Twitters-phere:

Remote work.

Take me through your day

(day in the life of a remote developer)

• Get dressed
• Take a lunch

What are some of the challenges you've faced?

• John: schedule work just becomes intertwined with life. Dedicated meeting days or blocks make life so much better. Having some kind of boundaries.
• John: communications making sure to have a place for “chatter” and an “updates” cadence.

Some tips?

Get dressed every morning

Have a dedicated space or device

Get good at notification settings and use them

• Slack Status vs "Snooze" — For the hour

Office Hours / Schedule

Over communicate in passive channels

Video / Audio Setup

• Good Audio is most important
• Invest in lighting before a camera.
• A bad camera with good lighting is better than good camera with bad lighting.

Change your scenery

Work from energy not time.

Reduce distractions. Really don’t work with Netflix on in the background.

What are some of the pros / cons of working remote?

• John: Pros: random bunch dates with the wife. We brunch hard.
• John: Flexibility to travel and work. (Trip to Nashville this weekend) .
• John: Lunch break bike rides and dip in the ocean.
• John: Changing scenery, will regularly work from a park on a mountain top or pretentious coffee shops

What are your favorite tools?

• Standing Desk
• Loom
• Slack
• Miranda time zones app

Audio / Video Setup

• Headphones with Good Audio #1 priority, #2 is noise canceling (if you need it)
• Blue Yeti Mic
• A bad camera with good lighting is better than a good camera with bad lighting.
• Elgato Key Light
• Logitech Brio Webcam

https://github.com/KyleAMathews/typefaces

Photos of our home office Desk Setups

Resources

• Book: Remote
• Book: Ultimate Guide to remote work

Picks

• Trailer Github App
• Typefaces — Self host google fonts
• Supermarket — Just a fun book

We are going to be talking through the main / really popular API partners out there and give some quick feedback on how to integrate/go about them. Plus some lessons learned to keep in mind when planning integrations like this.

Sendgrid + Other Transactional Email

John: Formatting emails — inline styles only.

John: Some services have "Templates" with "Placeholders", some you pass the full HTML

John: Having some kind fo "log" object in your own domain can be very helpful.

John: Priority on background jobs for timely emails —

JP: Iterable. Opendoor uses this tool to send text, email, and push notifications. Everything hinges around handlebars / mustache and OOF - inline styles

JP: Side project with send grid, just a list of template ids

await deliverTemplateEmail({ to: user.emailAddress, templateId: SOME_TEMPLATE_ID, data: { contactFirstName: user.firstName, viewMyAccountLink: ${config.BASE_URL}/user/dashboard, }, });

Stripe + Other Payment Providers

• John: Tokenization and data storage
• John: Drop in vs Whitelabel — "Checkout" vs "Elements"
• John: Embrace Test Mode in Stipe (Super powerful)
• John: Subscriptions, Promocodes + More
• JP: I actually don't have much to say about payment providers. The interesting thing is that in Opendoor world, we hand off our users to an operator. I.e. you wouldn't purchase a home a la Amazon

Twilio (SMS)

• John: STOP replies edge case
• John: Logs are helpful
• John: Twilio Webhooks
• John: Testing mocks is really useful
• JP: Seriously, twilio powers the world. We've used tools that hook into Twilio that provide an interface for customer support. See Front App

Scheduler / Chron Jobs

• John: Heroku Scheduler
• John: Think about failure handling, resend logic into scheudulers

OAuth Login?

Other?

Picks

• John: Sweet Maria's Green Coffee Beans and Roasting Guides
• JP: None!

Welcome to Iteration, a weekly podcast about programming, development, and design.

• My name is JP, I am a software engineer at Opendoor. Today I am joined by John
• John Intro

This week on code reviews

What makes good code review? Here's a link I found on reddit a while ago:

http://cassandra.apache.org/doc/latest/development/how_to_review.html

https://www.reddit.com/r/cscareerquestions/comments/byxmk1/what_makes_for_a_good_code_review_session/

Another tweet:

https://twitter.com/addyosmani/status/1198502828425150465

• Any good / bad experiences with CR?
  • JP: It's not personal
  • John: I've worked with team members who take feedback as a prescription for every time
    • Rant about chefs, recipes and concepts
  • John: People not giving the PR in context. It's flagged WIP and then calling out a comment or a long method. Focus on the approach not the syntax at this point.
  • John: I give code reviews for my clients team or other agencies.
    • Can feel like a power struggle.
    • I have to sometimes be open minded about solutions.
    • If tests are passing and it's reasonably documented and maintainable, it gets merged.
    • Example: Very javascript heavy interaction that could of just been Markup
• What was your first CR like (receiving it and giving it)?
  • JP: it took me a while to get comfortable leaving code review for people who I looked up to. +1
  • John: It's hard getting feedback from the team who works under you, they can be shy about it. Can be frustrating. That's why at several points I've literally paid a tutor.
• How frequently do you do it?
  • John: I get reviewed once a week. I give reviews multiple times a day.

How is CR Conducted at John's agency vs at Opendoor?

• JP: Different kinds of PR's - WIP, Ready for Code Review, etc
• JP: CR Etiquette
• John: It's pretty informal — working on stronger processes around this. We "Sometimes" do a WIP review. Lead Dev or I always do a final review before deployments.
• John: For more "final" reviews, I try to summarize my thoughts into an actual checklist into the main comment body.

CR Tips

• JP: Take your time with it
• JP: Pull the code down and run it. Tinker around. This helps me see the bigger picture
• JP: Know when to leave nit pick comments.
• JP: Think of the potential test cases before you read them.
• John: Giving Good feedback
  • Consider the McKinsey Approach
    • Permission
    • Observation
    • I noticed that... Have you considered...
    • Try to take ego out of it
    • Never assume
    • Compliment Sandwich —
    • Bring it all together: Wow, this was a lot of hard work. Great job overall. I noticed that you brought in JQuery as a dependency. Have you considered using Vanila JS instead? That way we keep our site fast and avoid possibly uneccisary dependencies. Here's an article that might help. Very impressed by your CSS skills in this. Keep rocking!
• JP: Get other engineers involved +1 Mob Review
• John: Ideally the person who submitted the PR takes the time to fix their own code. Sometimes you've just got to get code live.
  • Async "Pair" — turn on screen recorder, walk through all your comments as you fix them. Do this when code is pressed for time.

Picks

• JP: https://www.gitify.io/
• JP2: https://www.reddit.com/r/cscareerquestions/comments/byxmk1/what_makes_for_a_good_code_review_session/
• John: Rocket Emoji's - https://matthewpalmer.net/rocket/

JP's Experience

• Minimal
• Often saying "yes" too frequently
• This year I only said yes to opportunities I could deliver on
• Doing consulting work for friends.... 🤔❌
• I come from a design background where I was known as the "design guy". To this day, people still ask me if I can make logos for them.

John's experience with freelance

• I started Freelancing in June 2015 (Small Rails work)
• The last 5 years I've built it into a small agency
• We did over $350k last year
• I've been able to travel, have flexible hours, and pick and choose projects and learning.

Pros of freelancing

• Extra cash (on the side)
• Flexibility
• Lot of different projects
• Less politics
• You have the power to negotiate and capture your full value with no lost efficiency or politics at play.

Cons of freelance

• No paid time off
• No benefits
• No growth opportunities - You have to be a self-starter
• Taxes, paperwork business development
• Sometimes you get boring projects
• Loneliness
• Hard to find work at first
• You have to be paid less than you are worth. That’s capitalism. There has to be a gap between what you cost and the value you provide.
• Moving from project to project gets hard. You need to be sure you really like / want shallow variety.

Getting started

• You need to pick a skill/stack/specialty.
• Make sure you have someone out there who’s paying people for it.
• People need to understand what you do and who you do it for.
• “I build Wordpress sites for dentists”
• “I do Ruby on Rails for medical startups”
• It positions you as a specialist. Specialists have more authority, less competition and make more money.

How to find clients (at first)

• Free or discounted work for Nonprofits
• Upwork / Thumbtack / Craigslist
• Portfolio work that's as close to a real project as possible
• Equity work for startups
• Open source
• Blogging (my top 2 biggest clients were from my blog)
• This season shouldn’t last for more than a year. If it does, you may want to consider a "joby job"

Once leads are coming to you:

• Raise your rate by at least 20% or so every estimate until your rejection rate is over half.
• If you are landing every bid, it’s a bad sign. You are too cheap.
• JP's Formula = Hourly rate at his "joby job" ~ $50/hr — double it or triple it

Billing approaches

Fixed Fee

• Milestone payments
• You get to a point of your hourly being diluted

Value based billing

• Milestone payments
• Understand the business enough to get a sense of the potential value you can provide.
• Ask lots of questions to really understand their business. Skim books, YouTube anything to be able to speak intelligently about their business needs.
• Once you quantify the outcome:
  • “You make $300k a year from your website leads now, you think my work could improve that by 20%. That’s $60,000. My services are just an investment of $12,000 that you’ve estimated will give you a return of $60k in your first year”
  • So instead of charging $2k for that static marketing site, you can be confident in charging $12,000 - it’s a small investment for the returns the client says they should get. It’s a deal.
• Charge more.
  • By pricing yourself “competitively,” you inadvertently signal to them that you’re “average” — and great clients, by definition, aren’t looking for average.
• It takes time.
• My average client lead to close has been about 2-3 months in the last 3 years. The average client revenue has been over $50k per client.

Hourly / Retainer Billing

• Pre-pay is the way I was doing it. Discounts for higher chunks of hours. This worked really well for ongoing development and maintence contracts.

Tools

• Harvest
• Upwork
• Catch
• Transferwise
• Bench
• Project Management software (notion, sheets, basecamp)

How to write estimates

• fixed price
• Retainer
• Hourly
• Value based fixed price

Mistakes / misconceptions

• it’s a numbers game. This is false! Don’t spray 300 people with a cold email and no context. I get these constantly. Spend 3 hours researching 3 clients you can offer value too. Build a relationship, be a resource, it takes time.
• Provide a ton of value at a sustainable but low wage.
• Selling outcomes you don’t fully control. Example: I want this rich interactive functionality on a square space site that I can’t give you admin access for. Not having copy, not having design assets, domain access. Etc.
• Fixed price billing with a lack of scope.
• Growing to quickly
• Having a closed mind to unknown domains.

Taxes + LLC's WTF?

• In the states - you have to pay taxes (I retain at least 20% of my income)
• LLC protects you
• Errors and omissions insurance is good to have as well

Links / Resources

• Seth Godin Freelancers workshop
• The business of authority

Picks

• https://www.llcuniversity.com/ - LLC University
• Stipe Atlas — Pay the money get an LLC

Ruby on Rails: 5 Things we hate 5 things we love. A quick overview of some of the key concepts, limitations, and strengths of the Ruby on Rails Framework.

😍John - Convention over configuration

There is a strong "Rails way" this lets you focus on product, higher level abstractions, and move quicker through your day to day. You have less decisions to make.

🤮Convention over configuration

The "Rails way" is stupid, puts you in a box. Sometimes my needs and problems don't fit into the rails conventions.

😍Love: It's Stable and reliable.

No "shiny object" syndrome that you get in the JavaScript community.

🤮Hate: It's boring and doesn't keep up with modern trends. [jp]

I never know the right balance of "React" sprinkles inside of my .erb files. Sometimes it feels like I should just do a full blown SPA? Plus, sometimes making a form in React is so much easier for me than remembering all of the weird Rails Form shit

😍Love: It's server rendered.

🤮Hate: It's server rendered.

😍Love: It' just Ruby

🤮Hate: Forms

Why are forms so damn complicated? Maybe I just don't have a good understanding of data modeling...

😍Love: Old tutorials for things are mostly still relevant

🤮Hate: Rails devs are just "Script kiddies"

Picks

JP: 🧦 https://bombas.com/

John: Abstract — Netfilx

John: Hey I'm John I run a firm that builds web and mobile apps.

Happy new year — this week we're talking through resolutions and goals for 2020 as software developers:

JP — Goal #1: Build a full stack app with Elixir

• really stretching myself here on this full stack node app

JP — Goal #2: System design

• maybe even pick up UML?

JP — Goal #3: Algorithm fundamentals

• Going through https://interviewcamp.io/

John — Goal #1 Blog

• Blog / Write / Document my work more
  • Motivation:
  • It helps ideas stick
  • Some of my best clients have been gained through my blog.
  • It's a good way to give back.
  • Become a better communicator.
  • Document for the team.

John — Goal #2: System design

• I'm copying JP Here — already been wanting to re-read through Domain Driven Design, (The lost season 1 LOLZ)
• Web Scaleabaility for Startup Engeneers

John — Goal #3 JavaScript

• JavaScript Skillz Up.
• I've made strides in 2019 but I want to take it to the next level.
• I still find front end intimidating.
• I limit myself in functionality to avoid complex UI.
• It holds back product sometimes.

John — Goal #4 Focus

• Focus more on my core.
• I spend a lot of time on accounting, project management, issue triage and more.
• I want to have better processes, tooling, automation and team support on the things I'm not good at.
  • Processes — QA, Client Handoff, Documentation
  • Tooling — Project Management, Error Handling, Staging, Documentation
  • Automation — Weekly updates, Invoicing, Payroll

Picks

• A Youtube Playlist of every office deleted scene
• MacOS — Sidecar
• https://www.princestreetpizzamenu.com/

Where to find Luis:

• Twitter: @luijar
• Blog: https://medium.com/@luijar

Books by Luis

• Joy of JavaScript
• Functional Programming in JavaScript
• RxJS in Action

A weekly podcast about programming, development, and design.

I'm John, I run a design and development firm that builds apps and websites.

I'm joined by JP:

Hi everyone! I'm a full stack software engineer at a real estate tech start up.

Catch up / What's today's episode about?

• John: California is on fire 🔥Making my job — complicated

• Let's talk about git!

• I recently watched this quick 4 hour course which is going to be my pick: https://frontendmasters.com/courses/git-in-depth/

• Let's assume that listeners use git daily

Teaching / Learning section

Git at a very high level

• Version Control
• Major, major oversimplification: key value store
  • key = hash of data
  • value = data
• You use the key to retrieve your data (i.e. git checkout is just moving the pointer to the particular commit hash)
• Three (4 if you count remote) areas where code lives
  • Working: "untracked" files - this is your playground or scratch pad, current "working area"
  • Staging: files that will be part of your next commit. this is like saying, 'hey, I want to add these files and changes to my repo as they are no longer just scratchpad thoughts'
    • this is how git knows what changed between last commit and your current commit
  • Repo: files that git knows about. the repo contains all of your commits
  • Remote: Github, bitbucket, etc

What does your personal / work git workflow look like?

i.e. walk me through how you might use git when you implement a new feature

this can be a longer section where we talk about git / github as it relates to working on a product

• How often you commit
• What your commit messages look like
• PR etiquette
• Git Squash vs Leaving all the history

Goodies + TIL section

Git Goodie #1: --no-pager

• Have you ever done a git diff or a git branch and your terminal opens up a "new page"? You can throw in the --no-pager flag and it will display the contents in the same window instead

Git TIL: git commit without the -m flag

• I learned that the -m flag is only for short commit messages

John: Git Goodie — git stash

• I only learned this one a year ago, incredibly useful.
• you can name your stashes!
• pop + apply
• git stash list

I'm John, I run a design and development firm that builds apps and websites.

I'm joined by JP:

Hi, I'm a software engineer at a real estate tech start up

Catch up / What's today's episode about?

This week Best and Worst Apps

• Design and development patterns we love and hate.

JP: Gripe 1: 👎 Page Reloads

Web app: Iterable - every "save" reloads the page

Mobile app: Notion - every change to a kanban board reloads the page; every time you swipe back, the page reloads

Takeaway: Optimistic rendering

John: Password resets taking a thousand years

• Takeaway: Prioritize the background job, please.

JP: Gripe 2: Resetting my filter settings

Mobile app: apartments.com; I would need to register to save my settings. Maybe this is intended?

• Takeaway: Don't be user-hostile, don't use negative incentives.
• Takeaway: Use local storage (Cookies) or local device when a user is not authenticated, redirect on account creation and save that data.

John: Not thinking about the size of the device

• Putting things I care about at the tippy top of the app. Put it under my thumb!
• Takeaway: Test your apps in different contexts, huuuuge and tiny.
• I've made this mistake - shipped apps that don't render properly on an iPhone 5s

JP: Gripe 3: Login button on marketing page opens new tab and authenticates me

• Bad Web apps: Iterable, Lever
• Good web apps: Amplitude
• Weird in the middle apps: Coderpad
• Takeaway: Take the time to get auth right. Be careful how you handle oAuth

John: Facebook Logout Bullshit

If you log out of the facebook app it doesn't actually log you out.

It goes to this screen with your profile photo and a password field, it's still collecting data on accounts associated with that phone.

• Takeaway: Don't prioritize business needs over product simplicity and privacy.

Slack Gripes

• JP: Slack turns apostrophes into curly apostrophes
  • https://practicaltypography.com/straight-and-curly-quotes.html
  • “ - curly
  • " - straight
• John: Drafts jump up to the top of the screen and go missing from your threads
• John: Global notification "Mute" switch outside of your system settings.
• John: The account management strategy is bonkers — Why can't I have one login that gets me to all my workspaces?

John: Deranged Email Collection Pop Ups

"Would you like to be rich and beautiful?"

• Yes! I'm awesome.
• No thanks, I'll stay poor and ugly"
• Takeaway: "Push back on stakeholders, suggest more thoughtful design solutions, if well executed "interstitial" email collection can be just as effective and way less user hostile.
• Keep in mind: Google knocks down SEO significantly on email pop ups websites

JP: Cool feature 1: Power user shortcuts

Desktop app: Slack has a cmd + k to search, cmd + r to refresh, etc

Desktop app: Youtube scroll on a full screen video

Chrome: youtube + tab to search | ebay + tab to search

• Takeaway: Provide more than one way to access common functionality, this can be a keyboard shortcut, a gesture. Reward power users.

John: In app pop up ads

• Spotify new album announcements
• Netflix new shows
• Youtube Premium ads
• WORST: Apple "Have you tried the new maps?"
• Fuuuuuuuuuuck that.
• Takeaway: Feature new features or content passively in context. Highlight new content etc. Don't interrupt users. We are better than that.

John: Multiple Accounts + Team Management

• Stripe does this so so well. One login can get to multiple accounts, secure, simple.
• Bank of America — basically just need to delete the app every time to switch between my company and personal accounts.
• Pastel — You can't belong to more than one "Team"
• Slack — Multiple "Workspaces" new phone sign into 4 different workspaces.
  • Takeaway:
    • Be really thoughtful about user account management, understand that more than one person need to use your app and access your data. Think about from day one tying data to an "Account", "company" or "Household" that includes the single user.
    • Example: App for dog trainers, every trainer belongs to a "School" even if it's just themselves, every dog and client belongs to a "Household" that way you can easily add and remove user's access to a "School" or "Hosuehold"
    • If you tie all the data to the individual user, it's really tough to share access.

John: Hitlist of Beautiful platforms that get most things mostly right

• Robinhood
• Reddit Mobile
• Airbnb
• Square
• Twitter
• Pinterest

John: iOS "Smartlinks"

• Drive me bananans
  • If you tap a phone number there is no way to "Copy" it. the only option is to "Call"
  • If you tap an address "Open in Maps" 🙄 🤮
  • If you tap an email "Apple Mail" 🙄 🤮
  • Lock-in BS

Picks:

• John: Blinkist - Book summaries
• JP: Away

A weekly podcast about programming, development, and design.

• My name is John Jacob, I am a developer and designer.
• I am joined by my co-host JP

Conversation — When Tech Meets Business

Who is Jon? Tell us a bit about your educational background and how you eventually landed at Opendoor

Jon, Briefly tell us why you're interested in Real Estate

• potential to talk about the domains we are interested in as well
  • education
  • health

As a software engineer, why is it important to understand the domain that you're building for?

• Understand customer pain points
  • Example searching for a home: Zillow and more
• Understand the competition
• User value directly — Redfin and Zillow — are just lead gen tools. Let's focus on lower level.

1. Build in domains you are excited about
2. Understand customer pain points
3. Check out the competitive landscape
4. Books books books

Do you think you need to be interested in the domain you're working in to do well?

• Not necessarily, building tech can be an interesting exercise in itself
• You have to be open minded, and empathetic
• Obviously, when you are passionate about a product, there's magic in that.

What are some insights (perhaps specific to real estate) that came from someone who was non-technical?

How do you know when you should apply technology to solve a domain problem?

• Think about it in terms of Pain
• High transaction is the opportunity
• Repetitive tasks is an opportunity

Picks

• JP: Netlify
• John: Duck Duck Go
• Jon: Murphy bed

Links

• John Jacob 
• JP
• Guest: Jon

This episode uses Chapter 13 of Extreme programing as a jumping off point

Testing Early, Often, and Automated

Here is the dilemma in software development: defects are expensive, but eliminating defects is also expensive.

• Instead of talking about having a kick-ass automated test suite, frequently testing code, and all of that good stuff, we should talk about something a little different.

Q: What was the last big bug you can think of? How did you handle it?

• Health coaching group discussions, mobile users could not post into group discussions for 48 hours. It’s a core feature of the platform.
• React Native Upgrade → Weird android bug where people could not take a photo to upload their proof of funds

Q: What was the reason for the latest big bug?

• lack of automated integration tests in the Mobile app.
• We have some unit testing we also have full API tests, but not enough coverage in the integration.
• We made a small change to the group discussion model, the mobile app wasn’t updated to consider this change, timing the rollout.
• Android Weirdness, lack of QA, rushing to get to the latest and greatest

Q: How do you handle bugs in general?

• Testing is first line of defense.
• QA is backup (One other dev)
• App signal is the catch all (After deployment)
• Users are the last line of defense RABBITHOLE
  • Give users a clear escape hatch / line of communication.
  • So many times we’ve caught flawed design assumptions from that feedback. Users love it too.
  • Superlative language "Thank you so much, you are the best, we really really appreciate you sending that in and I'm so sorry if you are having issues. "

Q: John Ask: What’s the most common causes of bugs?

• Test data does not properly represent production data - phone formats / etc
• An Edge case that wasn’t considered
• The feature functions properly but the functionality is wrong / not what the stakeholder intended.
• Rollout was not planned, data transition or all platforms are not in sync.
• Browser or context considerations. Mobile vs tablet / android device universe.
• Lack of QA, lack of tests
• Rushing things

John — Summary / Thoughts on book overall

• Overall got the most out of this vs other books we've read

Picks

• JP: Heroku! Review Apps (spins up a new app every time a PR is opened); Pipelines
• John: Contentful + Rails to give clients ability to update copy and images on marketing pages.

This episode jumps off Chapter 12 of Extreme programing by Kent Beck.

Planning is an exercise in listening, speaking, and aligning goals for a specific time period. It is valuable input for each team member. Without planning, we are individuals with haphazard connections and effectiveness. We are a team when we plan and work in harmony.

XP recommends planning at any timescale with these four steps.

1.) List the items of work that may need to be done.
2.) Estimate the items.
3.) Set a budget for the planning cycle.
4.) Agree on the work that needs to be done within the budget. As you negotiate, don't change the estimates or the budget.

Questions for discussion

Question 1: Walk us through how you plan a new feature. In other words, how do you bring a new idea from concept to reality?

1. Pitch

This usually comes from the client, sometimes myself or the team.

• Here's an example of a recent client pitch:

So here is our high level break down. 1st we add a new bottom tab that says students seeking this tab replaces the settings gear tab. The settings tab will be moved to the top right corner of the app. When a student clicks that tab the design attached (below) would show. * Design shows a list of students who have performed searches, with a "Message" button on each.

Rules A student should show up on a tutors seeking list if......A student search is <7 days oldThey have not been messaged by 3 different tutors initiallyThey are within a tutors travel radiusSearched subject is on Tutor's subject listNotifications FiredEvery-time a new students signs-up a tutor that meets the above criteria will receive a notification about a new student signing up that they can reach out to.Additions:Add a box on the tutor stats page that lets tutors see new students seeking help in their area.

Whiz Tutor — an app where you can find a book nearby tutors for in-person tutoring.

Pitch was — when students search for but don't book a tutor, let relevant tutors message those students. This would happen through a "Students Seeking" tab that shows up in the tutors Mobile app.

2. Design

Hand off the pitch to a designer on the team to refine and recommend a scope.

Question the work

• Try to tease out the "Jobs to be done", "user stories" that exist in the pitch
• Question if this needs to exist at all "Default to no"
• Look for "Off the shelf" > Workarounds using the current system.
  • Can we do this with Zapier or a spreadsheet?
• Features often die in this phase.

Define the work

• Name the things. Attach nouns and verbs to the functionality.
  • "Students Seeking" became > "Leads" >
  • "Message this student" became > "Reply to Lead" > Lead Replies
• Figure out where this "lives" in the context of the existing feature set.
• Figure out each entities lifecycle, how does it get created, updated viewed and destroyed?
  • A students search activity generates leads, a tutor can view relevant leads in their area, a tutor can reply to a lead, once three tutors reply to a lead that lead is no longer visible to other tutors.
• Try to get ahead of pitfalls, ask a lot of questions.
• Sometimes designer will talk with a developer just to make sure to identify and avoid any technical hotspots.
• Customer interviews if needed

Handoff the design

• Output — Low fidelity mockup, usually handed off with a screen recording, this is shared with client to capture any last pitfalls or miscommunication.
• We try to time-box each design iteration to just a couple hours.

3. Initial Client Review

• We shoot an email with the mockups and screen recording attached, just to be sure we are all on the same page.
• If there's tweaks we make a new low-fidelity design where it's still cheap.
• Client lays out "Must haves" and "nice to haves"

4. Estimate and Plan

• Once we are in alignment on the overall trajectory of the feature, Mockups and client context is handed over to a developer.
• Developer reviews the functionality, jobs to be done, user stories etc and attempts to estimate the work.
• This is the point where we break the work down into quantifiable, assignable "user stories" related to the feature.
• Plan the technical approach
• Keys to estimating more accurately
  • Look at history
  • Break things down smaller
  • Think about all "Contexts" and "States"

5. Client Approval

• We have designs, we have estimated user stories.
• Here's the point where we can give ranges of hours and get a firmer list of "Must haves" and "nice to haves"
• Client gives us a go / no go on user stories.
• Again — Customer interviews if needed to be more confident in scope setting.

Question 2: How do you decide when a feature is in scope vs. out of scope?

• Each step chips away at the scope, Example: in design, if we can't name things, it goes back to a pitch. In the estimates if it's too expensive it goes back to design.

Question 3: Talk about a time when planning failed and scope creep was real. How do you think this could have been prevented?

So recent and painful.

• Client reached out wanting to build a huge WebApp.
• I recommended we take a 3 weeks to refine the design, set a scope, basic feature list, basically this process. I gave very rough ballpark numbers of timelines and costs without having a feature list locked down.
• Client pushed hard to just get started, not define any of the work upfront, preached "Agile" — We got started with essentially no plan.
• Scope creep was massive, and scope within features. Example: Photo and file attachments in the messaging tool before a single use was using the messaging tool.
• Spent way too much time on functionality that was thrown out the window.
• Bottom line — client spent 4x my initial estimates, project went twice as long and they still don't have a working product.

Closing thoughts on planning

• Planning is people, planning takes time and intention.
• XP: Compromise Scope, not quality, time or cost. "Lowering the quality of your work doesn't eliminate the work, it just shifts it later... creates the illusion of progress... you pay in reduced satisfaction and damaged relationships"
• XP: Use past facts to guide estimates, not your gut.
• XP: Don't try to over-optimize planning, "You can't automate relationships"
• Our agency Project management overhead is about 15% of the project cost. Very real, very needed.

Picks

• JP: React Hooks
• John: Everything I googled for a week- In an attempt to dispel the idea that if you have to google stuff you’re not a proper engineer, this is a list of nearly everything I googled in a week at work, where I’m a software engineer with several years’ experience. https://twitter.com/type__error

Corollary Practices of Extreme Programing

corollary: noun, a proposition that follows from one already proved. e.g. "The huge increases in unemployment were the corollary of expenditure cuts.

TLDR: Walk before you run

Real Customer Involvement

The point of customer involvement is to reduce wasted effort by putting the people with the needs in direct contact with the people who can fill those needs.

• things I’ve missed from not including customers: block width buttons, “bookings” language, “clickable cards” SO much is missed without really involving customers.

Root Cause Analysis

(After you write tests and fix the bug...) Once the defect is resolved, figure out _why_ the defect was created and wasn't caught. Initiate the necessary changes to prevent this kind of defect in the future

Five Whys

• hint: it's usually a people-problem

Incremental Development

• "Slices" concept from Shape Up
• Scoping the work into a very tiny working piece of functionality and incrementing work from there. - If you were to rebuild facebook, just create a "Wall" and a "newsfeed", leave "likes" or "comments" for a future iteration.

Negotiated scope contract

Magic formula for success as an agency:

• It's taken me 4+ years of freelance software development to learn this lesson.
• Scope is flexible, budget, time quality are not.
• This is a game-changer, learn this as early as possible.

Other practices

• shared code
• single code base
• daily deployment

The Whole XP Team

A variety of people must work together in interlinking ways to make a project more effective. They have to work together as a group for each to be successful.

TLDR: what should each of these roles do on an XP team?

• Tester - find the happy path; find ways to break it

• Interaction Designer - choose overall metaphors for the system; create personas and goals; help the team analyze and make sense of the world;

• Product Managers - write stories; pick themes and stories in quarterly cycles; prioritizes; encourage communication between customers and programmers

• Project Managers Facilitate communication, help identify priorities and consistent accountability.

• Executives Courage, confidence and accountability

Picks

• JP: GatsbyJS
• John: Figma

A weekly podcast about programming, development, and design through the lens of amazing books, chapter by chapter

John: Hi, I'm John and I'm joined by JP.

JP: Today we will be going through chapters 6, 7, and 8 for those following alone - which are all about Extreme Programming practices. These are the things that XP teams are doing on a daily basis. Kent Beck defines two categories for practices: Primary Practices and Corollary Practices. You must first master the primary practices before considering corollary ones. This episode focuses on primary practices.

Practices that do not serve a purpose or have values are empty. For example, pair programming for the sake of making your boss happy doesn't make much sense. However, pair programming to communicate, get feedback, simplify the system, catch errors, and bolster courage makes a lot of sense.

Reminder - XP Principles

• Humanity
• Economics
• Mutual benefit
• Self-similarity
• Improvement
• Diversity
• Reflection
• Flow
• Opportunity
• Redundancy
• Failure
• Quality
• Baby steps
• Accepted responsibility

Primary Practices (Chapter 7)

Sit together

XP predicts that the more face time you have, the more humane and productive the project.

👨‍🏫 humanity

👨‍🏫 improvement

👨‍🏫 quality

Informative workspace

Make your workspace about work. An interested observer should be able to walk into the team space and get a general idea of how the project is going in 15 seconds.

• 🐶 Digital workspace counts for remote teams — hygiene on backlogs, clarity on where project status is.

👨‍🏫 mutual benefit - doing stuff today that benefits me now and in the future

👨‍🏫 flow

Energized work 🔥

Work only as many hours as you can be productive and only as many hours as you can sustain. Burning yourself out unproductively today and spoiling the next two days' work isn't good for you or for the team.

Taking care of yourself is the quickest way back to energized work.

I turn to long work hours as a way of grabbing control in a situation in which I am otherwise out of control

• 🐶 Recommended reading - Deep Work & Make Time

👨‍🏫 flow

👨‍🏫 humanity

👨‍🏫 improvement

👨‍🏫 mutual benefit

Hot tips:

➡️ stay the same amount of time but manage time better

➡️️️️️ block off 2 hours at a time in your calendar just for coding

➡️ turn off phone, email, and slack notifications

Pair programming

• 🐶 Nothing better for getting better and writing better code. Need to make a more regular practice of this.

Stories

Plan using customer-visible functionality. As soon as the story is written, try to estimate the development effort necessary to implement it.

Write stories on index cards and put them on a frequently passed wall. Every attempt I've seen to computerize stories has failed to provide a fraction of the value of having real cards on a real wall.

• 🐶 Small discrete shippable changes. Should fit on an index card.
• 🐶 I've written my share of stories that are 2.0 Messaging tool. That's waaaay too open ended.

👨‍🏫 flow

👨‍🏫 reflection

👨‍🏫 quality

Ten-minute build

• 🐶 Absolutely true, anything more than 10-15 mins you end up with a bunch of PR's with a broken build.

Continuous integration

• 🐶 If you don't have CI set up, even for a solo project. Do it.

Getting Started (Chapter 8)

REMEMBER! XP is a way to improve both your development process and your experience in it.

• adapt by adding practices that meet your goals and express your values
• you don't have to implement all of the practices at once. pick one, see how they meet your goals and align with your values.
• baby steps!
• 🐶 Even if you can't get your team to switch, adopt a practice on your own.
• 🐶 The only person you can actually change is yourself, even if you are the boss!

Change always starts at home. The only person you can actually change is yourself. [...] Dictating practices to a team destroys trust and creates resentment.

• lead by example

• 🐶 Find a practice - List out Things that drain you, list out things that energize your work, adopt practices around these two things, preventing drain and supporting energizing!

Picks

• JP: http://www.pythontutor.com/visualize.html#mode=edit - so cool!
• John: https://github.com/sirupsen/airrecord - Worked so well to hack to gather an MVP, incredible. No migrations and the rest of the team could read / write data to the database.

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

Hi, I'm John and I'm joined by JP.

Today we will be going through chapter 5 and continuing our discussion about the guiding principles of Extreme Programming.

• Intros
• Chit Chat

Recap:

• values are the roots of things we like and don't like in a situation
  • communication, simplicity, feedback, courage, respect
• practices are evidence of values
• principles bridge the gap between values and practices

Values are too abstract to directly guide behavior. (This is why we discuss things in the context of principles)

Other principles may guide your team, but these are the principles that guide XP:

• Humanity
• Economics
• Mutual benefit
• Self-similarity
• Improvement
• Diversity
• Reflection
• Flow
• Opportunity
• Redundancy
• Failure
• Quality
• Baby steps
• Accepted responsibility

Now obviously we aren't going to bore you with discussion on all 14 of these principles, so today we'll only talk about a handful of them.

Humanity - noun, the characteristics that make us human 🐸

Copy and paste alert

What do people need to be good developers? What are some basic human needs?

• Safety - freedom from hunger, physical harm and threats to loved ones. Fear of job loss threatens this
• Accomplishment - opportunity to contribute to their society
• Belonging - ability to identify with a group from which they receive validation
• Growth - opportunity to expand their skills and perspective
• Intimacy - ability to understand and be understood by others

Interestingly, satisfying these requisites meets both business and human needs.

Self-Similarity 👻

"Fractal Nature of geology" When nature finds a shape that works, she uses it wherever she can.
A crystal is a material whose constituents, such as atoms, molecules or ions, are arranged in a highly ordered microscopic structure — the same arrangment all the way to an atomic level. The same shape, makes up arrangments that make the same shape, that makes up arrangements that make the same shape.

All's to say - I've found that many things that prove useful at a small scale, work at larger scales

Concepts like

• Good names work for functions, methods, models, controllers, variables and namespaces
  — breaking things up into smaller peices, methods, functions, models controllers, etc
• process If it works to break up a method, it will probably work to break up a controler
• extraction Definining data in one organized place (switch statment Javascript example?)
• Simplicity

Diversity 🐸

Software development teams where everyone is alike, while comfotable, are not effective. Teams need to bring together a variety of skills, attitudes, and perspectives to see problems and pitfalls, to think of multiple ways to solve problems, and to implement the solutions. Teams need diversity

The principle of diversity suggets that the programmers should work together on the problem and both opinions should be valued.

Oppourtunity 👻

"Learn to see problems as opportunities for change."

To reach exellence, problems need to turn into opportunities for learning and improvment, not just survival.

Conciously choose to transform each problem into an opportunity. Good book on this the obsticle is the way

Example: .env files for all of our projects got posted to a public repo. We migrated toward a better more secure system, credentials that would be harder to leak and are easier to rotate. We used the problem as an oppourtunity to improve our architecture.

Quality 👻

Sacrificing quality is not effective as a means of control... Quality should not be a control variable.

• These are the variables you should change: Time, Cost, Money and Scope. Never quality

This is really extreme.

Author makes the aurgument that when you skimp on quality you end up spending even more time or money. This rings true, I have often taken the wrong approach in projects of skipming on design, testing or refacting and it doesn't really help in the long run.

We'd all like to get more features out the door for less money, it's just not doable. Less is less.

Failure 🐸

If you're having trouble succeeding, fail. Don't know which of the three ways to implement a story? Try it all three ways.

When you don't know what to do, risking failure can be the shortest, surest road to success

Conclusion:

• Principles give you a better idea of what the practice is intended to accomplish
• Understanding the principles gives you the opportunity to create practices that work in harmony with your existing practices and your overall goals

Picks

• JP: Burke Williams deep tissue massage. I'm all about the self-care
• John: App called "Mood" free app that helped me be more mindful of my emotions. It's been really insightful and helpful. I've moved from an average of 44% negative emotions to 55% positive emotions in just about 2 weeks. Just stoping and noticing my humanity, how some things make me feel has made a big impact in my overall mental wellness. I'm finding really interesting corollaries between my activities and diet and my overall happiness.

5 Essential Values in Extreme Programing
Extreme Programing By Kent Beck - Chapters 2,3 and 4

Chapter 2 - Learning to Drive
frequent, small corrections
don't wait to find out if you are going in the wrong direction
Chapter 3 - Values, Principles, and Practices
values are the roots of things we like and don't like in a situation.
Making values explicit is important because without values, practices quickly become rote (habitual repetition), activities performed for their own sake buck lacking any purpose or direction.

practices are evidence of values
Practices are clear. Everyone knows if I've attended the morning standup meetings. Whether I really valuecommunication is fuzzy. Whether I maintain practices that enhance communication is concrete.

principles bridge the gap between values and practices
START HERE
Chapter 4 - Values
Chapters 2 and 3 are small introductory sections, here is the TLDR:

Software, teams, and requirements change. We need to be able to adapt
to such change. The next 3 sections will be about values, practices,
and principles of Extreme Programming
Chapter 4 is about values

Everyone who touches software has a sense of what matters. One person might think what really matters is carefully thinking through all conceivable design decisions before implementing. Another might think what really matters is not having any restrictions on his own personal freedom.

What actually matters is not how any given person behaves as much as how the individuals behave as part of a team and as part of an organization.

Sometimes it's easy to bikeshed over things like code style. Arrow functions vs function declaration, inline functions vs methods, etc
XP embraces 5 values to guide development

1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect
6. Communication
   When you encounter a problem, ask yourselves if the problem was caused by a lack of communication. What communication do you need now to address the problem? What communication do you need to keep yourself out of this trouble in the future?

JP: Retro feedback and postmortem feedback often includes communication - both good and bad
2. Simplicity
To make a system simple enough to gracefully solve only today's problems is hard work.

"What is the simplest thing that could possible work?"

JP: Emphasis on "today's problems" - how can we provide value to the customer without compromising on theirexperience and without overengineering a solution?

JS: Stakeholder communicatinon, actively work to include everyone in at the key touchpoints, initial concept, mokcup, prototype, final review.

JS: Have something to look at / talk about. Somebody make a mockup, somebody write some pseudocode

3. Feedback
   Being satisfied with improvement rather than expecting instant perfection, we use feedback to get closer and closer to our goals. Feedback comes in many forms.

opinions about an idea, yours or your teammates

how the code looks when you implement the idea

whether the tests were easy to write

whether the tests run

how the idea works once it has been deployed

JP: Be agile! Look to build an MVP. Get analytics on things and make decisions from there. It's hard to invest in an idea entirely and then end up ditching the whole thing. Everyone feels burned.

JS: Again, think through key touchpoints, (99%, 50%, 1%)[https://medium.com/the-mission/how-to-scale-yourself-the-99-50-1-framework-7798518f36e1]

4. Courage
   Courage as a primary value without counterbalancing values is dangerous. Doing something without regard for the consequences is not effective teamwork. [...] The courage to speak truths, pleasant or unpleasant, fosters communication and trust. The courage to discard failing solutions and seek new ones encourages simplicity. The courage to seak real, concrete answers creates feedback.

JP: Being able to speak up when you disagree with people's ideas and being able to listen and exercising patience.
JS: Being honest with yourslef and stakeholders about timelines, replytimes, scope.
JS: Having the courage to set boundries. - "I need this by tomorrow" - I'm sorry, I can't make that happen for you.
5. Respect
If members of a team don't care about each other and what they're doing, XP won't work. If members of a team don't care about a project, nothing can save it. Every person whose life is touched by software development has equal value as a human being. No one is intrinsically worth more than anyone else.

JP: It's much easier when everyone respects each other.
JS: Reconize there's rarely a "wrong" approach, avoid letting pesonal preference becoming the "right" way.
JS: Reconize positives, "what I like about this is... however" Try to keep things in a positive context.
6. Other
This list isn't exhaustive. The important thing is that your team should align on core values.
Other Values: safety, security, predictability, and quality-of-life <- I feel like these need an episode!
Chapter conclusion:
Values don't provide concrete advice about what to do in software development. Because of the distance between values and practices, we need a way to bridge the gap between them. Principles are the tool we need.

Picks
JP: Pair code review sessions
JS: the (99/50/1 framework)[https://medium.com/the-mission/how-to-scale-yourself-the-99-50-1-framework-7798518f36e1]
JS: Basecamp's new book - (Shape Up)[https://basecamp.com/shapeup]

Extreme Programing Explained Embrace change

By Kent Beck

Chapter 1 - What is XP?

"Extreme Programing is about social change. It's about letting go of habits and patterns that were adaptive in the past, but now in the way of us doing out best work. It's about giving up the defenses that protect us but interfere with our productivity. It may leave us feeing exposed.

It's about being open about what we are capable of doing and then doing it. And, allowing and expecting others to do the same...

...It's about the process of becoming more of our best selves and in the process our best as developers. And, it's about writing great code...

"Philosophy of software based on... communication, feedback, simplicity, courage and respect.

"XP is my attempt to reconcile humanity and productivity in my own practice of software development..."

• John — Humanity and productivity. Pomodoro timers, too much coffee, pushing weekends.

"How would you do it if you had enough time? — Fussing about the constraints distracts you from your goals. Your clear self does the best work no matter what the constraints are"

• John — Riff on Time Constraints — Time is always my blocker. Is that a good one?

Final Summary — What is XP?

• Giving up old habits
• Fully appreciating yourself for total effort today
• Striving to do better tomorrow
• Consistently Evaluating yourself
• Meeting your Human needs

A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.
Roundtable: Getting a Job in Tech

Between books - Discussion about career development in tech

Guest: John Rivera - Link?

John S to lead discussion -
Where do you work now? What do you do?
John S: Run an agency, we are a small team of remote developers, we do mobile apps and web apps.
John R: Just started working on Amazon photos mobile app for the prints feature team, I do cross-platform mobile development primarily using React Native. But I’ve also gotten to do my fair share of project management with ChefSteps, and am seeking to pursue that at Amazon
JP: Opendoor
Where did you start? Where were you before tech?
5mins each on origin story
John S: Dabbled in design + web for ever — I was working in the corporate world a job I didn’t love but I was successful. Stepped back and switched careers at November 2015 - switched career at 25
John R: I worked at uhaul and albertsons as a meat clerk. Started things off by saving up for a bootcamp. Did freelance.
JP: MySpace layouts in 9th grade, 13-14 years ago. Then web design until about 2015
What’s been a key practice or tool in moving your career forward?
John R: Networking, Diving deep, embracing things that aren’t in my domain
John S: Consistency, Keeping up with friendships (networking), Blogging, pushing outside comfort zone.
How do you balance getting work done now vs ongoing learning?
John S: Use new tools and techniques in the day to day
John R:
JP: Being proactive with code review and looking to senior engineers
How do you get a good Job in tech?
John S: Network, publishing, making your work visible, random blog post from 2016
John R:
JP: I got my job from meetups

What would you have told yourself 3 years ago?
John S: Consistency, life is a marathon not a sprint. Keep stretching yourself outside comfort zone. Focus on less, go deeper on less things.
John R:
JP: Take breaks, you won’t forget how to code if you take a day off

CLOSE - no picks

John R - Where can people find you?

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

Work Stuff

• Work / Life separation
• Playing a lot with Vue JS - did an implementation on top of rails and loved it.
• Rivets JS
• Pre-built Sketch UI components (https://craftwork.design/)
• Refactoring UI (https://refactoringui.com/)
• Breaking things up! Learning more about technical design patterns.

Summary of "Refactoring"

• The Two Hats - Divide time between adding functionality and refactoring.
• Lots of Nested Functions read like a story
• Refactoring and performance
• Bad Smells
• Catalog of refactors / Catalog of patterns
  • Patterns of Enterprise Application Architecture
  • Decorator / Presenters (Displays Stuff)
  • Query Objects (Looks for stuff)
  • Service Objects (Does stuff)
  • Gateway Object (Defines access)
  • Mapper Object (Pricing Package) that associates customer lease and asset

Picks:

• Send later in Gmail
• Time Timer
• Angeles Crest Highway

Things mentioned
Craftwork design https://craftwork.design/

• Rivests JS
• Vue JS

To do refactoring properly, I need a solid suite of tests to spot my inevitable mistakes.

The Value of Self-Testing Code

• make sure all tests are fully automatic and that they check their own results
• a suite of tests is a powerful bug detector that decapitates the time it takes to find bugs

If you want to refactor, you have to write tests

A First Test

• simplicity of feedback from tests. just dots
• personally like verbose test output

Add Another Test

Testing should be risk driven; remember, I'm trying to find bugs, now or in the future. Therefore I don't test accessor methods that just read and write a field. They are so simple that I'm not likely to find a bug there.

My focus is to test areas that I'm most worried about going wrong.

Probing the Boundaries

• Seeing what happens when things go wrong

Whenever I have a collection of something, ... I like to see what happens when it's empty

• What happens when negative numbers are passed to a function that expects positive numbers? Division by zero?
  How do you probe boundaries?

Much More Than This

When you get a bug report, start by writing a unit test that exposes the bug

Picks

• JP: Taking time off

• Drawing from Chapter 7 - Encapsulation

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

Encapsulate Record (162)

var organization = { name: "JP Sio", country: "USA" };

becomes ⬇️

class Organization {
  constructor(data) {
    this._name = data.name;
    this._country = data.country;
  }

  get name() {
    return this._name;
  }
  set name(arg) {
    this._name = arg;
  }

  get country() {
    return this._country;
  }
  set country(arg) {
    this._country = arg;
  }
}

• you can hide what is stored and provide methods
• consumer of class Organization doesn't need to know / care which is stored and which is calculated
• nice getter and setter methods
• makes it easier to refactor -> can hide implementation of internals and update the internals while keeping the same external interface

Encapsulate Collection (170)

class Person {
  get courses() {
    return this._courses;
  }
  set courses(aList) {
    this._courses = aList;
  }
}

becomes ⬇️

class Person {
  get courses() {
    return this._courses.slice();
  }
  addCourse(aCourse) {
    /*...*/
  }
}

• slice() is key here, does not modify the original array - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice
• common approach is to provide a getting method for the collection to return a copy
• basically, never mutate the original

Replace Primative with Object (174)

orders.filter(0 => "high" === o.priority || "rush" === o.priority)

becomes ⬇️

orders.filter(o => o.priority.higherThan(new Priority("normal")));

• this goes back to "Primitive Obsession"

• programmers are often hesitant to create their own types and rely only on primitives. i.e. representing a phone number as a string instead of as it's own type

A telephone number may be represented as a string for a while, but later it will need special behavior for formatting, extracting the area code, and the like

• create a new class for that bit of data
• at first, the class does very little. in fact it probably only wraps a primitive
• but now you have a place to put behavior specific to its needs

Inline Function (115) 🥴

Sometimes it's better to not try to split things apart, sometimes it just complicates things.

// before refactor: 

function getItemPrice(item) {
  if (itemOnSale(item) == true) {
    return item.price - 5
  } else {
    return item.price
  }
};

function itemOnSale(product) {
  if (product.onSale == true) {
    return true;
  } else {
    return false;
  }
};

let original = getItemPrice(sweatshirt);

// after refactor: 

function newGetItemPrice(item) {
  if (item.onSale == true) {
    return item.price - 5
  } else {
    return item.price
  }
};

Extract Class (182) 🥴

• Talk through HUGE applicant model (in Ruby)
• Broke this into child objects
  • Applicant Health History
  • Applicant Habits
  • Applicant Lifestyle
  • Applicant Method
  • Applicant Legal Release

Picks

• JP: None :(
• John: Quad Lock phone mount - bikes

The theme of this chapter: just because you know how to refactor, doesn't mean you know when. This chapter talks about the when.

One thing we won't try to give you is precise criteria for when a refactoring is overdue. In our experience, no set of metrics rivals informed human intuition. What we will do is give you indications that there is trouble that can be solved by a refactoring.

Mysterious Name

• there can be ambiguity in your naming in many places: variable, class, function, method, database field, etc

Duplicated Code 🔥

• keep it dry

Long Functions 🔥

• Since the early days of programming, people have realized that the longer a function is, the more difficult it is to understand

Long Parameter List 🔥

• long parameter lists can be confusing

Global Data 🔥

• the problem with global data is that it can be modified from anywhere in the codebase, making it harder to figure out which code touched it should you need to debug it

Mutable Data

• changes to data often lead to unexpected consequences and tricky bugs
• mutable data that can be calculated elsewhere is particularly pungent

Divergent Change ✅

• if you look at a module and say, "well, I will have to change these three functions every time -------- happens" - this is an indication of divergent change
• divergent change occurs when one module is often changed in different ways for different reasons
• can be solved with split phase, extract function, extract class, move function

Shotgun Surgery ✅

• similar to divergent change.
• every you make a change, you need to make a ton of little edits to a lot of different classes

Feature Envy

• occurs when a function in one module spends more time communicating with functions or data inside another module than it does within its own.

Data Clumps

• grouping data together when it really should be it's own object

Primitive Obsession ✅

• programmers are often hesitant to create their own types and rely only on primitives. i.e. representing a phone number as a string instead of as it's own type

Repeated Switches

• alleviated with polymorphism

Loops

• use pipelines instead, i.e. filter, map, each, reduce

Speculative Generality ✅

editor choice

• can be spotted when the only users of a function or class are a test case. this is a classic case of premature optimization. "we'll eventually want to add this feature..."

Message Chains

• when a client asks one object for another object, which the client then asks for yet another object, and so on.

Middle Man

• when you have too much delegation (due to all of your great encapsulating of implementation details)
• the solution is to delegate directly, cut the middle man

Insider Trading

Large Class ✅

• class is doing too much

Alternative Classes with Different Interfaces

Data Class

Refused Bequest

Picks:

• JP: https://classicleatherfobs.co.uk/product-category/porsche/
• John: https://c-command.com/toothfairy/

• Extract Function
• Change Function Decleration
• Replace Temp with query
• Replace conditional with polymorphism
  Refactoring in Practice
  Introduce Parameter Object - 140
• Structure your parameters
• This way order doesn’t matter
• You can set default values
• Grouping data is more clear in the relationship
  Replace Constructor with Factory Function 334 -
• Encapsulating the creation of objects (the initialize) into a factory Function
  In Ruby: Creating a new User and Organization within a UserOrganizationFactory call / Tangent / Related to FormObjects.
  In JavaScript: availableVariants - big array with Item, Colors, Sizes - replaced with variantFactory(34,2345,2345,) just passing ID’s
  Extract Function into class - 182
• Consolidate up a bunch of related functions into a parent class
  Split Phase 154 - Variant of Extract Function
• When a function is dealing with two different things - look for a way to split it out - was cleaner approach.
  JavaScript
• Cart.js - logic of API calls associated with the user input
• Split this into discrete functions
  Ruby
• Notification logic was calling Twilio
• Encapsulate this into it’s own method
• Later then it was a service object to itself
  My Cart.js Story - (Refactoring in Vue / JavaScript)

• addItem - for adding item to cart
• removeItem - for removing item from cart
• increaseItemCount - for adjusting line item
• decreaseItemCount - for adjusting line item
• setLineItemCount - for adding to cart an initial value
  First - Rename Methods (Change Function Declaration) 124
• addItem - became - addItemToCart
• removeItem - became - removeItemFromCart
• increaseItem - became - increaseLineItemCount
• decreaseItem - became - decreaseLineItemCount
  Second - Extract Function 106
• Both increaseLineItemCount and decreaseLineItemCount were doing something very similar.
• So I created a new function of setLineItemQty
• Both my methods of increaseLineItemCount and decreaseLineItemCount were then calling this setLineItemQty that accepted a qty parameter - function.
  Second - parameterize Function 310
• This did take a refactor of my vue listeners.
• Since I had this new setLineItemQty that accepted a qty parameter
• I replaced increaseLineItemCount and decreaseLineItemCount a single function of setLineItemQty
• Deleted a lot of code
  Third - Used inline function 106 to simply alias another function.
• Through the above refactors I realized that addItemToCart was doing the same transactional work as setLineItemQty to 1
• I removed the body of addItemToCart and replaced it with setLineItemQty with the default params accordingly.
  Fourth - Again used inline function 106 to alias another function
• Through the above refactors I realized that removeItemFromCart was doing the same transactional work as setLineItemQty to 0
• I removed the body of removeItemFromCart and replaced it with setLineItemQty with the default params accordingly
  Fifth - I used
  I realized that all these functions were just doing the same thing. Adjusting CartLineItemCount.

• The final refactor simply deleted removeItemFromCart and addItemToCart
  In closing:

• Code went from 160 lines to around 60
• It’s way DRY
• It’s way more reusable
• The interface to my cart.js is now just a single function of setLineItemQty
  Updated my vue listeners - Every interaction within this front end is just calling setLineItemQty

Picks:

• vue.js - https://vuejs.org/ -
• Burnout Reddit thrread: https://www.reddit.com/r/cscareerquestions/comments/b6xzr0/how_do_you_keep_from_burning_out_at_your_job/

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

• Define Refactoring
• “If someone says their code is broken for a couple days while they are refactoring =, you can be pretty sure they aren’t refactoring.
• Adding Features Vs Refactoring

Why should we refactor?

• Code rot - overtime the code decays - rushed or poorly executed changes
• Regular refactoring helps keep things in shape
• Makes things easier to understand
• (Delegating issues in clean codebase vs rough)
• Refactoring helps find bugs
• Refactoring helps us work faster long term - cleaning your workspace
• Over time adding new features is easier

Getting buy in for refactors:

• Don’t tell your manager / client
• Build it into your estimates
• You are being paid for your expertise
• be confident in somewhat hiding the implementation. (Depends on your role)

When to refactor:

• Prepatory Refactoring
• Comprehension refactoring
• Long term refactor - Ech small change leaves everything is a still working state, not just “up to date”
• In code reviews

When to not refactor:

• If the code is working fine and it doesn’t need to be changed
• If it works like an API
• When it will slow down an essential new feature.

Legacy Code

Refactoring Tools for future episodes?

• Writing Ruby Gems
• Renovate Bot

Picks

• JP: Free Event Tickets
• John: Eero wifi router

This episode walks through specific code examples from Chapter 1 of Martin Fowler's Refactoring...

Some of the refactors

Change Function Declaration

• Rename things
• Names are hard
• A few general categories of things you can name
  • predicate? - Should only return true / false - Javascript start with is - ruby question mark - so isValidPhone(number)
  • In Ruby - ! For destructive / dangerous actions - update_recent_activity! - name destructive actions or actions with side effects really well.
  • Formatting? - use - as - number_as_phone(number) or to to_bmi(user.weight, user.height)

Extract Function

Replace temp w/ query

• Extending this example:

Instead of:

accounts = get_accounts(user)
transactions = get_transactions(accounts)

we can just do:

transactions = get_transactions(get_accounts(user))

Replace conditional with polymorphism

Notification.deliver! example

Picks

• JP: Thanos JS - https://thanosjs.org/
• John: Loom https://www.loom.com/ - and http://www.telestream.net/screenflow/overview.htm

Refactoring

Improving the Design of Existing Code

by Martin Fowler (with Kent Beck)

Introduction

• What’s in the book?
• Who’s it for?
• What’s refactoring?

Refactoring process:

• Identify a pain, smell a smell, we’ll talk more about when to refactor in later episodes.
• Separate feature additions from refactors
• Refactorings are like diets - a lifestyle vs an intensive
• Test coverage first
• Small changes continually running tests
• End goal: lots of small well-named functions that tells a clear story.

Considerations + Thoughts

• Tests let JP in react native move faster
• Refactoring lets you get things out of your head and into the code. Do this continuously.
• Performance and refactoring

My Pick:

• How To Code Well - howtocodewell.net
• Dark Net Diaries https://darknetdiaries.com/
• Selection - Apple's Design Process

This week is a more casual episode where we talk about recent struggles findings and some of our favorite parts of our most recent book. Practical Object-Oriented Programming in Ruby

We'll be back episode covering a new book - Refactoring by Martin Fowler

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

CH2 - Designing Classes with a single responsibility

Chapter 7 - Favorite Takeaways/Examples From POODR

• Duck Typing -
• Modules -

My Team Came up with:

include Listable

include Lister

Any user type can act as a “Lister” and add things to the list

Any object can be “Listable” or “added to a list”

Recent Lessons - Always have a staging environment

Picks:

https://thispersondoesnotexist.com/

Testing… Testing… 123

Publishing February 18th - Hope everyone had a good Valentine’s Day weekend!

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

Introduction

• Writing changeable code is an art on which practice relies on three different skills. First, you must understand object-oriented design. Poorly designed code is naturally difficult to change.
• First, you must understand object-oriented design. A poorly designed code is naturally difficult to change.
• Second, you must be skilled at refactoring code.
• Finally, the art of writing a changeable code requires the ability to write high-value tests. Tests give you the confidence to refactor constantly.

Reasons to test:

• Finding Bugs
• Supplying Documentation
• Deferring Design Decisions
• Supporting Abstractions
• Exposing Design Flaws

Knowing What to test:

• “Most developers write too many tests” - OR NONE! hahaha
• Tests should concentrate on the incoming or outgoing messages that cross an object’s boundaries.
• Back to the Kitchen Metaphor - Test that ordering a hamburger, returns a hamburger as expected, not that the kitchen staff turns on the grill or slices tomatoes.
• Incoming messages should be tested for the state they return.
• Outgoing command messages should be tested to ensure they get sent.
• Outgoing query messages should not be tested.

Knowing When to Test

• Write tests first, whenever it makes sense to do so

Knowing How to test:

• Testing Styles: Test Driven Development (TDD) and Behavior Driven Development (BDD).
• Proving the Public Interface
• Injecting Dependencies as Roles
• Testing Inheritance - Test your base class - then include the module to test each of the responses that are in the base class.
• Creating Test Doubles - DiameterDouble - A test double is a stylized instance of a role player that is used exclusively for testing - tend to override the base class in my test helper - I’ve run into silent errors this way.
• Testing Private Methods - interface. These private messages are like proverbial trees falling in empty forests; they do not exist, in a perfect world they do not need to be tested - testing them is a code smell.
• Testing Ducks - create a preferred test interface - mechanic and a guide can both prepare - you can establish a single interface and simply pass the different objects into it.
• Testing Inherited Code
• Testing Models + Objects Vs interface - where’s the balance?

Tests are indispensable. Well-designed applications are highly abstract and under constant pressure to evolve; without tests these applications can neither be understood nor safely changed. The best tests are loosely coupled to the underlying code and test everything once and in the proper place. They add value without increasing costs.

Next Episode - Recap of Practical Object-Oriented Design and New book announcement!

Picks:

NOUN PROJECT - https://thenounproject.com/

**Super Smash Bros Ultimate **

Neil Davis - @Nei1dor

Aaron Kelton

Metz, Sandi. Practical Object-Oriented Design in Ruby

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

“Combining the qualities of two existing subclasses, something that inheritance cannot readily accommodate.”

We talked about inheritance, then modules, now this builds on top of the idea of modules and pushes it further.

Composing a bicycle of parts...

Bicycle > has A parts

Parts has subclasses of - RoadBikeParts and MountainBikeParts

Making the Parts Object More Like an Array - This part was freaky

Parts Factory

Different Configs within the parts factory > an array of all the keys and attributes - road_config - mountain_config

Using all this to make a recumbent bike:

Once this is all set up you have this incredibly powerful interface of a bicycle composed of parts:

Bicycle.new(

size: 'L',

parts: PartsFactory.build(recumbent_config))

Composition VS Aggregation

A Meal is composed of an appetizer - An appetizer does not survive outside of the meal. When the meal is gone by definition the appetizer is gone. A meal is composed of an appetizer.

A band is an aggregate of musicians - when the band breaks up the musicians don’t die.

“Composition” encompasses both aggregation and composition -

“This distinction between composition and aggregation may have a little practical effect on your code.”

Deciding Between Inheritance and Composition

“Think of it this way: For the cost of arranging objects in a hierarchy, you get message delegation for free.”

When in doubt use Composition over inheritance

“The general rule is that faced with a problem that composition can solve, you should be biased towards doing so. If you cannot explicitly defend inheritance as a better solution, use composition.”

John’s Pick: Book: "It Doesn’t Have To Be Crazy At Work" -> David Heinemeier Hansen and Jason Fried

JP: Kahn Academy - digging into math again

Next Week: Final Chapter - Designing Cost-Effective Tests

Chapter 7. Sharing Role Behavior with Modules

Welcome to iteration

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

Modules! Modules! Modules!

Last episode we talked about inheritance which was kind of an extension of duck typing… but sometimes we need to combine the qualities of two existing subclasses, something that inheritance cannot readily accommodate.

Many object-oriented languages provide a way to define a named group of methods that are independent of class and can be mixed in to any object. In Ruby, these mix-ins are called modules.

Discovering the Schedulable Duck Type

The Schedule expects its target to behave like something that understands lead_days, that is, like something that is “schedulable.” You have discovered a duck type.

This specific example illustrates the general idea that objects should manage themselves; they should contain their own behavior.

Mountain Bike? Mechanic?

Now, in the code above, the dependency on Schedule has been removed from Bicycle and moved into the Schedulable module, isolating it even further.

Like Using Inheritance

COMES BACK TO AUTOMATIC MESSAGE DELEGATION

Loggable Example

When Bicycle includes Schedulable, all of the methods defined in the module become part of Bicycle’s response set.

When a single class includes several different modules, the modules are placed in the method lookup path in reverse order of module inclusion. Thus, the methods of the last included module are encountered first in the lookup path.

When a single class includes several different modules, the modules are placed in the method lookup path in reverse order of module inclusion. Thus, the methods of the last included module are encountered first in the lookup path.

Picks:

John: Type to Siri - Accessibility > Siri > Type to Siri

JP: Scrimba - https://scrimba.com/playlist/pKwrCg

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

Sani Metz - Object-Oriented Design in Ruby

“Inheritance is, at its core, a mechanism for automatic message delegation. It defines a forwarding path for not-understood messages.”

Where to Use Inheritance

Objects that share a common parent -

The objects that you are modeling must truly have a generalization-specialization relationship.

Bicycle Touring Company - FastFeet

Bikes - Mountain and Road Bikes

Bikes have an overall size, a handlebar tape color, a tire size, and a chain type.

• Only mountain bikes have shocks
• Only Road bikes have handlebar tape

Create a new empty Bicycle Class

Let RoadBike > Bicycle

And MountainBike > Bicycle

When in doubt put less code in the parent, it’s easier to promote code later when you need a shared code.

“The general rule for refactoring into a new inheritance hierarchy is to arrange code so that you can promote abstractions rather than demote concretions.”

A superclass may have many subclasses, but each subclass is permitted only one superclass.

This family tree image is, however, a bit misleading. In many parts of the biological world, it’s common for descendants to have two ancestors.

It’s really useful to rails a NotImplementedError in the parent class in the methods that are required from their children, for example, default tire_size -

“Creating code that fails with reasonable error messages takes minor effort in the present but provides value forever.”

Initialize > Post Initialize to append any or overrode attributes from the parent initialize method.

Initialize + post_initialize

Closes with a mic drop - Initializing a new RecumbentBike is so DRY and painless!

“Inheritance solves the problem of related types that share a great deal of common behavior but differ across some dimension.”

“The best way to create an abstract superclass is by pushing code up from concrete subclasses.”

“When your problem is one of needing numerous specializations of a stable, common abstraction, inheritance can be an extremely low-cost solution.”

PICKS

• JP: Machine Learning with JavaScript
• John: Refactoring UI by Adam Wathan and Steve Schoger -
• Hard Wired Internet - Ran a Cat 5 Cable from my router - SO WORTH IT.

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

Duck types are public interfaces that are not tied to any specific class.

Objects that are defined by their behavior than by their class name.

if an object quacks like a duck and walks like a duck, then its class is immaterial, it’s a duck.

In a way, the “+” operator is a “duck type” - because it responds differently to a different type of objects.

Preparer

TripCoordinator, Mechanic, Driver can all be a preparer - they all respond to the prepare method in their own ways.

At a higher level, what are these all doing? They are preparing something - we can trust within this shared interface.

Within mechanic - we only call prepare_trip vs gas_up or full_water_tank-

Instead of switching on type

You

Talk through this Object:

Notification Object?

https://github.com/withbetterco/wellstart/blob/master/app/models/notification.rb#L156

It has this insane method checking to see if the user’s notification settings match the notification that’s trying to send

We are wanting to extend the notification object, for another type - Push Notifications

Object (message, comment, like)

User

NotificationSettings

Notifier

Notification Policy

“The ability to tolerate ambiguity about the class of an object is the hallmark of a confident designer.”

Recognizing a duck:

“You can replace the following with ducks: • Case statements that switch on class • kind_of? and is_a? • responds_to?”

Polymorphic Objects

Went from a ParticipantNote, and ProgramNote, and ApplicantNote, to one single Note object through a Notable Module. They all have “ has _many: notes, as:: notable” instead of each having “program_notes”, applicant_notes, etc.

“you are missing an object, one whose public interface you have not yet discovered.”

Dot files - .zshrc - Custom prompt - with my git status -

Slippers from JP - Quadie

At an object-oriented level, applications are made up of classes but defined by messages

• The design is concerned with messages that pass between objects
• This conversation between objects takes places using interfaces

Defining Interfaces

Imagine a restaurant kitchen. Customers order food off a menu. The menu is a kind of public interface. Within the kitchen, messages get passed and the way a meal is prepared (implementation details) are private to the customer.

• Classes are like kitchens. The class exists to fulfill a single responsibility but implements many methods

Public Interfaces

• reveal primary responsibility
• expected to be invoked by others
• will not change on a whim
• safe for other to depend on
• thoroughly documented in the tests

Private Interfaces

• handle implementation details
• not expected to be sent by other objects
• can change for any reason whatsoever
• unsafe for others to depend on
• may not even be referenced in tests

The public interface is a contract that articulates the responsibilities of your class

Example App: Bicycle Touring Company

• FastFeet Inc. is a company that offers road and mountain bike trips
• They use a paper system
• Routes that are offered may occur several times during the year
• Each Route has limitations on the number of customers who may go and requires a specific number of guides who double as mechanics
• Each Route is rated according to its aerobic difficulty.
• Mountain bike trips have an additional rating that reflects technical difficulty.
• Customers have an aerobic fitness level and a mountain bike technical skill level to determine if a trip is right for them
• Customers may rent bikes or they can bring their own
• FastFeet Inc has a few bikes available and also shares in a pool of bike rentals from local shops
• Rental bikes come in various sizes and are suitable for either road or mountain bike trips

Use case

• A customer, in order to choose a trip, would like to see a list of available trips of appropriate difficulty, on a specific date, where rental bikes are available

Constructing an Intention

• WHEW - where do we even start with this brand new application? A lot of requirements here.
• It's important to start DESIGNING your application. Don't just dive in and start writing code! PLAN
• The first thing you should do is form an intention about the objects and messages needed to satisfy the use case

• Sequence diagrams can be helpful for planning because the design conversation has shifted
• Instead of thinking about what classes should exist and what responsibilities they should have, we are NOW deciding what messages should be sent, where to send them, and who should receive them
• You don't send messages because you have objects, you have objects because you send messages

Asking for "What" Instead of Telling "How"

The distinction between a message that asks for what a sender wants and a message that tells the receiver how to behave may seem subtle but the consequences are significant

• Let's say we have two objects that need to communicate: trip and mechanic
• We could have the trip send messages to the mechanic in order to prepare a bicycle:
  • clean bicycle
  • pump tires
  • lube chain
  • check breaks
• The problem with this is that we're telling the mechanic HOW to prepare the bike.
• We should be telling the mechanic WHAT to do and leave the implementation details up to the mechanic.
• Instead, the trip should just send the message:
  • prepare bicycle
• Doing this gives the responsibility of preparing a bicycle to the mechanic entirely. We trust the mechanic to accomplish this task. We tell what and not how

Seeking Context Independence

The best possible situation is for an object to be completely independent of its context. An object that could collaborate with others without knowing who they are or what they do could be reused in unanticipated and novel ways

• We could do this with dependency injection

Using Messages to Discover Objects

Recall the use case: A customer, in order to choose a trip, would like to see a list of available trips of appropriate difficulty, on a specific date, where rental bicycles are available

• This application needs an object to embody the rules at the intersection of Customer, Trip, and Bicycle
• We have an unknown object; we just know we need some object to receive our message
• What if we defined a TripFinder class that is responsible for finding suitable trips
  • It contains all the knowledge of what makes a trip suitable
  • it knows the roles
  • its job is to do whatever is necessary to respond to this message

Writing Code That Puts Its Best (Inter)Face Forward

Methods in the public interface should:

• be explicitly defined as such
• be more about what than how
• have names that will not change
• take a hash as an options parameter

• Ruby provides three relevant keywords: public, protected, and private
• These keywords indicate which methods are stable and unstable. It also indicates how visible a method is to other parts of your application

JP’s: HackingWithSwift

John’s Pick: MacStadium.com -

To collaborate, an object must know something about others. Knowing creates a dependency. If not managed carefully, these dependencies will strangle your application

Recognizing Dependencies

An object has a dependency when it knows:

• The name of another class.
  • Gear expects a class named Wheel to exist
• The name of a message that it intends to send to someone other than self.
  • Gear expects a Wheel instance to respond to diameter
• The arguments that a message requires.
  • Gear knows that Wheel.new requires a rim and a tire
• The order of those arguments.
  • Gear knows the first argument to Wheel.new should be rim and the second should be tire

Writing Loosely Coupled Code

Inject Dependencies

see 1_inject_dependencies.rb

• Referring to a class by its name inside of another class is bad.
• If the name of Wheel class changes, the gear_inches method must also change
• The bigger problem is that gear_inches is explicitly saying that it is only willing to calculate gear inches for instances of Wheel
• Gear will only collaborate with any other kind of object even if that object has a diameter and uses gears!

It's is not the class of the object that's important, it's the message you plan to send to it.

• Gear needs access to an object that can respond to diameter - a duck type
• We can use a technique called dependency injection to move the creation of a new Wheel instance outside of the class

Isolate Dependencies

see 2_isolate_dependencies.rb

Isolate Instance Creation

• Sometimes you can't break all unnecessary dependencies, but you can isolate them
• The first technique moves Wheel.new from gear_inches and into Gear's initialize method
• The next alternative isolates the creation of a Wheel into its own wheel method

Isolate Vulnerable External Messages

• gear_inches depends on Gear responding to wheel and wheel responding to diameter
• by creating a different diameter method to hold wheel.diameter, we remove the dependency within gear_inches

Remove Argument-Order Dependencies

see 3_remove_arg_orer_dependencies.rb

Use Hashes for Initialization Arguments

• arguments of our initialize method must be passed in the correct order. we can pass an object instead to remove this dependency

Explicitly Define Defaults

• we can use the fetch method to set defaults when using hashes in our initialize method
• fetch expects the key you're fetching to be in the hash and supplies several options for handling missing keys
• fetch will only set the default if the key is not found in the hash

Managing Dependency Direction

• All examples thus far have shown Gear depending on Wheel or diameter - but the code could have easily been written so that Wheel depends on Gear or ratio

Choosing Dependency Direction

Depend on things that change less often

John’s pick - Pick Krisp -https://krisp.ai

The foundation of an object-oriented system is the message, but the most visible organizational structure is the class

Questions to ask yourself:

• What are your classes?
• How many should you have?
• What behavior will they implement?
• How much do they know about other classes?
• How much of themselves should they expose?

Creating Classes That Have a Single Responsibility

A class should do the smallest possible useful thing; that is, it should have a single responsibility

An Example Application: Bicycles and Gears

• Let's take a look at bikes. Consider the types of gears that bikes use

Small Gears

• easy to pedal, not as fast
• takes many pedals just to make the tires rotate once
• can help you creep along steep hills

Large Gears

• harder to pedal, fast

• sends you flying down those steep hills

• one pedal rotation with your foot might cause the tires to rotate multiple times

• Let's start with a small script and then extrapolate classes out of it:

  Large Gear

  chainring = 52
  cog = 11
  ratio = chainring / cog.to_f

  puts 'Large Gear:'\
  "\n#{chainring}-tooth chainring"\
  "\n#{cog}-tooth cog"\
  "\n#{ratio.round(2)} rotations"

  Small Gear

  chainring = 30
  cog = 27
  ratio = chainring / cog.to_f

  puts "\nSmall Gear:"\
  "\n#{chainring}-tooth chainring"\
  "\n#{cog}-tooth cog"\
  "\n#{ratio.round(2)} rotations"

• Since we're talking about gears, it only makes sense that we start by creating a Gear class based on the behavior above

see 1_gear.rb

• Our Gear class has three methods: chainring, cog, and ratio

• Gear is a subclass of Object and thus inherits many other methods besides the three that we defined

• What I'm trying to say is that the complete set of behavior / the total set of messages to which it can respond is fairly large

• This is great and all - but what if we want to extend the functionality by taking into account the effect of the difference in wheels

  • Bigger wheels travel much farther during each wheel rotation versus smaller wheels

• Consider this formula

  gear inches = wheel diameter × gear ratio

  (where)

  wheel diameter = rim diameter + (2 × tire diameter)

see 2_gear.rb

• This new code is great except our old call to Gear.new(52, 11) no longer works because we added 2 more arguments to our initialize method

Why Single Responsibility matters

• Applications that are easy to change consist of classes that are easy to reuse. [...] A class that has more than one responsibility are difficult to reuse

Determining If a Class Has a Single Responsibility

• How can you tell if your class is only doing a single thing? Try describing what it does in a single sentence. You'll find out very quickly
• Remember that a class should do the smallest possible useful thing
• When we look at our Gear class - perhaps it is doing too much
• We are calculating gear_inches, which is fine - but calculating the tire size seems a little weird

When to Make Design Decisions

• When we look at the Gear class, there's something off about having rim and tire in there.
• Right now the code in Gear is transparent and reasonable - this doesn't mean that we have great design. All it means is that we have no dependencies
• Right now, Gear lies about its responsibilities as it has multiple responsibilities in that it has to do "wheel" calculations in our gear_inches message

Write Code That Embraces Change

Here are some techniques that help you write code that embraces change

Depend on Behavior, Not Data

• Behavior is captured in methods and invoked by sending messages
• Objects also contain data (not just behavior)

Hide Instance Variables

• Always wrap instance variables in accessor methods instead of directly referring to variables, like the ratio method does.

• We can do this by using an attr_reader

  BAD

  def ratio
  @chainring / @cog.to_f
  end

  GOOD

  def ratio
  chainring / cog.to_f
  end

• If your instance variable is referred to multiple times and it suddenly needs to change, you're in for a world of hurt.

• Your method that wraps your instance variable becomes the single source of truth

• One drawback is that because you can wrap any instance variables in methods, its possible to obfuscate the distinction between data and objects

• But the point is that you should be hiding data from yourself.

• Hiding data from yourself protects code from unexpected changes

Hide Data Structures

• Depending on a complicated data structure can also lead to a world of hurt
• For instance, if you create a method that expects the data structure is being passed to it to be an array of arrays with two items in each array - you create a dependency

see 3_obscuring_references.rb

• Ruby makes it easy to separate structure from meaning
• You can use a Ruby Struct class to wrap a structure

see 4_revealing_references.rb

• the diameters method now has no knowledge of the internal structure of the array
• diameters just know that it has to respond to rim and tire and nothing about the data structure
• Knowledge of the incoming array is encapsulated in our wheelify method

Enforce Single Responsibility Everywhere

Extra Extra Responsibilities from Methods

def diameters
  wheels.collect { |wheel| wheel.rim + (wheel.tire * 2) }
end

• this method clearly has two responsibilities

  • iterate over wheels
  • calculate the diameter of each wheel

• we can separate these into two methods that each have their own responsibility

  def diameters
  wheels.collect { |wheel| diameter(wheel) }
  end

  def diameter(wheel)
  wheel.rim + (wheel.tire * 2)
  end

• separating iteration from the action that's being performed on each element is a common case of multiple responsibilities

Finally, the Real Wheel

• New feature request: program should calculate bicycle wheel circumference
• Now we can separate a Wheel class from our Gear class

see 5_gear_and_wheel.rb