POPULARITY
In this conversation live from RubyConf San Diego, Andrew and Julie sit down with Elise Shaffer, host of The Ruby on Rails Podcast. They kick things off with sharing conference experiences, the joy of reconnecting with friends, and the unique energy the in-person events bring. The discussion shifts to the concept and practice of Test Driven Development (TDD), its benefits, and how it aids in problem-solving during coding. An interesting point is discussed about whether tests or code should be written first, and whether it's okay to write tests after the code. They also dive into the handling of tests on legacy codes within Rails. The conversation wraps up with gratitude to the organizers, speakers, volunteers, and attendees at RubyConf. Press download now to hear more! [00:00:24] Elise shares her conference experience mentioning enjoying the sessions and seeing friends from previous conferences, and Julie and Andrew share their joy of being in the company of friends, the conference atmosphere, and food. [00:01:39] Elise shares the number of Ruby and Rails conferences she's attended and her most memorable one which was Steel City Ruby, highlighting the value of smaller conferences and tight-knit communities. [00:02:45] They discuss the difference between in-person and online conferences, agreeing that in-person events offer more energy and interaction. [00:03:50] The conversation shifts to memorable conferences as Andrew reminisces about his first conference experience at RailsConf in Pittsburgh. Julie talks about her first conference, RailsConf 2022 in Portland, where she met Elise and Andrew and where Ruby for All was conceived.[00:06:12] Andrew asks Julie about her rise in popularity withing a year, moving from a newcomer toa recognized member of the community. The group jokes about autographs and fame within the Ruby community. Elise shares her role in the community, especially with the podcast she hosts. [00:09:33] Elise and Andrew discuss the technical aspects of testing and continuous integration within software development. She explains her background in Ruby and Rails, where she focused on testing and its challenges in larger applications, and she discusses strategies for testing and the importance of testing not every permutation but preventing major issues, [00:12:46] Julie asks Elise to explain parallelized testing. Elise details using CircleCl or other runners to break up many tests across multiple workers to speed up the process.[00:13:56] Elise explains what Test Driven Development (TDD) means to her, and Julie asks whether TDD is always applicable, like when fixing a bug rather than creating a new feature. [00:15:30] Elise wishes TDD was still popular and stresses that TDD is a skill that must be developed. She describes the advantages of TDD, particularly in large applications, where having a robust test suite allows for faster development and less worry about breaking something inadvertently. [00:18:58] Andrew challenges the concept of TDD, suggesting that for a talented engineer, tests might seem like a waste of time. Elise responds by emphasizing that TDD is a thinking tool that aids in understanding the problem. [00:20:59] The discussion turns to reviewing tests. Elise explains her approach to reviewing pull requests by checking the problem solved, reviewing commits one at a time, and comparing her list of tests with the submitted ones, placing higher importance on the tests than the code itself. [00:24:02] Elise and Andrew compare their personal styles in reviewing code and the importance of preparing commit messages for review. Julie is curious how Elise and Andrew manage their commit history and whether they use the command line for combining commits. Andrew mentions using interactive rebase. [00:24:47] If you're interested in getting into TDD, Elise tells us she's working on a course about test driving in Rails applications coming out on early next year , but also recommends reading two great books: Test Driven Development: By Example by Kent Beck and 99 Bottles of OOP by Sandi Metz.[00:25:33] Julie questions how to handle TDD in a legacy codebase with complex and nested tests. Elise suggests pairing with someone more knowledgeable to break up the tests into smaller, more manageable files. Panelists:Andrew MasonJulie J.Guest:Elise ShafferSponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteElise Shaffer WebsiteElise Shaffer GitHubThe Ruby on Rails PodcastCircleCITest Driven Development: By Example by Kent Beck99 Bottles of OOP by Sandi Metz (00:24) - - Introduction and conference experience (01:39) - - Memorable conferences and tight-knit communities (02:45) - - In-person vs. online conferences (03:50) - - First conference experiences (06:12) - - Julie's rise in popularity and fame in the community (09:33) - - Testing and continuous integration in software development (12:46) - - Parallelized testing and speeding up test processes (13:56) - - Test Driven Development (TDD) and its applicability (15:30) - - Advantages of TDD and its role in understanding problems (18:58) - - Challenges to the concept of TDD (20:59) - - Reviewing tests and pull requests (24:02) - - Managing commit history and using interactive rebase (24:47) - - Recommendations for learning TDD (25:33) - - Handling TDD in legacy codebases
New week, new episode. And the guest is Khaled Souf, and I challenge him with the heuristic “Split functionality into small units” from the Xebia Essentials repository (https://essentials.xebia.com/thirty-minute-methods/). Khaled will explain how he approaches software, and what are the tools, practices and techniques that he uses to deliver value. We also discuss inclusion and diversity as a critical aspect for organisations to strive! Khaled recommends: Test Driven Development: By Example by Kent Beck Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans Patterns, Principles, and Practices of Domain-Driven Design by Scott Millett and Nick Tune DDD Crew GitHub repo (https://github.com/ddd-crew) The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso The 7 Habits of Highly Effective People by Stephen Covey Khaled (@khaledsouf) is a passionate Senior dev/trainer/coach/DDD Distiller based in Montréal. He has been working for several years in Paris (France). He is also an organiser of the Software Crafters Montréal Meetup and the Unconference SOCRATES Canada. Currently, he works at Zenika Montréal as a senior consultant.
Resources Mentioned in this episodeIntroduction to Test Driven Development (TDD).TDD Vs BDD – Analyze The Differences With Examples.Test Driven Development: By Example.Messenger Platform Tutorial (TDD Approach).https://cucumber.io/Example Mentioned in the Episode:Title: Returns and exchanges go to inventory.As a store owner,I want to add items back to inventory when they are returned or exchanged,so that I can track inventory. Scenario 1: Items returned for refund should be added to inventory.Given that a customer previously bought a black sweater from meand I have three black sweaters in inventory,when they return the black sweater for a refund,then I should have four black sweaters in inventory. Scenario 2: Exchanged items should be returned to inventory.Given that a customer previously bought a blue garment from meand I have two blue garments in inventoryand three black garments in inventory,when they exchange the blue garment for a black garment,then I should have three blue garments in inventoryand two black garments in inventory. Episode Picks:Luay: Facebook Engineering Process with Kent Beck.
פודקאסט מספר 389 של רברס עם פלטפורמה - אורי ורן מארחים באמצע מאי, עם סימנים חלקיים של חזרה לשיגרת קורונה (דמיינו סאונד של שיעול קל) ואחרי המון זמן חזרה באולפן בכרכור את רועי אושרוב, פרק שנקבע לפני המון זמן בעולם אחר של לפני הקורונה (עוד דחיית קורונה בקטנה) - והנושא קרוב לליבנו: דיברנו בעבר הרבה על Continuous Deployment וזה יהיה הנושא העיקרי להיום (וסביר שעוד כמה נושאים נוספים באיזור).קודם כל - רועי: חלק מהמאזינים כבר מכירים, עוקבים ב-Twitter, Twitch ו/או השתתפו ב-Meetup (יש את CD/XP Israel ואת R&D Leaders), ובכל זאת קצת רקע - אז רועי אושרוב - מתכנת, אב לשלושה בנים נמרצים (עוד מעט חוזרים ללימודים…)מתכנת מזה למעלה מ-20 שנה - התחלה (מקצועית) עם Visual Basic ומאז עוד כמה שפות (וכן - לפני 20 שנה זה כבר לא היה Cobol, פה זה המתקדמים . . .) - היו #C ו-Java ו-++C ו-Python ו-Ruby . . . בימים אלה נכנס חזק ל JavaScript.בארץ עזרתי להקים את קבוצת Agile-Israel- ה-User Group הראשון שהוקמה כבר לפני יותר מ-10 שנים (כשארכיטקטים ב-Microsoft צחקו על “המשוגע עם ה-Agile וה-TDD")כתבתי בזמנו ספר שנקרא The Art of Unit Testing, שבימים אלו אני מוציא את המהדורה השלישית שלו - אם הקודמים היו ב-#C אז החדש הוא כבר ב-JavaScriptגם כי כולם עובדים היום ב-JavaScript וזה קהל יעד מעניין - וגם כי רציתי קצת יותר ללמוד את עולם ה - Functional Programming וזה משהו ש-JavaScript (גם) מאפשרוזה גם מאוד מאתגר לנסות להעביר את העולם הזה לעולם החדש.המהדורה הראשונה וגם השנייה היו מבוססות #C - והשלישית היא בעצם Re-write כמעט שלם - אני כרגע בפרק הרביעי, ואנשים פשוט “קורעים” אותי עם ה-Reviews ואני לומד המון תוך כדי, זה ממש כיף.חשבתי שאני יודע JavaScript לפני כן, ועכשיו אני יודע כמה אני לא יודע - אומרים שאם אתה רוצה ללמוד משהו, תלמד אותו? אז בספרים הראשונים למדתי #C ובספר הזה אני לומד JavaScriptזה עולם יותר מסובך ויותר מאתגר - Multi-Paradigm: אם #C הוא Object-Oriented אז כאן גם Object וגם Model . . . מאוד מעניין.באיזשהו שלב נסעתי לחו”ל, Relocation לנורבגיה למשך 2-3 שניםהיה מאוד מעניין ומאתגר - עבדתי שם בתור יועץ.לאחר מכן נסענו ועבדתי בניו-ג’רזי, ומשם עברנו לקליפורניה - ולפני בערך שנתיים וחצי חזרנו לארץ (הילדים גדלו, והיינו צריכים לקבל החלטה של Fork או Merge בחזרה ל-Master . . .)עשיתם Unit Test לפני כן? ה- Integration test היה לצאת ולראות האם אנחנו יכולים לחזור . . .אז חזרנו ומעכשיו עד סוף החיים יש את ה What-if? - חלק מהחוויות של ה-Relocation.המעבר לנורבגיה לא היה מטעם העבודה?לא . . . בזמנו היה לי בלוג וכתבתי את הספר והרצאתי בכנסים - וגם לימדתי בנורבגיה בערך פעם בחודש; זה הכניס הרבה מאוד כסף והיה מאוד כיף - ובאיזשהו שלב חשבתי על מה יקרה אם במקום שבוע בחודש אלמד ארבעה שבועות בחודש? . . .גם כסף וגם מקום נחמד . . .”אתה משוגע” . . . פרסמתי בבלוג שלי שאני מחפש עבודה בנורבגיה, יצרו איתי קשר מכמה חברות, מצאנו את החברה הנכונה לעבוד בה - ואז הגענו לנורבגיה והבנו שזו הייתה טעות כלכלית מטורפת . . .נורבגיה זה המקום השני הכי יקר בעולם - ואז הגיע החורף . . . היינו צריכים ללמוד איך לנהל שלושה ילדים בשלג, שבדר”כ יותר גבוה מהילדים: לקחת לבית ספר, להלביש, והכל בלי עזרת הורים ומשפחה מסביב - כיף גדול, ממליץ בחום (או בקור).זה היה אתגר שאני שמח שעשינו - למדנו המון על עצמנו בתור משפחה וגם על תרבות אחרת - אמנם גם שם עבדתי בהיי-טק, אבל כאן בארץ, כשאנחנו עובדים בתור מתכנתים אנחנו בתוך תרבות ישראלית, וכשאנחנו יוצאים מהארץ אנחנו בהרבה מקרים צריכים ללמוד חוקי התנהגות אחרים לגמרי - ולקח לי המון זמן ללמוד את החוקים האלה.התרבות הסקנדינבית ולאחר מכן התרבות האמריקאית, הפולטיקה של איך לשכנע אנשים, איך להגיד לא בלי להגיד לא, המון דברים מעניינים . . . אתגר מעניין ולמדתי המון, אפילו בלי קשר לטכנולוגיה.(אורי) לא רק להגיד לא בלי להגיד לא - זה איך לשמוע “לא” בלי שאומרים לך “לא” . . .(רועי) דווקא יש לי סיפור מצחיק על זה - כשגרתי בארה”ב, היה לי מנהל אמריקאי “עם הכפתור סגור עד החלק האחרון בחולצה”יום אחד הייתה לנו שיחה, ואחרי רבע שעה של שיחה, כשהרגשתי ממש טוב עם עצמי, הבנתי שהוא בעצם מנסה לתת לי פידבק שלילי, שעשיתי משהו לא בסדר.אחרי 20 דקות של שיחה, פתאום הייתי צריך לשאול אותו - רגע, אתה מנסה להגיד לי שעשיתי משהו לא בסדר?התשובה “באמריקאית” הייתה כמובן “אני לא חושב שהייתי אומר את זה ככה, אבל יכול להיות שיש אנשים שהיו קצת נפגעים . . . אבל עוד פעם, זה עניין של תרבות, לא בטוח, אני חושב שעשית את הדבר הנכון, אבל . . .”.בקיצור - הוא התכוון ל-”כן”, ולקח לי המון זמן ללמוד איך אנשים באמת מנסים לדבר בדרגות האלה, וזה קצת כמו ללמוד שפת תכנות, ללמוד את הניואנסים האלה.בהקשר הזה - הנורבגים הם יותר “קשים לקריאה” מהאמריקאים, או יותר קלים?הנורבגים יותר קלים, הם הרבה יותר Straight to the point - למרות שבהתחלה הם מאוד נחמדים ומחוייכים הם בסופו של דבר יותר סגורים, אבל הם יגידו לך אם הם חושבים שאתה טועה.הם עדיין יהיו מאוד עדינים - יחסית לישראלים זה הבדל מאוד גדול, ועדיין קשה (לנו) להבין אותם.אז הזכרנו על קצה המזלג את הנושא של Continuous Delivery - יש שיגידו Continuous Deployment ואנחנו מנסים לפעמים להבין את ההבדל בין שניהם אז אולי ננסה לדבר גם על זה - למעשה, הנושא היה במרכז הפוקוס של לא מעט סטארטאפים לפני משהו כמו עשר שנים . . . בהמשך לשיחה מקדימה שעשינו, אני חושב שמה שמעניין באפיזודה הנוכחית זה שהיום זה כבר מעניין את כולם - לא מעניין רק את הסטארטאפים אלא גם את הארגונים הגדולים ביותראם יצא לך להאזין לאחת השיחות האחרונות שלנו עם נתי שלום פה בפודקאסט, הוא כינה את זה שם כמעיין "שרשרת אספקה” או “מערך ייצור” של חברות, כש-Contentious Delivery זה חלק בלתי נפרד מהדברים האלה, וחברות שלא ילמדו לעבוד עם ה-Flow המודרני הזה למעשה יכחדו - והוא לא מדבר על סטארטאפים, אלא על חברות מהגדולות ביותר בעולם, שהבינו את הנושא.אני (רן) מעריך שזה משהו שמעסיק אותך ביום יום . . .כן . . . אני אקדים ואגיד שכשחזרתי לארץ . . . אחד הדברים שעסקתי בו כשגרתי בארה”ב היה ייעוץ לארגונים מאוד גדולים בעולמות של Contentious Delivery ו - DevOps ו - Extreme Programming - ולמדתי לקחים, גם של מה אפשר או אי אפשר לעשות, איך לקדם שינויים ארגוניים מאוד מסובכים ברמה הבירוקרטית ועם המון בעיות - לא במקומות עם 50 אנשים אלא עם 50,000 עובדים.כשחזרתי לארץ, היו בערך 50,000 מיטאפים ישראליים - כשיש אחד על Python ואחד על Lambda ואחד על Semicolon, ואחד על Angular ואחד על פסיקים ועל נקודות . . . אבל אין מיטאפ שמדבר או קהילה שמדברת על מה שמחבר בין הדברים האלה.יש מיטאפים על Agile, אבל מה שהצחיק אותי (עצוב, אבל בכל זאת) היה שכשדיברתי עם חלק מהאנשים בקהילת ה-Agile בישראל (שהשתנתה מאוד, חלק לטובה וחלק פחות) - חלק מהם אמרו, כשדיברתי איתם על Contentious Delivery, ש”זה לא אנחנו, אנחנו Agile”, מתוך איזושהי הנחת יסוד שכשמדברים על Agile Coaching או על Agile Consulting מדברים על התהליך ה Scrum-י או על SAFe וכל הדברים האלה - ו - Contentious Delivery זה חלק מהעולם של ה- Ops וה - Infrastructure וה - Pipelines . . .זו הבנה, לדעתי, שגויה לחלוטין של אחד מהדברים הבסיסיים ביותר של איך אנחנו אמורים לעבוד - השמן בגלגלים, מה שגורם לנו להיות אג’יליים, אלו אותם Engineering Practices, אותם מנהגים שבאים מלמטה, ובלעדיהם כל התהליך הזה מלמעלה הוא בסך הכל “עלים של ורדים שאתה מפזר על מיטה של קוצים” (מטאפורה נוראית, אני יודע, Work with me here . . .).אני (אורי) יכול מאוד להזדהות עם מה שאתה אומר, בכמה אספקטים - באיזשהו מקום Agile או Agile Practices - יכול להיות גם שיחד עם כמות חברות הייעוץ שיש סביב זה, נוצר המון Buzz מסביב ואלו בסוף Practices - אפשר ללמוד אותם, לתרגל אותם וכו’.כשמדברים על DevOps ו - Contentious Delivery ודברים כאלה - אז זה כבר משהו שצריך ליצור סביבו תרבות, זה לא רק “נעשה את הישיבה הזו ואת הישיבה הזו, נתעד ככה או נתעד אחרת”.(רועי) זה עוד יותר קשה - אתה ממש צריך לשנות התנהגות של אנשים(אורי) התנהגות של אנשים, תרבות ותפיסת עולם של מה חשוב, למי יש אחריות על מה והוא צריך לקחת את האחריות הזו - ויש פה הרבה עניין של Trust בהורדה של האחריות אל המפתח, ולא כל הנהלה יכולה לעשות את זה.(רועי) ואם ה-Trust הזה נלקח לפני שנים רבות על ידי איזשהו ארגון שהחליט לעבוד בצורה מסויימת, עשה מעיין “הפרדת רשויות” - והיום אנחנו נמצאים במצב שבו ארגונים מנסים לקחת חזרה את השליטה אבל אבל אנשים לא רוצים לתת את השליטה חזרה לפיתוח, כיוון ש”ככה לא עושים דברים” . . . למה “ככה לא עושים דברים”? “כי תמיד עשינו דברים בצורה אחרת”“למה עשינו דברים בצורה אחרת”? אף אחד כבר לא זוכר . . .(אורי) כן . . רן, אני לא יודע אם אתה מרגיש כמוני, אנחנו עשינו את הדברים האלה ב-2011 ב-Outbrain ביחד, עם הרבה דחיפה שלך (רן) למקום הזה, ומשם Outbrain ככה - ונראה לנו שככה העולם . . . אין כבר אנשים שלא עושים Contentious Delivery . . .(רועי) זה מה שאתם רואים . . .זה מה שאנחנו מרגישים - שזה כבר לא Novelty, ואם זה כל כך מושרש ומוטמע אצלנו אז כנראה שכבר כל העולם ככה, ואנחנו מופתעים לראות כמה זה לא ככה.(רועי) אני חושב שאתם חיים בסוג של בועה, אמנם מאוד טובה, שבה אתם נמצאים כמה שנים קדימה לעומת כל מיני ארגונים.הרבה ארגונים שאני עובד איתם, ובעצם כנראה יש כאן איזשהו עניין של הטייה כי בדרך כלל קוראים למישהו כמוני כשארגון לא מצליח בדברים האלה ולא כשהוא מצליח, אז אלו הארגונים שאני אראה . . .קוראים לי כשרוצים לכתוב Unit Tests טובים ויש Unit Tests ממש גרועים, או כשרוצים לעשות שינוי בתהליך של Contentious Delivery והתהליך לוקח חודשים ויש המון Bottlenecks באמצע - אלה החברות שאני רואה.מה שאני רואה זה שזה קיים בהמון חברות - כמעט בלי קשר לתעשייה שבה אנחנו נמצאים - ה - Patterns או ה Anti-Patterns שאני רואה כמעט תמיד קשורים לאנשים, כמעט אף פעם לא טכנולוגיים, הטכנולוגיה זה בעצם החלק הכי פשוט - ללמוד Kubernetes זה לא הבעיה שלנו . . .(אורי) Contentious Delivery ו - Contentious Deployment היו הרבה לפני Kubernetes (רועי) בוא נתחיל ככה - Extreme Programming, שלדעתי זה נושא שפעם היה והיום עומד לקבל במה בחזרה ובגדול, זו בעצם מתודלוגיה שהתחילה לדעתי באיזור 1996, והאדם שהביא אותה לעולם, לפחות מהזוית שלי , זה Kent Beck - הוא כתב ספר שנקרא Extreme Programming Explained וספר שנקרא Test Driven Development: By Example - שני ספרים שקראתי בזמנו ולמדתי מהם המון - הוא התחיל את העולם הזה.מכאן, Extreme Programming (או XP) מדבר על כל הדבר הזה - אחד מהם היה Contentious Integration, אחר הוא Test Driven Development וגם Pair Programming ו Refactoring ו - Shared Code Ownership - הרבה דברים שאנחנו היום רואים אנשים שמנסים לממש - הם באים מהעולם הזה.כשאתה (אורי)
As a programmer, Kent Beck chats about various topics of broad interest to developers, including some of his books: “Extreme Programming Explained: Embrace Change,” “Test-Driven Development: By Example,” and “Implementation Patterns.” He wrote “Implementation Patterns” to highlight the positive habits a developer should form in order to write accessible code. He also shares about what it’s like to experiment with new ideas and implement them, especially when others doubt what you're trying to achieve. This relates to the concept behind the explore-to-expand transition and a short piece he wrote titled "Idea to Impact." Finally, Tim and Kent talk through the difference between refactoring and tidying, Kent's involvement with agile software and test-driven development, and what exactly test-commit-revert is. And yes, they talk a little bit about event streaming too!EPISODE LINKSExtreme Programming Explained: Embrace ChangeTest-Driven Development: By ExampleSmalltalk Best Practice PatternsImplementation PatternsOh, the Methods You’ll Compose (inspired by “Implementation Patterns”)Idea to ImpactFast/Slow in 3X: Explore/Expand/ExtractRefactoring: Improving the Design of Existing CodeNominalism and RealismRobert Mathus, W.V.O. Quine, and ThanosJoin the Confluent Community Slack
EPISODE DESCRIPTION: In this episode, Phil talks to software developer Kent Beck, director of Three Rivers Institute (TRI) and author of multiple programming books. Kent shares his thoughts on how he looks at software development, the value of community and the untapped potential of engineering talent that exists in different areas of the world. KEY TAKEAWAYS: (1.39) - Phil opens by asking Kent to expand on the introduction and tell everyone a bit more about himself. Kent explains that for the last 7 years he has been working at Facebook. His main focus, while there, was on the engineering culture. During those 7 years, he did a lot of writing, coaching and educating. As well as studying the culture as a whole. (2.18) - Phil asks Kent to share a unique career tip. Kent says: “It's easy to treat software development as a production process where there's some functionality and the more quickly you can produce it, the better you are and I think that that's it's an understandable mistake but a fairly large mistake.” “I prefer to look at software development as a learning process that throws off running software as a by-product. If you do that, you'll learn to do your job better and better, over time, and those improvements compound on each other.” (3.15) - Phil asked Kent to share his worst IT moment and what he learned from that experience. Kent said it was the first time he was fired. He went on to explain he was not paying enough attention to the feedback by saying: “I thought here's the job. I'm doing this job. That was much more important to me then what the team as a whole was trying to accomplish and I did my job as I saw it. It just wasn't what the person signing the checks cared about.” (4.09) - From then on, Kent has made a point of really listening and also making sure he is communicating effectively. He said: “So you’ll hear me, if I give a talk with question and answer, I almost always will say ‘Does that answer your question?’” (5.00) - Phil asks Kent about his career highlight or greatest success. Kent said – “Right at the beginning of my career, I stumbled into a relationship with Ward Cunningham, who would go on to invent the wiki. And it was really a mentor-student relationship, at first”. He explained how working with Ward gave him confidence in his abilities and reinforced, in his mind, the need to value his ideas. As well reinforcing the importance of listening to others. (6.43) - Phil asks if Kent felt it was the foundation of many of the things he went on to do subsequently. Kent said he thought it was. For example, “This habit of checking in started very much with the work that I did with Ward. So we would spend a few hours maybe programming something. And then we would go have a coffee and talk about not just the content that we'd worked on, but the process that we'd used for it.” Regularly checking in enabled them to pick up on little details at each stage. For example, something as simple as the fact that they had used 4 keystrokes for a process prompted them to ask can we make it 3? They optimized everything from the micro stuff all the way up to how does this fit into society. (7.39) - Phil asks what excites Kent the most about the future of the IT industry and careers in IT. Kent responds saying that 'things are going to definitely radically change'. He expands this statement by explaining that there's unbelievably good engineering talent in Africa which may lead to large-scale collaborations. Kent then states that "we're going to have to find ways of having finer-grain commits and quicker path to production, better feedback from production; but also we’re going to have to confront some of the limitations of the social structures that we’ve built around programming. (09.44) – Kent went on to say that things have the potential to change a lot but also the potential to stagnate if people become complacent. (9.55) – Phil asks Kent whether or not he thinks the trend of diversity will continue. Kent says, “I think the world has big problems, engineers and software engineers can be part of addressing those problems. We don't have near enough engineers to throw away five sixths of the world's engineering talent just because it happens to be female or have melanin in its skin.” (10.31) - What first attracted you to a career in IT? (10.41) – “My dad was an electrical engineer, and then a programmer. And when he gave me my first book about BASIC, it was like remembering. It was not like learning. It was just like, Oh, yeah, yeah, yeah, that’s how that works.” (11.00) – Phil asked - So you felt you found the logic behind it quite straightforward? It just worked with the way you think? Kent said yes and explained he took a microprocessor manual and just read it repeatedly until he remembered it. Even though he did not completely understand it. He knew that he just had to continue to work hard and expand his knowledge. (11.34) – What is the best career advice you ever received? Kent replied: “Um, I'm not much of an advice taker." (12.09) - If you were to begin your IT career again, right now, what would you do? Kent's reply was to: “Treat it as a learning process. Act as if you haven't graduated from school. This is just your next class and you're going to treat it as a learning process and when the class is over and you've learned the lessons, you're going to go to a different class.” The more diverse your learning, the more cross-fertilization happens. (12.55) - What career objectives are you currently focusing on yourself? (13.35) – “My focus is on longer-term relationships, especially with large scale software development. I think that's, that's something I have now a lot of experience with, and I have some ideas that aren't widely shared. So that's a focus. I'm also going to do individual coaching because I receive the benefits of that as a young engineer.” (14.13) – “It's much more highly leveraged to produce better engineers, than any amount of code that you could write.” He is also experimenting, so he can learn whether he has more leverage with an audience of geeks or business owners. (14.43) - What's the number one non technical skill that has helped you in your career so far? (14.57) – “I come to a place of compassion more quickly than a lot of people seem to. So if somebody is doing something that doesn't make any sense to me, I'll get annoyed just like anybody else. But pretty quickly I start to try to see the situation from their perspective. And I think that's a powerful habit.” “It is helpful for me to be able to see the situation from the other person’s perspective.” (15.54) - Can you share a parting piece of career advice with the IT Career Energizer audience. "Learning works better in a community" (16.29) – What’s the best way to connect with you? Kent says that his website is provides information about what he’s up to, what he’s written recently and where he’ll be speaking. (17.21) – Phil reminds the audience of the upcoming changes to the podcasts and the timescales for those changes. BEST MOMENTS: (3.00) – “Even a small change in learning trajectory can result in a large change in productive capacity”. (3.57) – “I did my job as I saw it. It just wasn't what the person signing the check cared about.” (Don’t forget to really listen to the client and the team) (7.50) – “Things are definitely going to change radically. There's a huge pool of unbelievably good engineering talent in Africa that hasn't been tapped.” (8.35) – “The pull request, code review, merge, deploy model I think is starting to run out of steam.” (9.34) – “We're going to have to find ways of building and maintaining teams and teamwork across a greater variety of thinking styles and cultural backgrounds.” (16.01) – “Learning works better in a community. I learn faster, I learn better if I share that learning experience with somebody else.” GUEST BIO: Kent Beck is the founder and director of Three Rivers Institute (TRI). His career has combined the practice of software development with reflection, innovation and communication. His contributions to software development include “Patterns For Software”, “The Rediscovery of Test-First Programming” and “Extreme Programming”. Kent has also authored multiple books, including “Test Driven Development By Example” and “Extreme Programming Explained”. CONTACT THE GUEST - KENT BECK: Website: www.kentbeck.com Twitter: https://twitter.com/KentBeck @KentBeck LinkedIn: https://www.linkedin.com/in/kentbeck/ Books: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530 https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658 CONTACT THE HOST - PHIL BURGESS: Website: www.itcareerenergizer.com Twitter: https://twitter.com/PhilTechCareer LinkedIn: https://www.linkedin.com/in/philburgess/ Email: phil.burgess@itcareerenergiser.com
Panel: Charles Max Wood Joe Eames Aimee Knight Special Guests: Kent Beck In this episode, the JavaScript Jabber panel talks to Kent Beck. Kent left Facebook 4 months ago after working for them for 7 years and is now self-unemployed so that he can decompress from the stressful environment that he was a part of for so long. He now travels, writes, creates art, thinks up crazy programming ideas, and is taking a breather. They talk about what he did at Facebook, what his coaching engagement sessions consisted of, and the importance of taking time for yourself sometimes. They also touch on what he has learned from his experience coaching, how to create a healthy environment within the workplace, and more! In particular, we dive pretty deep on: Kent intro/update Ruby Rogues Episode 23 Worked at Facebook for 7 years What were you doing at Facebook? Unique culture at Facebook His strengths as a developer didn’t match with the organization’s Coaching developers TDD and Patterns Advantages as an old engineer What did coaching engagement consist of? Takes time to build trust Discharging shame Need permission to take care of what you need to Being at your best so you can do your best work Vacation in place What have you learned in your time working with people? The nice thing about coaching Everyone is different How do we create a healthy environment within the workplace? Mentor in Ward Cunningham What is it costing us? Why did you decide to leave? And much, much more! Links: Ruby Rogues Episode 23 @KentBeck kentbeck.com Kent’s GitHub Sponsors Kendo UI Sentry Digital Ocean Picks: Charles The Five Dysfunctions of a Team by Patrick Lencioni Crucial Accountability by Kerry Patterson Aimee n-back Joe Test Driven Development: By Example by Kent Beck Kent The Field Guide to Understanding 'Human Error' by Sidney Dekker Conspiracy: Peter Thiel, Hulk Hogan, Gawker, and the Anatomy of Intrigue by Ryan Holiday
Panel: Charles Max Wood Joe Eames Aimee Knight Special Guests: Kent Beck In this episode, the JavaScript Jabber panel talks to Kent Beck. Kent left Facebook 4 months ago after working for them for 7 years and is now self-unemployed so that he can decompress from the stressful environment that he was a part of for so long. He now travels, writes, creates art, thinks up crazy programming ideas, and is taking a breather. They talk about what he did at Facebook, what his coaching engagement sessions consisted of, and the importance of taking time for yourself sometimes. They also touch on what he has learned from his experience coaching, how to create a healthy environment within the workplace, and more! In particular, we dive pretty deep on: Kent intro/update Ruby Rogues Episode 23 Worked at Facebook for 7 years What were you doing at Facebook? Unique culture at Facebook His strengths as a developer didn’t match with the organization’s Coaching developers TDD and Patterns Advantages as an old engineer What did coaching engagement consist of? Takes time to build trust Discharging shame Need permission to take care of what you need to Being at your best so you can do your best work Vacation in place What have you learned in your time working with people? The nice thing about coaching Everyone is different How do we create a healthy environment within the workplace? Mentor in Ward Cunningham What is it costing us? Why did you decide to leave? And much, much more! Links: Ruby Rogues Episode 23 @KentBeck kentbeck.com Kent’s GitHub Sponsors Kendo UI Sentry Digital Ocean Picks: Charles The Five Dysfunctions of a Team by Patrick Lencioni Crucial Accountability by Kerry Patterson Aimee n-back Joe Test Driven Development: By Example by Kent Beck Kent The Field Guide to Understanding 'Human Error' by Sidney Dekker Conspiracy: Peter Thiel, Hulk Hogan, Gawker, and the Anatomy of Intrigue by Ryan Holiday
Panel: Charles Max Wood Joe Eames Aimee Knight Special Guests: Kent Beck In this episode, the JavaScript Jabber panel talks to Kent Beck. Kent left Facebook 4 months ago after working for them for 7 years and is now self-unemployed so that he can decompress from the stressful environment that he was a part of for so long. He now travels, writes, creates art, thinks up crazy programming ideas, and is taking a breather. They talk about what he did at Facebook, what his coaching engagement sessions consisted of, and the importance of taking time for yourself sometimes. They also touch on what he has learned from his experience coaching, how to create a healthy environment within the workplace, and more! In particular, we dive pretty deep on: Kent intro/update Ruby Rogues Episode 23 Worked at Facebook for 7 years What were you doing at Facebook? Unique culture at Facebook His strengths as a developer didn’t match with the organization’s Coaching developers TDD and Patterns Advantages as an old engineer What did coaching engagement consist of? Takes time to build trust Discharging shame Need permission to take care of what you need to Being at your best so you can do your best work Vacation in place What have you learned in your time working with people? The nice thing about coaching Everyone is different How do we create a healthy environment within the workplace? Mentor in Ward Cunningham What is it costing us? Why did you decide to leave? And much, much more! Links: Ruby Rogues Episode 23 @KentBeck kentbeck.com Kent’s GitHub Sponsors Kendo UI Sentry Digital Ocean Picks: Charles The Five Dysfunctions of a Team by Patrick Lencioni Crucial Accountability by Kerry Patterson Aimee n-back Joe Test Driven Development: By Example by Kent Beck Kent The Field Guide to Understanding 'Human Error' by Sidney Dekker Conspiracy: Peter Thiel, Hulk Hogan, Gawker, and the Anatomy of Intrigue by Ryan Holiday
ペアプログラミング, コードレビュー, 開発者テスト, Go, 子育てなどについてt_wada さんと話しました。 難易度は？ 効果は？ 実践して初めて分かった「ペアプログラミング」の実際 ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Programming by Takuto Wada Test Driven Development: By Example 便利な道具が発明されると.. | Takuto Wadaさんのツイート Mocks Aren’t Stubs Test Double | xUnit Patterns Package testing | The Go Programming Language Packages and Testing | Frequently Asked Questions | The Go Programming Language The Rise of Worse is Better Simplicity is Complicated Go, from C to Go Fastly に入社しました Write Code Every Day お知らせ: 2017/8/4 12:10-12:40 で builderscon 2017 のランチセッションにて出張ajitofmをやります。お楽しみに！
How to design software? What are the techniques we can use? How can we become better at it? We've interviewed 3 engineers with completely different backgrounds to find out. Host: Andrey Salomatin https://twitter.com/flpvsk Guests: Craig Andera https://twitter.com/craigandera Eric Elliott https://twitter.com/_ericelliott Mario Zechner https://twitter.com/badlogicgames Mentions by Craig: Cognitect http://cognitect.com Cognicast http://blog.cognitect.com/cognicast/ You Are Not So Smart Podcast https://youarenotsosmart.com/podcast/ Rich Hickey, creator of Clojure PL https://twitter.com/richhickey Mentions by Eric: Blog https://medium.com/@_ericelliott Online Course https://ericelliottjs.com/ Mentions by Mario: LibGDX https://libgdx.badlogicgames.com/ http://www.gamefromscratch.com/ Books and talks that shaped you as an engineer, Craig: A book by Martin Fowler "Patterns of Enterprise Application Architecture" http://www.goodreads.com/book/show/70156.Patterns_of_Enterprise_Application_Architecture Rich Hickey talks: https://changelog.com/rich-hickeys-greatest-hits/ Books and talks that shaped you as an engineer, Eric: A book by Kent Beck "Test Driven Development: By Example" http://www.goodreads.com/book/show/387190.Test_Driven_Development Collection of links "Required JavaScript Reading" https://github.com/ericelliott/essential-javascript-links/blob/master/README.md Books and talks that shaped you as an engineer, Mario: A book by Andre LaMothe "Tricks of the 3D Game Programming Gurus" http://www.goodreads.com/book/show/2042298.Tricks_of_the_3D_Game_Programming_Gurus "The dragon book" by Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman, official name "Compilers: Principles, Techniques, and Tools" http://www.goodreads.com/book/show/703102.Compilers
Craig Stuntz talks about an Incredibly Strange Programming Language: Idris. Show notes: Craig's slides for Incredibly Strange Programming Languages Stir Trek conference The Sapir-Whorf hypothesis Type-Driven Development With Idris, by Edwin Brady TDD (Test Driven Development). If you've never heard of that, check out Kent Beck's seminal book, Test Driven Development: By Example. Improving Enterprises Papers We Love - Columbus Craig Stuntz's blog Craig Stuntz on Twitter Want to be on the next episode? You can! All you need is the willingness to talk about something technical. Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.
In this episode, Adam talks to Konstantin Kudryashov, creator of Behat and BDD Practice Manager at Inviqa. Konstantin and Adam talk about the schools of TDD, how to use test doubles effectively, and common challenges people face when trying to learn TDD. This episode is brought to you by Hired. everzet on Twitter Inviqa "Design How Your Objects Talk Through Mocking" presentation "Test Driven Development: By Example", by Kent Beck "Growing Object Oriented Software Guided By Tests", by Steve Freeman and Nat Pryce The "Tell, Don't Ask" principle Sandi Metz's "Magic Tricks of Testing" talk Ian Cooper's "TDD: Where did it all go wrong?" talk Conway's Game of Life BDD London Meetup Sponsored by Hired
© 2020-2025 Ivy Podcast Discovery LLC
