iteration

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 listensJP clear action items for problemsWhat makes a good 1:1 (Manager perspective)?John When reports are honest about motivations (I want more money, etc)John Clear feedback about my managementWhat makes a bad 1:1?JP when 1:1s just become another medium for standup updatesJP when 1:1s become a way for your manager to micromanageFormatWhat 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 / conceptsFocus 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 conversationMoneyball firing clipPicksJohn: 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 + DesignersFew TopicsIC vs ManagerCode on the side only to show thingsNot coding for productionCode outside of your core codeRight sizing a teamSystems Thinking "Stocks + Flows" (Slack)Mythical Man MonthFalse premise: More heads = faster resultsRemove bottlenecksBreak up the workKitchen MetaphorContext + DocumentationSafety + EmpowermentPermission + TrustAccessLeading by example"Law of the lid"Don't scar on the first cutForbidden Conversations / honestyPicksJohn: https://handmirror.app/JP: https://freezingcam.com/

Welcome to Iteration, a podcast about programming, development, and designJohn 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 projectMaybe 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.rbPicksJP: https://tuple.app/I used this to pair with Joe and it was SICKJohn: YNAB (https://www.youneedabudget.com/)Different approach to budgeting that sucks less

NOTE THIS IS A RE-UPLOAD AS THERE WAS ISSUES WITH OUR PREVIOUS UPLOAD  > 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 ToolsJiraTrello JohnAsana JohnGithub (issues + projects) JohnZenhub JohnPivotal TrackerNotion JohnSpecial mention: Canny.io → https://main-street.canny.io/adminNew BloodLinear App: https://linear.app/Height App: https://height.app/ (private beta)Monday? I always see ads for this on youtube: https://monday.com/BASECAMPPicksJP: https://martinfowler.com/articles/feature-toggles.htmlJohn: https://supabase.io/ (Open Source Firebase)https://elainewherry.com/2012/06/26/the-recruiter-honeypot/

E-commerce EpisodeJohn: 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-GrittyHow to model purchasesModel PaymentsHow to test paymentsGotchas when building e-commerceDiscountsSalesCouponsRefundsInventory vs digital goodsHeadless vs “full stack”Stacks / ServicesInventory and More (full stack)ShopifyBigCommerceMagnetoSolidusSpreeSimple / digital onlyInstagram + PaypalGum roadSaas Solutions Stripe CheckoutPaddleFast SpringChargifyhttps://recurly.com/PicksJP: https://hotwire.dev/ (hehe)John: https://linear.app/ReferencesActs as shoping cart gemPay gemFoundation

Approaches to Building AppsSeverless (Lambda functions)PWA (progressive web apps)Headless (Ecom / cms)ContentfulShopifyTech Trending UpwardsE-commerce (up 37% from last year)Artificial Intelligence(AWS sagemaker, GPT-3)Voice search66million smart speakers - 1/3 27% of mobile searches are voice basedAMP'dApps will continue to ruin the internetChatbotsJP: I personally hate these things. Just get me to a customer service rep ASAPPicksJP: 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 startupOur 2020 Goals Episode → Link✅ 2020 Developer Goals2020 ReviewJPGoal 1 (JP): Build Elixir App: (C+)I did build a really quick proof of concept Rust API that spits out some JSONI also followed a tutorial for a full stack Golang appGoal 2 (JP): System Design (F)Did not read the books that I wanted to readGoal 3 (JP): Algorithms - (C+)Just haven't had the time - but I have reviewed some array based algorithms FWIWJohnGoal 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 MainlyGoal 4 (John): Focus

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 startuphttps://macwright.com/2020/05/10/spa-fatigue.htmlTopics / Guiding QuestionsWhat's a SPA?From the articleThe main UI is built & updated in JavaScript using React or something similar.The backend is an API that that application makes requests against.The more techincal one:https://developer.mozilla.org/en-US/docs/Glossary/SPAAn 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.comBreaks REST might be a good time to considerCommunityWhat's wrong with this SPA's?Increased complexity — Development and deploymentOften 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 freeAsync fetchingState managementURL's just workStrong ConventionsStable minimal maintenanceWhat's bad about Server Rendered?Page ReloadCan feel clunkyLess ReactiveMobile App — Now what? SPA lays a stronger groundworkWhat's good about SPA'sBenefits are for the userDeveloper Ego'sData foundationsBreaks CRUDCommunityPushing technology forward is a good thing.What's bad about SPA'sHow much of a pain in the ass it is to Manage URL'sComplexity — Front end + Back endAuthenticationImage UploadMultiple API endpoints for a single pageState is way harder in a SPADebuggingClosing ThoughtsSPA's are great when you are breaking "REST / CRUD"SPA's are great when you need multiple consumers of the same dataThis is highly personal, you gotta go with what you love.WiFiPicksJohn — Distraction Free Phone from the book Make TimeMobile: 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 adsDesktop: https://selfcontrolapp.com/ —JP - https://railsnew.io/

