Podcasts about yagni

Zach Bellay tells us about the devil and the angel on his shoulders, Pete Koomen thinks today's AI apps are like horseless carriages, Hyperwood is an open source system for crafting furniture from simple wooden slats, Scott Antipa agrees with YAGNI but adds YAGRI & Antony Henao debunks three common myths that get engineers stuck.

Zach Bellay tells us about the devil and the angel on his shoulders, Pete Koomen thinks today's AI apps are like horseless carriages, Hyperwood is an open source system for crafting furniture from simple wooden slats, Scott Antipa agrees with YAGNI but adds YAGRI & Antony Henao debunks three common myths that get engineers stuck.

Zach Bellay tells us about the devil and the angel on his shoulders, Pete Koomen thinks today's AI apps are like horseless carriages, Hyperwood is an open source system for crafting furniture from simple wooden slats, Scott Antipa agrees with YAGNI but adds YAGRI & Antony Henao debunks three common myths that get engineers stuck.

Lords: * Andrew * Kate Topics: * Is it okay to make a game that is boring * My friend wants me to play WoW. Should I? * How to melt chocolate * Kate's Wallace and Gromit song * https://bsky.app/profile/hownottodraw.bsky.social/post/3lfctso62a22q * VFX is like cooking, game design is like baking * Looksmaxxing Microtopics: * Adam Atomic's Pico-8 renaissance. * Vampire vs. Pope Army * Still Kate. * Grass and flowers and touching them. * The bifurcation of Bluesky into Twitter 2 and Mastodon into Not Twitter. * The different kinds of people who tell you you're doing it wrong on different social media services. * Looking at Bluesky and realizing it's just like Twitter, and having a reaction to that realization. * Comparing your mood before using an internet service to your mood afterwards. * You're the cow, baby! * A story about living in a village of fewer than twenty people where nothing happens for thirty years. * Countervailing forces preventing your game design from becoming a worry stone. * Going outside and being bored until being bored stops feeling like an assault on all your senses. * Talking to your mates in the pub about your new socks. * Your mayonnaise manufacturing district. * YAGNI. * That time your ex-husband stole your knife and without a knife you can't cut food! Or ropes! * Needing medical help and asking the guy in your village who owns half an encyclopedia. * A miserable experience that is worth doing. * The big advantage of playing World of Warcraft in Hardcore mode. * WoW Classic and WoW Classic Classic. * A game about killing 40 rats. * The game for children that do annoying dances. * Who knows about causality? * The two year period when game designers played nothing but World of Warcraft. * Getting addicted to an MMO and never contributing anything to society ever again. * Entering into an activity with a miserly determination to not have fun. * What it takes to do a dungeon. * The spaces between the exciting parts. * Melting chocolate on top of parchment paper. * Melting chocolate with a hair dryer. * A Fraught Bark Experience. * Mouthfuls of raw flour. * Cake Batter Bark. * Rescuing seized chocolate. * Counterintuitive chocolate behavior. * Baking: It's Stupid. * Adding a tart cheese to cream of mushrooms soup. * Reading the poem as if you're not singing it in your head. * Asking the vicar to share a stir-fry. * Adding swear words to the Wallace and Gromit theme. * Leggy Desert Boy, by Percy Bysshe Shelley. * The verse in Eleanor Rigby where they talk about cooking and eating dinner. * Words that rhyme with "pint." * Rhyming "pint" with "2019." * Inventing an OC named "blorange" to solve your rhyming problems. * Taking flavors and synthesizing new flavors. * Hammering on the "fun" button for forty or fifty years. * Having the one hit and not needing another hit. * Exploring a multidimensional design space and tapping on all the walls to see which ones are destructible. * Starting to make a game and finding out whether it's an easy game to make. * Langoliers. * Night Snacker. * Releasing games exclusively in the Topic Lords discord. * The art of turning your mortal vessel into a weapon. * Softmaxxing vs. Hardmaxxing. * Doing tongue exercises to sharpen your jaw. * The Wikipedia page with the most scare quotes on it. * Limb-lengthening surgery. * Dabbing: it's just extremely short-term looksmaxxing. * When two subcultures have two different words for the same idea. * Whether the Xes in "Looksmaxxing" are the kisses and the Os the hugs, or vice versa. * Whether the Xes in are the kisses and the Os are the hugs or whether the Xes are the dead eyes on the cartoon face. * Archiving the VODs.

Austin Story, Senior Engineering Director at Doximity, joins Robby to explore the intricacies of building maintainable systems, fostering team accountability, and enabling faster iteration without sacrificing quality. Austin shares how his team approached migrating from a monolithic GraphQL architecture to a federated model, why simplicity matters for long-term success, and how guiding principles like YAGNI influence his decision-making.Doximity is a leading digital platform for medical professionals, and their technology blog offers deep dives into the systems and tools that power their innovative solutions.Key Topics Discussed[00:00:41] What is maintainable software? Austin highlights key traits, including testability, simplicity, and ease of removal.[00:02:09] Designing for removability: Why it's important and how it enables iterative progress.[00:03:05] YAGNI (You Aren't Gonna Need It): How this principle shapes Austin's approach to feature development.[00:04:13] Migrating to GraphQL Federation: Benefits of breaking up a monolithic GraphQL server and the challenges faced during the transition.[00:05:56] GraphQL vs. REST: How GraphQL aids developer productivity while maintaining backward compatibility.[00:10:53] Collaboration between data and application teams: Using tools like Kafka to bridge gaps and improve workflow.[00:17:00] Upgrading Ruby on Rails applications: Balancing autonomy with central guidance for seamless updates.[00:27:55] Fostering ownership on teams: The cultural practices that empower engineers to take initiative and drive results.[00:34:29] Prioritizing work effectively: How Austin's team uses quarterly planning and measurable "goalposts" to align efforts with impact.[00:40:00] Avoiding bike-shedding: Keeping meetings and reviews focused on meaningful progress.Key TakeawaysSimplicity Wins: Maintainable software is easier to adapt, remove, and iterate on when it's kept simple.Iterate and Refine: Use principles like YAGNI to avoid over-engineering and ensure systems are built to evolve.Collaboration Drives Success: Bridging communication between specialized teams can unlock untapped potential.Focus on Outcomes: Define clear goals and track measurable results to ensure projects align with business needs.Resources MentionedYAGNI (You Aren't Gonna Need It)GraphQL Federation OverviewDoximity Technology BlogThe Mom Test by Rob FitzpatrickAustin Story on LinkedInAustin Story's WebsiteStay ConnectedFollow Austin:LinkedInWebsiteThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

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  

Сегодня поговорим, какие бывают уязвимости, а также почему ключи доступа лучше паролей.00:10 Как работает вход по ключу доступа00:52 Почему ключи доступа лучше паролей02:02 Почему ключи доступа хуже паролей03:00 Зачем это Гуглу03:44 Что такое уязвимость04:17 Какие бывают уязвимости06:04 Малвари06:40 Уязвимости нулевого дня07:58 Как разработчики обнаруживают уязвимости08:50 Как устроены рекомендательные системы09:50 Как это устроено технически11:15 Какие бывают рекомендательные системы13:27 Где ещё применяются рекомендательные системы14:10 Что имеют в виду программисты, когда говорят про DRY и YAGNI14:29 DRY16:00 YAGNIПодкаст записан при поддержке Английского от Яндекс Практикума. Новый курс английского для карьеры в IT здесь: https://v.thecode.media/5s1qsЖурнал «Код»: https://v.thecode.media/wh4sc

