Podcasts about dry don

In this episode of the Mob Mentality Show, we are excited to have Dave Copeland share his experiences in the world of agile development, focusing on the critical nuances behind well-known principles such as SRP (Single Responsibility Principle), YAGNI (You Aren't Gonna Need It), DRY (Don't Repeat Yourself), and the often-debated #NoEstimates approach. Drawing from his journey transitioning from government waterfall projects to agile methodologies at a startup, Dave kicks off a discussion with invaluable lessons on how teams can avoid misunderstanding and misapplying agile aphorisms, or avoid the pitfalls of following agile aphorisms too woodenly. ### The Dangers of Following the Literal Words of Agile Aphorisms? Have you ever seen a team stuck arguing over what SRP or SOLID (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) truly means? Dave explains how teams can misinterpret these catchy phrases, leading to confusion, low cohesion, improper coupling, and poor decision-making. We dive into real-world examples from Dave's experience, discussing when it's okay to duplicate code and when it's not, the delicate balance between over-engineering and under-engineering, and the importance of nuance in agile practices. ### "Just Sharing" vs. Universal Recommendations Is it wise to blindly follow every "recommendation" from an agile coach, or is there room for discussion, experimentation, and adaptation? With Dave we tackle the common issue of semantic diffusion. We explore how teams can navigate complex situations and adapt agile and lean principles to their unique contexts. ### Organizational Change and Safe Learning Environments We bring in the “Reading Rainbow” analogy and other examples to illustrate how organizational change needs to be gradual, allowing for nuanced learning. We also emphasize the importance of creating an environment where team members can safely fail while being guided by experienced developers in real-world contexts. Whether you're scaling a team or trying to stack the deck with the right mix of skills, actionable strategies for fostering growth are discussed.  ### Estimates, #NoEstimates, and Dealing with Uncertainty The conversation gets even more interesting as we delve into the jarring #NoEstimates and its sometimes misunderstood implications. Dave brings up valid situations with real deadlines (e.g., seasonal deliveries, regulations) and we weigh-in on ways to handle them with or without estimates that are less likely to lead to self-sabotage. We also discuss the impact of automation on estimates, and what terms like "estimate" really mean. Continuous Delivery (CD) also takes center stage as we discuss examples of how it and the practice of "don't sell what you don't already have built" fosters trust and reduces uncertainty. We touch on the various unknowns that can arise in development, how CD can help mitigate them, and whether teams can benefit from an "#OptionalEstimates" mindset. Throughout, Dave provides practical advice on aligning practices with business goals and managing risks effectively. ### Coaching, Coding, and Higher-Level Roles Finally, we explore Dave's thoughts on balancing hands-on coding with coaching responsibilities, especially in higher-level roles. How do you set expectations for coaches, and how can team composition shape the effectiveness of good practices? Whether you're actively writing code or stepping back to guide others, Dave shares examples for making both approaches work. Don't miss this episode packed with deep dives into agile practices, team dynamics, and nuanced leadership. Be sure to subscribe to the Mob Mentality Show on your favorite platform to catch this episode and others like it! Video and Show Notes: https://youtu.be/IPFYe_oOFtI  