In this episode we dive deep on tech stack choices, why they matter, how to choose one, when tech stack doesn't matter and when it makes all the difference in the world.

Back from break: In this episode JP + John cover all kinds of topics. Balancing life with a baby, testing, API dependencies and more.

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 CAToday's topicThe "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 TwillioThis is a "Full Stack" — No code app development framework in the cloud.WYSIWYG for "Apps"This isn't software!Popular Codeless toolsFull "App" Developmenthttps://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 clonesAirtableRetoolSmartsheetNotionQuickbaseDomain Specific CodelessShopify ← eCommerceSharetribe ← Build a Marketplace AppSubstack ← Paid NewslettersMighty Networks ← Paid CommunitiesPodia ← Sell online coursesSo so many moreUpsides of Low CodeLow Code / No Code is an incredible tool for going from 0-1.All NotesDownsides of Low CodeLow 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 gotchasJohn'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 SoftwareNotesOther thoughts regarding of Low codeNon 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 ToolsAccept the limitationsSpending 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 inWhere does data live? Is it secure? is it backed up? Is it in a silo? Can it be migrated / exported?Popular Codeless Resourceshttps://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 codeRyan Hoover: The Rise of No-CodePodcast: Going Codeless: Is this the way of the future?Forbes: The Low-Code/No-Code Movement: More Disruptive Than You RealizePicksJohn — Lighthouse Chrome Dev ToolsJP - https://github.com/kelseyhightower/nocode

Welcome to Iteration, a podcast about programming, development, and design.John's blog post on the topic PicksJP: Siema SliderJohn: Rough Notation JS

Welcome to Iteration, a podcast about programming, development, and design.This week we talk through the most common abbreviations in software. For a whole complete list and discussion — visit this link PicksJohn: TeladocJP: https://github.com/scenic-views/scenicLinks JP on TwitterJohn on Twitter