Joël shares a unique, time-specific bug he encountered, which causes a page to crash only in January. This bug has been fixed in previous years, only to reemerge due to subsequent changes. Stephanie talks about her efforts to bring more structure to her work-from-home environment. She describes how setting up a bird feeder near her desk and keeping chocolates at her desk serve as incentives to work more from her desk. Together, Stephanie and Joël take a deep dive into the challenges of breaking down software development tasks into smaller, more manageable chunks. They explore the concept of 'vertical slice' development, where features are implemented in thin, fully functional segments, contrasting it with the more traditional 'horizontal slice' approach. This discussion leads to insights on collaborative work, the importance of iterative development, and strategies for efficient and effective software engineering. thoughtbot Live Streams (https://www.youtube.com/@thoughtbot/streams?themeRefresh=1) Stephanie's Live Stream (https://www.youtube.com/watch?v=jWmCOMbOxTs) Joël's Talk on Time (https://www.youtube.com/watch?v=54Hs2E7zsQg) Finish the Owl Meme (https://knowyourmeme.com/photos/572078-how-to-draw-an-owl) Full Stack Slices (https://thoughtbot.com/blog/break-apart-your-features-into-full-stack-slices) Elephant Carpaccio (https://blog.crisp.se/2013/07/25/henrikkniberg/elephant-carpaccio-facilitation-guide) Outside-in Feature Development (https://thoughtbot.com/blog/testing-from-the-outsidein) Working Iteratively (https://thoughtbot.com/blog/working-iteratively) Transcript:  STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world in the year 2024? JOËL: Yeah, it's 2024. New year, new me. Or, in this case, maybe new year, new bugs? I'm working on a project where I ran into a really interesting time-specific bug. This particular page on the site only crashes in the month of January. There's some date logic that has a weird boundary condition there, and if you load that page during the month of January, it will crash, but during the entire rest of the year, it's fine. STEPHANIE: That's a fun New Year's tradition for this project [laughs], fixing this bug [laughs] every year. JOËL: It's been interesting because I looked a little bit at the git history of this bug, and it looks like it's been fixed in past Januarys, but then the fix changes the behavior slightly, so people bring the behavior back correct during the rest of the year that also happens to reintroduce the bug in January, and now I'm back to fixing it in January. So, it is a little bit of a tradition. STEPHANIE: Yeah, that is really funny. I was also recently debugging something, and we were having some flakiness with a test that we wrote. And we were trying to figure out because we had some date/time logic as well. And we were like, is there anything strange about this current time period that we are in that would potentially, you know, lead to a flaky test? And we were looking at the clock and we're like, "I don't think it's like, you know, midnight UTC or anything [laughs] like that." But, I mean, I don't know. It's like, how could you possibly think of, like, all of the various weird edge cases, you know, related to that kind of thing? I don't think I would ever be like, huh, it's January, so, surely, that must [laughs] mean that that's this particular edge case I'm seeing. JOËL: It's interesting because I feel like there's a couple of types of time-specific bugs that we see pretty frequently. If you're near the daylight savings boundary, let's say a week before sometimes, or whatever you're...if you're doing, like, a week from now logic or something like that, typically, I'll see failures in the test suite or maybe actual crashes in the code a week before springing forward and a week before falling back. And then, like you said, sometimes you see failures at the end of the day, Eastern time for me, when you approach that midnight UTC time boundary. I think this is the first time I've seen a failure in January due to the month being, like, a month boundary...or it's a year boundary really is what's happening. STEPHANIE: Yeah. That just sounds like another [laughs] thing you have to look out for. I'm curious: are you going to fix this bug for real or leave it for [laughs] 2025? JOËL: I've got a fix that I think is for real and that, like, not only fixes the break in January but also during the rest of the year gives the desired behavior. I think part of what's really interesting about this bug is that there are some subtle behavioral changes between a few different use cases where this code is called, part of which depend on when in the year you're calling it and whether you want to see it for today's date versus you can also specify a date that you want to see this report. And so, it turns out that there are a lot more edge cases than might be initially obvious. So, this turned into effectively a product discussion, and realizing, wait a minute, the code isn't telling the full story. There's more at a product level we need to discuss. And actually, I think I learned a lot about the product there. So, while it was maybe a surprising and kind of humorous bug to come across, I think it was actually a really good experience. STEPHANIE: Nice. That's awesome. That's a pretty good way to start the year, I would say. JOËL: I'd say so. How about you? What's new in your world? STEPHANIE: So, I don't know, I think towards the end of the year, last year, I was in a bit of a slump where I was in that work-from-couch phase of [laughs] the year, you know, like, things are slowing down and I, you know, winter was starting here. I wanted to be cozy, so I'd, you know, set up on the couch with a blanket. And I realized that I really wasn't sitting at my desk at all, and I kind of wanted to bring a little bit of that structure back into my workday, so I [chuckles] added some incentives for me to sit at my desk, which include I recently got a bird feeder that attaches to the window in my office. So, when I sit at my desk, I can hopefully see some birds hanging out. They are very flighty, so I've only seen birds when I'm, like, in the other room. And I'm like, oh, like, there's a bird at the bird feeder. Like, let me get up close to, like, get to admire them. And then as soon as I, like [laughs], get up close to the window, they fly away. So, I'm hoping that if I sit at my desk more, I'll spontaneously see more birds, and maybe they'll get used to, like, a presence closer to the window. And then my second incentive is I now have little chocolates at my desk [laughs]. JOËL: Nice. STEPHANIE: I've just been enjoying, like, a little treat and trying to keep them as a...okay, I've worked at my desk for an hour, and now I get a little reward for that [laughs]. JOËL: I like that. Do you know what kind of species of birds have been coming to your feeder? STEPHANIE: Ooh, yes. So, we got this birdseed mix called Cardinal and Friends [laughs]. JOËL: I love that. STEPHANIE: So, I have seen, like, a really beautiful red male cardinal come by. We get some robins and some chickadees, I think. Part of what I'm excited for this winter is to learn more how to identify more bird species. And I usually like to be out in nature and stuff, and winter is a hard time to do that. So, this is kind of my way of [chuckles] bringing that more into my life during the season. So, this is our first episode after a little bit of a break for the holidays. There actually has been some content of ours that has been published out in the world on the internet [laughs] during this time. And just wanted to point out in the few weeks that there weren't any Bike Shed episodes, I ended up doing a thoughtbot Rails development livestream with thoughtbot CEO Chad Pytel, and that was my first-time live streaming code [laughs]. And it was a really cool experience. I'm glad I had this podcast experience. So, I'm like, okay, well I have, you know, that, like, ability to do stuff kind of off script and present in the moment. But yeah, that was a really cool thing that I got to do, and I feel a little bit more confident about doing those kinds in the future. JOËL: And for those who are not aware, Chad does–I think it's a weekly live stream on Fridays where he's doing various types of code. So, he's done some work on some internal projects. He did a series where he upgraded, I think, a Rails 2 app all the way to Rails 7, typically with a guest who's another teammate from thoughtbot working on a thing. So, for those of our listeners that might find interesting, we'll put a link in the show notes where you can go see that. I think it's on YouTube and on Twitch. STEPHANIE: Yes. JOËL: What did you pair on? What kind of project were you doing for the livestream? STEPHANIE: So, we were working on thoughtbot's internal application called Hub, which is where we have, like, our internal messaging features. It's where we do a lot of our business operations-y things [laughs]. So, all of the, like, agency work that we do, we use our in-house software for that, and so Chad and I were working on a feature to introduce something that would help out with how we staff team members on projects. In other content news [laughs], Joël, I think you have something to share as well. JOËL: Yeah. So, we've mentioned on past episodes that I gave a talk at RubyConf this past November all about what the concept of time actually means within a program and the different ways of representing it, and the fact that time isn't really a single thing but actually kind of multiple related quantities. And over the holiday break, the talks from that conference got published. I'm pretty excited that that is now out there. We'd mentioned that as a highlight in the previous episode, highlighting accomplishments for the year, but it just wasn't quite out yet. We couldn't link it there. So, I'll leave a link in the show notes for this episode for anyone who's interested in seeing that. STEPHANIE: Sounds like that talk is also timely for a debug you -- JOËL: Ha ha ha! STEPHANIE: Were also mentioning earlier in the episode. So, a few episodes ago, I believe we mentioned that we had recently had, like, our company internal hackathon type thing where we have two days to get together and work with team members who we might not normally work with and get some cool projects started or do some team bonding, that kind of thing. And since I'm still, you know, unbooked on client work, I've been doing a lot of internal thoughtbot stuff, like continuing to work on the Hub app I mentioned just a bit ago. And from the hackathon, there was some work that was unfinished by, like, a project team that I decided to pick up this week as part of my internal work. And as I was kind of trying to gauge how much progress was made and, like, what was left to accomplish to get it over the finish line so it could be shipped, I noticed that because there were a couple of different people working on it, they had broken up this feature which was basically introducing, like, a new report for one of our teams to get some data on how certain projects are going. And there was, like, a UI portion and then some back-end portion, and then part of the back-end portion also involved a bit of a complex query that was pulled out as a separate ticket on its own. And so, all of those things were slightly, you know, were mostly done but just needed those, like, finishing touches, and then it also needed to come together. And I ended up pairing on this with another thoughtboter, and we spent the same amount of time that the hackathon was, so two days. We spent those two days on that, like, aspect of putting it all together. And I think I was a bit surprised by how much work that was, you know, we had kind of assumed that like, oh, like, all these pieces are mostly finished, but then the bulk of what we spended our time doing was integrating the components together. JOËL: Does this feel like a bit of a finish the rest of the OWL meme? STEPHANIE: What is that meme? I'm not familiar with it, but now I really want to know [laughs]. JOËL: It's a meme kind of making fun of some of these drawing tutorials where they're like, oh; first you draw, like, three circles. STEPHANIE: [laughs] JOËL: And then just finish the rest of the owl. STEPHANIE: [laughs] JOËL: And I was thinking of this beautifully drawn picture. STEPHANIE: Oh, that's so funny. Okay, yeah, I can see it in my head [laughs] now. It's like how to go from three circles, you know, to a recognizable [laughs] owl animal. JOËL: So, especially, they're like, oh, you know, like, we put in all the core classes and everything. It's all just basically there. You just need to connect it all together, and it's basically done [laughs]. And then you spend a lot of time actually getting that what feels like maybe the last 20 or 10% but takes maybe 80% of the time. STEPHANIE: Yeah, that sounds about right. So, you know, kind of working on that got me thinking about the alternative, which is honestly something that I'm still working on getting better at doing in my day-to-day. But there is this idea of a vertical slice or a full-stack slice, and that, basically, involves splitting a large feature into those full-stack slices. So, you have, like, a fully implemented piece rather than breaking them apart by layers of the stack. So, you know, I just see pretty frequently that, like, maybe you'll have a back-end ticket to do the database migration, to create your models, just whatever, maybe your controllers, or maybe that is even, like, another piece and then, like, the UI component. And those are worked on separately, maybe even by different people. But this vertical slice theory talks about how what you really want is to have a very thin piece of the feature that still delivers value but fully works. JOËL: As opposed to what you might call a horizontal slice, which would be something like, oh, I've built three Rails models. They're there. They're in the code. They talk to tables in the database, but there's nothing else happening with them. So, you've done work, but it's also more or less dead code. STEPHANIE: Yeah, that's a good point. I have definitely seen a lot of unused code paths [laughs] when you kind of go about it that way and maybe, like, that UI ticket never gets completed. JOËL: What are some tips for trying to do some of these narrower slices? Like, I have a ticket, and I have some work I need to do. And I want to break it down because I know it's going to be too big, and maybe the, like, intuitive way to do it is to split it by layers of your stack where I might do all the models, commit, ship that, deploy, then do some controllers, then do some view, or something like that, and you're suggesting instead going full stack. How do you break down the ticket more when all the pieces are interrelated? STEPHANIE: Yeah, that's a great point. One easy way to visualize it, especially if you have designs or something for this feature, right? Oftentimes, you can start to parse out sections or components of the user interface to be shipped separately. Like, yes, you would want all of it to have that rich feature, but if it's a view of some cards or something, and then, yeah, there's, like, the you can filter by them. You can search by them. All of those bits can be broken up to be like, well, like, the very basic thing that a customer would want to see is just that list of cards, and you can start there. JOËL: So, aggressively breaking down the card at, like, almost a product level. Instead of breaking it down by technical pieces, say, like, can we get even smaller amounts of behavior while still delivering value? STEPHANIE: Yeah, yeah, exactly. I like that you said product level because I think another axis of that could also be complexity. So, oftentimes, you know, I'll get a feature, and we're like, oh, we want to support these X number of things that we've identified [laughs]. You know, if it's like an e-com app you're building, you know, you're like, "Do we have all these products that we want to make sure to support?" And, you know, one way to break that down into that vertical slice is to ask, like, what if we started with just supporting one before we add variants or something like that? Teasing out, like, what would end up being the added complexity as you're developing, once you have to start considering multiple parameters, I think that is a good way to be able to start working more iteratively. And so, you don't have to hold all of that complexity in your head. JOËL: It's almost a bit of like a YAGNI principle but applied to features rather than to code. STEPHANIE: Yeah. Yeah. I like that. At first, I hesitated a little bit because I've certainly been in the position where someone has said like, "Well, we do really need this [laughs]." JOËL: Uh-huh. And, sometimes, the answer is, yes, we do need that, but what if I gave you a smaller version of that today, and we can do the other thing tomorrow? STEPHANIE: Right. Yeah, it's not like you're rejecting the idea that it's necessary but the way that you get about to that end result, right? JOËL: So, you keep using the term vertical slice or full-stack slice. I think when I hear that term, I think of specifically an article written by former thoughtboter, German Velasco, on our blog. But I don't know if that's maybe a term that has broader use in the industry. Is that a term that you've heard elsewhere? STEPHANIE: That's a good question. I think I mostly hear, you know, some form of like, "Can we break this ticket down further?" and not necessarily, like, if you think about how, right? I'm, like, kind of doing a motion with my hand [chuckles] of, like, slicing from top to bottom as opposed to, you know, horizontal. Yeah, I think that it may not be as common as I wish it were. Even if there's still some amount of adapting or, like, persuading your team members to get on board with this idea, like, I would be interested in, like, introducing that concept or that vocabulary to get teams talking about, like, how do they break down tickets? You know, like, what are they considering? Like, what alternatives are there? Like, are horizontal slices working for them or not? JOËL: A term that I've heard floating around and I haven't really pinned down is Elephant Carpaccio. Have you heard that before? STEPHANIE: I have, only because I, like, discovered a, like, workshop facilitation guide to run an exercise that is basically, like, helping people learn how to identify, like, smaller and smaller full-stack slices. But with the Elephant Carpaccio analogy, it's kind of like you're imagining a feature as big as an elephant. And you can create, like, a really thin slice out of them, and you can have infinite number of slices, but they still end up creating this elephant. And I guess you still get the value of [chuckles] a little carpaccio, a delicious [laughs] appetizer of thinly sliced meat. JOËL: I love a colorful metaphor. So, I'm curious: in your own practice, do you have any sort of guidelines or even heuristics that you like to use to help work in a more, I guess, iterative fashion by working with these smaller slices? STEPHANIE: Yeah, one thought that I had about it is that it plays really well with Outside-In Test Driven Development. JOËL: Hmmm. STEPHANIE: Yeah. So, if, you know, you are starting with a feature test, you have to start somewhere and, you know, maybe starting with, like, the most valuable piece of the feature, right? And you are starting at that level of user interaction if you're using Capybara, for example. And then it kind of forces you to drop down deeper into those layers. But once you go through that whole process of outside-in and then you arrive back to the top, you've created your full-stack feature [laughs], and that is shippable or, like, committable and, you know, potentially even shippable in and of itself. And you already have full test coverage with it. And that was a cool way that I saw some of those two concepts work well together. JOËL: Yeah, there is something really fun about the sort of Red-Green-Refactor cycle that TDD forces on you and that you're typically writing the minimum code required to pass a test. And it really forces you out of that developer brain where you're just like, oh, I've got to cover my edge cases. I've got to engineer for some things. And then maybe you realize you've written code that wasn't necessary. And so, I've found that often when I do, like, actually TDD a feature, I end up with code that's a lot leaner than I would otherwise. STEPHANIE: Yes, lean like a thin slice of Elephant Carpaccio. [laughter] JOËL: One thing you did mention that I wanted to highlight was the fact that when you do this outside-in approach for your tiny slice, at the end, it is shippable. And I think that is a core sort of tenet of this idea is that even though you're breaking things down into smaller and smaller slices, every slice is shippable to production. Like, it doesn't break the build. It doesn't break the website. And it provides some kind of value to the user. STEPHANIE: Yeah, absolutely. I think one thing that I still kind of get hung up on sometimes, and I'm trying to, you know, revisit this assumption is that idea of, like, is this too small? Like, is this valuable enough? When I mentioned earlier that I was working on a report, I think there was a part of me that's like, could I just ship a report with two columns [laughs]? And the answer is yes, right? Like, I thought about it, and I was like, well, if that data is, like, not available anywhere else, then, yeah, like, that would be valuable to just get out there. But I think the idea that, like, you know, originally, the hope was to have all of these things, these pieces of information, you know, available through this report, I think that, like, held me back a little bit from wanting to break it down. And I held it a little bit too closely and to be like, well, I really want to, like, you know, deliver something impressive. When you click on it, it's like, wow, like, look at all this data [laughs]. So, I'm trying to push back a little bit on my own preconceived notions that, like, there is such a thing as, like, a too small of a demo. JOËL: I've often worked with this at a commit level, trying to see, like, how small can I get a commit, and what is too small? And now you get into sort of the fraught question of what is a, you know, atomic commit? And I think, for me, where I've sort of come down is that a commit must pass CI. Like, I don't want a commit that's going to go into the main branch. I'm totally pro-work-in-progress commits on a branch; that's fine. But if it's going to get shipped into the main branch, it needs to be green. And it also cannot introduce dead code. STEPHANIE: Ooh. JOËL: So, if you're getting to the point where you're breaking either of those, you've got some sort of, like, partial commit that's maybe too small that needs more to be functional. Or you maybe need to restructure to say, look, instead of adding just ten models, can I add one model but also a little bit of a controller and a view? And now I've got a vertical slice. STEPHANIE: Yeah, which might even be less code [laughs] in the end. JOËL: Yes, it might be less code. STEPHANIE: I really like that heuristic of not introducing dead code, that being a goal. I'm going to think about that a lot [laughs] and try to start introducing that into when I think something is ready. JOËL: Another thing that I'll often do, I guess, that's almost like it doesn't quite fit in the slice metaphor, but it's trying to separate out any kind of refactor work into its own commit that is, you know, still follows those rules: it does not introduce dead code; it does not break the build; it's independently shippable. But that might be something that I do that sets me up for success when I want to do that next slice. So, maybe I'm trying to add a new feature, but just the way we built some of the internal models, they don't have the interface that I need right now, and that's fine because I don't want to build these models in anticipation of the future. I can change them in the future if I need. But now the future has come, and I need a slightly different shape. So, I start by refactoring, commit, maybe even ship that deploy. Maybe I then do my small feature afterwards. Maybe I come back next week and do the small feature, but there are two independent things, two different commits, maybe two different deploys. I don't know that I would call that refactor a slice and that it maybe goes across the full stack; maybe it doesn't. It doesn't show to the user because a refactor, by definition, is just changing the implementation without changing behavior. But I do like to break that out and keep it separate. And I guess it helps keep my slices lean, but I'm not quite sure where refactors fit into this metaphor. STEPHANIE: Yeah, that's interesting because, in my head, as I was listening to you talk about that, I was visualizing the owl again, the [laughs] owl meme. And I'm imagining, like, the refactoring making the slice richer, right? It's like you're adding details, and you're...it's like when you end up with the full animal, or the owl, the elephant, whatever, it's not just, like, a shoddy-looking drawing [laughs]. Like, ideally, you know, it has those details. Maybe it has some feathers. It's shaded in, and it is very fleshed out. That's just my weird, little brain trying [laughs] to stretch this metaphor to make it work. Another thing that I want to kind of touch a little bit more about when we're talking about how a lot of the work I was spending recently was that glue work, you know, the putting the pieces together, I think there was some aspect of discovery involved that was missed the first time around when these tickets were broken up more horizontally. I think that one really important piece that I was doing was trying to reconcile the different mental models that each person had when they were working on their separate piece. And so, maybe there's, like, an API, and then the frontend is expecting some sort of data, and, you know, you communicate it in a way that's, like, kind of hand-off-esque. And then when you put it together, it turns out that, oh, the pieces don't quite fit together, and how do you actually decide, like, what that mental model should be? Naming, especially, too, I've, you know, seen so many times when the name...like, an attribute on the frontend is named a little bit different than whatever is on the backend, and it takes a lot of work to unify that, like, to make that decision about, should they be the same? Should they be different? A lot of thought goes into putting those pieces together. And I think the benefit of a full-stack slice is that that work doesn't get lost. Especially if you are doing stuff like estimating, you're kind of discovering that earlier on. And I think what I just talked about, honestly, is what prevents those features from getting shipped in the end if you were working in a more horizontal way. JOËL: Yeah. It's so easy to have, like, big chunks of work in progress forever and never actually shipping. And one of the benefits of these narrower slices is that you're shipping more frequently. And that's, you know, interesting from a coding perspective, but it's kind of an agile methodology thing as well, the, like, ship smaller chunks more frequently. Even though you're maybe taking a little bit more overhead because you're having to, like, take the time to break down tasks, it will make your project move faster as a whole. An aspect that's really interesting to me, though, is what you highlighted about collaboration and the fact that every teammate has a slightly different mental model. And I think if you take the full-stack slice and every member is able to use their mental model, and then close the loop and actually, like, do a complete thing and ship it, I think it allows every other member who's going to have a slightly different mental model of the problem to kind of, yes, and... the other person rather than all sort of independently doing their things and having to reconcile them at the end. STEPHANIE: Yeah, I agree. I think I find, you know, a lot of work broken out into backend and frontend frequently because team members might have different specialties or different preferences about where they would like to be working. But that could also be, like, a really awesome opportunity for pairing [laughs]. Like, if you have someone who's more comfortable in the backend or someone more comfortable in the frontend to work on that full-stack piece together, like, even outside of the in-the-weeds coding aspects of it, it's like you're, at the very least, making sure that those two folks have that same mental model. Or I like what you said about yes, and... because it gets further refined when you have people who are maybe more familiar with, like, something about the app, and they're like, "Oh, like, don't forget about we should consider this." I think that, like, diversity of experience, too, ends up being really valuable in getting that abstraction to be more accurate so that it best represents what you're trying to build. JOËL: Early on, when I was pretty new working at thoughtbot, somebody else at the company had given me the advice that if I wanted to be more effective and work faster on projects, I needed to start breaking my work down into smaller chunks, and this is, you know, fairly junior developer at the time. The advice sounds solid, and everything we've talked about today sounds really solid. Doing it in practice is hard, and it's taken me, you know, a decade, and I'm still working on getting better at it. And I wrote an article about working iteratively that covers a lot of different elements where I've kind of pulled on threads and found out ways where you can get better at this. But I do want to acknowledge that this is not something that's easy and that just like the code that we're working on iteratively, our technique for breaking things down is something that we improve on iteratively. And it's a journey we're all on together. STEPHANIE: I'm really glad that you brought up how hard it is because as I was thinking about this topic, I was considering barriers into working in that vertical slice way, and barriers that I personally experience, as well as just I have seen on other teams. I had alluded to some earlier about, like, the perception of if I ship this small thing, is it impressive enough, or is it valuable enough? And I think I realized that, like, I was getting caught up in, like, the perception part, right? And maybe it doesn't matter [chuckles], and I just need to kind of shift the way I'm thinking about it. And then, there are more real barriers or, like, concrete barriers that are tough. Long feedback loops is one that I've encountered on a team where it's just really hard to ship frequently because PR reviews aren't happening fast enough or your CI or deployment process is just so long that you're like, I want to stuff everything into [chuckles] this one PR so that at least I won't have to sit and wait [laughs]. And that can be really hard to work against, but it could also be a really interesting signal about whether your processes are working for you. It could be an opportunity to be like, "I would like to work this way, but here are the things that are preventing me from really embracing it. And is there any improvement I can make in those areas?" JOËL: Yeah. There's a bit of a, like, vicious cycle that happens there sometimes, especially around PR review, where when it takes a long time to get reviews, you tend to decide, well, I'm going to not make a bunch of PRs; I'm going to make one big one. But then big PRs are very, like, time intensive and require you to commit a lot of, like, focus and energy to them, which means that when you ask me for a review, I'm going to wait longer before I review it, which is going to incentivize you to build bigger PRs, which is going to incentivize me to wait longer, and now we just...it's a vicious cycle. So, I know I've definitely been on projects where a question the team has had is, "How can we improve our process? We want faster code review." And there's some aspect of that that's like, look, everybody just needs to be more disciplined or more alert and try to review things more frequently. But there's also an element of if you do make things smaller, you make it much easier for people to review your code in between other things. STEPHANIE: Yeah, I really liked you mentioning incentives because I think that could be a really good place to start if you or your team are interested in making a change like this, you know, making an effort to look at your team processes and being like, what is incentivized here, and what does our system encourage or discourage? And if you want to be making that shift, like, that could be a good place to start in identifying places for improvement. JOËL: And that happens on a broader system level as well. If you look at what does it take to go from a problem that is going to turn into a ticket to in-production in front of a client, how long is that loop? How complex are the steps to get there? The longer that loop is, the slower you're iterating. And the easier it is for things to just get hung up or for you to waste time, the harder it is for you to change course. And so, oftentimes, I've come on to projects with clients and sort of seen something like that, and sort of seen other pain points that the team has and sort of found that one of the root causes is saying, "Look, we need to tighten that feedback loop, and that's going to improve all these other things that are kind of constellation around it." STEPHANIE: Agreed. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

In this episode, Matt Swanson returns to discuss YAGNI (you ain't gonna need it),  Kent Beck's quote "make the change easy (warning: this may be hard) then make the easy change," why educational materials for beginners abound, but that's not the case for intermediate and advanced developers, what drives people to create educational materials, the purpose of testing, and being judicious in what you spend your time thinking about.Matt Swanson on TwitterMatt Swanson on GitHubMatt Swanson on DevTo

Stephanie is hosting a holiday cookie swap. Joël talks about participating in thoughtbot's end-of-the-year hackathon, Ralphapalooza. We had a great year on the show! The hosts wrap up the year and discuss their favorite episodes, the articles, books, and blog posts they've read and loved, and other highlights of 2023 (projects, conferences, etc). Olive Oil Sugar Cookies With Pistachios & Lemon Glaze (https://food52.com/recipes/82228-olive-oil-sugar-cookies-recipe-with-pistachios-lemon) thoughtbot's Blog (https://thoughtbot.com/blog) Episode 398: Developing Heuristics For Writing Software (https://www.bikeshed.fm/398) Episode 374: Discrete Math (https://www.bikeshed.fm/374) Episode 405: Sandi Metz's Rules (https://www.bikeshed.fm/405) Episode 391: Learn with APPL (https://www.bikeshed.fm/391) Engineering Management for the Rest of Us (https://www.engmanagement.dev/) Confident Ruby (https://pragprog.com/titles/agcr/confident-ruby/) Working with Maybe from Elm Europe (https://www.youtube.com/watch?v=43eM4kNbb6c) Sustainable Rails Book (https://sustainable-rails.com/) Episode 368: Sustainable Web Development (https://www.bikeshed.fm/368) Domain Modeling Made Functional (https://pragprog.com/titles/swdddf/domain-modeling-made-functional/) Simplifying Tests by Extracting Side Effects (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) The Math Every Programmer Needs (https://www.youtube.com/watch?v=wzYYT40T8G8) Mermaid.js sequence diagrams (https://mermaid.js.org/syntax/sequenc) Sense of Belonging and Software Teams (https://www.drcathicks.com/post/sense-of-belonging-and-software-teams) Preemptive Pluralization is (Probably) Not Evil (https://www.swyx.io/preemptive-pluralization) Digging through the ashes (https://everythingchanges.us/blog/digging-through-the-ashes/) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: I am so excited to talk about this. I'm, like, literally smiling [chuckles] because I'm so pumped. Sometimes, you know, we get on to record, and I'm like, oh, I got to think of something that's new, like, my life is so boring. I have nothing to share. But today, I am excited to tell you about [chuckles] the holiday cookie swap that I'm hosting this Sunday [laughs] that I haven't been able to stop thinking about or just thinking about all the cookies that I'm going to get to eat. It's going to be my first time throwing this kind of shindig, and I'm so pleased with myself because it's such a great idea. You know, it's like, you get to share cookies, and you get to have all different types of cookies, and then people get to take them home. And I get to see all my friends. And I'm really [chuckles] looking forward to it. JOËL: I don't think I've ever been to a cookie swap event. How does that work? Everybody shows up with cookies, and then you leave with what you want? STEPHANIE: That's kind of the plan. I think it's not really a...there's no rules [laughs]. You can make it whatever you want it to be. But I'm asking everyone to bring, like, two dozen cookies. And, you know, I'm hoping for a lot of fun variety. Myself I'm planning on making these pistachio olive oil cookies with a lemon glaze and also, maybe, like, a chewy ginger cookie. I haven't decided if I'm going to go so extra to make two types, but we'll see. And yeah, we'll, you know, probably have some drinks and be playing Christmas music, and yeah, we'll just hang out. And I'm hoping that everyone can kind of, like, take home a little goodie bag of cookies as well because I don't think we'll be going through all of them. JOËL: Hearing you talk about this gave me an absolutely terrible idea. STEPHANIE: Terrible or terribly awesome? [laughs] JOËL: So, imagine you have the equivalent of, let's say, a LAN party. You all show up with your laptops. STEPHANIE: [laughs] JOËL: You're on a network, and then you swap browser cookies randomly. STEPHANIE: [laughs] Oh no. That would be really funny. That's a developer's take on a cookie party [laughs] if I've ever heard one. JOËL: Slightly terrifying. Now I'm just browsing, and all of a sudden, I guess I'm logged into your Facebook or something. Maybe you only swap the tracking cookies. So, I'm not actually logged into your Facebook, but I just get to see the different ad networks it would typically show you, and you would see my ads. That's maybe kind of fun or maybe terrifying, depending on what kind of ads you normally see. STEPHANIE: That's really funny. I'm thinking about how it would just be probably very misleading and confusing for those [laughs] analytics spenders, but that's totally fine, too. Might I suggest also having real cookies to munch on as well while you are enjoying [laughs] this browser cookie-swapping party? JOËL: I 100% agree. STEPHANIE: [laughs] JOËL: I'm curious: where do you stand on raisins in oatmeal cookies? STEPHANIE: Ooh. JOËL: This is a divisive question. STEPHANIE: They're fine. I'll let other people eat them. And occasionally, I will also eat an oatmeal cookie with raisins, but I much prefer if the raisins are chocolate chips [chuckles]. JOËL: That is the correct answer. STEPHANIE: [laughs] Thank you. You know, I understand that people like them. They're not for me [laughs]. JOËL: It's okay. Fans can send us hate mail about why we're wrong about oatmeal cookies. STEPHANIE: Yeah, honestly, that's something that I'm okay with being wrong about on the internet [laughs]. So, Joël, what's new in your world? JOËL: So, as of this recording, we've just recently done thoughtbot's end-of-the-year hackathon, what we call Ralphapalooza. And this is sort of a time where you kind of get to do pretty much any sort of company or programming-related activity that you want as long as...you have to pitch it and get at least two other colleagues to join you on the project, and then you've got two days to work on it. And then you can share back to the team what you've done. I was on a project where we were trying to write a lot of blog posts for the thoughtbot blog. And so, we're just kind of getting together and pitching ideas, reviewing each other's articles, writing things at a pretty intense rate for a couple of days, trying to flood the blog with articles for the next few weeks. So, if you're following the blog and as the time this episode gets released, you're like, "Wow, there's been a lot of articles from the thoughtbot blog recently," that's why. STEPHANIE: Yes, that's awesome. I love how much energy that the blog post-writing party garnered. Like, I was just kind of observing from afar, but it sounds like, you know, people who maybe had started posts, like, throughout the year had dedicated time and a good reason to revisit them, even if they had been, you know, kind of just, like, sitting in a draft for a while. And I think what also seemed really nice was people were just around to support, to review, and were able to make that a priority. And it was really cool to see all the blog posts that are queued up for December as a result. JOËL: People wrote some great stuff. So, I'm excited to see all of those come out. I think we've got pretty much a blog post every day coming out through almost the end of December. So, it's exciting to see that much content created. STEPHANIE: Yeah. If our listeners want more thoughtbot content, check out our blog. JOËL: So, as mentioned, we're recording this at the end of the year. And I thought it might be fun to do a bit of a retrospective on what this year has been like for you and I, Stephanie, both in terms of different work that we've done, the learnings we've had, but maybe also look back a little bit on 2023 for The Bike Shed and what that looked like. STEPHANIE: Yes. I really enjoyed thinking about my year and kind of just reveling and having been doing this podcast for over a year now. And yeah, I'm excited to look back a little bit on both things we have mentioned on the show before and things maybe we haven't. To start, I'm wondering if you want to talk a little bit about some of our favorite episodes. JOËL: Favorite episodes, yes. So, I've got a couple that are among my favorites. We did a lot of good episodes this year. I really liked them. But I really appreciated the episode we did on heuristics, that's Episode 398, where we got to talk a little bit about what goes into a good heuristic, how we tend to come up with them. A lot of those, like, guidelines and best practices that you hear people talk about in the software world and how to make your own but then also how to deal with the ones you hear from others in the software community. So, I think that was an episode that the idea, on the surface, seemed really basic, and then we went pretty deep with it. And that was really fun. I think a second one that I really enjoyed was also the one that I did with Sara Jackson as a guest, talking about discrete math and its relevance to the day-to-day work that we do. That's Episode 374. We just had a lot of fun with that. I think that's a topic that more developers, more web developers, would benefit from just getting a little bit more discrete math in their lives. And also, there's a clip in there where Sara reinterprets a classic marketing jingle with some discrete math terms in there instead. It was a lot of fun. So, we'd recommend people checking that one out. STEPHANIE: Nice. Yes. I also loved those episodes. The heuristics one was really great. I'm glad you mentioned it because one of my favorite episodes is kind of along a similar vein. It's one of the more recent ones that we did. It's Episode 405, where we did a bit of a retro on Sandi Metz' Rules For Developers. And those essentially are heuristics, right? And we got to kind of be like, hey, these are someone else's heuristics. How do we feel about them? Have we embodied them ourselves? Do we follow them? What parts do we take or leave? And I just remember having a really enjoyable conversation with you about that. You and I have kind of treated this podcast a little bit like our own two-person book club [laughs]. So, it felt a little bit like that, right? Where we were kind of responding to, you know, something that we both have read up on, or tried, or whatever. So, that was a good one. Another one of my favorite episodes was Episode 391: Learn with APPL [laughs], in which we basically developed our own learning framework, or actually, credit goes to former Bike Shed host, Steph Viccari, who came up with this fun, little acronym to talk about different things that we all kind of need in our work lives to be fulfilled. Our APPL stands for Adventure, Passion, Profit, and Low risk. And that one was really fun just because it was, like, the opposite of what I just described where we're not discussing someone else's work but discovered our own thing out of, you know, these conversations that we have on the show, conversations we have with our co-workers. And yeah, I'm trying to make it a thing, so I'm plugging it again [laughs]. JOËL: I did really like that episode. One, I think, you know, this APPL framework is a little bit playful, which makes it fun. But also, I think digging into it really gives some insight on the different aspects that are relevant when planning out further growth or where you want to invest your sort of professional development time. And so, breaking down those four elements led to some really insightful conversation around where do I want to invest time learning in the next year? STEPHANIE: Yeah, absolutely. JOËL: By the way, we're mentioning a bunch of our favorite things, some past episodes, and we'll be talking about a lot of other types of resources. We will be linking all of these in the show notes. So, for any of our listeners who are like, "Oh, I wonder what is that thing they mentioned," there's going to be a giant list that you can check out. STEPHANIE: Yeah. I love whenever we are able to put out an episode with a long list of things [laughs]. JOËL: It's one of the fun things that we get to do is like, oh yeah, we referenced all these things. And there is this sort of, like, further reading, more threads to pull on for people who might be interested. So, you'd mentioned, Stephanie, that, you know, sometimes we kind of treat this as our own little mini, like, two-person book club. I know that you're a voracious reader, and you've mentioned so many books over the course of the year. Do you have maybe one or two books that have been kind of your favorites or that have stood out to you over 2023? STEPHANIE: I do. I went back through my reading list in preparation for this episode and wanted to call out the couple of books that I finished. And I think I have, you know, I mentioned I was reading them along the way. But now I get to kind of see how having read them influenced my work life this past year, which is pretty cool. So, one of them is Engineering Management for the Rest of Us by Sarah Drasner. And that's actually one that really stuck with me, even though I'm not a manager; I don't have any plans to become a manager. But one thing that she talks about early on is this idea of having a shared value system. And you can have that at the company level, right? You have your kind of corporate values. You can have that at the team level with this smaller group of people that you get to know better and kind of form relationships with. And then also, part of that is, like, knowing your individual values. And having alignment in all three of those tiers is really important in being a functioning and fulfilled team, I think. And that is something that I don't think was really spelled out very explicitly for me before, but it was helpful in framing, like, past work experiences, where maybe I, like, didn't have that alignment and now identify why. And it has helped me this year as I think about my client work, too, and kind of where I sit from that perspective and helps me realize like, oh, like, this is why I'm feeling this way, and this is why it's not quite working. And, like, what do I do about it now? So, I really enjoyed that. JOËL: Would you recommend this book to others who are maybe not considering a management path? STEPHANIE: Yeah. JOËL: So, even if you're staying in the IC track, at least for now, you think that's a really powerful book for other people. STEPHANIE: Yeah, I would say so. You know, maybe not, like, all of it, but there's definitely parts that, you know, she's writing for the rest of us, like, all of us maybe not necessarily natural born leaders who knew that that's kind of what we wanted. And so, I can see how people, you know, who are uncertain or maybe even, like, really clearly, like, "I don't think that's for me," being able to get something out of, like, either those lessons in leadership or just to feel a bit, like, validated [laughs] about the type of work that they aren't interested in. Another book that I want to plug real quick is Confident Ruby by Avdi Grimm. That one was one I referenced a lot this year, working with newer developers especially. And it actually provided a good heuristic [laughs] for me to talk about areas that we could improve code during code review. I think that wasn't really vocabulary that I'd used, you know, saying, like, "Hey, how confident is this code? How confident is this method and what it will receive and what it's returning?" And I remember, like, several conversations that I ended up having on my teams about, like, return types as a result and them having learned, like, a new way to view their code, and I thought that was really cool. JOËL: I mean, learning to deal with uncertainty and nil in Ruby or maybe even, like, error states is just such a core part of writing software. I feel like this is something that I almost wish everyone was sort of assigned maybe, like, a year into their programming career because, you know, I think the first year there's just so many things you've got to learn, right? Like basic programming and, like, all these things. But, like, you're looking maybe I can start going a little bit deeper into some topic. I think that some topic, like, pretty high up, would be building a mental model for how to deal with uncertainty because it's such a source of bugs. And Avdi Grimm's book, Confident Ruby, is...I would put that, yeah, definitely on a recommended reading list for everybody. STEPHANIE: Yeah, I agree. And I think that's why I found myself, you know, then recommending it to other people on my team and kind of having something I can point to. And that was really helpful in the kind of mentorship that I wanted to offer. JOËL: I did a deep dive into uncertainty and edge cases in programs several years back when I was getting into Elm. And I was giving a talk at Elm Europe about how Elm handles uncertainty, which is a little bit different than how Ruby does it. But a lot of the underlying concepts are very similar in terms of quarantining uncertainty and pushing it to the edges and things like that. Trying to write code that is more confident that is definitely a term that I used. And so Confident Ruby ended up being a little bit of an inspiration for my own journey there, and then, eventually, the talk that I gave that summarized my learnings there. STEPHANIE: Nice. Do you have any reading recommendations or books that stood out to you this year? JOËL: So, I've been reading two technical books kind of in tandem this year. I have not finished either of them, but I have been enjoying them. One is Sustainable Rails by David Bryant Copeland. We had an episode at the beginning of this year where we talked a little bit about our initial impressions from, I think, the first chapter of the book. But I really love that vocabulary of writing Ruby and Rails code, in particular, in a way that is sustainable for a team. And that premise, I think, just gives a really powerful mindset to approach structuring Rails apps. And the other book that I've been reading is Domain Modeling Made Functional, so kind of looking at some domain-driven design ideas. But most of the literature is typically written to an object-oriented audience, so taking a look at it from more of a functional programming perspective has been really interesting. And then I've been, weirdly enough, taking some of those ideas and translating back into the object-oriented world to apply to code I'm writing in Ruby. I think that has been a very useful exercise. STEPHANIE: That's awesome. And it's weird and cool how all those things end up converging, right? And exploring different paradigms really just lets you develop more insight into wherever you're working. JOËL: Sometimes the sort of conversion step that you have to do, that translation, can be a good tool for kind of solidifying learnings or better understanding. So, I'm doing this sort of deep learning thing where I'm taking notes as I go along. And those notes are typically around, what other concepts can I connect ideas in the book? So, I'll be reading and say, okay, on page 150, he mentioned this concept. This reminds me of this idea from TDD. I could see this applying in a different way in an object-oriented world. And interestingly, if you apply this, it sort of converges on maybe single responsibility or whatever other OO principle. And that's a really interesting connection. I always love it when you do see sort of two or three different angles converging together on the same idea. STEPHANIE: Yeah, absolutely. JOËL: I've written a blog post, I think, two years ago around how some theory from functional programming sort of OO best practices and then TDD all kind of converge on sort of the same approach to designing software. So, you can sort of go from either direction, and you kind of end in the same place or sort of end up rediscovering principles from the other two. We'll link that in the show notes. But that's something that I found was really exciting. It didn't directly come from this book because, again, I wrote this a couple of years ago. But it is always fun when you're exploring two or three different paradigms, and you find a convergence. It really deepens your understanding of what's happening. STEPHANIE: Yeah, absolutely. I like what you said about how this book is different because it is making that connection between things that maybe seem less related on the surface. Like you're saying, there's other literature written about how domain modeling and object-oriented programming make more sense a little bit more together. But it is that, like, bringing in of different schools of thought that can lead to a lot of really interesting discovery about those foundational concepts. JOËL: I feel like dabbling in other paradigms and in other languages has made me a better Ruby developer and a better OO programmer, a lot of the work I've done in Elm. This book that I'm reading is written in F#. And all these things I can kind of bring back, and I think, have made me a better Ruby developer. Have you had any experiences like that? STEPHANIE: Yeah. I think I've talked a little bit about it on the show before, but I can't exactly recall. There were times when my exploration in static typing ended up giving me that different mindset in terms of the next time I was coding in Ruby after being in TypeScript for a while, I was, like, thinking in types a lot more, and I think maybe swung a little bit towards, like, not wanting to metaprogram as much [laughs]. But I think that it was a useful, like you said, exercise sometimes, too, and just, like, doing that conversion or translating in your head to see more options available to you, and then deciding where to go from there. So, we've talked a bit about technical books that we've read. And now I kind of want to get into some in-person highlights for the year because you and I are both on the conference circuit and had some fun trips this year. JOËL: Yeah. So, I spoke at RailsConf this spring. I gave a talk on discrete math and how it is relevant in day-to-day work for developers, actually inspired by that Bike Shed episode that I mentioned earlier. So, that was kind of fun, turning a Bike Shed episode into a conference talk. And then just recently, I was at RubyConf in San Diego, and I gave a talk there around time. We often talk about time as a single quantity, but there's some subtle distinctions, so the difference between a moment in time versus a duration and some of the math that happens around that. And I gave a few sort of visual mental models to help people keep track of that. As of this recording, the talk is not out yet, so we're not going to be able to link to it. But if you're listening to this later in 2024, you can probably just Google RubyConf "Which Time Is It?" That's the name of the talk. And you'll be able to find it. STEPHANIE: Awesome. So, as someone who is giving talks and attending conferences every year, I'm wondering, was this year particularly different in any way? Was there something that you've, like, experienced or felt differently community-wise in 2023? JOËL: Conferences still feel a little bit smaller than they were pre-COVID. I think they are still bouncing back. But there's definitely an energy that's there that's nice to have on the conference scene. I don't know, have you experienced something similar? STEPHANIE: I think I know what you're talking about where, you know, there was that time when we weren't really meeting in person. And so, now we're still kind of riding that wave of, like, getting together again and being able to celebrate and have fun in that way. I, this year, got to speak at Blue Ridge Ruby in June. And that was a first-time regional conference. And so, that was, I think, something I had noticed, too, is the emergence of regional conferences as being more viable options after not having conferences for a few years. And as a regional conference, it was even smaller than the bigger national Ruby Central conferences. I really enjoyed the intimacy of that, where it was just a single track. So, everyone was watching talks together and then was on breaks together, so you could mingle. There was no FOMO of like, oh, like, I can't make this talk because I want to watch this other one. And that was kind of nice because I could, like, ask anyone, "What did you think of, like, X talk or like the one that we just kind of came out of and had that shared experience?" That was really great. And I got to go tubing for the first time [laughs] in Asheville. That's a memory, but I am still thinking about that as we get into winter. I'm like, oh yeah, the glorious days of summer [laughs] when I was getting to float down a lazy river. JOËL: Nice. I wasn't sure if this was floating down a lazy river on an inner tube or if this was someone takes you out on a lake with a speed boat, and you're getting pulled. STEPHANIE: [laughs] That's true. As a person who likes to relax [laughs], I definitely prefer that kind of tubing over a speed boat [laughs]. JOËL: What was the topic of your talk? STEPHANIE: So, I got to give my talk about nonviolent communication in pair programming for a second time. And that was also my first time giving a talk for a second time [laughs]. That was cool, too, because I got to revisit something and go deeper and kind of integrate even more experiences I had. I just kind of realized that even if you produce content once, like, there's always ways to deepen it or shape it a little better, kind of, you know, just continually improving it and as you learn more and as you get more experience and change. JOËL: Yeah. I've never given a talk twice, and now you've got me wondering if that's something I should do. Because making a bespoke talk for every conference is a lot of work, and it might be nice to be able to use it more than once. Especially I think for some of the regional conferences, there might be some value there in people who might not be able to go to a big national conference but would still like to see your talk live. Having a mix of maybe original content and then content that is sort of being reshared is probably a great combo for a regional conference. STEPHANIE: Yeah, definitely. That's actually a really good idea, yeah, to just be able to have more people see that content and access it. I like that a lot. And I think it could be really cool for you because we were just talking about all the ways that our mental models evolve the more stuff that we read and consume. And I think there's a lot of value there. One other conference that I went to this year that I just want to highlight because it was really cool that I got to do this: I went to RubyKaigi in Japan [laughs] back in the spring. And I had never gone to an international conference before, and now I'm itching to do more of that. So, it would be remiss not to mention it [laughs]. I'm definitely inspired to maybe check out some of the conferences outside of the U.S. in 2024. I think I had always been a little intimidated. I was like, oh, like, it's so far [laughs]. Do I really have, like, that good of a reason to make a trip out there? But being able to meet Rubyists from different countries and seeing how it's being used in other parts of the world, I think, made me realize that like, oh yeah, like, beyond my little bubble, there's so many cool things happening and people out there who, again, like, have that shared love of Ruby. And connecting with them was, yeah, just so new and something that I would want to do more of. So, another thing that we haven't yet gotten into is our actual work-work or our client work [laughs] that we do at thoughtbot for this year. Joël, I'm wondering, was there anything especially fun or anything that really stood out to you in terms of client work that you had to do this year? JOËL: So, two things come to mind that were novel for me. One is I did a Rails integration against Snowflake, the data warehouse, using an ODBC connection. We're not going through an API; we're going through this DB connection. And I never had to do that before. I also got to work with the new-ish Rails multi-database support, which actually worked quite nice. That was, I think, a great learning experience. Definitely ran into some weird edge cases, or some days, I was really frustrated. Some days, I was actually, like, digging into the source code of the C bindings of the ODBC gem. Those were not the best days. But definitely, I think, that kind of integration and then Snowflake as a technology was really interesting to explore. The other one that's been really interesting, I think, has been going much deeper into the single sign-on world. I've been doing an integration against a kind of enterprise SAML server that wants to initiate sign-in requests from their portal. And this is a bit of an alphabet soup, but the term here is IdP-initiated SSO. And so, I've been working with...it's a combination of this third-party kind of corporate SAML system, our application, which is a Rails app, and then Auth0 kind of sitting in the middle and getting all of them to talk to each other. There's a ridiculous number of redirects because we're talking SAML on one side and OIDC on the other and getting everything to line up correctly. But that's been a really fun, new set of things to learn. STEPHANIE: Yeah, that does sound complicated [laughs] just based on what you shared with me, but very cool. And I was excited to hear that you had had a good experience with the Rails multi-database part because that was another thing that I remember being...it had piqued my interest when it first came out. I hope I get to, you know, utilize that feature on a project soon because that sounds really fun. JOËL: One thing I've had to do for this SSO project is lean a lot on sequence diagrams, which are those diagrams that sort of show you, like, being redirected from different places, and, like, okay, server one talks to server two talks, to the browser. And so, when I've got so many different actors and sort of controllers being passed around everywhere, it's been hard to keep track of it in my head. And so, I've been doing a lot of these diagrams, both for myself to help understand it during development, and then also as documentation to share back with the team. And I found that Mermaid.js supports sequence diagrams as a diagram type. Long-term listeners of the show will know that I am a sucker for a good diagram. I love using Mermaid for a lot of things because it's supported. You can embed it in a lot of places, including in GitHub comments, pull requests. You can use it in various note systems like Notion or Obsidian. And you can also just generate your own on mermaid.live. And so, that's been really helpful to communicate with the rest of the team, like, "Hey, we've got this whole process where we've got 14 redirects across four different servers. Here's what it looks like. And here, like, we're getting a bug on, you know, redirect number 8 of 14. I wonder why," and then you can start a conversation around debugging that. STEPHANIE: Cool. I was just about to ask what tool you're using to generate your sequence diagrams. I didn't know that Mermaid supported them. So, that's really neat. JOËL: So, last year, when we kind of looked back over 2022, one thing that was really interesting that we did is we talked about what are articles that you find yourself linking to a lot that are just kind of things that maybe were on your mind or that were a big part of conversations that happened over the year? So, maybe for you, Stephanie, in 2023, what are one or two articles that you find yourself sort of constantly linking to other people? STEPHANIE: Yes. I'm excited you asked about this. One of them is an article by a person named Cat Hicks, who has a PhD in experimental psychology. She's a data scientist and social scientist. And lately, she's been doing a lot of research into the sense of belonging on software teams. And I think that's a theme that I am personally really interested in, and I think has kind of been something more people are talking about in the last few years. And she is kind of taking that maybe more squishy idea and getting numbers for it and getting statistics, and I think that's really cool. She points out belonging as, like, a different experience from just, like, happiness and fulfillment, and that really having an impact on how well a team is functioning. I got to share this with a few people who were, you know, just in that same boat of, like, trying to figure out, what are the behaviors kind of on my team that make me feel supported or not supported? And there were a lot of interesting discussions that came out of sharing this article and kind of talking about, especially in software, where we can be a little bit dogmatic. And we've kind of actually joked about it on the podcast [chuckles] before about, like, we TDD or don't TDD, or, you know, we use X tool, and that's just like what we have to do here. She writes a little bit about how that can end up, you know, not encouraging people offering, like, differing opinions and being able to feel like they have a say in kind of, like, the team's direction. And yeah, I just really enjoyed a different way of thinking about it. Joël, what about you? What are some articles you got bookmarked? [chuckles] JOËL: This year, I started using a bookmark manager, Raindrop.io. That's been nice because, for this episode, I could just look back on, what are some of my bookmarks this year? And be like, oh yeah, this is the thing that I have been using a lot. So, an article that I've been linking is an article called Preemptive Pluralization is (Probably) Not Evil. And it kind of talks a little bit about how going from code that works over a collection of two items to a collection of, you know, 20 items is very easy. But sometimes, going from one to two can be really challenging. And when are the times where you might want to preemptively make something more than one item? So, maybe using it has many association rather than it has one or making an attribute a collection rather than a single item. Controversial is not the word for it, but I think challenges a little bit of the way people typically like to write code. But across this year, I've run into multiple projects where they have been transitioning from one to many. That's been an interesting article to surface as part of those conversations. Whether your team wants to do this preemptively or whether they want to put it off and say in classic YAGNI (You Aren't Gonna Need It) form, "We'll make it single for now, and then we'll go plural," that's a conversation for your team. But I think this article is a great way to maybe frame the conversation. STEPHANIE: Cool. Yeah, I really like that almost, like, a counterpoint to YAGNI [laughs], which I don't think I've ever heard anyone say that out loud [laughs] before. But as soon as you said preemptive pluralization is not evil, I thought about all the times that I've had to, like, write code, text in which a thing, a variable could be either one or many [laughs] things. And I was like, ooh, maybe this will solve that problem for me [laughs]. JOËL: Speaking of pluralization, I'm sure you've been linking to more than just one article this year. Do you have another one that you find yourself coming up in conversations where you've always kind of like, "Hey, dropping this link," where it's almost like your thing? STEPHANIE: Yes. And that is basically everything written by Mandy Brown [laughs], who is a work coach that I actually started working with this year. And one of the articles that really inspired me or really has been a topic of conversation among my friends and co-workers is she has a blog post called Digging Through the Ashes. And it's kind of a meditation on, like, post burnout or, like, what's next, and how we have used this word as kind of a catch-all to describe, you know, this collective sense of being just really tired or demoralized or just, like, in need of a break. And what she offers in that post is kind of, like, some suggestions about, like, how can we be more specific here and really, you know, identify what it is that you're needing so that you can change how you engage with work? Because burnout can mean just that you are bored. It can mean that you are overworked. It can mean a lot of things for different people, right? And so, I definitely don't think I'm alone [laughs] in kind of having to realize that, like, oh, these are the ways that my work is or isn't changing and, like, where do I want to go next so that I might feel more sustainable? I know that's, like, a keyword that we talked about earlier, too. And that, on one hand, is both personal but also technical, right? It, like, informs the kinds of decisions that we make around our codebase and what we are optimizing for. And yeah, it is both technical and cultural. And it's been a big theme for me this year [laughs]. JOËL: Yeah. Would you say it's safe to say that sustainability would be, if you want to, like, put a single word on your theme for the year? Would that be a fair word to put there? STEPHANIE: Yeah, I think so. Definitely discovering what that means for me and helping other people discover what that means for them, too. JOËL: I feel like we kicked off the year 2023 by having that discussion of Sustainable Rails and how different technical practices can make the work there feel sustainable. So, I think that seems to have really carried through as a theme through the year for you. So, that's really cool to have seen that. And I'm sure listeners throughout the year have heard you mention these different books and articles. Maybe you've also been able to pick up a little bit on that. So, I'm glad that we do this show because you get a little bit of, like, all the bits and pieces in the day-to-day, and then we aggregate it over a year, and you can look back. You can be like, "Oh yeah, I definitely see that theme in your work." STEPHANIE: Yeah, I'm glad you pointed that out. It is actually really interesting to see how something that we had talked about early, early on just had that thread throughout the year. And speaking of sustainability, we are taking a little break from the show to enjoy the holidays. We'll be off for a few weeks, and we will be back with a new Bike Shed in January. JOËL: Cheers to a new year. STEPHANIE: Yeah, cheers to a new year. Wrapping up 2023. And we will see you all in 2024. JOËL: On that note, shall we wrap up the whole year? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/ referral. Or you can email us at referrals@thoughtbot.com with any questions.

Matt and Aaron talk about programming books and try to answer the question "do we need them?"This season of YAGNI was made possible by our friends at Flipper Cloud - Are big launches stressing you out? Then you need feature flags!Flipper Cloud helps your team deploy the code now and then roll out features when you're good and ready. Get started for free atflippercloud.ioAaron Francis on Twitter // PlanetScaleMatt Swanson on Twitter // arrows.toAaron's shedAaron reading printed docs on the beachSQL Window FunctionsThe Pragmatic ProgrammerThe Timeless Way of BuildingCulture is StuckUse the Index, Luke!MySQL for Developers courseWhy do programmers use books as monitor stands?

Matt and Nate talk about Redis and try to answer the question "do we need it?"This season of YAGNI was made possible by our friends at Flipper Cloud - Are big launches stressing you out? Then you need feature flags!Flipper Cloud helps your team deploy the code now and then roll out features when you're good and ready. Get started for free atflippercloud.ioNate Berkopec on Twitter // SpeedshopMatt Swanson on Twitter // arrows.to"Redis is not faster than your database""Your data fits in RAM"March of progressneo4jsidekiqACIDkredisWafris"Running Sidekiq...with a volatile eviction policy"Solid QueueSolid CacheThe open source gift exchangepuma/pumaThe Silver Rule

Matt and Jason talk about Service Objects and try to answer the question "do we need them?"This season of YAGNI was made possible by our friends at Flipper Cloud - Are big launches stressing you out? Then you need feature flags!Flipper Cloud helps your team deploy the code now and then roll out features when you're good and ready. Get started for free atflippercloud.ioJason Swett on Twitter // Code with JasonMatt Swanson on Twitter // arrows.toJason's Snail Mail newsletterBrevity is the soul of wit

Matt and Josh talk about automated testing and try to answer the question "do we need them?"This season of YAGNI was made possible by our friends at Flipper Cloud - Are big launches stressing you out? Then you need feature flags!Flipper Cloud helps your team deploy the code now and then roll out features when you're good and ready. Get started for free atflippercloud.ioJosh Pigford on Twitter // DetangleMatt Swanson on Twitter // arrows.toWittgenstein's RulerWhy doesn't Stripe have a /mrr endpoint?GitHub Project Paper CutsBaremetricsMaybeLaser TweetsCedar & SailThe best restaurant in the worldKim Kardashian - Kimoji appCursor AI EditorStated vs Revealed preferences

Matt and Trevor talk about GraphQL and try to answer the question "do we need it?" (Bonus hot takes on VCR snapshot testing)This season of YAGNI was made possible by our friends at Flipper Cloud - Are big launches stressing you out? Then you need feature flags!Flipper Cloud helps your team deploy the code now and then roll out features when you're good and ready. Get started for free atflippercloud.ioTrevor Turk on Twitter // Hello WeatherMatt Swanson on Twitter // arrows.toGraphQL: The DocumentaryGraphiQLn+1 problems in GraphQLBFF: Backend for FrontendGraph TheorySchema stitchingBonus: VCR

Matt and Charity talk about Friday Deploys and try to answer the question "do we need them?"This season of YAGNI was made possible by our friends at Flipper Cloud - Are big launches stressing you out? Then you need feature flags! Flipper Cloud helps your team deploy the code now and then roll out features when you're good and ready. Get started for free at flippercloud.ioCharity Majors on Twitter // honeycomb.ioMatt Swanson on Twitter // arrows.toFriday deploy freezes are exactly like murdering puppiesCoaching treeFrequency Reduces Difficulty (Martin Fowler)Payoff space vs consistency spaceBlame-aware postmortemDORA metrics

- beware fast talkers, as Ray Dalio says in Principles https://www.principles.com/ (as a tweet: https://twitter.com/RayDalio/status/1599056902637248514 )- beware pattern obsessives (any pattern, architecture, SOLID, CQRS, Event Sourcing, Outside-in testing, you name it, someone wears it as a badge)- evolve your architecture - YAGNI, but do think ahead- currently available for c# contracts- building rustworkshop.co

Ci sono concetti che non devono mai essere dimenticati, come KISS, YAGNI e DRY. Acronimi che per un dev dovrebbero essere fondamentali alla pari dei principi SOLID.Qui non si tratta di pattern architetturali o principi di design, ma del puro BUONSENSO nel fare bene quello che facciamo.

Everything has to start somewhere. Why not here?

Liz and Sarah have a new strategy: You Ain't Gonna Need It! YAGNI—a tip from a listener—is helping Liz and Sarah think about work differently. One example? Not spending energy on projects before they're done deals. In Take Two, listeners share times in their lives that give them the same feeling of euphoria that Liz and Sarah get from handing in the last script of the season. Then in HIH WFH they discuss the decision NOT to return to Puerto Rico and how working from home allows them to get MORE work done. Finally, this week's Hollywood Hack is a handy gadget for summer adventures: the Heroclip® Mini. Get in touch on Twitter: @sarahmfain & @elizabethcraft Get in touch on Instagram: @Sfain & @LizCraft Visit our website: https://happierinhollywood.com Join our Facebook group: https://www.facebook.com/HappierinHollywood/ Happier in Hollywood is part of ‘The Onward Project,' a family of podcasts brought together by Gretchen Rubin—all about how to make your life better. Check out the other Onward Project podcasts—Happier with Gretchen Rubin, Side Hustle School, Do The Thing, and Everything Happens with Kate Bowler . If you liked this episode, please subscribe, leave a review, and tell your friends! LINKS Heroclip® Mini https://myheroclip.com/products/heroclip-mini?variant=29621301215297 FOX | Fantasy Island https://www.fox.com/fantasy-island/ Happy Campers https://sunshine-parenting.com/happy/Get in touch on Twitter: @sarahmfain & @elizabethcraft Learn more about your ad choices. Visit podcastchoices.com/adchoices

kumagi さんをゲストに、Value Object について語っていただいたエピソードです。 話したネタ Value Objectについて整理しよう Value Object とは何か？ Value Object で複数の値をくるむcompoundの具体例は？ Value Object のメリット・デメリットは？ 別名参照問題 Value Object は何でないか？ YAGNI原則 不変オブジェクト (Immutable Object) 書籍: リファクタリング 既存のコードを安全に改善する（第2版） マーチン・ファウラー氏のblog記事 - ValueObject Value Object Obsession と Primitive Obsession Primitive Obsession のメリットは？ Value Objectの言説はどこから生まれてきたのか？ 「オブジェクト指向エクササイズ」でクセの強いコードを矯正しよう 書籍: Effective C++ 第3版 書籍: Effective Java 第3版 書籍: CODE COMPLETE 第2版 上 完全なプログラミングを目指して 書籍: CODE COMPLETE 第2版 下 完全なプログラミングを目指して

Sara Bine (a Lead Programmer at Tighten) joins us this week to talk all about YAGNI aka 'You Aren't Gonna Need It': what it is, why it's so important for anybody who's building software, and more.

This week we discuss Apple's record breaking iPhone sales in India. A new MacBook Air could be coming with a notch, MagSafe, next generation Apple Silicon and more ports, along with a 5G iPhone SE. Apple's App Store likely to survive two U.S. Bills aimed to change it. We discuss Tom Harrington's Clash of the Optionals and Jesse Squire's interpretation on how to handle non-optionals with Core Data. Apple unveils contactless payments via Tap to Pay on iPhone. We revisit 2048, Threes, Wordle and the endless chain of "rip offs". Apple releases macOS Big Sur and Catalina security updates. Picks: The Smart Guitar Amp & App, Log: Job Application Tracker, open source iOS apps, Hidden Mac tricks, DevToys For macOS, Fire in the Valley, and Using Combine

In this episode, Jake and Michael discuss Michael's new job, YAGNI, and approaches to working your way into a new codebase and a new industry.This episode is sponsored by Workvivo and Makeable.dk and was streamed live.Show links Laravel Transporter Saloon YAGNI ClickUp Allen Holub on building software better and building better software 

Uso l'articolo "Overengineering can kill your product" ( https://www.mindtheproduct.com/overengineering-can-kill-your-product/ ) per dare il via a questa puntata e spendere due parole sul quanto sia costoso e controproducente scrivere del codice complesso.Consiglio poi la visione delle sessioni di Marco Cecconi a riguardo dell'architettura di StackOverflow, una sessione datata, ma sempre attuale e piena di consigli:- https://youtu.be/E9QljNyCmq4 - https://youtu.be/t6kM2EM6so4 - https://youtu.be/2tG0JZuYzp0 - https://stackexchange.com/performance

話したネタ ゼロから作る時系列データベースエンジン 時系列データとは何か？ RDBで時系列データを扱う場合の課題とは？ 時系列データの特徴とは？ イミュータブルなデータとは？ influxDB Timescale DB VictoriaMetrics M3DB 時系列DBにおけるカーディナリティの高さとは？ tstorage なぜ時系列DBを自分で実装したのか？ ali gosivy tstorageの設計概要は？ パーティショニングのメリットとは？ Write Amplificatonとは？ Bloom Filter LSM Treeとは？ 34. NewSQLとは w/ tzkb メモリパーティションの特徴とは？ 時系列データをソート済みにする工夫 QuestDB パーティションをフラッシュするタイミングは？ Write Ahead Log データ量を削減する工夫は？ Gorilla: A Fast, Scalable, In-Memory Time Series Database タイムスタンプとデータを分けて符号化する delta encoding と delta-of-delta encoding データ側はXORで符号化する tstorageのdisadvantageは？ tstorageの今後の開発方針 YAGNI原則 【メディア事業部】サーバーサイドエンジニア（基盤） 宣伝 fukabori.fm の個人スポンサー募集中

PAGNI (Probably Are Gonna Need It) and YAGNI (You ain't Gonna Need It) abstracciones tempranas que tienen sentido y otras que sencillamente sabotean tu futuro, hoy @castrolem y @duranmla nos hablan un poco de esto.

Te comparto 10 principios básicos de programación que todo programador debe saber incluyendo: KISS, DRY, SRP, SoC, Yagni y Ley de Curly.

Te comparto 10 principios básicos de programación que todo programador debe saber incluyendo: KISS, DRY, SRP, SoC, Yagni y Ley de Curly.

A great question on Staff Engineer that I recieved recently focused on creating a culture of good documents rather than a culture of perfect documents. Here are my quick thoughts. https://lethain.com/discouraging-perfection/ Staff Engineercultural export of Amazon’s memo cultureYAGNIto model that behavior

Collecting user data and tracking users across the web is a hot topic. For some, it’s nice to have, for others, it’s their entire business model. Let’s talk about what we collect, what we do with it, and the principle of YAGNI. Show Notes: SiteGround   The post YAGNI: You and Your User’s Data appeared first on Geek 2 English Podcast.

Quanto tempo devemos investir no design de um sistema novo? Esse tempo desgasta a relação com o cliente? As decisões são acertadas? Qual arquitetura usar? Microsserviços logo de início? Que tal uma ideia evolutiva? Nesse episódio falamos de Design Simples. Confira! Participantes Marcio Frayze David marcio@segunda.tech https://twitter.com/marciofrayze https://segunda.tech https://masto.donte.com.br/web/accounts/138458 Julianno Martins Silva juliannoms@gmail.com https://twitter.com/juliannoms Links: Artigo sobre Yagni (You Aren't Gonna Need It), do Martin Fowler: https://martinfowler.com/bliki/Yagni.html Artigo sobre Monolith First, do Martin Fowler: https://martinfowler.com/bliki/MonolithFirst.html Livro Extreme Programming Explained: https://www.goodreads.com/book/show/67833.Extreme_Programming_Explained Livro de XP https://www.goodreads.com/book/show/9737235-extreme-programming Artigo Is Design Dead?, do Martin Fowler: https://www.martinfowler.com/articles/designDead.html

This is another How I'd Build It episode, where listeners send in their feature requirements and we discuss them on the show. In this one we talk about a sailing application where there's a need to keep track of whether members' payments are up-to-date. Adam and I also talk about the YAGNI principle as well as why it's not possible to have high-quality code without tests.

Wir unterhalten uns heute mit Christian über die neue Python-Release 3.9 und Design und Softwarearchitektur-Patterns. Mehr Einführungstext? YAGNI!   Shownotes Unsere E-Mail für Fragen, Anregungen & Kommentare: hallo@python-podcast.de News aus der Szene Python 3.9 / Real Python Podcast Episode zu den neuen Features PEP 617 neuer PEG Parser für Python - yacc / lex Podcast.__init__ Episode zum neuen PEG Parser PEP 622 -- Structural Pattern Matching PHP: a fractal of bad design Djangocon Europe Talks Python Software Verband FrOSCon 2020 Talks Black und isort vertragen sich jetzt Yapf - Alternative zu black Lex Fridman & James Gosling Java, JVM, Emacs, and the Early Days of Computing Lex Fridman & Chris Lattner The Future of Computing and Programming Languages Lex Fridman & Jim Keller Moore's Law, Microprocessors, and First Principles Design Patterns Revenge of the Nerds | Man braucht Patterns -> die Sprache hat versagt Design Patterns Gang of Four (GoF) Software design pattern mit mehr als GoF Entwurfsmuster Python Design Patterns Builder: lxml builder builder module Borg Pattern Zope Flyweight für kleine ints in Python Observer Pattern YAGNI Model View Controller Decorator Pattern Active Record Data Mapper Pattern SOLID Clean Code Cosmic Python Repository Pattern Unit of work Öffentliches Tag auf konektom

YAGNI stands for You aren’t gonna need it and its a pillar in extreme programming, in this video I discuss this philosophy within the context of Backend Engineering. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it * Extreme Programming Rob Jefferies * You Aren’t Gonna Need it .. true but only if the design is well defined * But I am going to need it * Waterfall vs Agile --- Send in a voice message: https://anchor.fm/hnasr/message

В честь десятого выпуска было принято решение пройтись по популярной теме хорошего кода. В этот раз никаких статей, только наш опыт и наши мысли. Мы полностью и детально обсудили любимую на собеседованиях тему SOLID. Рассмотрели примеры и попытались более глубоко, чем это обычно делают в ежедневных статьях, проанализировать каждую отдельную букву этой аббревиатуры. Также не забыли мы и о более простых, но важных принципах, как KISS, DRY, YAGNI и CQS.00:03:12 - SOLID00:44:55 - KISS00:59:02 - DRY01:07:30 - CQS (Command Query Segregation)Выпуск, в котором обсуждалась библиотека Mockk можно найти здесь.Оставить комментарии можно здесь.

Nachdem wir (Christian, Johannes, Dominik und Jochen) uns schon mehrfach zu diesem Thema zusammensetzen wollten, es dann aber aus Terminfindungsschwierigkeiten nicht hinbekommen haben, es dann doch noch geschafft haben, mit dem Ergebnis aber noch nicht zufrieden waren, um uns dann noch einmal in das Fegefeuer der Terminfindungsschwierigkeiten zurückzubegeben, haben wir es letztlich doch noch  hinbekommen, eine Episode zu diesem Thema aufzunehmen o/. Shownotes Unsere E-Mail für Fragen, Anregungen & Kommentare: hallo@python-podcast.de News aus der Szene pipenv release appenv auf dem pythoncamp Async Python is not faster | Klarstellung dazu von Łukasz Langa asyncio Promise Projektmanagement Projekt Project management triangle Cynefin Manifesto for Agile Software Development Peopleware - Buch zum Thema ("make a cheeseburger, sell a cheeseburger") Original waterfall paper Rapid Application Development Manager Tools Employee Retention YAGNI Second System Tools GitLab FogBugz Jira Trello Odoo Taiga Redmine CRE028 Extreme Programming Öffentliches Tag auf konektom

Zu wenig Fokus auf die Architektur eures Projekts wird euch vor genauso große Probleme stellen wie zu viel desselben. Doch wie findet man dann das richtige Maß in der Architekturarbeit? In Folge 63 sprechen wir mit Stefan Tilkov über die Frage der richtigen Priorisierung. Stefan ist Geschäftsführer von INNOQ und ist als Principal Consultant in der Beratung von Firmen im Bereich der Softwarearchitektur tätig. Dadurch konnte er bereits langjährige Erfahrung sammeln, wenn es um erfolgversprechende Konzepte in Planung und Aufbau von Architektur geht. Wie die goldene Mitte zwischen Over-Engineering und fehlender Weitsicht erreicht werden und wieso es keine Musterlösung für jedes Projekt geben kann, erzählte er uns im Livestream dieser Folge. Weitere von Stefan angesprochene Begriffe und Themen findet ihr hier: Definitionen von “Softwarearchitektur” gesammelt auf Software Engineering Institute You Aren't Gonna Need It (yagni)-Prinzip Cargo Cult Programming Stefan ist Autor und Mitherausgeber folgender Bücher, die euch weiterführende Informationen zu dieser Folge liefern: Tilkov, Stefan et. al. (2015): „REST und HTTP”. dpunkt. Tilkov, Stefan; Starke, Gernot (Hg.) (2007): „SOA-Expertenwissen“. dpunkt. Ihr könnt Stefan unter @stilkov auf Twitter folgen. Picks of the Day Stefan: Mit der Programmierumgebung und -sprache "Dark" Backends programmieren. Dark ist funktional orientiert und besitzt eine skalierbare Infrastruktur. Aktuell in Private Beta. Jojo: Performance-Tab in Chrome zum Analysieren, welche Elemente einer Webseite negativen Einfluss auf ihre Performance haben. Es ermöglicht auch die Simulierung mobiler CPUs zum Testen anderer Endgeräte. Fabi: Super einfach IoT-Devices programmieren mit dem NodeMCU-Development-Board, bspw. für die automatische Gartenbewässerung. Streamt uns! Die nächste Live-Folge nehmen wir am Mittwoch, den 3. Juni, um 18 Uhr auf. Seid dabei und bringt eure Fragen und Anregungen ein! Auf unserer Webseite erhaltet ihr mehr Informationen. Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback. podcast@programmier.bar Folgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. Twitter Instagram Facebook Meetup YouTube  Musik: Hanimo

This episode I speak to Jason McCreary. JMac has been a developer for twenty years and in that time has created many projects including Shift, authored BaseCode - for practises on improving the code you write. He also produces the video course, Confident Laravel. We discuss working handling stresses when writing code, YAGNI, identifying burn out and more!

In episode 4, host Brandon Aaskov (Principal Software Developer, Rocket Insights) talks with Rocket Insights developers Matt DiDomenico, Matt Merrill, Dave Oelfke and Ian Pirro about over engineering systems.  We dive into anticipating problems that might not exist, the temptation to impress other engineers and missing the mark with end users. As always, we end with picks for you to follow up on! Topics: 0:00 - Intros and YAGNI. 2:00 - Don't optimize ... yet. 3:00 - Being afraid of code judgement. 4:10 - Thoughts on Heroku. 5:20 - Think about the end user instead of impressing other developers. 8:50 - When should you start thinking about scale as a developer?  What's the line between Dev and DevOps in scaling? 11:00 - The trough of disillusionment with new apps and component libraries. 13:00 - Know your customer. If you don't, ask questions. 15:20 - Perfect is the enemy of done. 17:45 - On premature code reuse... 21:10 - Be Lazy! / Number of git repos as a proxy for complexity. 23:15 - Timelines are good and force you to ship and get feedback. 25:00 - Silly things engineers do in the name of good code. 26:50 - Picks: Dave - Goole Chrome plugin proposal and a huge digression into privacy and ads Brandon - Bad Blood: Secrets and Lies in a Silicon Valley Startup Matt M. - The Idea Factory: Bell Labs and the Great Age of American Innovation Matt D. - Zeit Now Ian - Tab Soda

Iniziamo questo primo episodio parlando di alcuni principi di programmazione assolutamente da conoscere: KISS, YAGNI e DRY.Concetti chiave che stanno alla base della scrittura del *buon codice*.Articoli della settimana:HttpRepl: A command-line tool for interacting with RESTful HTTP services * https://devblogs.microsoft.com/aspnet/httprepl-a-command-line-tool-for-interacting-with-restful-http-services/ * https://docs.microsoft.com/en-us/aspnet/core/web-api/http-replUse dependency injection in .NET Azure Functions * https://dev.to/azure/leveraging-the-dependency-injection-support-in-azure-functions-54f8 * https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection

Descubre como escuchar el episodio completo en https://www.danielprimo.io/nivel

In this episode, Jake and Michael are joined by JMac to discuss maintainable code, keeping your Laravel codebase up to date, and more.

W trzydziestym siódmym odcinku tematem będzie kod. Zastanowimy się jaki kod jest czysty i prosty oraz czy zawsze to znaczy to samo. Rozmawiamy o tym czy stosowanie wszystkich znanych wzorców projektowych (DRY, YAGNI, SOLID oraz GRASP) pomaga w tym aby kod był prosty i czysty czy może wręcz przeciwnie? Dodatkowo małą domieszka programowania funkcyjnego oraz matematyki. Miłego słuchania.   Polecamy: Security day - https://www.meetup.com/pl-PL/Poznan-Security-Meetup/events/255244492/ Książki: * Becomig technical leader * Achaja * Virion * re:work * jesteś marką * 4 obsesje wyjątkowego szefa * Dobre Życie Podcasty: * dev:cast - o programowaniu bez kaca * biznes w it - Piotr Bucki Chrzestni: * Konrad Kokosa * Andrzej Bargański * Paweł Dulak * Michał Franc Linki z odcinka: * Konrad Kokosa - Książka * Code smells * hadouken indent * ndepend * sonar qube * OstraPiła o code review * train wrecking pattern * analiza kodu z visual studio * Pan raczy żartować Panie Faynman * Code review guidelines * xor swap * Greg Young - 8 lines of code * odcinek o IOC * nie powinno być user, raczej czytelnik, pasażer, etc * npm - usunięty pad left * jquery - file upload security* konferencja boiling frogs

Safia finds out that she already knew some of the design patterns, but not the name, Adam is confused about the fascade pattern, they talk about DRY, YAGNI, and they get into TDD, and a bit of the Unix philosophy.

This week, Jeffrey and Squirrel help a listener with the role of design and architecture in an agile team. The answer involves arcane-sounding but fun concepts like elephant carpaccio, evolutionary design, and YAGNI. SHOW LINKS: - YAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it - Elephant Carpaccio: http://alistair.cockburn.us/elephant+carpaccio - Evolutionary Design: https://martinfowler.com/tags/evolutionary%20design.html - XP Explained: https://www.barnesandnoble.com/w/extreme-programming-explained-kent-beck/1119347147 - GOOS book: http://www.growing-object-oriented-software.com/ - Sprint zero: https://www.frontrowagile.com/blog/posts/125-sprint-zero-for-product-owners - Trim the tail and order by risk: http://alistair.cockburn.us/Design+as+Knowledge+Acquisition - Up-front design in a previous episode: https://soundcloud.com/troubleshootingagile/enhancing-agility-through-technical-excellence-and-good-design *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: see link on troubleshootingagile.com Tweet us: twitter.com/TShootingAgile Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

We're on to Agile Principle 10 this week: "Simplicity - the art of maximizing the amount of work not done - is essential." In comparison to the dark old days when the Agile Manifesto was written, the way projects are simplified and broken down seems a huge improvement. But simplicity plays an essential role in achieving the all-important first Agile Principle of "satisfying the customer through early and continuous delivery of valuable software," so Squirrel and Jeffrey discuss why this principle is still so important today. They discussed: -How simplicity asks you to exercise discipline and restraint. -How Elephant carpaccio helps to provide an environment in which that restraint is easier. -How simplicity is not just a call for businesses to restrain themselves in their demand for features, but for developers to restrain themselves in their demand for best practices- and how they can employ YAGNI instead. -What YAGNI is. -How to build a whole application's worth of software without actually writing any software. *** SHOWNOTES: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -Alistair Cockburn's brilliant Elephant Carpaccio lesson: http://alistair.cockburn.us/Elephant+carpaccio -What is YAGNI?: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it -Zapier: https://zapier.com/ -IFTTT: https://ifttt.com/ *** We'd love to hear any thoughts, ideas or feedback you have regarding the show. Email us: agile@troubleshootingagile.com Tweet us: twitter.com/TShootingAgile Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2

In der zweiten Episode meiner „Wissenshäppchen“ geht es um ein weiteres wichtiges Prinzip der Softwareentwicklung: You Ain’t Gonna Need It (YAGNI) (alternativ auch You Aren’t Gonna Need It). Wir sollten immer nur das entwickeln, was wir wirklich brauchen! Always implement things when you actually need them, never when you just foresee that you need them.... Der Beitrag You Ain’t Gonna Need It (YAGNI) – Wissenshäppchen #2 erschien zuerst auf IT-Berufe-Podcast.

On today's episode we break down the idea of ‘The Last Responsible Moment'. We talk about the benefits of leaving certain decisions to the latest possible time before finalizing them. Although this might sound like a bad idea and perhaps slightly irresponsible there really are times when only doing what is absolutely necessary at any give point can work in your favor. During this chat we try to figure when that is and when that is not. We also go down the rabbit hole on the concept of ‘You Ain't Gonna Need It', or YAGNI, which is helpful in understanding The Last Responsible Moment. On top of this the chat veers into shaving yaks, Yik Yak and some other things that do not involve yaks. Listen in to hear all about it!

Pain Driven Development Pain Driven Development, or PDD, is the practice of writing software in such a way that you only "fix" problems when they are causing pain, rather than trying to preempt every possible issue. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Many of you have probably heard of various "DD" approaches to writing software. There's TDD, or Test Driven Development. There's BDD, for Behavior Driven Development. In this tip, I want to introduce you to another one, PDD: Pain Driven Development. Pain Driven Development Software development is full of principles, patterns, and best practices. It can be tempting, especially when you've recently learned about a new way of doing things, to want to apply it widely to maximize its benefits. Some time ago, when XML was a new thing, for instance, Microsoft went all-in with it. They decided to "XML ALL THE THINGS" and in some places, this was great. And in many cases, not so much. In my own experience, I find this is often the case when I'm learning a new design pattern or trying to fully understand a particular principle. It can be easy, when you're constantly on the lookout for applications of recent knowledge, to find excuses to apply these techniques. One particular set of principles that many object-oriented programmers know are the SOLID principles. I have a course on SOLID on Pluralsight that I encourage you to check out, which covers these principles in depth. One thing that is worth remembering, though, is that you shouldn't, and honestly can't, apply all of the principles to every aspect of your software. You need to pick your battles. You need to actually ship working software. You don't know when you begin a project where extension is going to be necessary, so you can't anticipate every way in which you might support the Open-Closed Principle for every class or method in your program. Build and ship working software, and let feedback and new requirements guide you when it comes to applying iterative design improvements to your code. When you're back in the same method for the Nth time in the last month because yet another requirement has changed how it's supposed to work, that's when you should recognize the pain your current design is causing you. That's where Pain Driven Development comes into play. Refactor your code so that the pain you're experiencing as a result of its current design is abated. Extreme Programming introduced the concept of YAGNI, or You Ain't Gonna Need It. PDD is closely aligned with this concept. YAGNI cautions against building things you might need in the application, and instead favors building only what's required today (but in a responsible manner, so you can revise the design in the future). PDD offers similar guidance, but from a different perspective. The message with PDD is, follow YAGNI and build only what is required today, but recognize when you'll "need it" by the pain the current design causes you as you try to work around/with it. Well-designed code is enjoyable to work with. If you frequently find yourself frustrated with the code you're working with, see if you can identity the source(s) of the pain, and apply refactoring techniques to alleviate the problem. Show Resources and Links Pain Driven Development (PDD) SOLID Principles of OOD Refactoring Fundamentals

Anjali Menon, Head of Growth Operations at Magic, joins me, Jen Spencer to discuss integrations with complementary technologies, listening to data, being honest with your community of partners and more on this episode of The Allbound Podcast. Jen: Hi everybody. Welcome to The Allbound Podcast. I'm Jen Spencer, Vice President of Sales and Marketing here at Allbound. And today, I am joined by Anjali Menon, Head of Growth Operations for Magic. Welcome.   Anjali: Thank you so much. Happy to be here.   Jen: I'm really happy to have you. And I'm excited to talk about your career but, before we get into that, I want to talk a little bit about Magic. Because for all the times I've ever thought, "Man, I wish I just had this like personal assistant." You guys are kind of helping solve that problem for me, right? What's the scoop? Tell me a little bit more about the company.   Anjali: Absolutely. So thank you for having me, first and foremost. And I'm really excited to be here. Magic is a text-based platform that allows you to, just as you said, get personal assistants on demand. So the scope of what you can ask is really sort of infinite. You could ask for things as simple as somebody getting you lunch, to perhaps helping with your office needs and things that are much more grandiose in scale, planning a significant other's birthday party or something like that. But the idea is that you get manpower on-demand to increase your productivity. We launched in 2015, February of 2015. Actually, when it launched, it just went viral. I mean, we had a massive waiting list and it was really validation that people want personal assistants. They want more time in their day.   Jen: Yeah, I'm telling you, it's like as soon as I learned about it, I'm like, "Okay, what should I ask?" Like, "What should I ask for help with?" right? So, it's just such a cool concept. And you're Head of Growth Operations there. What does that entail? I'm starting to see Directors of Growth. I think this I the first time I've seen Growth Operations. What does that mean? What's your role like?   Anjali: Yeah, definitely. It's a really interesting one because we are a growth team, first and foremost. But because we interface with operations so closely, just by nature of the work that we do, we're constantly having to fulfill the requests that our clients put in. That's ultimately how we end up with Growth Operations.   So under this umbrella branch of what we call Growth Operations, there's a few sort of subcategories. We've got a sales team, which has historically been focused on sort of inbound leads as a main source of acquisition. Then we've got an activation team that interfaces with our operations team quite frequently to ensure that sort of consistent quality of service. And this team is critical because Magic's end product is ultimately defined by the user. You tell us what you want and we deliver it. So the activation has to be really customized. And that's in part where a lot of the operations work comes in with growth. And then the third piece which is pretty nascent in its start, but we now have a B2B and partnerships team as well, so those are kind of the three.   Jen: So let's let's dig into that a little bit, you're just getting started with it, but when you think about the plans, this go-to-market strategy for Magic, how important do you believe those strategic partnerships are going to be in your success? What kind of plans do you have in the works?   Anjali: This is such an interesting question because partners can add so much value to our type of business. But it's really a matter of finding the right fit because Magic has so many complexities. You can ask for anything as simple as lunch to something as complex as carrying out a whole sale cycle for a business using Magic. So because it runs the gamut of things that you can do, we really have to evaluate what partners make sense for us. But for Magic, like many other businesses, I think success for our customers comes in the form of efficiency gains, obviously, cost savings, and value-add. And partners can add all of these things.   Some examples of partners that we're exploring right now are things like verticalized partnerships. So, if we can sit on top of other services that already have domain expertise, it's a win-win for us, i.e., if I already can use a cleaning service that I know is good and I can just recommend that to my clients, then I'm saving them and us time by doing so.   Other sorts of partners that are interesting for us are ones that sort of epitomize our values. We have two really interesting values at Magic. Yet, their concepts that are sort of known in the startup community but I'm not sure how widely they're known beyond that. And the two concepts are called yagni and plow.   Yagni is a term that means “you ain't gonna need it.” It's one of those things that in the startup community, people will say it all the time. But it's a term that really signifies when we work with you, we want a partnership that understands that we're working under constraints, and you understand that, and I understand that. And we don't go build things that we don't really need at the moment. We'll build them when it's absolutely necessary. So that's something that we might look for as a value in terms of partnerships. And then this other concept is plow, which you'll hear almost every day in our office. And that's a concept, particularly for a personal assistant kind of concierge company, it's the concept that you don't give up. You keep plowing to make sure that whatever the client wants, you try to get. And so we would hope that our partners sort of share those values as well, maybe on these sales or affiliate side for example.   So really, I think partnerships are key for us, but they need to align strategically both in what we're doing as well as what our clients needs, as well as, finally, what the partners themselves need. And the reason I emphasize this is because when we went viral two years ago, we had major, major brands coming to us, asking us to do partnerships with them. And we turned most of them down. And the reason is, we had to sort of be true to what our capabilities were, and you've got to be honest with what you can deliver and what the partner expects. And so at that point, we hadn't even really figured out who was our right customer profile and did this major brand make sense for what we were doing. Just because they're a major brand doesn't mean they're a good partner for you. So, I know that's a long-winded answer, but I think, in short, partners are very, very useful particularly for our business. But I think that the key is really making sure that there's alignment on both sides for what that partner can do.   Jen: It's very, very sage advice. And it can be very tempting for organizations to just bring on those partners that have me with those big brands. But, if there's not that alignment...and especially for a very quickly growing young company, you got to have that focus, right? So, I think what you're saying you guys are doing is you're definitely going down the right path. I absolutely love hearing it. And those strategic partnerships just make perfect sense.   How about integrations? Are you looking at other complementary technologies as a way that they might play a role in your growth goals? One of the things I'm thinking about, just kind of off the top of my head is like different apps I might be in on a regular basis like Postmates for delivering food or supplies or what have you. I mean, are you thinking about technology, and in that respect, for partnership?   Anjali: Totally. So, this is such a great question for two reasons. One is because we actually just launched a Magic version for Slack. So this Magic-Slack integration allows teams and businesses to more easily and more transparently use Magic as kind of like an office manager. So Slack has been really useful for us as the first step to growing our business in sort of a different category. And so, I think when we think about these partnerships, for example, I sort of alluded to value being very similar. Slack is one whose whole value prop is to increase productivity with teams, and we have a very similar value prop, it's a Productivity Tool. So there's synergy here. And if we can reach more of our target audience through a medium that allows teams to interact more collaboratively like Slack, that's exactly the kind of thing that's good for our business but even better for our clients. So Slack is the major one that we've been focused on.   You kind of alluded to Postmates. And that's a whole other category of sort of partnerships that we'd also be thinking about. Basically these other sorts of niche services that we can kind of sit on top of or that they can kind of sit on top of us, either way. And we can just kind of use them as our clients come in and say, "Hey, I need a burrito." well, the fastest way to do that is through DoorDash or Postmates or something like that. So those are the other kinds of partnerships that we would look at as well. And so, absolutely. That's definitely something that increases productivity and efficiency for us.   Jen: I know I can speak on behalf of the Allbound #AllStars, we try to make Slack do everything. So we try to run our whole business through Slack. Things that are important and all of the shenanigans as well.   Anjali: That's awesome. Well, what's interesting is with the Slack integration, we're finding different use cases for Magic just by virtue of being on a different platform other than text. Because when you're suddenly on a platform that allows for different teams to interact with one Magic as if they were an office manager suddenly Magic becomes the office manager, and it's booking appointments for people, it's bringing vaccines on campus, it's booking team outings, and suddenly the use cases are becoming very different in the way that they interact with Magic is different too, just by virtue of the platform. So it's actually a key growth initiative for us to be thinking about these other kinds of platforms, because they increase the ways in which folks use Magic, increasing their own productivity. But it's also, of course, then expanding the reach of who can use us as well, which is really good for both sides.   Jen: I want to ask you a little bit about some of your past experience. Before you were at Magic, I know you were at Twitter. Before that, you led marketplace operations at TaskRabbit. And marketplaces and partnerships and communities of engagement, there's a lot of similarities there. And you helped launch the TaskRabbit Elite Program. So, let me know how did that concept for that program come about originally? And I'd love any feedback on how it helped really grow the company since its inception.   Anjali: Definitely. So, I am proud to say that the TaskRabbit Elite Program still exist today. So when you go to TaskRabbit, despite the business model having changed from one that was traditionally like a bidding system to one that's now more automated with algorithms, the TaskRabbit Elite Program's still maintained. And the reason is because it actually does really impact the business goals and growth.   The reason it came about was mostly for two sides. And it's two sides in parts because TaskRabbit is a two-sided marketplace. So, on the client side, when we were back in the bidding system, clients would put in a request for something like, "Hey, I need a cleaner." And it was possible that hundreds of taskers could bid on those requests. And clients would sort of face this paradox of choice kind of paralysis because they wouldn't know who to choose.   And so, the concept of the TaskRabbit Elite for clients specifically was, can we give them a sort of value set that allows clients to choose who is the right TaskRabbit for me for this particular job set? And then, on the Tasker side, on the community side, which was the side that I was most closely involved with, we had never created a systematic, defined program that really supported workers in the sharing economy. It was not something we had done formally. And so this was our first attempt to say, "Hey, there are a lot of people hustling on this platform to make it a great one. We should reward them in some way." And so for folks who delivered, who had great ratings, who consistently performed, we thought this is a great way to reward them and get their earnings up by showcasing their work more to the right kinds of people.   Similarly, it also helped new Taskers sort of ingratiate themselves on the platform because now new Taskers had a sort of defined path towards something that they could work to. And so, it was possible that within a month of becoming a new Tasker, you could actually become an Elite TaskRabbit when I launched this thing. And so, it motivated a lot of newer TaskRabbits to do a lot of work and get promoted and get more work. So ultimately, it was kind of a win-win for both sides. On the tasking community, it supported them by giving them more visibility and giving them more work. And on the client side, it helped them narrow their choice to the right Tasker for their job.   And ultimately, we switched the whole model to actually emphasize that specific point, finding the right Tasker for your job. So now, if you go to TaskRabbit, nobody's bidding anymore. You're just sort of shown the right TaskRabbits for you and you just pick the one that's good for you. It's a much easier process now but that concept really sort of originated with that Tasker Elite program. And the reason it exists today, again, is because both of those sides of the community are still served in the same purpose.   So it's been something that was strategic for the company. It ended up ultimately making Taskers more money, which is why we kept going with the program because it was giving them more money and was giving them more incentives to get more work on the platform. And so, yeah, it's something that I'm really proud of because it allowed us to build a community in a way that was very positive for both sides.   Jen: To take sort of a page out of Tiffany Bova's book, she talks about making your customer the true north, like the center of your universe, right? And in every decision that you make in your business, like thinking about it from the perspective of that customer. What's going to be best for that customer? Because people ask, "Should I sell directly? Should I sell online? Should I sell through channel partners? Should I do X, Y or Z?" And the answer should be, well how does your customer want to...right? How do they want to buy? How do they want to be served? What's going to be best for them? And ultimately, if you do what's going to be best for them, that will end up being best for the business and for all the business partners that are part of that ecosystem.   Anjali: Exactly.   Jen: So, it's great to hear.   Anjali: A quick side note on that. We actually spotted the problem of clients not getting what they wanted and not identifying the North Star through data. Because I think folks don't know this, but the reason TaskRabbit changed their model is because a lot of tasks were being put into the system, that is to say, clients were asking for things to be done, but then they weren't always choosing TaskRabbit to get them done. And the reason was in part because of bids. It was because a lot of TaskRabbits could put in bids and then people would get so overwhelmed that we would see this long-tailed distribution of tasks that got bids, but then the client didn't do anything with them. So this effort was to give them exactly what you said, that North Star.   Jen: We talked to a lot of people, and they're building partner programs, whether they're reseller programs, referral partners, affiliates. But they're not just trying to build a program just to get leads or just for top of funnel. They're really looking, "How can I build a true community for my partner ecosystem?" Maybe it's to get partners collaborating with each other, or to get partners and customers collaborating to get shared visibility and really a shared experience. And I'm just wondering, over the course of your career, whether you want to speak to something from being at Twitter or TaskRabbit or even at Magic now, do you have any advice for people who are setting out to attempt to create a community?   Anjali: Yeah, definitely. That's such a cool question because I look at building communities or partner communities or whatever form of community you're building, like a two-sided marketplace because that's the background I come from. So the relationship needs to benefit not only your clients but the partners themselves. So for a business like Magic, that's so dynamic where the scope of what we offer is pretty much sky's the limit, we in particular need partners who understand this and can be flexible enough to work within the constraints of that model. So I would really say for folks who are interested in building this kind of community, define and qualify the ideal folks in the community and how do they fit into what you're building?   Because if you can't define that, then you're not in a good position to set up the community and your partners for success. And I think, and again this is what I alluded to earlier, but when we had major brands coming to us, we didn't even know who was a good partner for us and who were our right customers. But now we're in so much of a better position to do that, so we can start thinking about that. So definitely being able to understand who those right partners are for your community is key. The other thing I would say is honesty is everything, be honest with your community of partners. Because then, the expectations are set correctly. Don't over play your capabilities because you think that's what your partners want to hear. You are the partner in the partnership, and for it to work, I think really, really being able to transparently lay out the scope of what you can do, why you're doing it, and why it's important as it relates to your values are all very key. So that would be sort of my best advice.   Jen: I think that's some really great advice and such a great way to wrap this up. But before I let you go, I always ask some more personal questions just so folks can get to know you a little bit better. You shared so much awesome stuff with us today, but I'm going to dig in a little bit more if you're up for it.   Anjali: I am, of course.   Jen: Okay. So easy questions. First one is what is your favorite city?   Anjali: Oh, okay, Cape Town, South Africa.   Jen: Oh, I have not heard that one yet. So why is that your favorite city? Tell me.   Anjali: So, I'm somebody who loves to travel. And I think that when you travel, you can often find places that you can call home, that are often not your true home. And you just know it when you're there. And so when I went to South Africa, I immediately felt this sense of home. Because South Africa is a lot like San Francisco, where I'm from, in the sense of scenery is very beautiful, there's a lot of nature, Table Mountain, a lot of ocean. People love surfing over there, but then the culture was also just very, very friendly and people were very welcoming. And I also love animals and wildlife. So being surrounded by all of that with a very sort of gracious culture, it felt like home. So that's my favorite city.   Jen: Well, you kind of hinted at my next question. Are you an animal lover?   Anjali: Yeah, I am.   Jen: Do you have any pets?   Anjali: I grew up with two dogs, Larry and Lucky. One was a German Shepherd and one was a tiny little Pomeranian. And they were best friends. But no, I do love animals. So South Africa made sense.   Jen: Great. Next question, Mac or PC?   Anjali: Mac.   Jen: And my last question, if I was able to offer you an all-expenses-paid trip, where would it be to?   Anjali: Well, the next place that I want to go to is Iceland. Because I'm a nature lover. I love exploring. And tickets are cheap right now so it wouldn't cost you too much probably.   Jen: Remember, this is a magic land where I have all the money in the world and I can send you anywhere you want to go. But I appreciate you thinking about me.   Anjali: Well, in that case, I probably just need the money, still in Iceland, but I'd probably go on some kind of luxury retreat, looking at the Northern Lights or something like that. But yeah, I think if we had all the money in the world, the place would be Iceland.   Jen: All right. Awesome. I love the practical fantasy, it's fantastic. Well, I just want to thank you again. Thank you for sharing some of your time with me and our listeners today. If anyone would like to reach out to you personally, what's the best way for them to connect with you?   Anjali: Sure. So they can connect with me via email and it's just 0-7, my first name and my last name. So that's Anjali Menon @gmail.com. I can spell that out as well, would that be helpful?   Jen: Sure, sure.   Anjali: Okay. So it's 0-7-A-N as in "Nancy" J-A-L-I as an "igloo" M-E-N as in "Nancy" O-N as in "Nancy" at gmail.com. So that's 07anjalimenon@gmail.com.   Jen: Perfect. Well, it's been great getting a chance to learn a little bit more about you and talking about partnerships and communities. So, thank you so much.   Anjali: Thank you for having me.   Jen: Yeah. Absolutely, absolutely. And thanks, everyone else for tuning in and we'll be back next week with an all-new episode.   Male Announcer: Thanks for tuning into The Allbound Podcast. For past episodes and additional resources, visit the resource center at allbound.com. And remember, never sell alone.

After a hiccup that led to having to re-record the first five minutes of the show, Jake and Michael talk about manually updating Laravel apps and the virtues of doing so regularly, a brief outburst on politics, and comparing modern JavaScript frameworks with legacy jQuery.

We start off this week following up on Protocol Oriented Programming, CarPlay receivers and the iCloud Calendar bug. We discuss Kickstarter's move to open source their IOS and Android apps. Air Pods are available for order and instantly backordered. We also cover Issues with MacBook Pro battery issues and Apple's reaction. Jaime discusses his newly acquired Google Home. Picks: Apple Support app, The Twist, Dongle Dangler and TouchBar Piano. Episode 123 Show Notes YAGNI Architecture Astronauts second-system effect How to Avoid Protocol Orientation Obsessed Programming PromiseKit Sony XAV-AX100 Car AV Receiver with Apple CarPlay & Android Auto™ CarPlay After Market Systems tunein.com Radio Apple rolling out ‘Report Junk’ feature for iCloud Calendar invites from unknown senders to address spam Apple offering AirPods battery replacements for free under warranty, $49 without Open sourcing our Android and iOS apps! Artsy Actions on Google Eliza example on GitHub Cortana to open up to new devices and developers with Cortana Skills Kit and Cortana Devices SDK Why Apple is removing ‘time remaining’ battery life estimates following MacBook Pro complaints New MacBook Pro Users Report Improved Battery Life on macOS 10.12.2 Uberless - A video purportedly shows a driverless Uber running a red light in San Francisco. Episode 123 Picks Apple Support by Apple The “Twist” ‘Dongle Dangler’ Kickstarter project aims to help you keep track of your 3.5mm headphone adapter Touch Bar Piano

Jacob and Michael catch up for the first time since returning from Laracon, discussing some of their favourite parts, talks, and memorable parts of the three-day event.

In this mini Fragment, Donn talks about one of his favorite topics, YAGNI. YAGNI is an acronym that stands for "You Arent Going To Need It". Donn explains what it is, why its useful and shares a personal story of how he was introduced to the YAGNI concept back in 2008.

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

02:48 - Jim Gay Introduction Twitter GitHub Blog Ruby DSL Handbook 03:43 - Object Design Clean Ruby SOLID Principles 04:39 - DCI (Data, Context, Interaction) Main Resource for DCI (FullOO) 07:20 - What Painpoint DCI Aims to Solve The Gang of Four Book object-composition Mailing List (Google Group) 09:31 - Designing From DCI From the Start (Process) Levels of Use Cases Writing Effective Use Cases by Alistair Cockburn 11:42 - Object Composition Single Responsibility Principle 13:56 - Definitions: Forwarding, Delegation, Consultation, and Inheritance Class-Based Inheritance vs Prototype-Based Inheritance JavaScript Influence 18:37 - DCI and Service Objects Context 24:36 - Roles and Object Factoring Authentication 28:49 - One Context in a Single File surrounded 30:17 - Coupling and Cohesion 31:37 - Typeclasses 33:09 - DCI Criticism casting 36:51 - The Current State of DCI (Skepticism & Criticism?) Domain-Driven Design 38:56 - Preventing Reuse 41:18 - When should you not use DCI? 43:45 - Transition: Using/Undoing DCI (Experimentation) 45:04 - Resources fulloo.info Marvin object-composition Mailing List (Google Group) Clean Ruby More DCI Blog Posts by Jim Delegation Is Everything And Inheritance Does Not Exist Chubby Models Are Still Fat With Concerns. DCI Focuses On How Things Work Together The Gang Of Four Is Wrong And You Don't Understand Delegation Triggering The DCI Context OOP, DCI And Ruby - What Your System Is Vs. What Your System Does 4 Simple Steps - Extending Ruby Objects - The Tip Of The Iceberg With DCI Picks Richard Hamming: You and Your Research (Jessica) Martin Fowler: Yagni (Coraline) Ruby Monday (Saron) JunkFill (Saron) Wappalyzer (Saron) WhatFont (Saron) Julian Feliciano: What Is Source Control? (Saron) Bodum Santos Stovetop Glass Vacuum 34-Ounce Coffee Maker (Avdi) The Master and His Emissary: The Divided Brain and the Making of the Western World by Iain McGilchrist (Jim) request_store_rails (Jim) littleBits (Jim)

Join Mark, Greg, and new co-host Peter as we discuss Language Productivity and Estimation. Productivity Using Scala will make you less productive - Is Productivity King? There are many more things in “development” which will lower your productivity than the language you eventually implement the solution in. I (Mark) think I made the comment I've never seen scala as being "a more productive language", but a more flexible, adaptable, etc. language which may lead to more productivity, but productivity is WAY more the sum of intangible parts of development How do you measure productivity in a language, and when should you expect to get results, e.g. 6 months, 1 year, 2 years - 5 years? Is there a correlation between small, modular, artifacts and static typing? does having a contract get better with smaller service ( even if generic type contracts ) Is static typing a fractal cost on your code base. The better you write your code the more cost you incur? Static typing suits large method and class as you pay the tax less times? How do you determine the productivity of a new language? Statically typed javascript (typescript) Estimation How does switching languages affect how you handle time estimates? How do you handle time estimates in general? (Mark) I’ve often seen it said rather than just estimate how long it will take, estimate how long it will take Person X to do it ( if they’re doing the work, taking into account things you know about their productivity/skill level/work load etc.) - you may know Clojure/Scala well, but with DevY is to do the work and not yet fully up to skill with the toolset..... Development estimates are only accurate if you are maintaining velocity. What error margin and corrective multiplier is reasonable? What methods of estimate generation are good? Planning poker can be slow, but can be a great method of generating estimates. Function Point Calculations as a confirmation guideline How far out do you estimate, and how does YAGNI play into this.

At the MVP Summit, Carl and Richard talk to Steve Smith about the Software Craftmanship calendar. While filled with good messages like Separating Concerns and YAGNI, it also has hilarious images of why you should follow these principles. The conversation digs into each of the topics with different ideas and approaches to being successful. A fun Thursday show!Support this podcast at — https://redcircle.com/net-rocks/donations

Обсуждаем увиденное на презентации от Google. Появление их браузера на iOS. Говорим о важности наличия здравого смысла у программиста и о некоторых базовых принципах, которые он должен знать. Клавиатуры и метод слепой печати: наш опыт. В выпуске: - Новинки Google I/O: Android 4.1, планшет Nexus 7 и очки дополненной реальности. - Google Chrome for iOS всем! - Я знаю DRY, KISS, YAGNI, SOLID и еще кучу непонятных слов. - Какими клавиатурами мы пользуемся и как набираем код. Голоса подкаста: Антон Сергеев (hackPNZ) Слава Федотов (fe.off) Антон Копылов Ссылки: - А гуглхром-то не настоящий! - Механические клавиатуры Podsafe: J.1.0 - Frozen Paradise

At the MVP Summit, Carl and Richard talk to Steve Smith about the Software Craftmanship calendar. While filled with good messages like Separating Concerns and YAGNI, it also has hilarious images of why you should follow these principles. The conversation digs into each of the topics with different ideas and approaches to being successful. A fun Thursday show!Support this podcast at — https://redcircle.com/net-rocks/donations