Meet two of Jam's newest engineers Max & Aidan! In this episode they discuss what engineering onboarding is like at Jam, plus all the “boring” parts of software development. Internal docs, codebase organization, local environments… As a company totally focused on bug capture; at Jam, these topics are our Jam!We discuss:(00:13) Why we love talking about the “boring” parts of eng (they're not boring to us!)(02:32) Finding alignment as the codebase and team get bigger(05:06) A sneak peek at a new feature Aidan just built(10:42) Max and Aidan debate how much DRY (Don't Repeat Yourself) is too much(12:53) Dani shares the 7 different versions of Jam's UI before we found PMF! 

Los podemos llamar principios, reglas o simplemente buenas prácticas, pero son esas bases que hacen que no vayamos a inventar lo que ya está hecho o agregar complejidad a lo que debería ser sencillo. En este episodio de CodigoTecno repasamos esas ideas que sin importar el lenguaje de programación, nos permiten desarrollar de manera eficiente sin preocuparnos por cometer errores que se podrían evitar. Con la práctica, las vamos incluyendo y en un momento nos damos cuenta que ya está en nuestra labor cotidiana, que nos brota por defecto y eso es lo bueno, al ir incluyéndola se hará parte nuestra. Algunos de los principios comentados en el este podcast: - KISS : Keep it simple stupid. - YAGNI: You ain´t gonna need it. - Simplest thing + Baby steps. - Separation of Concerns. - DRY : Don´t repeat yourself. - Code for the manteiner Si conocés alguna otra que deberíamos comentar, te invito a compartirla. Gracias por estar allí como cada semana y si este podcast te impactó o te pareció útil, la mejor forma de colaborar es valorarlo o compartirlo con alguien mas, así puede llegar a mas personas, hacer una review en la plataforma desde donde escuchas #codigotecno - https://www.facebook.com/codigotecno - https://www.instagram.com/codigotecno Sumate a la comunidad en Youtube: https://bit.ly/2JLaKRj Mas recursos en : http://www.estudioplaneta.com Mirá mi perfil completo en: https://www.linkedin.com/in/soleralejandro/ En Telegram estamos empezando a armar el canal donde compartimos material que puede aportar a tu formación, recursos y cosillas interesantes. Te esperamos en : https://t.me/codigotecno Envíame un email : codigotecno (arroba) hotmail.com Seguinos en las redes de podcast mas populares: * En Spotify : https://spoti.fi/31Dp4Sq * En Ivoox : https://bit.ly/2JoLotl * En Itunes: https://apple.co/2WNKWHV * En Anchor.fm: https://bit.ly/3OiVCsN ¡ Y como siempre, muy buen código para todos, hasta la próxima !

Summary For business analytics the way that you model the data in your warehouse has a lasting impact on what types of questions can be answered quickly and easily. The major strategies in use today were created decades ago when the software and hardware for warehouse databases were far more constrained. In this episode Maxime Beauchemin of Airflow and Superset fame shares his vision for the entity-centric data model and how you can incorporate it into your own warehouse design. Announcements Hello and welcome to the Data Engineering Podcast, the show about modern data management Introducing RudderStack Profiles. RudderStack Profiles takes the SaaS guesswork and SQL grunt work out of building complete customer profiles so you can quickly ship actionable, enriched data to every downstream team. You specify the customer traits, then Profiles runs the joins and computations for you to create complete customer profiles. Get all of the details and try the new product today at dataengineeringpodcast.com/rudderstack (https://www.dataengineeringpodcast.com/rudderstack) Your host is Tobias Macey and today I'm interviewing Max Beauchemin about the concept of entity-centric data modeling for analytical use cases Interview Introduction How did you get involved in the area of data management? Can you describe what entity-centric modeling (ECM) is and the story behind it? How does it compare to dimensional modeling strategies? What are some of the other competing methods Comparison to activity schema What impact does this have on ML teams? (e.g. feature engineering) What role does the tooling of a team have in the ways that they end up thinking about modeling? (e.g. dbt vs. informatica vs. ETL scripts, etc.) What is the impact on the underlying compute engine on the modeling strategies used? What are some examples of data sources or problem domains for which this approach is well suited? What are some cases where entity centric modeling techniques might be counterproductive? What are the ways that the benefits of ECM manifest in use cases that are down-stream from the warehouse? What are some concrete tactical steps that teams should be thinking about to implement a workable domain model using entity-centric principles? How does this work across business domains within a given organization (especially at "enterprise" scale)? What are the most interesting, innovative, or unexpected ways that you have seen ECM used? What are the most interesting, unexpected, or challenging lessons that you have learned while working on ECM? When is ECM the wrong choice? What are your predictions for the future direction/adoption of ECM or other modeling techniques? Contact Info mistercrunch (https://github.com/mistercrunch) on GitHub LinkedIn (https://www.linkedin.com/in/maximebeauchemin/) Parting Question From your perspective, what is the biggest gap in the tooling or technology for data management today? Closing Announcements Thank you for listening! Don't forget to check out our other shows. Podcast.__init__ (https://www.pythonpodcast.com) covers the Python language, its community, and the innovative ways it is being used. The Machine Learning Podcast (https://www.themachinelearningpodcast.com) helps you go from idea to production with machine learning. Visit the site (https://www.dataengineeringpodcast.com) to subscribe to the show, sign up for the mailing list, and read the show notes. If you've learned something or tried out a project from the show then tell us about it! Email hosts@dataengineeringpodcast.com (mailto:hosts@dataengineeringpodcast.com)) with your story. To help other people find the show please leave a review on Apple Podcasts (https://podcasts.apple.com/us/podcast/data-engineering-podcast/id1193040557) and tell your friends and co-workers Links Entity Centric Modeling Blog Post (https://preset.io/blog/introducing-entity-centric-data-modeling-for-analytics/?utm_source=pocket_saves) Max's Previous Apperances Defining Data Engineering with Maxime Beauchemin (https://www.dataengineeringpodcast.com/episode-3-defining-data-engineering-with-maxime-beauchemin) Self Service Data Exploration And Dashboarding With Superset (https://www.dataengineeringpodcast.com/superset-data-exploration-episode-182) Exploring The Evolving Role Of Data Engineers (https://www.dataengineeringpodcast.com/redefining-data-engineering-episode-249) Alumni Of AirBnB's Early Years Reflect On What They Learned About Building Data Driven Organizations (https://www.dataengineeringpodcast.com/airbnb-alumni-data-driven-organization-episode-319) Apache Airflow (https://airflow.apache.org/) Apache Superset (https://superset.apache.org/) Preset (https://preset.io/) Ubisoft (https://www.ubisoft.com/en-us/) Ralph Kimball (https://en.wikipedia.org/wiki/Ralph_Kimball) The Rise Of The Data Engineer (https://www.freecodecamp.org/news/the-rise-of-the-data-engineer-91be18f1e603/) The Downfall Of The Data Engineer (https://maximebeauchemin.medium.com/the-downfall-of-the-data-engineer-5bfb701e5d6b) The Rise Of The Data Scientist (https://flowingdata.com/2009/06/04/rise-of-the-data-scientist/) Dimensional Data Modeling (https://www.thoughtspot.com/data-trends/data-modeling/dimensional-data-modeling) Star Schema (https://en.wikipedia.org/wiki/Star_schema) Database Normalization (https://en.wikipedia.org/wiki/Database_normalization) Feature Engineering (https://en.wikipedia.org/wiki/Feature_engineering) DRY == Don't Repeat Yourself (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) Activity Schema (https://www.activityschema.com/) Podcast Episode (https://www.dataengineeringpodcast.com/narrator-exploratory-analytics-episode-234/) Corporate Information Factory (https://amzn.to/3NK4dpB) (affiliate link) The intro and outro music is from The Hug (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/Love_death_and_a_drunken_monkey/04_-_The_Hug) by The Freak Fandango Orchestra (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/) / CC BY-SA (http://creativecommons.org/licenses/by-sa/3.0/)

Sponsors Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan Triplebyte offers a $1000 signing bonus CacheFly Panel Nader Dabit Justin Bennett Lucas Reis Dave Ceddia Charles Max Wood Joined by Special Guests: Thomas Aylott, Conlin Durbin Episode Summary Conlin Durbin is a front end software engineer for a company called Lessonly and occasionally writes about React. Thomas Aylott is a web guy from the 90’s who was briefly on the React team, and he makes thingsthatdostuff.com and groovytiesquad.com. The panel discusses  Conlin’s article Link Lists in the Wild: React Hooks. They begin by talking about the relationship between linked lists and React hooks. Linked lists are used under the hood to render hooks every time that they’re created and maintain integrity of the hook chain. They discuss the importance of knowing what goes on under the hood share their methods of learning. They give tips for learning on the job. The panel agrees that one of the best ways to learn is to teach. Conlin shares his experience working for Lessonly, a company that builds lesson-building software. The panel discusses WET (Write Everything Twice) vs DRY (Don’t Repeat Yourself) programming. They talk about when it is beneficial to have abstractions in code and when it is not. It’s also important to think about the humans that are going to be using it, and to write the code so that it’s humane. They praise good error messages that tell you exactly where you went wrong and how to fix it. They talk about the dangers of putting invariants everywhere, and finish by talking about ways to improve. Links Linked list React Fiber Hooks Backbone JavaScript Redux Gatsby Flow Jake Archibald: In The Loop-JS Conf Asia 2018 (video) What the heck is the event loop anyway? (video) Practical 00 Design in  Ruby, Sandi Metz Stop trying to be so DRY, instead Write Everything Twice (WET) Sebastian Markbage: Minimal API Surface Area – Learning patterns instead of frameworks Someone Is Changing Your Code Conlin Durbin username for most places is ‘wuz’, except Twitter for twitter it’s @CallMeWuz Follow DevChat on Facebook and Twitter Picks Justin Bennett: The 3 most effective ways to build trust as a leader article Pheonix Live View Lucas Reis: Pamela Zave Small Functions Considered Harmful article Dave Ceddia: New Redux course Kinesis Advantage 2 Keyboard Charles Max Wood: MicroConf BuzzSprout Thomas Aylott: Noflojs.org The Laws of Human Nature by Robert Greene Conlin Durbin: https://dev.to/ Soft Skills Engineering Conlin’s Discord server

Sponsors Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan Triplebyte offers a $1000 signing bonus CacheFly Panel Nader Dabit Justin Bennett Lucas Reis Dave Ceddia Charles Max Wood Joined by Special Guests: Thomas Aylott, Conlin Durbin Episode Summary Conlin Durbin is a front end software engineer for a company called Lessonly and occasionally writes about React. Thomas Aylott is a web guy from the 90’s who was briefly on the React team, and he makes thingsthatdostuff.com and groovytiesquad.com. The panel discusses  Conlin’s article Link Lists in the Wild: React Hooks. They begin by talking about the relationship between linked lists and React hooks. Linked lists are used under the hood to render hooks every time that they’re created and maintain integrity of the hook chain. They discuss the importance of knowing what goes on under the hood share their methods of learning. They give tips for learning on the job. The panel agrees that one of the best ways to learn is to teach. Conlin shares his experience working for Lessonly, a company that builds lesson-building software. The panel discusses WET (Write Everything Twice) vs DRY (Don’t Repeat Yourself) programming. They talk about when it is beneficial to have abstractions in code and when it is not. It’s also important to think about the humans that are going to be using it, and to write the code so that it’s humane. They praise good error messages that tell you exactly where you went wrong and how to fix it. They talk about the dangers of putting invariants everywhere, and finish by talking about ways to improve. Links Linked list React Fiber Hooks Backbone JavaScript Redux Gatsby Flow Jake Archibald: In The Loop-JS Conf Asia 2018 (video) What the heck is the event loop anyway? (video) Practical 00 Design in  Ruby, Sandi Metz Stop trying to be so DRY, instead Write Everything Twice (WET) Sebastian Markbage: Minimal API Surface Area – Learning patterns instead of frameworks Someone Is Changing Your Code Conlin Durbin username for most places is ‘wuz’, except Twitter for twitter it’s @CallMeWuz Follow DevChat on Facebook and Twitter Picks Justin Bennett: The 3 most effective ways to build trust as a leader article Pheonix Live View Lucas Reis: Pamela Zave Small Functions Considered Harmful article Dave Ceddia: New Redux course Kinesis Advantage 2 Keyboard Charles Max Wood: MicroConf BuzzSprout Thomas Aylott: Noflojs.org The Laws of Human Nature by Robert Greene Conlin Durbin: https://dev.to/ Soft Skills Engineering Conlin’s Discord server

Prvá časť našej série o čistom kóde. Preberáme v nej prvé kapitoly knihy Clean Code od Roberta "Uncle Bob" Martina. V prvej časti porozprávame niečo o tom, ako by mal programátor pomenovávať rôzne prvky v kóde. V druhej časti rozoberáme funkcie, ich odporúčanú dĺžku, počet parametrov a ďalšie veci. (00:00 - 00:48) Úvod (00:49 - 03:55) Názvy (03:56 - 05:29) Vyhľadateľné názvy (05:29 - 08:51) Mental mapping (08:52 - 09:40) Nesnažte sa byť vtipný v kóde (09:40 - 10:37) Názvy funkcií by mali byť slovesá (10:38 - 12:52) Jeden názov pre každý koncept (12:53 - 13:24) Funkcie (13:25 - 15:12) Dĺžka funkcií (15:13 - 16:07) Zhora dole (16:08 - 17:57) Jedna úroveň vnorenia v rámci funkcie (17:58 - 20:42) Koľko parametrov by mala mať funkcia (20:43 - 22:09) Funkcia by mala robiť jednu vec (22:10 - 23:30) DRY - Don't repeat yourself (23:31) - Záver http://streetofcode.sk/podcast/ep-11/ The post Ep. 11 – Clean Code Part 1 (Názvy, Funkcie) appeared first on Street of Code.

A weekly podcast about development and design through the lens of amazing books, chapter-by-chapter. Pivot a bit: Less agnostic, more useful to just lean into the technologies we use every day for a while. We'll do our best to keep the information generally useful to all software developers. Moving forward this is a Web Development Podcast covering Ruby on Rails, Javascript and React. New book: Practical Object-Oriented Design in Ruby by Sandi Metz Also known as POODR About the Author: Sandi Metz: She is one of the foremost thought leaders in clean code. If you want some amazing programming talks just look up Sandi Metz on YouTube. About the book: “The Complete Guide to Writing Maintainable, Manageable, Pleasing, and Powerful Object-Oriented Applications” About Object-Oriented Design: Object-oriented applications are made up of objects and the messages that pass between them. Messages will turn out to be the more important of the two, but in this brief introduction (and in the first few chapters of the book) the concepts will get equal weight. “In a world of objects, new arrangements of behavior emerge naturally. You don't have to explicitly write code for the spouse_steps_on_cat procedure, all you need is a spouse object that takes steps and a cat object that does not like being stepped on. Put these two objects into a room together and unanticipated combinations of behavior will appear.” “Unfortunately, something will change. It always does. The customers didn't know what they wanted, they didn't say what they meant…. Even applications that are perfect in every way… change is ubiquitous and omnipresent” WHY IS CHANGE SO HARD!? Dependencies stand in the way of change Object Oriented Design is about Managing Dependencies “In the absence of design, unmanaged dependencies wreak havoc because objects know too much about one another.” “Part of the difficulty of design is that every problem has two components. You must not only write code for the feature you plan to deliver today, you must also create code that is amenable to being changed later.” Design Principles SOLID - design: Single Responsibility - Do one thing well. Open-Closed - You should be able to extend without modifying. Consistent interface. Liskov Substitution (Swap out code underneath methods) - squares and rectangles Interface Segregation - specific interfaces Dependency Inversion - High-level modules should not depend upon low-level modules. Both should depend upon abstractions. DRY - Don't Repeat Yourself LoD - Law of Demeter - Talk only to closely related objects- the principle of least knowledge Design Patterns Service Objects, Factory, Adapter, Decorator - This book doesn't cover these. Big Up Front Design Pitfalls Design takes time Next Chapter - we really get our hands dirty Sandi Metz Links: https://www.youtube.com/watch?v=npOGOmkxuio&t=1841s https://www.youtube.com/watch?v=29MAL8pJImQ https://www.youtube.com/watch?v=8bZh5LMaSmE&t=1s Pick: JP: https://testingjavascript.com/  John: SOLID Design Patterns in Javascript https://www.youtube.com/watch?v=GtZtQ2VFweA&feature=share - - - - - New Book: Practical Object-Oriented Design

Michael Nygard: @mtnygard | Wide Awake Developers (Mike’s Blog) | The Cognitect Blog | Release It! Design and Deploy Production-Ready Software This episode is sponsored by Pivotal. 01:42 - Mike’s Background and Career Path Thus Far 02:59 - Complex Systems The Complexity Explorer 06:22 - Continuous Partial Failure and Looking at Microservices Mike’s New Normal Blog Series 11:23 - “Agile”: Why? 14:03 - Antifragility Blog Post: From Resilient to Antifragile Nassim Taleb’s Antifragile Normal Accidents: Living with High-Risk Technologies by Charles Perrow 20:18 - Evolutionary Design Blog Post: The Art of War, Maneuverability, and Microservices Sun Tzu’s The Art of War Matt’s Antifragile Architecture Talk Evolutionary Architecture by Neal Ford, Rebecca Parsons, and Pat Kua 29:05 - Redundancy and DRY (Don’t Repeat Yourself) YAGNI (You Aren’t Gonna Need It) 37:11 - What services should I actually have? 41:00 - Contracts Between Services 48:29 - Advice for Someone Getting Started as an Architect: Ward Cunningham’s c2 Wiki The Pattern Oriented System Architecture Series

hello，这里是《科技最前沿》，喜爱科学的你来啦，我是你的老朋友微信公众号——丘孔语论。科技最前沿，主要从丘孔语论比较感兴趣的几个领域来谈论科学科技，可能涉及天文、物理、互联网/IT、人工智能/Ai、数码/手机、编程、大数据、商业大佬、创新创业创客、化学、医学、养生、心理学、灵性等领域；认识天地，开阔思维，重塑自我。程序员精选 2017-04-24 15:49成功的职业生涯通常是指规定时间内，发布高质量且被认可的工作。这对于IT开发人员也没什么不同。成功的开发人员能在预估范围内编写出高质量的代码，并通过发布伟大的产品让利益相关者满意。那么开发人员如何才能做到这一点呢？有些人认为开发人员是魔术师，按几个按钮就能让计算机变魔法。现实情况则要复杂得多：我们得遵循一定的原则来编写可靠的代码，测试我们的工作，并不断更新到最新的技术。1、编写可读性强的代码我将从与人直觉相反的这一方面开始。我已经数不清我碰到过多少人认为编写一些不可思议的、复杂的代码可以为他们提供工作的保障。“如果除了我其他人都不知道薪资报告模块是如何工作的话，上面就肯定不敢炒我鱿鱼！”当然，这在理论上可能是对的（尽管有太多的人在说这句话的时候往往高估了自己）。虽然企业老板可能不会炒掉你，但他们也不会支付你很多薪水。如果公司不能在薪资报告模块上失去你，那么自然而然也不会晋升你。它不会把你放到另一个更受人瞩目的项目上。这样做只会让你牢固地待在当前位置，就像死水一样波澜不惊。2、推理不快乐路径在编程世界中，所谓的“快乐路径”提出了一种高度乐观的情景。沿着快乐路径行进，没有出错的地方，也没有错误发生。在编写和测试代码时，学会广泛地去推理不快乐路径的场景。如果作为开发者的你能够因为在推理不快乐路径方面一次成功而出名，那么你对细节的注重将为你赚到更多的酬劳。3、证明你的抉择为什么你要在这里使用工厂模式？为什么你选择那个特定的Javascript框架？如果你在回答这类问题时使用“因为这是正确方法”诸如此类的答案，那么就不会给你带来任何好处。这个世界在很大程度上依赖于软件和软件开发者的传递性。我们拥有经常使我们处于权威地位的专业知识，特别是在与非技术人员或不太有经验的利益相关者打交道的时候。因此，你会发现，你经常采取的是那种大家尝试的做法，“我说怎么做就怎么做”。4、选择一款强大的编辑器即使是经验最为丰富的程序员也需要良好编辑器的配合。他们喜欢用文本编辑器胜过IDE编辑器，因为这样可以学到更多东西。无论什么情况，尽量使用键盘快捷键。在选择编辑器时，认真考虑并挑选最好的（Emacs或Vim），因为它们是通用的。其次，挑选你的首选平台最支持的。5、了解数据结构和算法如果你不知道什么时候应该使用快速排序、不懂辨认O(n2)程序、不会写递归函数，你的工作效率将会降低，尽可能去了解底层命令（plumbing），以便能够作出明智的决定（Web框架是怎么存储session状态的？Cookie到底是什么？）。6、对项目要从一而终尽管项目收尾阶段的工作确实强度极大且较为枯燥，但我仍然建议大家坚持到最后并始终抱以理想的工作热情，而且能够从一而终的程序员才是一位负责任、有担当的开发者。7、整洁的代码胜过巧妙的代码要想让其他人能够读懂你的代码，尽量使用最少的代码来完成任务。遵循DRY（Don't repeat yourself）的原则，使用明确定义的对象和库，将任务分解成小而简单的代码段。8、潜意识是强大的工具离开10分钟往往就可以解决一个问题。控制编程时间，给自己一个多姿多彩的生活，劳逸结合能让你在工作时更高效、更愉悦。当然，即便是上了年纪的程序员也知道，以最少的时间完成最高效的工作是成为10倍效率开发者的必要条件。作为一个程序员，我觉得在职业生涯中最好的一件事儿就是从电脑前站起来，去拜访那些在某一领域有所建树的人们。9、推动自身和团队进步重视批评，以包容的态度接受批评并提升自己是非常重要的事情。没有这个基础，你不可能成为一个高效的开发者。一位智者曾经说过：“聪明的人善于从自己的错误中学习，而智慧的人善于从别人的错误中学习。”10、使用在线社区和论坛俗话说，共享的问题就是减半的问题。当你绞尽脑汁解决问题的时候，请注意不要浪费太多时间在孤军奋战上。很有可能你的问题，其他某个人已经经历过了，他的经验教训会对你产生极大的帮助。访问在线社区，例如Stackoverflow或TechNet寻求提示和技巧。11、充分利用工具和实用程序有大量的软件可用于帮助提升开发人员的构建速度。 除了visual Studio——这款开发微软软件的必备工具现在已经是开箱即用的了——还有很多其他的工具和第三方插件可帮助开发人员做的更好：ReSharper使得编写代码更容易；Web Essentials在创建web app时可提供方便的功能；FxCop / StyleCop用于广泛的代码分析；SPCAF（用于SharePoint / Office 365的开发）。12、通过注释来写逻辑说到编码，我有坚持很多原则和想法。其中一个就是，代码中95%都是逻辑。另一个就是从人类语言到编程语言，逻辑并没有改变。这也就是意味着，如果你能在代码中写出来，也就可以用英语或者其他语言写下来。13、良好的时间管理迟到对于任何一家公司都是个头痛的问题。作为一个程序员，有时候为了完成任务常常不得不熬夜，从而导致第二天上班就迟到了。但是我们忽略了这一点，我们的工作时间至关重要，因为在这段时间里我们要和客户同步，也要与团队其他成员一齐协作。14、深入理解客户需求仅仅了解单一用户的表面意思是远远不够的。一个伟大的程序员应该具备能把繁琐的要求理解并分解成项目的技术任务或子任务的能力，并且最后拿到的成果应精确满足客户的需求。另外还有一点可以通过自身的学习来获取一大进步。

00:16 – Welcome to “99 Bottles of Podcasts!” …we mean, “Greater Than Code!” 99 Bottles of OOP by Sandi Metz and Katrina Owen (https://www.greaterthancode.com/2016/11/21/008-sandi-metz-and-katrina-owen/) 01:31 – Collaboration on the Book Practical Object-Oriented Design in Ruby by Sandi Metz (https://www.poodr.com/https://www.poodr.com/) People who like me call me disciplined & meticulousPeople who don't call me anal & pedanticIt's the same thing. @kytrinyx @greaterthancode— Jessica Kerr (@jessitron) November 21, 2016 14:56 – Audience: Who is this book for? 99 Bottles of Beer Exercise (https://www.sandimetz.com/99bottles/sample#appendix-exercise) 21:06 – The DRY (Don’t Repeat Yourself) Principle (https://en.wikipedia.org/wiki/Don't_repeat_yourself); Duplication and Replication DRYing too hard: "people encapsulate the pieces that are identical, though they don't represent a complete idea." @kytrinyx @greaterthancode— Jessica Kerr (@jessitron) November 21, 2016 29:21 – Code Review and Naming Things 30:40 – “In what ways is it 99 Bottles a richer kata than fizz buzz (http://wiki.c2.com/?FizzBuzzTest)?” – Benjamin Fleischer (https://twitter.com/hazula) 32:53 – “The 99 Bottles book seems to document all the trade-offs we’ve been implicitly making. Could this possibly be a first step in automating those decisions? i.e.: Might we take those now-explicit rules and partially automate the process of programming?” – Craig Buchek (https://twitter.com/CraigBuchek) 34:47 – Llewellyn Falco: “Sparrow Decks” (http://llewellynfalco.blogspot.com/p/sparrow-decks.html) Kathy Sierra (https://en.wikipedia.org/wiki/Kathy_Sierra) Philip Kellman (https://en.wikipedia.org/wiki/Philip_Kellman) 39:57 – “what non-Ruby technologies are you interested in right now?” – Darin Wilson (https://twitter.com/darinwilson) The more people involved in a projectthe less important the code becomesand more important the interactions.@kytrinyx @greaterthancode— Jessica Kerr (@jessitron) November 21, 2016 “Code is easy; people are hard. If you want to get things done, you have to get good at people.” - @sandimetz— Greater Than Code (@greaterthancode) November 21, 2016 45:00 – Sandi’s Unique Approach to Teaching 47:53 – Speaking at Conferences Listening is not how people learn.We learn by doing.To help someone learn-by-doing, ask them questions.@sandimetz @greaterthancode— Jessica Kerr (@jessitron) November 21, 2016 Reflections: Coraline: Inspiration to return to work on her book about empathy. Also, exploring whether that visual interpretation of code is the shape of code in the abstract or the shape of the code that’s written on-screen. Sandi: Controversy around the notion that duplication is better than the wrong abstraction. Katrina: We are humans and we have ideas and sharing those ideas makes us visible to other humans. It is also incredibly important and impactful to speak. Jessica: Development of relationships and partnerships with someone who will push you. Sam: Helping people realize things on their own is greater than telling them the answer. Also, practicing better self-control in coding and mentoring. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guests: Katrina Owen and Sandi Metz.

In part two of our interview with Dave Thomas, we dive into some of his other contributions to the community, including coining the phrase “DRY” (Don’t Repeat Yourself), popularizing the code kata, and signing the Manifesto for Agile Software Development. We explore the impacts of these contributions, particularly to code newbie community. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Code Kata DRY SOLID Manifesto for Agile Software Development Agile Is Dead Codeland Conf Codeland 2019

Dave Thomas has done a lot for the programming community. He coined the phrase “DRY” (Don’t Repeat Yourself). He popularized the idea of code katas. He was one of the signers of the Manifesto for Agile Software Development, and he's the founder of the Pragmatic Bookshelf publishing company. But despite all that, he refers to himself as simply a programmer. In this episode, he shares his own coding journey, gives advice to new developers on how to navigate the mountain of information available, and how he ended up becoming a publisher. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Lone Star Ruby Elixir Tacit knowledge Design patterns C2.com Airbrake Avdi Grimm CodeNewbie Austin Elm Functional programming Statically Typed vs. Dynamically Typed Languages Codeland Conf Codeland 2019

In the future, CSS visualizations will dramatically change. How they will change is debatable but they will enable developers to do a lot more than they may think. We may see custom properties like variables to further improve DRY (Don't Repeat Yourself) code & on-the-fly cascading calculations, CSS Extensions to create our own custom selector properties, custom functions, & custom selector combinations.  Some of these rules are even starting to be implemented in browsers today like “will-change” to pre-optimize changes in DOM structures and CSS Shapes. These will further help us define display, flow, & wrapping of content and it's containers. CSS is moving rapidly and this is just the tip of what is to come for web development in the coming years or even months in some cases.   It used to be to create powerful visualizations in a browser you needed to use Flash or some non-standard tool to get the performance & consistency you needed from complicated animations. Today we have help in bridging the gaps of today and tomorrow. CSS Preprocessors given us powerful features in our CSS code. Some of the more notable ones are loops, conditionals, variables, custom mixins/functions, and heavy grade math calculations. While these are extremely useful, they only help us, currently, before we even see CSS in the browser. Online tools like Codepen.io help us quickly build and view CSS, HTML, & JavaScript that can be easily shared and updated without the overhead of understanding setup, build processess, or dependency management. Although extremely powerful, this means that the tools we have only have the ability to allow CSS to react to change in the DOM in a limited capacity. Looking at todays standard CSS, we now have ways of doing some dynamic calculations and conditions in the browser and device viewers. Directives like @supports and @media give us powerful conditionals. We have several types units of measurement, such as viewport units, frequency units, time units, & resolution units. Rules like ‘calc' give us the ability to computationally react to mutations in the DOM tree. Keyframe Directives give us robust animation, the ‘transform' rule yields great power to setup and animate DOM structures and also dynamically change rotation, skewing, scaling, and translation both 2D and 3D space, all without needing one line of JavaScript. Resources http://davidwalsh.name http://codepen.io/thebabydino/live/08634ee35593c97bd8cfb2ddd9324c24 http://davidwalsh.name/css-supports http://www.w3.org/TR/css3-values/ https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Using_CSS_transforms http://css-tricks.com/five-questions-with-david-walsh/ http://codepen.io/collection/wHune/ http://codepen.io/thebabydino/pen/jgtof http://codepen.io/thebabydino/ http://techblog.rga.com/math-driven-css/ http://davidwalsh.name/css-flip http://css-tricks.com/a-couple-of-use-cases-for-calc/ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Using_CSS_animations http://stackoverflow.com/users/1397351/ana http://davidwalsh.name/svg-animation http://stackoverflow.com/users/1397351/ana http://stackoverflow.com/help/badges/17/necromancer?userid=1878132 http://sass-lang.com/ http://www.myth.io/ http://dev.w3.org/csswg/css-extensions/ http://sarasoueidan.com/ http://shoptalkshow.com/episodes/129-sara-soueidan/ http://5by5.tv/webahead/81 http://www.sitepoint.com/css-variables-can-preprocessors-cant/ http://codepen.io/shankarcabus/pen/jcyDA http://daneden.github.io/animate.css/ http://codepen.io/thebabydino/tag/calc()/ http://figures.spec.whatwg.org/