Today's topic:Onboarding into a new codebaseAs a new hire / contractor for a freelance projectFrom JP:Reviewing other people's PRs on a new codebaseSubmitting your first PRUnderstanding how data flows through the appI've found that the organization of the code and the quality of abstractions makes or breaks this pointRamping 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 softwareRead the Docs, all that you can get your hands onReview closed issues / tickets, try to understand the language /culture of the teamReview the tests, this is a good place to start if there is any, especially integration or feature tests that are higher levelFind the "God" objects if you can.Write docs as you go, great way to get it into your headOnboarding someone else onto a new codebaseFrom JPHiring contractors for a projectOnboarding new hiresReviewing new hires' pull requests **it's own episode maybe? Code Review?**How do you onboard someone else?I think domain context is importantFrom JohnSupport the advise given above! It's just the reverseFirst: Domain ContextThen —Provide DocsTestsSimple first issuePair on the onboarding Dev's first PR VS sink or swimTry to demonstrate what tools and process you use in a projectPicksJP: https://apps.apple.com/de/app/meeter-fast-call-initiation/id1510445899?l=en&mt=12John:Rails View ComponentsIt'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 skillsHard 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 techniquesConversation 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 summarySection 1: CareerFew tips to improve your career:From SS: Specialize, don't generalize.From SS: "Fake it till you make it"JohnAlways be working on yourself: "Luck is when preparation meets opportunity"Meet lots of people, be helpful and friendlyDo a lot of interviews.Confidence and enthusiasm — "Being enthusiastic is worth 25 IQ points."JPThe importance of friendliness. How does this work for introverts?Recommended Career BooksLinchpinStartup of YouJP: Crucial ConversationsSection 2: Marketing yourselfFrom 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.JohnBlog, be vocal — Share what you learn, don't be afraid to look dumb.Teach others when you canTake speaking and presentation gigs (Was a speaker at GA and got work out of it, you never know)Again — SpecializeJPI love this idea around you being a service. EAAS: Engineer as a serviceI have mixed feelings about marketing yourself. I go back and forth on whether or not I want a bigger online presenceSection 3: LearningFrom 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 codeWhiteboard, talk about problems from a domain perspectiveSection 4: ProductivityFrom SS: FocusJohn: +1 (20% done isn't worth anything. 5 tasks 20% done, or 1, 100% done)From SS: Pomodoro TechniqueFrom SS: KanbanJohn:Getting Things DoneBreak down the work.80/20 — Pareto principleEat that FrogJP:I'm currently giving Pomodoro a shot. I'm trying to figure out how to effectively context shiftHow do you eat an elephant?Sections 5 and 6 — Financial and FitnessSection 7: SpiritFrom SS: power of positive thinkingFrom John:Mental space, day off, unplug sometimes.Confidence + enthusiasmJP:I could use some tips from this section...BONUS From John: CommunicationThis one probably goes at the top of my list.#1 — Learn to be a better writer.Book: On Writing WellTool: Hemingway EditorHeadline writing — Most important things firstLearn how to explain complicated topics. ELI5PicksJohn: NapsJP: Loom screen recording

Welcome to Iteration, a weekly podcast about programming, development, and design.This week — javascript frameworksWhat 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 ironAt 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 managementPrograming is all about abstractions —Shared abstractionsFramework vs LibraryLine 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 Frustratinghttps://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 sitesThe 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: 53kInitial Release: 2006From JP: https://mootools.net/AngularGithub Stars: 60kInitial Release: 2010John: 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 itReactGithub Stars: 148kInitial Release 2013John: 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.jsGithub Stars: 164kInitial Release 2014John: 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 mentionsMeteor / Ember / BackboneFrameworks of Frameworks:Next js — New up and coming —  BlitzGatsbtySails JSLast MentionStimulus (Mostly for Rails)Initial release 2019John uses heavily, it's like a lightweight Vue customized for Rails.Tips for Using a JS FrameworkJP: Learn Vanila JavaScript firstJohn: Go all inJP's Pickhttps://www.instagram.com/archipics.ig/John's PickGetting 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.DestructingMethods in JS ObjectsUnderstanding Hoisting

Welcome to Iteration, a weekly podcast about programming, development, and design.JP LayoffsLet's talk about layoffs!https://techcrunch.com/2020/04/15/softbank-backed-opendoor-has-announced-a-massive-layoff-cutting-35-of-its-employees/600+ employeesI 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 attentionCollab tools:vid streaming is hot nowhttps://github.com/jeanpaulsio/action-cable-signaling-serverJohn LayoffsC19 forced our company to extend our runway, laying off half our team.7 of 11 got laid offThis has been hard to adapt, created a lot of work and pushed out our timelines.Interviews?Phone Screens over a dozenLeads from personal network + spreadsheetsHot tip: If you are in high demand set up a calendlyHot tip: Block out time in your calendar so it's not wall to wall meetings30 minutes is bad 25 minutes and 55 minutesInterviews 4 or 5 technical interviewsState of techRestaurants with awkward appsJohn Bad IRS SiteThe new IRS website to get stimmy money breaks every single UI best practice. It's a perfect case study usability 101Validations aren't until after submissionNot responsiveOnly supports firefox (Officially)Very strange validations - money with no coma or $ST vs Street with no previous notice.Reddit threadJP Government Websites are just kind of funny in generalI 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 TopicsPicksJohn - 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 SciLinks + ReferencesJP's Action Cable Signaling Server RepoOpenDoor Layoffs announcement

Welcome to Iteration, a weekly podcast about programming, development, and design.Article that inspired the episodeQuick notes from this article:problem statement: interviewing can be annoying because it's an interruption from deep workproblem statement: after you've done a ton, it can be boringtwo 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 interviewersread this article to see where you are in both attracting and assessing talentContextHow 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 interviewsWhat type of interviews do you conduct? Behavioral? Technical?JP: I've only ever conducted technical interviewsJohn: 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:quick intros, try to keep this to a maximum of: 3 minutesintroduction to the question + planning before execution: 5 minutespair programming: 45-50 minutesclosing questions: the remainderJohn: 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 listedApplications 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 expectationsWe talk background, career goals and motivations for applying to this jobThey 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 variesJohn: 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 mindJPDon't let a candidate spin their wheels - try to unblock them. See what working with them would actually be like.JohnMy interview style is a bit different.Honest — Never set any kind of false expectation, be yourselfUnpretentious — No trick questions or techno-bableReal — Try to communicate and work with candidates as you would in the job.You'd never toss out a question "just to stump" a coworkerPicksJP: https://github.com/ayu-theme/ayu-vim - I've moved away from DraculaJP: 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 thingsso 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:

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 JohnJohn Intro — I build and maintain Web Apps for startups.Developer roadmap 2020Web search "Developer roadmap 2020" and you'll find this Github repohttps://github.com/kamranahmedse/developer-roadmapYou 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-togetherLooking at this for 2 reasons1 — 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 PathsFront End — "Everything the user sees"Back endDev opsJohn: What about Mobile? This is called the "Web Developer Roadmap" but there is a lot of overlapBasicsWeb Dev 2020Front end + back end + dev opsPre-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 etcFront End Roadmap"Everything the user sees" https://roadmap.sh/frontendJP: Honestly, I don't know how DNS works. I should really do a google search for what happens when you do a google searchJP: 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 cloudBack-end Roadmap"Everything that the user doesn't see" https://roadmap.sh/backendJP: I wonder why javascript is the personal recommendation for back end languageJohn: Web: JavaScript, Ruby, Go or PHP seem to be good choices in today's landscape. Mobile of course is C# or JavaDevOps Roadmap"The equipment it all runs on" — The boiler room in titanic https://roadmap.sh/devopsJP and John are least experienced in this bucket. JP: Learn heroku lol"Get some administration knowledge in some OS"Wrap UpPicks:Cloud App — Way easier way to share screenshots + gifshttps://www.onsched.com/ - Appointment API

Welcome to Iteration, a weekly podcast about programming, development, and design.John: Hi I'm John a software engineer at a tech start up — Joined by JPJP: I'm JP, I'm a software engineer at a tech start upToday 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 dressedTake a lunchWhat 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 morningHave a dedicated space or deviceGet good at notification settings and use themSlack Status vs "Snooze" — For the hourOffice Hours / ScheduleOver communicate in passive channelsVideo / Audio SetupGood Audio is most importantInvest in lighting before a camera.A bad camera with good lighting is better than good camera with bad lighting.Change your sceneryWork 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 shopsWhat are your favorite tools?Standing DeskLoomSlackMiranda time zones appAudio / Video SetupHeadphones with Good Audio #1 priority, #2 is noise canceling (if you need it)Blue Yeti MicA bad camera with good lighting is better than a good camera with bad lighting.Elgato Key LightLogitech Brio Webcamhttps://github.com/KyleAMathews/typefacesPhotos of our home office Desk SetupsResourcesBook: RemoteBook: Ultimate Guide to remote workPicksTrailer Github AppTypefaces — Self host google fontsSupermarket — Just a fun book

This week: Essential integrations / services / API' sWe 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 EmailJohn: Formatting emails — inline styles only.John: Some services have "Templates" with "Placeholders", some you pass the full HTMLJohn: 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 stylesJP: Side project with send grid, just a list of template idsawait deliverTemplateEmail({ to: user.emailAddress, templateId: SOME_TEMPLATE_ID, data: { contactFirstName: user.firstName, viewMyAccountLink: ${config.BASE_URL}/user/dashboard, }, });Stripe + Other Payment ProvidersJohn: Tokenization and data storageJohn: Drop in vs Whitelabel — "Checkout" vs "Elements"John: Embrace Test Mode in Stipe (Super powerful)John: Subscriptions, Promocodes + MoreJP: 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 AmazonTwilio (SMS)John: STOP replies edge caseJohn: Logs are helpfulJohn: Twilio WebhooksJohn: Testing mocks is really usefulJP: Seriously, twilio powers the world. We've used tools that hook into Twilio that provide an interface for customer support. See Front AppScheduler / Chron JobsJohn: Heroku SchedulerJohn: Think about failure handling, resend logic into scheudulersOAuth Login?Other?PicksJohn: Sweet Maria's Green Coffee Beans and Roasting GuidesJP: 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 JohnJohn IntroThis 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.htmlhttps://www.reddit.com/r/cscareerquestions/comments/byxmk1/what_makes_for_a_good_code_review_session/Another tweet:https://twitter.com/addyosmani/status/1198502828425150465Any good / bad experiences with CR?JP: It's not personalJohn: I've worked with team members who take feedback as a prescription for every timeRant about chefs, recipes and conceptsJohn: 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 MarkupWhat 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. +1John: 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, etcJP: CR EtiquetteJohn: 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 TipsJP: Take your time with itJP: Pull the code down and run it. Tinker around. This helps me see the bigger pictureJP: Know when to leave nit pick comments.JP: Think of the potential test cases before you read them.John: Giving Good feedbackConsider the McKinsey ApproachPermissionObservationI noticed that... Have you considered...Try to take ego out of itNever assumeCompliment 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 ReviewJohn: 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.PicksJP: 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/

Iteration: A weekly podcast about programming, development, and design.JP's ExperienceMinimalOften saying "yes" too frequentlyThis year I only said yes to opportunities I could deliver onDoing consulting work for friends....

Welcome to Iteration, a weekly podcast about programming, development, and design.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.

Welcome to Iteration, a weekly podcast about programming, development, and design.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 Elixirreally stretching myself here on this full stack node appJP — Goal #2: System designmaybe even pick up UML?JP — Goal #3: Algorithm fundamentalsGoing through https://interviewcamp.io/John — Goal #1 BlogBlog / Write / Document my work moreMotivation:It helps ideas stickSome 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 designI'm copying JP Here — already been wanting to re-read through Domain Driven Design, (The lost season 1 LOLZ)Web Scaleabaility for Startup EngeneersJohn — Goal #3 JavaScriptJavaScript 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 FocusFocus 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, DocumentationTooling — Project Management, Error Handling, Staging, DocumentationAutomation — Weekly updates, Invoicing, PayrollPicksA Youtube Playlist of every office deleted sceneMacOS — Sidecarhttps://www.princestreetpizzamenu.com/

Join us this week as we talk about JavaScript. So much to love. We go deep with Author Luis Atencio. We talk through JavaScript's future, keeping up, learning and walk through a lot of nitty-gritty technical parts. Where to find Luis:Twitter: @luijarBlog: https://medium.com/@luijarBooks by LuisJoy of JavaScriptFunctional Programming in JavaScriptRxJS in Action

Git-ing things done.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

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, I'm a software engineer at a real estate tech start upCatch up / What's today's episode about?This week Best and Worst AppsDesign and development patterns we love and hate.JP: Gripe 1:

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 JPConversation — When Tech Meets BusinessWho is Jon? Tell us a bit about your educational background and how you eventually landed at OpendoorJon, Briefly tell us why you're interested in Real Estatepotential to talk about the domains we are interested in as welleducationhealthAs a software engineer, why is it important to understand the domain that you're building for?Understand customer pain pointsExample searching for a home: Zillow and moreUnderstand the competitionUser value directly — Redfin and Zillow — are just lead gen tools. Let's focus on lower level.Build in domains you are excited aboutUnderstand customer pain pointsCheck out the competitive landscapeBooks books booksDo 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 itselfYou have to be open minded, and empatheticObviously, 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 PainHigh transaction is the opportunityRepetitive tasks is an opportunityPicksJP: NetlifyJohn: Duck Duck GoJon: Murphy bed LinksJohn Jacob JPGuest: Jon

Iteration — A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.This episode uses Chapter 13 of Extreme programing as a jumping off pointTesting Early, Often, and AutomatedHere 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 fundsQ: 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 greatestQ: 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 RABBITHOLEGive 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 / etcAn Edge case that wasn't consideredThe 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 testsRushing thingsJohn — Summary / Thoughts on book overallOverall got the most out of this vs other books we've readPicksJP: Heroku! Review Apps (spins up a new app every time a PR is opened); PipelinesJohn: Contentful + Rails to give clients ability to update copy and images on marketing pages.

Planning: Managing ScopeThis 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 discussionQuestion 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. PitchThis 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 Workarounds using the current system.Can we do this with Zapier or a spreadsheet?Features often die in this phase.Define the workName the things. Attach nouns and verbs to the functionality."Students Seeking" became > "Leads" >"Message this student" became > "Reply to Lead" > Lead RepliesFigure 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 neededHandoff the designOutput — 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 ReviewWe 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 PlanOnce 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 approachKeys to estimating more accuratelyLook at historyBreak things down smallerThink about all "Contexts" and "States"5. Client ApprovalWe 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 planningPlanning 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.PicksJP: React HooksJohn: 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

Welcome to Iteration: a weekly podcast about programming, development, and design through the lens of amazing books, chapter by chapterCorollary Practices of Extreme Programingcorollary: 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 runReal Customer InvolvementThe 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 futureFive Whyshint: it's usually a people-problemIncremental Development"Slices" concept from Shape UpScoping 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 contractMagic 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 practicesshared codesingle code basedaily deploymentThe Whole XP TeamA 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 itInteraction 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 programmersProject Managers Facilitate communication, help identify priorities and consistent accountability.Executives Courage, confidence and accountabilityPicksJP: GatsbyJSJohn: 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.

Season 7 Episode 3 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

Season 7 Epsiode 2 A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter 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 Communication Simplicity Feedback Courage Respect 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 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] 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

Iteration — A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. 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

Iteration Season 06E09 - Release July 22nd 2019 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?

Iteration Podcast S06E08 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

Chapter 4 - Building Tests 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

Episode 6 - More Code Examples 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)

Chapter 3 - Bad Smells in Code 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

S06E04 - Iteration A weekly podcast about development and design through the lens of amazing books, chapter-by-chapter Refactors Before - 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/

Chapter 2 Principles in Refactoring 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

In this episode we dive deep into some specific refactors from Refactoring 's Chapter 1. We talk about renaming things, extracting functions, functions, replacing a temp with query and some other hot tips and tricks you can put into your code today. 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

Welcome to iteration. A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter. 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

S06E01 - DO IT LIVE! 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/

Iteration S05E09 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

Combining Objects with Composition 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

Metz, Sandi. Practical Object-Oriented Design in Ruby 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