Podcasts about fizzbuzz

Join Chris and Austin in this episode of The Mob Mentality show as they explore the captivating world of code katas with special guest Steve Kuo. Uncover the secret behind the reigning king of them all: FizzBuzz. Delve into a conversation about deliberate practice, motivation, grit, and feedback. Discover the art of becoming a master in any field and unravel the immense value of repetition and focus. Explore the concept of how much repetition is necessary for mastery and whether it can have a negative impact on team motivation. Brace yourself for tales of katas gone wrong and the common misunderstandings surrounding code katas. Gain insight into the key mindset required for successful katas and learn the importance of starting with the question, "What am I going to practice today?" Dive into the world of pair, mob, and collaborative katas, and understand their significance in honing your skills. But why is FizzBuzz hailed as the best code kata around? Unearth its remarkable versatility as a tool not only for learning programming languages but also for grasping design patterns and daily warmups. Discover how FizzBuzz can even teach you the art of ensemble and serve as a psychological safety tool. Explore the connection between grit and craftsmanship, and contemplate the question: "Are you what you do when no one is watching?" Uncover the intriguing phenomenon of semantic diffusion within the world of craftsmanship and how it influences our perception of skill. Lastly, Steve ends with a teaser on the six-minute interview. Tune in to this episode and immerse yourself in the magic of FizzBuzz and the transformative power of deliberate practice. Video and Show Notes: https://youtu.be/tCXwUJTvo6I 

About BrandonBrandon West was raised in part by video games and BBSes and has been working on web applications since 1999. He entered the world of Developer Relations in 2011 as an evangelist for a small startup called SendGrid and has since held leadership roles at companies like AWS. At Datadog, Brandon is focused on helping developers improve the performance and developer experience of the things they build. He lives in Seattle where enjoys paddle-boarding, fishing, and playing music.Links Referenced: Datadog: https://www.datadoghq.com/ Twitter: https://twitter.com/bwest TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate. Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other; which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io/screaminginthecloud. Observability: it's more than just hipster monitoring.Corey: This episode is sponsored in part by our friends at Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone I've been trying to get on the show for years, but I'm very bad at, you know, following up and sending the messages and all the rest because we all struggle with our internal demons. My guest instead struggles with external demons. He is the team lead for developer experience and tools advocacy at what I can only assume is a Tinder for Pets style company, Date-A-Dog. Brendon West, thank you for joining me today.Brandon: Hey, Corey, thanks for having me. I'm excited to be here. Finally, like you said, it's been a couple of years. But glad that it's happening. And yeah, I'm on the DevRel team at Datadog.Corey: Yes, I'm getting a note here in the headset of breaking news coming in. Yes, you're not apparently a dog dating company, you are a monitoring slash observability slash whatever the cool kids are calling it today telemetry outputer dingus nonsense. Anyone who has ever been to a community or corporate event has no doubt been tackled by one of the badge scanners that you folks have orbiting your booth, but what is it that you folks do?Brandon: Well, the observability, the monitoring, the distributed tracing, all that stuff that you mentioned. And then a lot of other interesting things that are happening. Security is a big focus—InfoSec—so we're adding some products around that, automated security monitoring, very cool. And then the sort of stuff that I'm representing is stuff that helps developers provide a better experience to their end-users. So, things like front-end monitoring, real-time user monitoring, synthetic testing of your APIs, whatever it might be.Corey: Your path has been somewhat interesting because you—well, everyone's path has been somewhat interesting; yours has been really interesting because back in 2011, you entered the world of developer relations, or being a DevReloper as I insist on calling it. And you were in a—you call it a small startup called SendGrid. Which is, on some level, hilarious from my point of view. I've been working with you folks—you folks being SendGrid—for many years now. I cared a lot about email once upon a time.And now I send an email newsletter every week, that deep under the hood, through a couple of vendor abstraction layers is still SendGrid, and I don't care about email because that's something that I can pay someone else to worry about. You went on as well to build out DevRel teams at AWS. You decided okay, you're going to take some time off after that. You went to a small scrappy startup and ah, nice. You could really do things right and you have a glorious half of the year and then surprise, you got acquired by Datadog. Congratu-dolances on that because now you're right back in the thick of things at big company-style approaches. Have I generally nailed the trajectory of the past decade for you?Brandon: Yeah, I think the broad strokes are all correct there. SendGrid was a small company when I joined, you know? There were 30 of us or so. So, got to see that grow into what it is today, which was super, super awesome. But other than that, yeah, I think that's the correct path.Corey: It's interesting to me, in that you were more or less doing developer relations before that was really a thing in the ecosystem. And I understand the challenge that you would have in a place like SendGrid because that is large-scale email sending, transactional or otherwise, and that is something that by and large, has slipped below the surface level of awareness for an awful lot of folks in your target market. It's, “Oh, okay, and then we'll just have the thing send an email,” they say, hand-waving over what is an incredibly deep and murky pool. And understanding that is a hard thing requires a certain level of technical sophistication. So, you started doing developer relations for something that very clearly needed some storytelling chops. How did you fall into it originally?Brandon: Well, I wanted to do something that let me use those storytelling chops, honestly. I had been writing code at an agency for coal mines and gold mines and really actively inserting evil into the world, power plants, and that sort of thing. And, you know, I went to school for English literature. I loved writing. I played in thrash metal bands when I was a kid, so I've been up on stage being cussed at and told that I suck. So I—Corey: Oh, I get that conference talks all the time.Brandon: Yeah, right? So, that's why when people ask me to speak, I'm like, “Absolutely.” There's no way I can bomb harder than I've bombed before. No fear, right? So yeah, I wanted to use those skills. I wanted to do something different.And one of my buddies had a company that he had co-founded that was going through TechStars in Boulder. SendGrid was the first accelerator-backed company to IPO which is pretty cool. But they had gone through TechStars in 2009. They were looking for a developer evangelist. So, SendGrid was looking for developer evangelist and my friend introduced me said, “I think you'd be good at this. You should have a conversation.” My immediate thought was what the hell is a developer evangelist?Corey: And what might a SendGrid be? And all the rest. Yes, it's that whole, “Oh, how do I learn to swim?” Someone throws you off the end of the dock and then retrospect, it's, “I don't think they were trying to teach me how to swim.” Yeah. Hindsight.Brandon: Yeah. It worked out great. I will say, though, that I think DevRel has been around for a long time, you know? The title has been around since the original Macintosh at Apple in 1980-ish. There's a whole large part of the tech world that would like you to think that it's new because of all the terrible things that their DevRel team did at Microsoft in the late-90s.And you can go read all about this. There were trials about it. These documents were released to the public, James Plamondon is the lead architect of all of this nastiness. But I think there was then a concerted effort to memory-hole that and say, “No, DevRel is new and shiny.” And then Google came along and said, “Well, it's not evangelism anymore. It's advocacy.”Corey: It's not sysadmin work anymore. It's SRE. It's not on-prem, it's Sparkling Kubernetes, et cetera, et cetera.Brandon: Yeah, so there's this sense in a lot of places that DevRel is new, but it's actually been around a long time. And you can learn a lot from reading about the history and understanding it, something I've given a talk on and written a bit about. So.Corey: My philosophy around developer relations for a while has been that in many cases, its biggest obstacle is the way that it is great at telling stories about fantastically complex, deeply technical things; it can tell stories about almost anything except itself. And I keep seeing similar expressions of the same problem again, and again, and again. I mean, AWS, where you worked, as an example: they love to talk about their developer advocates, and you read the job descriptions and these are high-level roles with sweeping responsibilities, broad basis of experience being able to handle things at a borderline executive level. And then they almost neuter the entire thing by slapping a developer advocate title on top of those people, which means that some of the people that would be most effectively served by talking to them will dismiss them as, “Well, I'm a director”—or a VP—“What am I going to do talking to a developer advocate?” It feels like there's a swing and a miss as far as encapsulating the value that the function provides.I want to be clear, I am not sitting here shitting on DevRel or its practitioners, I see a problem with how it [laugh] is being expressed. Now, feel free to argue with me and just scream at me for the next 20 minutes, and this becomes a real short show. But—Brandon: [laugh].Corey: —It'll be great. Hit me.Brandon: No, you're correct in many ways, which makes me sad because these are the same conversations that I've been having for the 11, 12 years that I've been in DevRel now. And I thought we would have moved past this at some point, but the problem is that we are bad at advocating for advocacy. We do a bad job of relating to people about DevRel because we spend so much time worried about stuff that doesn't really matter. And we get very loud voices in the echo chamber screaming about titles and evangelism versus advocate versus community manager, and which department you should report up to, and all of these things that ultimately don't matter. And it just seems like bickering from the outside. I think that the core of what we do is super awesome. And I don't think it's very hard to articulate. It's just that we don't spend the time to do that.Corey: It's always odd to me when I talk to someone like, “Oh, you're in DevRel. What does that mean?” And their immediate response is, “Well, it's not marketing, I'll tell you that.” It's feels like there might be some trauma that is being expressed in some strange ways. I do view it as marketing, personally, and people who take umbrage at that don't generally tend to understand what marketing is.Yeah, you can look at any area of business or any function and judge it by some of the worst examples that we've all seen, but when someone tells me they work in sales, I don't automatically assume that they are sending me horrifyingly passive-aggressive drip campaigns, or trying to hassle me in a car lot. It's no, there's a broad spectrum of people. Just like I don't assume that you're an engineer. And I immediately think, oh, you can't solve FizzBuzz on a whiteboard. No, there's always going to be a broad spectrum of experience.Marketing is one of those awesome areas of business that's dramatically misunderstood a lot. Similarly to the fact that, you know, DevRel can't tell stories, you think marketing could tell stories about itself, but it's still struggles, too, in a bunch of ways. But I do believe that even if they're not one of the same, developer relations and marketing are aligned around an awful lot of things like being able to articulate value that is hard to quantify.Brandon: I completely agree with that. And if I meet someone in DevRel that starts off the conversation by saying that they're not in marketing, then I know they're probably not that great at their job. I mean, I think there's a place of tech hubris, where we want to disrespect anything that's not a hard skill where it's not putting zeros and ones into a chip—Corey: And spoiler, they're all very hard skills.Brandon: [laugh]. Yeah. And so, first off, like, stop disrespecting marketing. It's important; your business probably wouldn't survive if you didn't have it. And second of all, you're not immune to it, right?Like, Heartbleed had a logo and a name for vulnerability because tech people are so susceptible to it, right? People don't just wake up and wait in line for three days for a new iPhone because tech marketing doesn't work, right?Corey: “Oh, tech marketing doesn't work on me,” says someone who's devoted last five years of their life to working on Kubernetes. Yeah, sure it doesn't.Brandon: Yeah exactly. So, that whole perspective is silly. I think part of the problem is that they don't want to invest in learning how to communicate what they do to a marketing org. They don't want to spend the time to say, “Here's how the marketing world thinks, and here's how we can fit into that perspective.” They want to come in and say, “Well, you don't understand DevRel. Let me define DevRel for you and tell you what we do.” And all those sorts of things. It's too prescriptive and less collaborative.Corey: Anytime you start getting into the idea of metrics around how do you measure someone in a developer advocacy role, the answer is, “Well, your metrics that you're using are wrong, and any metrics you use are wrong, and there's no good way to do it.” And I am sympathetic to that. When I started this place, I knew that if I went to a bunch of events and did my thing, good things would happen for the business. And how did I articulate that? Gut feel, but when you own the place, you can do that.Whereas when you are a function inside of another org, inside of another org, and you start looking at from the executive leadership position at these things, it's, “Okay, so let me get this straight. You cost as much as an engineer, you cost as much as that again, in your expenses because you're traveling all the time, you write zero production code, whenever people ask you what it is you do here, you have a very strange answer, and from what we can tell, it looks like you hang out with your friends in exotic locations, give a 15-minute talk from time to time that mentions our name at the beginning, and nothing else relevant to our business, and then you go around and the entire story is ‘just trust me, I'm adding value.'” Yeah, when it's time to tighten belts and start cutting back, is it any wonder that the developer advocacy is often one of the first departments hit from that perspective?Brandon: It doesn't surprise me. I mean, I've been a part of DevRel teams where we had some large number of events that we had attended for the year—I think 450-something—and the director of the team was very excited to show that off, right, you should have seen the CFOs face when he heard that, right, because all he sees is outgoing dollar signs. Like, how much expense? What's the ROI on 450 events?Corey: Yeah, “450 events? That's more than one a day. Okay, great. That's a big number and I already know what we're spending. Great. How much business came out of that?”And that's when the hemming and hawing starts. Like, well, sort of, and yadda—and yeah, it doesn't present well in the language that they are prepared to speak. But marketing can tell those stories because they have for ages. Like, “Okay, how much business came from our Superbowl ad?” “I dunno. The point is, is that there's a brand awareness play, there's the chance to remain top of the mental stack when people think about this space. And over the next few months, we can definitely see there's been a dramatic uptick in our business. Now, how do we attribute that back? Well, I don't know.”There's a saying in marketing, that half of your marketing budget is wasted. Now, figuring out which half will spend the rest of your career, you'll never get even close. Because people don't know the journey that customers go through, not really. Even customers don't often see it.Take this podcast, for example. I have sponsors that I do love and appreciate who say things from time to time on this show. And people will hear it and occasionally will become customers of those sponsors. But very often, it's, “Oh, I heard about that on the podcast. I'll Google it when I get to work and then I'll have a conversation with my team and we'll agree to investigate that.”And any UTM tracking has long since fallen by the wayside. You might get to that from discussions with users in their interview process, but very often, they won't remember where it came up. And it's one of those impossible to quantify things. Now, I sound like one of those folks where I'm trying to say, “Oh, buy sponsorships that you can never prove add value.” But that is functionally how advertising tends to work, back in the days before it spied on you.Brandon: Yeah, absolutely. And we've added a bunch of instrumentation to allow us to try and put that multi-touch attribution model together after the fact, but I'm still not sure that that's worth the squeeze, right? You don't get much juice out. One of the problems with metrics in DevRel is that the things that you can measure are very production-focused. It's how many talks did you give? How many audience members did you reach?Some developer relations folks do actually write production code, so it might be how many of the official SDK that you support got downloaded? That can be more directly attributed to business impact, those sorts of things are fantastic. But a lot of it is kind of fuzzy and because it's production-focused, it can lead to burnout because it's disconnected from business impact. “It's how many widgets did your line produce today?” “Well, we gave all these talks and we had 150,000 engaged developer hours.” “Well, cool, what was the business outcome?” And if you can't answer that for your own team and for your own self in your role, that leads pretty quickly to burnout.Corey: Anytime you start measuring something and grading people based on it, they're going to optimize for what you measure. For example, I send an email newsletter out, at time of this recording, to 31,000 people every week and that's awesome. I also periodically do webinars about the joys of AWS bill optimization, and you know, 50 people might show up to one of those things. Okay, well, from a broad numbers perspective, yeah, I'd much rather go and send something out to those 31,000, folks until you realize that the kind of person that's going to devote half an hour, forty-five minutes to having a discussion with you about AWS bill optimization is far likelier to care about this to the point where they become a customer than someone who just happens to be in an audience for something that is orthogonally-related. And that is the trick because otherwise, we would just all be optimizing for the single biggest platforms out there if oh, I'm going to go talk at this conference and that conference, not because they're not germane to what we do, but because they have more people showing up.And that doesn't work. When you see that even on the podcast world, you have Joe Rogan, as the largest podcast in the world—let's not make too many comparisons in different ways because I don't want to be associated with that kind of tomfoolery—but there's a reason that his advertisers, by and large, are targeting a mass-market audience, whereas mine are targeting B2B SaaS, by and large. I'm not here shilling for various mattress companies. I'm instead talking much more about things that solve the kind of problem that listeners to this show are likely to have. It's the old-school of thought of advertising, where this is a problem that is germane to a certain type of audience, and that certain type of audience listens to shows like this. That was my whole school of thought.Brandon: Absolutely. I mean, the core value that you need to do DevRel, in my opinion is empathy. It's all about what Maya Angelou said, right? “People may not remember what you said, but they'll definitely remember how you made them feel.” And I found that to be incredibly true.Like, the moments that I regret the most in DevRel are the times when someone that I've met and spent time with before comes up to have a conversation and I don't remember them because I met 200 people that night. And then I feel terrible, right? So, those are the metrics that I use internally. It's hearts and minds. It's how do people feel? Am I making them feel empowered and better at their craft through the work that I do?That's why I love DevRel. If I didn't get that fulfillment, I'd go write code again. But I don't get that sense of satisfaction, and wow, I made an impact on this person's trajectory through their career that I do from DevRel. So.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: The way that I tend to see it, too, is that there's almost a bit of a broadening of DevRel. And let's be clear, it's a varied field with a lot of different ways to handle that approach. I'm have a terrible public speaker, so I'm not going to ever succeed in DevRel. Well, that's certainly not true. People need to write blog posts; people need to wind up writing some of the sample code, in some cases; people need to talk to customers in a small group environment, as opposed to in front of 3000 people and talk about the things that they're seeing, and the rest.There's a broad field and different ways that it applies. But I also see that there are different breeds of developer advocate as well. There are folks, like you for example. You and I have roughly the same amount of time in the industry working on different things, whereas there's also folks who it seems like they graduate from a boot camp, and a year later, they're working in a developer advocacy role. Does that mean that they're bad developer advocates?I don't think so, but I think that if they try and present things the same way that you were I do from years spent in the trenches working on these things, they don't have that basis of experience to fall back on, so they need to take a different narrative path. And the successful ones absolutely do.Brandon: Yeah.Corey: I think it's a nuanced and broad field. I wish that there was more acceptance and awareness of that.Brandon: That's absolutely true. And part of the reason people criticize DevRel and don't take it seriously, as they say, “Well, it's inconsistent. This org, it reports to product; or, this org, it reports up to marketing; this other place, it's part of engineering.” You know, it's poorly defined. But I think that's true of a lot of roles in tech.Like, engineering is usually done a different way, very differently at some orgs compared to others. Product teams can have completely different methodologies for how they track and manage and estimate their time and all of those things. So, I would like to see people stop using that as a cudgel against the whole profession. It just doesn't make any sense. At the same time, two of the best evangelist I ever hired were right out of university, so you're completely correct.The key thing to keep in mind there is, like, who's the audience, right, because ultimately, it's about building trust with the audience. There's a lot of rooms where if you and I walk into the room; if it's like a college hackathon, we're going to have a—[laugh], we're going to struggle.Corey: Yeah, we have some real, “Hello fellow kids,” energy going on when we do that.Brandon: Yeah. Which is also why I think it's incredibly important for developer relations teams to be aware of the makeup of their team. Like, how diverse is your team, and how diverse are the audiences you're speaking to? And if you don't have someone who can connect, whether it's because of age or lived experience or background, then you're going to fail because like I said that the number one thing you need to be successful in this role is empathy, in my opinion.Corey: I think that a lot of the efforts around a lot of this—trying to clarify what it is—some cases gone in well, I guess I'm going to call it the wrong direction. And I know that sounds judgy and I'm going to have to live with that, I suppose, but talk to me a bit about the, I guess, rebranding that we've seen in some recent years around developer advocates. Specifically, like, I like calling folks DevRelopers because it's cutesy, it's a bit of a portmanteau. Great. But it's also not something I seriously suggest most people put on business cards.But there are people who are starting to, I think, take a similar joke and actually identify with it where they call themselves developer avocados, which I don't fully understand. I have opinions on it, but again, having opinions that are not based in data is something I try not to start shouting from the rooftops wherever I can. You live in that world a lot more posted than I do, where do you stand?Brandon: So, I think it was well-intentioned and it was an attempt to do some of the awareness and brand building for DevRel, broadly, that we had lacked. But I see lots of problems with it. One, we already struggle to be taken seriously in many instances, as we've been discussing, and I don't think we do ourselves any favors by giving ourselves cutesy nicknames that sort of infantilize the role like I can't think of any other job that has a pet name for the work that they do.Corey: Yeah. The “ooh-woo accounting”. Yeah, I sort of don't see that happening very often in most business orgs.Brandon: Yeah. It's strange to me at the same time, a lot of the people who came up with it and popularized it are people that I consider friends and good colleagues. So hopefully, they won't be too offended, but I really think that it kind of set us back in many ways. I don't want to represent the work that I do with an emoji.Corey: Funny, you bring that up. As we record this through the first recording, I have on my new ridiculous desktop computer thing from Apple, which I have named after a—you know, the same naming convention that you would expect from an AWS region—it's us-shitpost-one. Instead of the word shit, it has the poop emoji. And you'd be amazed at the number of things that just melt when you start trying to incorporate that. GitHub has a problem with that being the name of an SSH key, for example.I don't know if I'll keep it or I'll just fall back to just spelling words out, but right now, at least, it really is causing all kinds of strange computer problems. Similarly, it causes strange cultural problems when you start having that dissonance and seeing something new and different like that in a business context. Because in some cases, yeah, it helps you interact with your audience and build rapport; in many others, it erodes trust and confidence that you know what you're talking about because people expect things to be cast a certain way. I'm not saying they're right. There's a shitload of bias that bakes into that, but at the same time, I'd like to at least bias for choosing when and where I'm going to break those expectations.There's a reason that increasingly, my Duckbillgroup.com website speaks in business terms, rather than in platypus metaphors, whereas lastweekinaws.com, very much leans into the platypus. And that is the way that the branding is breaking down, just because people expect different things in different places.Brandon: Yeah and, you know, this framing matters. And I've gone through two exercises now where I've helped rename an evangelism team to an advocacy team, not because I think it's important to me—it's a bunch of bikeshedding—but it has external implications, right? Especially evangelism, in certain parts of the world, has connotations. It's just easier to avoid those. And how we present ourselves, the titles that we choose are important.I wish we would spend way less time arguing about them, you know, advocacy has won evangelism, don't use it. DevRel, if you don't want to pick one, great. DevRel is broader umbrella. If you've got community managers, people who can't write code that do things involving your events or whatever, program managers, if they're on your team, DevRel, great description. I wish we could just settle that. Lots of wasted air discussing that one.Corey: Constantly. It feels like this is a giant distraction that detracts from the value of DevRel. Because I don't know about you, but when I pick what I want to do next in my career, the things I want to explain to people and spend that energy on are never, I want to explain what it is that I do. Like I've never liked those approaches where you have to first educate someone before they're going to be in a position where they want to become your customer.I think, honestly, that's one of the things that Datadog has gotten very right. One of the early criticisms lobbed against Datadog when it first came out was, “Oh, this is basically monitoring by Fisher-Price.” Like, “This isn't the deep-dive stuff.” Well yeah, but it turns out a lot of your buying audience are fundamentally toddlers with no visibility into what's going on. For an awful lot of what I do, I want it to be click, click, done.I am a Datadog customer for a reason. It's not because I don't have loud and angry opinions about observability; it's because I just want there to be a dashboard that I can look at and see what's working, what's not, and do I need to care about things today? And it solves that job admirably because if I have those kinds of opinions about every aspect, I'm never going to be your customer anyway, or anyone's customer. I'm going to go build my own and either launch a competitor or realize this is my what I truly love doing and go work at a company in this space, possibly yours. There's something to be said for understanding the customer journey that those customers do not look like you.And I think that's what's going on with a lot of the articulation around what developer relations is or isn't. The people on stage who go to watch someone in DevRel give a talk, do not care, by and large, what DevRel is. They care about the content that they're about to hear about, and when the first half of it is explaining what the person's job is or isn't, people lose interest. I don't even like intros at the beginning of a talk. Give me a hook. Talk for 45 seconds. Give me a story about why I should care before you tell me who you are, what your credentials are, what your job title is, who you work for. Hit me with something big upfront and then we'll figure it out from there.Brandon: Yeah, I agree with you. I give this speaking advice to people constantly. Do not get up on stage and introduce yourself. You're not a carnival hawker. You're not trying to get people to roll up and see the show.They're already sitting in the seat. You've established your credibility. If they had questions about it, they read your abstract, and then they went and checked you out on LinkedIn, right? So, get to the point; make it engaging and entertaining.Corey: I have a pet theory about what's going on in some cases where, I think, on some level, it's an outgrowth of an impostor-syndrome-like behavior, where people don't believe that they deserve to be onstage talking about things, so they start backing up their bona fides to almost reassure themselves because they don't believe that they should be up there and if they don't believe it, why would anyone else. It's the wrong approach. By holding the microphone, you inherently deserve to hold the microphone. And go ahead and tell your story. If people care enough to dig into you and who you are and well, “What is this person's background, really?” Rest assured the internet is pretty easy to use these days, people will find out. So, let them do that research if they care. If they don't, then there's an entire line of people in this world who are going to dislike you or say you're not qualified for what it is you're doing or you don't deserve it. Don't be in that line, let alone at the front of it.Brandon: So, you mentioned imposter syndrome and it got me thinking a little bit. And hopefully this doesn't offend anyone, but I kind of starting to think that imposter syndrome is in many ways invented by people to put the blame on you for something that's their fault. It's like a carbon footprint to the oil and gas industry, right? These companies can't provide you psychological safety and now they've gone and convinced you that it's your fault and that you're suffering from this syndrome, rather than the fact that they're not actually making you feel prepared and confident and ready to get up on that stage, even if it's your first time giving a talk, right?Corey: I hadn't considered it like that before. And again, I do tend to avoid straying into mental health territory on this show because I'm not an—Brandon: Yes.Corey: Expert. I'm a loud, confident white guy in tech. My failure mode is a board seat and a book deal, but I am not board-certified, let's be clear. But I think you're onto something here because early on in my career, I was very often faced with a whole lot of nebulous job description-style stuff and I was never sure if I was working on the right thing. Now that I'm at this stage of my career, and as you become more senior, you inherently find yourselves in roles, most of the time, that are themselves mired in uncertainty. That is, on some level, what seniority leads to.And that's fine, but early on in your career, not knowing if you're succeeding or failing, I got surprise-fired a number of times when I thought I was doing great. There are also times that I thought I was about to be fired on the spot and, “Come on in; shut the door.” And yeah, “Here's a raise because you're just killing it.” And it took me a few years after that point to realize, wait a minute. They were underpaying me. That's what that was, and they hope they didn't know.But it's that whole approach of just trying to understand your place in the world. Do I rock? Do I suck? And it's that constant uncertainty and unknowing. And I think companies do a terrible job, by and large, of letting people know that they're okay, they're safe, and they belong.Brandon: I completely agree. And this is why I would strongly encourage people—if you have the privilege—please do not work at a company that does not want you to bring your whole self to work, or that bans politics, or however they want to describe it. Because that's just a code word for we won't provide you psychological safety. Or if they're going to, it ends at a very hard border somewhere between work and life. And I just don't think anyone can be successful in those environments.Corey: I'm sure it's possible, but it does bias for folks who, frankly, have a tremendous amount of privilege in many respects where I mentioned about, like, I'm a white dude in tech—you are too—and when we say things, we are presumed competent and people don't argue with us by default. And that is a very easy to forget thing. Not everyone who looks like us is going to have very similar experiences. I have gotten it hilariously wrong before when I gave talks on how to wind up negotiating for salaries, for example, because well, it worked for me, what's the problem? Yeah, I basically burned that talk with fire, redid the entire thing and wound up giving it with a friend of mine who was basically everything that I am not.She was an attorney, she was a woman of color, et cetera, et cetera. And suddenly, it was a much stronger talk because it wasn't just, “How to Succeed for White Guys.” There's value in that, but you also have to be open to hearing that and acknowledging that you were born on third; you didn't hit a triple. There's a difference. And please forgive the sports metaphor. They do not sound natural coming from me.Brandon: [laugh]. I don't think I have anything more interesting to add on that topic.Corey: [laugh]. So, I really want to thank you for taking the time to speak with me today. If people want to learn more about what you're up to and how you view the world, what's the best place to find you.Brandon: So, I'm most active on Twitter at @bwest, but you know, it's a mix of things so you may or may not just get tech. Most recently, I've been posting about a—Corey: Oh, heaven forbid you bring your whole self to school.Brandon: Right? I think most recently, I've been posting about a drill press that I'm restoring. So, all kinds of fun stuff on there.Corey: I don't know it sounds kind of—wait for it—boring to me. Bud-dum-tiss.Brandon: [laugh]. [sigh]. I can't believe I missed that one.Corey: You're welcome.Brandon: Well, done. Well, done. And then I also will be hiring for a couple of developer relations folks at Datadogs soon, so if that's interesting and you like the words I say about how to do DevRel, then reach out.Corey: And you can find all of that in the show notes, of course. I want to thank you for being so generous with your time. I really appreciate it.Brandon: Hey, thank you, Corey. I'm glad that we got to catch up after all this time. And hopefully get to chat with you again sometime soon.Corey: Brandon West, team lead for developer experience and tools advocacy at Datadog. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry and insulting comment that is talking about how I completely misunderstand the role of developer advocacy. And somehow that rebuttal features no fewer than 400 emoji shoved into it.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Resuelvo la kata FizzBuzz en JavaScript usando TDD.mail: info@joantolos.comSwag: http://store.joantolos.comOfficial web: http://www.nadanuevobajoelsol.comApple podcast: https://podcasts.apple.com/es/podcast/nada-nuevo-bajo-el-sol/id1563220961Spotify: https://open.spotify.com/show/6BcHhm3wO3cvSIMZL6ssG8

While many languages support laziness in some form, be it by explicit data types or generators, it is not one of the best understood features. In this live coding session, Jan shows you how to solve FizzBuzz using laziness and without any "x divides y" checks – first using Haskell, which is lazy by default, and then we will adapt the solution to work in other languages.   Presenter: Jan van Brügge  

While many languages support laziness in some form, be it by explicit data types or generators, it is not one of the best understood features. In this live coding session, Jan shows you how to solve FizzBuzz using laziness and without any "x divides y" checks – first using Haskell, which is lazy by default, and then we will adapt the solution to work in other languages.   Presenter: Jan van Brügge  

About EmmaEmma Bostian is a Software Engineer at Spotify in Stockholm. She is also a co-host of the Ladybug Podcast, author of Decoding The Technical Interview Process, and an instructor at LinkedIn Learning and Frontend Masters.Links: Ladybug Podcast: https://www.ladybug.dev LinkedIn Learning: https://www.linkedin.com/learning/instructors/emma-bostian Frontend Masters: https://frontendmasters.com/teachers/emma-bostian/ Decoding the Technical Interview Process: https://technicalinterviews.dev Twitter: https://twitter.com/emmabostian TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That's why they created the Jellyfish Engineering Management Platform, but don't you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you're doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part.Corey: This episode is sponsored in part by Liquibase. If you're anything like me, you've screwed up the database part of a deployment so severely that you've been banned from touching every anything that remotely sounds like SQL, at at least three different companies. We've mostly got code deployments solved for, but when it comes to databases we basically rely on desperate hope, with a roll back plan of keeping our resumes up to date. It doesn't have to be that way. Meet Liquibase. It is both an open source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails to ensure you'll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the weird things that I've found in the course of, well, the last five years or so is that I went from absolute obscurity to everyone thinking that I know everyone else because I have thoughts and opinions on Twitter. Today, my guest also has thoughts and opinions on Twitter. The difference is that what she has to say is actually helpful to people. My guest is Emma Bostian, software engineer at Spotify, which is probably, if we can be honest about it, one of the least interesting things about you. Thanks for joining me.Emma: Thanks for having me. That was quite the intro. I loved it.Corey: I do my best and I never prepare them, which is a blessing and a curse. When ADHD is how you go through life and you suck at preparation, you've got to be good at improv. So, you're a co-host of the Ladybug Podcast. Let's start there. What is that podcast? And what's it about?Emma: So, that podcast is just my three friends and I chatting about career and technology. We all come from different backgrounds, have different journeys into tech. I went the quote-unquote, “Traditional” computer science degree route, but Ali is self-taught and works for AWS, and Kelly she has, like, a master's in psychology and human public health and runs her own company. And then Sydney is an awesome developer looking for her next role. So, we all come from different places and we just chat about career in tech.Corey: You're also an instructor at LinkedIn Learning and Frontend Masters. I'm going to guess just based upon the name that you are something of a frontend person, which is a skill set that has constantly eluded me for 20 years, as given evidence by every time I've tried to build something that even remotely touches frontend or JavaScript in any sense.Emma: Yeah, to my dad's disdain, I have stuck with the frontend; he really wanted me to stay backend. I did an internship at IBM in Python, and you know, I learned all about assembly language and database, but frontend is what really captures my heart.Corey: There's an entire school of thought out there from a constituency of Twitter that I will generously refer to as shitheads that believe, “Oh, frontend is easy and it's somehow less than.” And I would challenge anyone who holds that perspective to wind up building an interface that doesn't look like crap first, then come and talk to me. Spoiler, you will not say that after attempting to go down that rabbit hole. If you disagree with this, you can go ahead and yell at me on Twitter so I know where you're hiding, so I can block you. Now, that's all well and good, but one of the most interesting things that you've done that aligns with topics near and dear to my heart is you wrote a book.Now, that's not what's near and dear to my heart; I have the attention span to write a tweet most days. But the book was called Decoding the Technical Interview Process. Technical interviewing is one of those weird things that comes up from time to time, here and everywhere else because it's sort of this stylized ritual where we evaluate people on a number of skills that generally don't reflect in their day-to-day; it's really only a series of skills that you get better by practicing, and you only really get to practice them when you're interviewing for other jobs. That's been my philosophy, but again, I've written a tweet on this; you've written a book. What's the book about and what drove you to write it?Emma: So, the book covers everything from an overview of the interview process, to how do you negotiate a job offer, to systems design, and talks about load balancing and cache partitioning, it talks about what skills you need from the frontend side of things to do well on your JavaScript interviews. I will say this, I don't teach HTML, CSS, and JavaScript in-depth in the book because there are plenty of other resources for that. And some guy got mad at me about that the other day and wanted a refund because I didn't teach the skills, but I don't need to. [laugh]. And then it covers data structures and algorithms.They're all written in JavaScript, they have easy to comprehend diagrams. What drove me to write this is that I had just accepted a job offer in Stockholm for a web developer position at Spotify. I had also just passed my Google technical interviews, and I finally realized, holy crap, maybe I do know what I'm doing in an interview now. And this was at the peak of when people were getting laid off due to COVID and I said, “You know what? I have a lot of knowledge. And if I have a computer science degree and I was able to get through some of the hardest technical interviews, I think I should share that with the community.”Because some people didn't go through a CS degree and don't understand what a linked list is. And that's not their fault. It's just unfortunately, there weren't a lot of great resources—especially for web developers out there—to learn these concepts. Cracking the Coding Interview is a great book, but it's written in backend language and it's a little bit hard to digest as a frontend developer. So, I decided to write my own.Corey: How much of the book is around the technical interview process as far as ask, “Here's how you wind up reversing linked lists,” or, “Inverting a binary tree,” or whatever it is where you're tracing things around without using a pointer, how do you wind up detecting a loop in a recursive whatever it is—yeah, as you can tell, I'm not a computer science person at all—versus how much of it is, effectively, interview 101 style skills for folks who are even in non-technical roles could absorb?Emma: My goal was, I wanted this to be approachable by anyone without extensive technical knowledge. So, it's very beginner-friendly. That being said, I cover the basic data structures, talking about what traditional methods you would see on them, how do you code that, what does that look like from a visual perspective with fake data? I don't necessarily talk about how do you reverse a binary tree, but I do talk about how do you balance it if you remove a node? What if it's not a leaf node? What if it has children? Things like that.It's about [sigh] I would say 60/40, where 40% is coding and technical stuff, but maybe—eh, it's a little bit closer to 50/50; it kind of depends. I do talk about the take-home assessment and tips for that. When I do a take-home assessment, I like to include a readme with things I would have done if I had more time, or these are performance trade-offs that I made; here's why. So, there's a lot of explanation as to how you can improve your chances at moving on to the next round. So yeah, I guess it's 50/50.I also include a section on tips for hiring managers, how to create an inclusive and comfortable environment for your candidates. But it's definitely geared towards candidates, and I would say it's about 50/50 coding tech and process stuff.Corey: One of the problems I've always had with this entire industry is it feels like we're one of the only industries that does this, where we bring people in, and oh, you've been an engineer for 15 years at a whole bunch of companies I've recognized, showing career progression, getting promoted at some of them transitioning from high-level role to high-level role. “Great, we are so glad that you came in to interview. Now, up to the whiteboard, please, and implement FizzBuzz because I have this working theory that you don't actually know how to code, and despite the fact that you've been able to fake your way through it at big companies for 15 years, I'm the one that's going to catch you out with some sort of weird trivia question.” It's this adversarial, almost condescending approach and I don't see it in any other discipline than tech. Is that just because I'm not well-traveled enough? Is that because I'm misunderstanding the purpose of all of these things? Or, what is this?Emma: I think partially it was a gatekeeping solution for a while, for people who are comfortable in their roles and may be threatened by people who have come through different paths to get to tech. Because software engineer used to be an accredited title that you needed a degree or certification to get. And in some countries it still is, so you'll see this debate sometimes about calling yourself a software engineer if you don't have that accreditation. But in this day and age, people go through boot camps, they can come from other industries, they can be self-taught. You don't need a computer science degree, and I think the interview process has not caught up with that.I will say [laugh] the worst interview I had was at IBM when I was already working there. I was already a web developer there, full-time. I was interviewing for a role, and I walked into the room and there were five guys sitting at a table and they were like, “Get up to the whiteboard.” It was for a web development job and they quizzed me about Java. And I was like, “Um, sir, I have not done Java since college.” And they were like, “We don't care.”Corey: Oh, yeah, coding on a whiteboard in front of five people who already know the answer—Emma: Horrifying.Corey: —during a—for them, it's any given Tuesday, and for you, it is a, this will potentially determine the course that your career takes from this point forward. There's a level of stress that goes into that never exists in our day-to-day of building things out.Emma: Well, I also think it's an artificial environment. And why, though? Like, why is this necessary? One of the best interviews I had was actually with Gatsby. It was for an open-source maintainer role, and they essentially let me try the product before I bought it.Like, they let me try out doing the job. It was a paid process, they didn't expect me to do it for free. I got to choose alternatives if I wanted to do one thing or another, answer one question or another, and this was such an exemplary process that I always bring it up because that is a modern interview process, when you are letting people try the position. Now granted, not everyone can do this, right? We've got parents, we've got people working two jobs, and not everyone can afford to take the time to try out a job.But who can also afford a five-stage interview process that still warrants taking vacation days? So, I think at least—at the very least—pay your candidates if you can.Corey: Oh, yeah. One of the best interviews I've ever had was at a company called Three Rings Design, which is now defunct, unfortunately, but it was fairly typical ops questions of, “Yeah, here's an AWS account. Spin up a couple EC2 instances, load balance between them, have another one monitored. You know, standard op stuff. And because we don't believe in asking people to work for free, we'll pay you $300 upon completion of the challenge.”Which, again, it's not huge money for doing stuff like that, but it's also, this shows a level of respect for my time. And instead of giving me a hard deadline of when it was due, they asked me, “When can we expect this by?” Which is a great question in its own right because it informs you about a candidate's ability to set realistic deadlines and then meet them, which is one of those useful work things. And they—unlike most other companies I spoke with in that era—were focused on making it as accommodating for the candidate as possible. They said, “We're welcome to interview you during the workday; we can also stay after hours and have a chat then, if that's more convenient for your work schedule.”Because they knew I was working somewhere else; an awful lot of candidates are. And they just bent over backwards to be as accommodating as possible. I see there's a lot of debate these days in various places about the proper way to interview candidates. No take-home because biases for people who don't have family obligations or other commitments outside of work hours. “Okay, great, so I'm going to come in interview during the day?” “No. That biases people who can't take time off.” And, on some level, it almost seems to distill down to no one likes any way that there is of interviewing candidates, and figuring out a way that accommodates everyone is a sort of a fool's errand. It seems like there is no way that won't get you yelled at.Emma: I think there needs to be almost like a choose your own adventure. What is going to set you up for success and also allow you to see if you want to even work that kind of a job in the first place? Because I thought on paper, open-source maintainer sounds awesome. And upon looking into the challenges, I'm like, “You know what? I think I'd hate this job.”And I pulled out and I didn't waste their time and they didn't waste mine. So, when you get down to it, honestly, I wish I didn't have to write this book. Did it bring me a lot of benefit? Yeah. Let's not sugarcoat that. It allowed me to pay off my medical debt and move across a continent, but that being said, I wish that we were at a point in time where that did not need to exist.Corey: One of the things that absolutely just still gnaws at me even years later, is I interviewed at Google twice, and I didn't get an offer either time, I didn't really pass their technical screen either time. The second one that really sticks out in my mind where it was, “Hey, write some code in a Google Doc while we watch remotely,” and don't give you any context or hints on this. And just it was—the entire process was sitting there listening to them basically, like, “Nope, not what I'm thinking about. Nope, nope, nope.” It was… by the end of that conversation, I realized that if they were going to move forward—which they didn't—I wasn't going to because I didn't want to work with people that were that condescending and rude.And I've held by it; I swore I would never apply there again and I haven't. And it's one of those areas where, did I have the ability to do the job? I can say in hindsight, mostly. Were there things I was going to learn as I went? Absolutely, but that's every job.And I'm realizing as I see more and more across the ecosystem, that they were an outlier in a potentially good way because in so many other places, there's no equivalent of the book that you have written that is given to the other side of the table: how to effectively interview candidates. People lose sight of the fact that it's a sales conversation; it's a two-way sale, they have to convince you to hire them, but you also have to convince them to work with you. And even in the event that you pass on them, you still want them to say nice things about you because it's a small industry, all things considered. And instead, it's just been awful.Emma: I had a really shitty interview, and let me tell you, they have asked me subsequently if I would re-interview with them. Which sucks; it's a product that I know and love, and I've talked about this, but I had the worst experience. Let me clarify, I had a great first interview with them, and I was like, “I'm just not ready to move to Australia.” Which is where the job was. And then they contacted me again a year later, and it was the worst experience of my life—same recruiter—it was the ego came out.And I will tell you what, if you treat your candidates like shit, they will remember and they will never recommend people interview for you. [laugh]. I also wanted to mention about accessibility because—so we talked about, oh, give candidates the choice, which I think the whole point of an interview should be setting your candidates up for success to show you what they can do. And I talked with [Stephen 00:14:09]—oh, my gosh, I can't remember his last name—but he is a quadriplegic and he types with a mouthstick. And he was saying he would go to technical interviews and they would not be prepared to set him up for success.And they would want to do these pair programming, or, like, writing on a whiteboard. And it's not that he can't pair program, it's that he was not set up for success. He needed a mouthstick to type and they were not prepared to help them with that. So, it's not just about the commitment that people need. It's also about making sure that you are giving candidates what they need to give the best interview possible in an artificial environment.Corey: One approach that people have taken is, “Ah, I'm going to shortcut this and instead of asking people to write code, I'm going to look at their work on GitHub.” Which is, in some cases, a great way to analyze what folks are capable of doing. On the other, well, there's a lot of things that play into that. What if they're working in environment where they don't have the opportunity to open-source their work? What if people consider this a job rather than an all-consuming passion?I know, perish the thought. We don't want to hire people like that. Grow up. It's not useful, and it's not helpful. It's not something that applies universally, and there's an awful lot of reasons why someone's code on GitHub might be materially better—or worse—than their work product. I think that's fine. It's just a different path toward it.Emma: I don't use GitHub for largely anything except just keeping repositories that I need. I don't actively update it. And I have, like, a few thousand followers; I'm like, “Why the hell do you guys follow me? I don't do anything.” It's honestly a terrible representation.That being said, you don't need to have a GitHub repository—an active one—to showcase your skills. There are many other ways that you can show a potential employer, “Hey, I have a lot of skills that aren't necessarily showcased on my resume, but I like to write blogs, I like to give tech talks, I like to make YouTube videos,” things of that nature.Corey: I had a manager once who refused to interview anyone who didn't have a built-out LinkedIn profile, which is also one of these bizarre things. It's, yeah, a lot of people don't feel the need to have a LinkedIn profile, and that's fine. But the idea that, “Oh, yeah, they have this profile they haven't updated in a couple years, it's clearly they're not interested in looking for work.” It's, yeah. Maybe—just a thought here—your ability to construct a resume and build it out in the way that you were expecting is completely orthogonal to how effective they might be in the role. The idea that someone not having a LinkedIn profile somehow implies that they're sketchy is the wrong lesson to take from all of this. That site is terrible.Emma: Especially when you consider the fact that LinkedIn is primarily used in the United States as a social—not social networking—professional networking tool. In Germany, they use Xing as a platform; it's very similar to LinkedIn, but my point is, if you're solely looking at someone's LinkedIn as a representation of their ability to do a job, you're missing out on many candidates from all over the world. And also those who, yeah, frankly, just don't—like, they have more important things to be doing than updating their LinkedIn profile. [laugh].Corey: On some level, it's the idea of looking at a consultant, especially independent consultant type, when their website is glorious and up-to-date and everything's perfect, it's, oh, you don't really have any customers, do you? As opposed to the consultants you know who are effectively sitting there with a waiting list, their website looks like crap. It's like, “Is this Geocities?” No. It's just that they're too busy working on the things that bring the money instead of the things that bring in business, in some respects.Let's face it, websites don't. For an awful lot of consulting work, it's word of mouth. I very rarely get people finding me off of Google, clicking a link, and, “Hey, my AWS bill is terrible. Can you help us with it?” It happens, but it's not something that happens so frequently that we want to optimize for it because that's not where the best customers have been coming from. Historically, it's referrals, it's word of mouth, it's people seeing the aggressive shitposting I engage in on Twitter and saying, “Oh, that's someone that should help me with my Amazon bill.” Which I don't pretend to understand, but I'm still going to roll with it.Emma: You had mentioned something about passion earlier, and I just want to say, if you're a hiring manager or recruiter, you shouldn't solely be looking at candidates who superficially look like they're passionate about what they do. Yes, that is—it's important, but it's not something that—like, I don't necessarily choose one candidate over the other because they push commits, and open pull requests on GitHub, and open-source, and stuff. You can be passionate about your job, but at the end of the day, it's still a job. For me, would I be working if I had to? No. I'd be opening a bookstore because that's what I would really love to be doing. But that doesn't mean I'm not passionate about my job. I just show it in different ways. So, just wanted to put that out there.Corey: Oh, yeah. The idea that you must eat, sleep, live, and breathe is—hell with that. One of the reasons that we get people to work here at The Duckbill Group is, yeah, we care about getting the job done. We don't care about how long it takes or when you work; it's oh, you're not feeling well? Take the day off.We have very few things that are ‘must be done today' style of things. Most of those tend to fall on me because it's giving a talk at a conference; they will not reschedule the conference for you. I've checked. So yeah, that's important, but that's not most days.Emma: Yeah. It's like programming is my job, it's not my identity. And it's okay if it is your primary hobby if that is how you identify, but for me, I'm a person with actual hobbies, and, you know, a personality, and programming is just a job for me. I like my job, but it's just a job.Corey: And on the side, you do interesting things like wrote a book. You mentioned earlier that it wound up paying off some debt and helping cover your move across an ocean. Let's talk a little bit about that because I'm amenable to the idea of side projects that accidentally have a way of making money. That's what this podcast started out as. If I'm being perfectly honest, and started out as something even more self-serving than that.It's, well if I reach out to people in this industry that are doing interesting things and ask them to grab a cup of coffee, they'll basically block me, whereas if I ask them to, would you like to appear on my podcast, they'll clear time on their schedule. I almost didn't care if my microphone was on or not when I was doing these just because it was a chance to talk to really interesting people and borrow their brain, people reached out asking they can sponsor it, along with the newsletter and the rest, and it's you want to give me money? Of course, you can give me money. How much money? And that sort of turned into a snowball effect over time.Five years in, it's turned into something that I would never have predicted or expected. But it's weird to me still, how effective doing something you're actually passionate about as a side project can sort of grow wings on its own. Where do you stand on that?Emma: Yeah, it's funny because with the exception of the online courses that I've worked with—I mentioned LinkedIn Learning and Frontend Masters, which I knew were paid opportunities—none of my side projects started out for financial reasonings. The podcast that we started was purely for fun, and the sponsors came to us. Now, I will say right up front, we all had pretty big social media followings, and my first piece of advice to anyone looking to get into side projects is, don't focus so much on making money at the get-go. Yes, to your point, Corey, focus on the stuff you're passionate about. Focus on engaging with people on social media, build up your social media, and at that point, okay, monetization will slowly find its way to you.But yeah, I say if you can monetize the heck out of your work, go for it. But also, free content is also great. I like to balance my paid content with my free content because I recognize that not everyone can afford to pay for some of this information. So, I generally always have free alternatives. And for this book that we published, one of the things that was really important to me was keeping it affordable.The first publish I did was $10 for the book. It was like a 250-page book. It was, like, $10 because again, I was not in it for the money. And when I redid the book with the egghead.io team, the same team that did Epic React with Kent C. Dodds, I said, “I want to keep this affordable.” So, we made sure it was still affordable, but also that we had—what's it called? Parity pricing? Pricing parity, where depending on your geographic location, the price is going to accommodate for how the currency is doing. So, yes, I would agree. Side project income for me allows me to do incredible stuff, but it wasn't why I got into it in the first place. It was genuinely just a nice-to-have.Corey: I haven't really done anything that asks people for money directly. I mean, yeah, I sell t-shirts on the website, and mugs, and drink umbrellas—don't get me started—but other than that and the charity t-shirt drive I do every year, I tend to not be good at selling things that don't have a comma in the price tag. For me, it was about absolutely building an audience. I tend to view my Twitter follower count as something of a proxy for it, but the number I actually care about, the audience that I'm focused on cultivating, is newsletter subscribers because no social media platform that we've ever seen has lasted forever. And I have to imagine that Twitter will one day wane as well.But email has been here since longer than we'd been alive, and by having a list of email addresses and ways I can reach out to people on an ongoing basis, I can monetize that audience in a more direct way, at some point should I need them to. And my approach has been, well, one, it's a valuable audience for some sponsors, so I've always taken the asking corporate people for money is easier than asking people for personal money, plus it's a valuable audience to them, so it tends to blow out a number of the metrics that you would normally expect of, oh, for this audience size, you should generally be charging Y dollars. Great. That makes sense if you're slinging mattresses or free web hosting, but when it's instead, huh, these people buy SaaS enterprise software and implement it at their companies, all of economics tend to start blowing apart. Same story with you in many respects.The audience that you're building is functionally developers. That is a lucrative market for the types of sponsors that are wise enough to understand that—in a lot of cases these days—which product a company is going to deploy is not dictated by their exec so much as it is the bottom-up adoption path of engineers who like the product.Emma: Mm-hm. Yeah, and I think once I got to maybe around 10,000 Twitter followers is when I changed my mentality and I stopped caring so much about follower count, and instead I just started caring about the people that I was following. And the number is a nice-to-have but to be honest, I don't think so much about it. And I do understand, yes, at that point, it is definitely a privilege that I have this quote-unquote, “Platform,” but I never see it as an audience, and I never think about that “Audience,” quote-unquote, as a marketing platform. But it's funny because there's no right or wrong. People will always come to you and be like, “You shouldn't monetize your stuff.” And it's like—Corey: “Cool. Who's going to pay me then? Not you, apparently.”Emma: Yeah. It's also funny because when I originally sold the book, it was $10 and I got so many people being like, “This is way too cheap. You should be charging more.” And I'm like, “But I don't care about the money.” I care about all the people who are unemployed and not able to survive, and they have families, and they need to get a job and they don't know how.That's what I care about. And I ended up giving away a lot of free books. My mantra was like, hey if you've been laid off, DM me. No questions asked, I'll give it to you for free. And it was nice because a lot of people came back, even though I never asked for it, they came back and they wanted to purchase it after the fact, after they'd gotten a job.And to me that was like… that was the most rewarding piece. Not getting their money; I don't care about that, but it was like, “Oh, okay. I was actually able to help you.” That is what's really the most rewarding. But yeah, certainly—and back really quickly to your email point, I highly agree, and one of the first things that I would recommend to anyone looking to start a side product, create free content so that you have a backlog that people can look at to… kind of build trust.Corey: Give it away for free, but also get emails from people, like a trade for that. So, it's like, “Hey, here's a free guide on how to start a podcast from scratch. It's free, but all I would like is your email.” And then when it comes time to publish a course on picking the best audio and visual equipment for that podcast, you have people who've already been interested in this topic that you can now market to.This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: I'm not sitting here trying to judge anyone for the choices that they make at all. There are a lot of different paths to it. I'm right there with you. One of the challenges I had when I was thinking about, do I charge companies or do I charge people was that if I'm viewing it through a lens of audience growth, well, what stuff do I gate behind a paywall? What stuff don't I? Well, what if I just—Emma: Mm-hm.Corey: —gave it all away? And that way I don't have to worry about the entire class of problems that you just alluded to of, well, how do I make sure this is fair? Because a cup of coffee in San Francisco is, what, $14 in some cases? Whereas that is significant in places that aren't built on an economy of foolishness. How do you solve for that problem? How do you deal with the customer service slash piracy issues slash all the other nonsense? And it's just easier.Emma: Yeah.Corey: Something I've found, too, is that when you're charging enough money to companies, you don't have to deal with an entire class of customer service problem. You just alluded to the other day that well, you had someone who bought your book and was displeased that it wasn't a how to write code from scratch tutorial, despite the fact that he were very clear on what it is and what it isn't. I don't pretend to understand that level of entitlement. If I spend 10 or 20 bucks on an ebook, and it's not very good, let's see, do I wind up demanding a refund from the author and making them feel bad about it, or do I say, “The hell with it.” And in my case, I—there is privilege baked into this; I get that, but it's I don't want to make people feel bad about what they've built. If I think there's enough value to spend money on it I view that as a one-way transaction, rather than chasing someone down for three months, trying to get a $20 refund.Emma: Yeah, and I think honestly, I don't care so much about giving refunds at all. We have a 30-day money-back guarantee and we don't ask any questions. I just asked this person for feedback, like, “Oh, what was not up to par?” And it was just, kind of like, BS response of like, “Oh, I didn't read the website and I guess it's not what I wanted.” But the end of the day, they still keep the product.The thing is, you can't police all of the people who are going to try to get your content for free if you're charging for it; it's part of it. And I knew that when I got into it, and honestly, my thing is, if you are circulating a book that helps you get a job in tech and you're sending it to all your friends, I'm not going to ask any questions because it's very much the sa—and this is just my morals here, but if I saw someone stealing food from a grocery store, I wouldn't tell on them because at the end of the day, if you're s—Corey: Same story. You ever see someone's stealing baby formula from a store? No, you didn't.Emma: Right.Corey: Keep walking. Mind your business.Emma: Exactly. Exactly. So, at the end of the day, I didn't necessarily care that—people are like, “Oh, people are going to share your book around. It's a PDF.” I'm like, “I don't care. Let them. It is what it is. And the people who wants to support and can, will.” But I'm not asking.I still have free blogs on data structures, and algorithms, and the interview stuff. I do still have content for free, but if you want more, if you want my illustrated diagrams that took me forever with my Apple Pencil, fair enough. That would be great if you could support me. If not, I'm still happy to give you the stuff for free. It is what it is.Corey: One thing that I think is underappreciated is that my resume doesn't look great. On paper, I have an eighth-grade education, and I don't have any big tech names on my resume. I have a bunch of relatively short stints; until I started this place, I've never lasted more than two years anywhere. If I apply through the front door the way most people do for a job, I will get laughed out of the room by the applicant tracking system, automatically. It'll never see a human.And by doing all these side projects, it's weird, but let's say that I shut down the company for some reason, and decide, ah, I'm going to go get a job now, my interview process—more or less, and it sounds incredibly arrogant, but roll with it for a minute—is, “Don't you know who I am? Haven't you heard of me before?” It's, “Here's my website. Here's all the stuff I've been doing. Ask anyone in your engineering group who I am and you'll see what pops up.”You're in that same boat at this point where your resume is the side projects that you've done and the audience you've built by doing it. That's something that I think is underappreciated. Even if neither one of us made a dime through direct monetization of things that we did, the reputational boost to who we are and what we do professionally seems to be one of those things that pays dividends far beyond any relatively small monetary gain from it.Emma: Absolutely, yeah. I actually landed my job interview with Spotify through Twitter. I was contacted by a design systems manager. And I was in the interview process for them, and I ended up saying, “You know, I'm not ready to move to Stockholm. I just moved to Germany.”And a year later, I circled back and I said, “Hey, are there any openings?” And I ended up re-interviewing, and guess what? Now, I have a beautiful home with my soulmate and we're having a child. And it's funny how things work out this way because I had a Twitter account. And so don't undervalue [laugh] social media as a tool in lieu of a resume because I don't think anyone at Spotify even saw my resume until it actually accepted the job offer, and it was just a formality.So yeah, absolutely. You can get a job through social media. It's one of the easiest ways. And that's why if I ever see anyone looking for a job on Twitter, I will retweet, and vouch for them if I know their work because I think that's one of the quickest ways to finding an awesome candidate.Corey: Back in, I don't know, 2010, 2011-ish. I was deep in the IRC weed. I was network staff on the old freenode network—not the new terrible one. The old, good one—and I was helping people out with various things. I was hanging out in the Postfix channel and email server software thing that most people have the good sense not to need to know anything about.And someone showed up and was asking questions about their config, and I was working with them, and teasing them, and help them out with it. And at the end of it, his comment was, “Wow, you're really good at this. Any chance you'd be interested in looking for jobs?” And the answer was, “Well, sure, but it's a global network. Where are you?”Well, he was based in Germany, but he was working remotely for Spotify in Stockholm. A series of conversations later, I flew out to Stockholm and interviewed for a role that they decided I was not a fit for—and again, they're probably right—and I often wonder how my life would have gone differently if the decision had gone the other way. I mean, no hard feelings, please don't get me wrong, but absolutely, helping people out, interacting with people over social networks, or their old school geeky analogs are absolutely the sorts of things that change lives. I would never have thought to apply to a role like that if I had been sitting here looking at job ads because who in the world would pick up someone with relatively paltry experience and move them halfway around the world? This was like a fantasy, not a reality.Emma: [laugh].Corey: It's the people you get to know—Emma: Yeah.Corey: —through these social interactions on various networks that are worth… they're worth gold. There's no way to describe it other than that.Emma: Yeah, absolutely. And if you're listening to this, and you're discouraged because you got turned down for a job, we've all been there, first of all, but I remember being disappointed because I didn't pass my first round of interviews of Google the first time I interviewed with them, and being, like, “Oh, crap, now I can't move to Munich. What am I going to do with my life?” Well, guess what, look where I am today. If I had gotten that job that I thought was it for me, I wouldn't be in the happiest phase of my life.And so if you're going through it—obviously, in normal circumstances where you're not frantically searching for a job; if you're in more of a casual life job search—and you've been let go from the process, just realize that there's probably something bigger and better out there for you, and just focus on your networking online. Yeah, it's an invaluable tool.Corey: One time when giving a conference talk, I asked, “All right, raise your hand if you have never gone through a job interview process and then not been offered the job.” And a few people did. “Great. If your hand is up, aim higher. Try harder. Take more risks.”Because fundamentally, job interviews are two-way streets and if you are only going for the sure thing jobs, great, stretch yourself, see what else is out there. There's no perfect attendance prize. Even back in school there wasn't. It's the idea of, “Well, I've only ever taken the easy path because I don't want to break my streak.” Get over it. Go out and interview more. It's a skill, unlike most others that you don't get to get better at unless you practice it.So, you've been in a job for ten years, and then it's time to move on—I've talked to candidates like this—their interview skills are extremely rusty. It takes a little bit of time to get back in the groove. I like to interview every three to six months back when I was on the job market. Now that I, you know, own the company and have employees, it looks super weird if I do it, but I miss it. I miss those conversations. I miss the aspects—Emma: Yes.Corey: —of exploring what the industry cares about.Emma: Absolutely. And don't underplay the importance of studying the foundational language concepts. I see this a lot in candidates where they're so focused on the newest and latest technologies and frameworks, that they forgot foundational JavaScript, HTML, and CSS. Many companies are focused primarily on these plain language concepts, so just make sure that when you are ready to get back into interviewing and enhance that skill, that you don't neglect the foundation languages that the web is built on if you're a web developer.Corey: I'd also take one last look around and realize that every person you admire, every person who has an audience, who is a known entity in the space only has that position because someone, somewhere did them a favor. Probably lots of someones with lots of favors. And you can't ever pay those favors back. All you can do is pay it forward. I repeatedly encourage people to reach out to me if there's something I can do to help. And the only thing that surprises me is how few people in the audience take me up on that. I'm talking to you, listener. Please, if I can help you with something, please reach out. I get a kick out of doing that sort of thing.Emma: Absolutely. I agree.Corey: Emma, thank you so much for taking the time to speak with me today. If people want to learn more, where can they find you?Emma: Well, you can find me on Twitter. It's just @EmmaBostian, I'm, you know, shitposting over there on the regular. But sometimes I do tweet out helpful things, so yeah, feel free to engage with me over there. [laugh].Corey: And we will, of course, put a link to that in the [show notes 00:35:42]. Thank you so much for taking the time to speak with me today. I appreciate it.Emma: Yeah. Thanks for having me.Corey: Emma Bostian, software engineer at Spotify and oh, so very much more. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an incoherent ranting comment mentioning that this podcast as well failed to completely teach you JavaScript.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Why Can't Programmers... Program?r/metagnosis

Heard of mob programming talked about but have not seen it in action? Check out this special episode of the Mob Mentality show where we do some live #remote #mobprogramming at Agile Open SoCal 2020. Come see five devs who have not mobbed together before (Nestor Valenzuela, Kenny Jacobson, Art Bergquist, Paul Moore, and Joseph Ishak) tackling FizzBuzz in Python.  Video and show notes: https://youtu.be/JeLKTvkGLNQ 

Co to jest gra FizzBuzz i jak wykorzystać ją podczas rozmowy kwalifikacyjnej

Cosa potremo mai imparare sul design da un semplicissimo esercizio di programmazione come FizzBuzz? La sfida è vedere come la codebase accetta un cambio di requisito. Si centra prima il requisito e poi si fa refactoring oppure si fa prima un refactoring che ci permetta di modificare semplicemente la codebase per soddisfare il nuovo requisito funzionale? Questo e tanto altro nell'intervista a Massimo Iacolare.

Summary Dylan Beattie talks about his love of programming, esoteric languages and his language, Rockstar. Details Who he is, what he does. Dylan and Bryan had Amstrad computers. Programming as art, programming for the sake of programming, Conway's game of life, demo scene, squeezing more out of the hardware. Squeezing more out of software; code golf; obfuscating code. Quine - programs that print themselves, quine relays, record is 128 languages. Esoteric languages, a story about Alfred Hitchcock, Turing completeness, examples of esoteric languages. The origins of Rockstar; an example of FizzBuzz in Rockstar, making real music. Dylan's hectic conference schedule. Full show notes

In this episode of Scaling Postgres, we discuss prepared plans, materialization, recursive CTEs and how to run safe database migrations. Subscribe at https://www.scalingpostgres.com to get notified of new episodes. Links for this episode: https://www.cybertec-postgresql.com/en/tech-preview-how-postgresql-12-handles-prepared-plans/ https://www.cybertec-postgresql.com/en/tech-preview-improving-copy-and-bulkloading-in-postgresql-12/ https://blog.timescale.com/rethinking-the-database-materialized-view-as-an-index/ https://fluca1978.github.io/2019/06/11/SequenceCheck.html https://fluca1978.github.io/2019/06/11/FizzBuzz.html https://fluca1978.github.io/2019/06/12/PartitioningCTE.html https://www.youtube.com/watch?v=KROgsx5zosA https://www.youtube.com/watch?v=B-iq4iHLnJU https://www.youtube.com/watch?v=a4OBp6edNaM https://habr.com/en/company/postgrespro/blog/452968/ https://info.crunchydata.com/blog/crunchy-postgres-kubernetes-operator-4.0  

GUEST BIO: Fran Buontempo is editor of the ACCU’s (Association of C and C++ Users) Overload magazine.  Fran has been programming in C++ for over a decade and also knows C# and Python.  Fran has also written a book about how to program your way out of a paper bag. EPISODE DESCRIPTION: Phil’s guest on today’s show is Fran Buontempo. She is a C and C++ expert who is the editor of the ACCU’s (Association of C and C++ Users) Overload magazine. Fran also works with C# and Python. She is a conference speaker, blogger, and author. Her first book, Genetic Algorithms and Machine Learning for Programmers (Pragmatic Programmers), has been well received. In it, she shares several ways to code your way out of a paper bag, as a fun way of providing an insight into emerging machine learning tech. KEY TAKEAWAYS: (0.53) – So firstly, I want to ask you about is your role as editor of the overload magazine? How long have you been doing that? Fran can’t remember exactly but she thinks it has been between 5 and 6 years. Becoming the editor happened slowly, almost by accident. Fran got involved with code critiques, writing book reviews and writing or editing one or two articles. So, when the editor stepped down she volunteered. (1.40) - In terms of the following of the magazine, what's its reach? It reaches a worldwide audience of around a thousand people. A magazine is produced each month. One month it is the member-only version. The next month a different version is published, which anyone can read. (2.38) In terms of your book, how did learning to program your way out of a paper bag come about? Fran was involved in interviewing candidates for a job. One interviewee was so bad that one of their colleagues said that they couldn’t “code their way out of a paper bag.” A throwaway comment that struck a chord with Fran and inspired her to dig deeper into machine learning and improve her skill set too. This led to her writing, her book, Genetic Algorithms and Machine Learning for Programmers (Pragmatic Programmers). In the book, she goes through several AI learning techniques using the example of escaping from a paper bag to illustrate what she was sharing. It was a great way to catch people’s attention and engage them. She was also able to include examples from some of the conference talks and articles she had written. (3.44) - So you're confident now that you can program your way out of a paper bag, presumably. Fran says yes, and she has the certificate to prove it. She gave her first talk at the ACCU conference on that very subject. For fun, she asked the audience to sign a certificate if they thought she had done well enough, which they did. (4.01) – Can you please share a unique career tip with the I.T. career audience?  Fran’s advice is to start seeing imposter syndrome as a positive thing. You get the feeling you are not sure what you are talking about when you put your head above the parapet and do something that stretches you. Feeling like that helps you to identify the holes in your knowledge and fill them. So, that is a positive thing. At this stage, Phil points out that imposter syndrome is simply a different way to describe self-doubt. (5.07) – Can you tell us about your worst career moment? And what you learned from that experience. Very early in Fran’s IT career, she was in the registry at the command prompt and accidentally deleted Windows from a work laptop. She panicked, but it all worked out OK. Not long after she was working in a team of seven that was reduced to just two, overnight. The next day everything broke. Fortunately, Fran was able to sort things out fairly quickly. But, it was a bad situation to find herself in. (6.46) – What was your best career moment? For Fran, her career highlights have come about mainly from human interactions. Being able to mentor people is something she finds to be particularly exciting and fulfilling. It feels great to watch them grow. Being thanked by someone you have helped on somewhere like stack overflow also feels good. Positive feedback from conferences and book reviews, also give her a lift. Of course, the comments are not always positive. Sometimes people do not agree with you or see the value of what you are offering. When that happens, it is important to handle things in a Zen way. Use it as a learning opportunity and see if there is something you could have done better. (8.30) – Can you tell us what excites you about the future of the IT industry and careers? The pace of innovation is exciting. It is especially good to see a new wave of young programmers becoming interested in C++. Version 11 has made a huge difference to how popular the language is, at the moment. Fran is also fascinated by what is happening with AI and machine learning. People are now achieving things that just 10 years ago would have been impossible. As new technologies emerge and advance, this is going to continue to happen, at an even faster rate (10.01) – What drew you to a career in IT? Fran responds that it was unemployment. As a teenager, she had done a little programming, using her Dad’s computer. But, she studied maths and philosophy at university. For 3 years she taught secondary school maths but ended up becoming unemployed. That is when she realized that she already had some of the skills she needed to work in the IT industry. So, she went to a local college and got a City and Guild qualification in C programming. It only took a few weeks to complete that course. Yet, that qualification was enough to land her an IT job. Fairly quickly, Fran learned C++. At which point, she was able to become far more productive. (11.31) – What is the best career advice you have ever received? One of her managers suggested that she join ACCU. That turned out to be great advice for Fran. Finding a group of like-minded people who are willing to help you makes a huge difference. (12.09) - Conversely, what is the worst career advice you've ever received? Fran loves coding, so wants to carry on doing that. Climbing the promotional ladder usually leads to you having less time available to actually program which is not what she wants. So, for her, the advice to move into management is bad advice. It is something she has been asked to do several times. But, it is something she is not likely to want to do. (12.50) – If you were to begin your IT career again, right now, what would you do? From the start, Fran would find a supportive group. Joining the ACCU made a huge difference to her. So, she would definitely do something like that early on. There is now plenty of good quality support available for anyone who uses or wants to learn how to use C++. (13.49) – What are your current career objectives? Recently, Fran has been daydreaming about retiring. But, she is currently fascinated with how AI can be used to speed up the programming process. At the recent ACCU conference, she demonstrated how to get AI to automatically generate FizzBuzz code. The code produced was pretty awful and it took ages to come out with the right tests. But, it did inspire her to try to do more things with AI. She is currently experimenting with genetic programming. AI has the potential to be used for all kinds of things, in particular, to create and help with test cases. Using AI you can dig deep and seek out numbers or strings that will fail the cases. Even established systems could benefit from being crash tested using AI. It could also be used for mutation testing. Fran thinks there is a lot of potential. (15.50) - What do you do to keep your own career energized? Fran finds that editing the Overload magazine keeps her energized. It makes it easier for her to stay up to date and pushes her to explore tech she would not otherwise notice. She also finds speaking at and attending conferences to be an energizing experience. Sitting back and listening is a much easier way to learn. Plus, you get to speak to the people delivering the talk afterward, which is a good way to learn more. (16.19) - What do you do in your spare time away from technology? Fran has a lot of interests outside of IT. She likes to do things that ground her. For example, she used to read dystopian cyberpunk sci-fi books as a way of switching off. These days, cooking, making bread, enjoying her garden and walking all help her to recharge her batteries (17.00) – Phil asks Fran to share a final piece of career advice with the audience. While listening to Mike Feathers, last year, at the Software Craftsmanship Conference Fran picked up a great piece of career advice. He reminded everyone that they have an amazing set of skills. Their abilities are in high demand. So, there is absolutely no reason to be unhappy in their career. If you are not happy, switch jobs or innovate. Coming up with a problem to solve and launching a start-up is always a possibility. It guarantees that you will be doing something that interests you BEST MOMENTS: (4.35) FRAN – "Imposter syndrome is really conscious incompetence from the four stages of learning." (7.53) FRAN – "You need to be quite Zen about how you read feedback." (8.15) PHIL – "For every extreme, ardent follower of yours, you're going to get somebody in the opposite end of the spectrum." (12.03) FRAN – "Finding a group of people who will help you is really important." (14.40) FRAN – "There's an overlap going on between the AI machine learning community and the tech community. If we talk to each other better, we can help each other out." (17.19) FRAN – "You have an amazing set of skills. So, you don't have to be unhappy in your career" CONTACT FRAN: Twitter: https://twitter.com/fbuontempo LinkedIn: https://about.me/frances_buontempo Personal Website: https://about.me/frances_buontempo

Nós que somos velhos e cansados na tecnologia achamos que algumas coisas já deram, e têm que acabar! Vem com a gente acabar com tudo isso aí! Nesse episódio, que está cheio de itens polêmicos que têm que acabar, o que mais varia é o nível de consenso, tem coisa que todo mundo acha que tem que acabar, e tem outras que nem tanto. Comenta lá embaixo no post do blog se você acha que algo tem que acabar ou não. Lá no final do post tem a lista final dos itens que tem que acabar, se você quiser um spoiler. Fabio, Giovanni e Lucas no estúdio Feed do podcast: www.lambda3.com.br/feed/podcast Feed do podcast somente com episódios técnicos: www.lambda3.com.br/feed/podcast-tecnico Feed do podcast somente com episódios não técnicos: www.lambda3.com.br/feed/podcast-nao-tecnico Links Citados: Episódio do Braincast sobre o que tem que acabar Livro Pensando rápido e devagar Automatic Semicolon Insertion (ASI) Exemplo de Fizzbuzz do Teles Participantes: Fabio Damasceno - @fabiodamasceno Giovanni Bassi - @giovannibassi Lucas Teles - @lucasteles42 Edição: Luppi Arts A lista do que tem que acabar está abaixo. Note que a lista não representa recomendações, é apenas a opinião de quem participou do episódio. Tem que acabar quem olha pra essa lista como uma lista de recomendações! E ajude a contar pra gente o que tem que acabar, incluindo itens e votando nos que já estão lá nesta pesquisa. Scrum Estimativa Projeto em cascata O ; do JavaScript Código em português sem acento Código em português SOAP UI SOAP REST OData Pastel Deploy manual GMUD Microsserviço sem justificativa técnica Profissional DevOps Decisões técnicas tomadas por pessoas não técnicas Gerente de projetos em tecnologia Arquiteto de software sem experiência Desculpa pra não fazer testes Desenvolvedor que só quer codar e não se envolve com o projeto Dev sênior de 2 anos de experiência Teclados não mecânicos Camada de aplicação DDD com receita de bolo Pessoas que não assumem suas decisões técnicas Camadas BOLOVO Cargo Cult Comunicação violenta jQuery Guerrinha de tecnologia (a minha é melhor que a sua) ES5 como target mínimo IE ASP.NET WebForms Emacs Qualquer editor que não suporte modo Vim Procedure no banco de dados Não fazer testes Selenium pra tudo Asserts com APIs que não são fluidas Moq SharePoint on premises ou como portal MVC 5 .NET Framework Commit de binários e componentes Qualquer coisa que não seja Git Framework que faz tudo tipo o Angular Injeção de dependência de construtor Dev que quer pagar hype com dinheiro dos outros Orientação a objetos Linguagens dinâmicas Treta técnica no Twitter On premises Qualquer coisa que não roda em contêineres cmd Twitter Bootstrap Horário não flexível Roupa social no escritório Créditos das músicas usadas neste programa: Music by Kevin MacLeod (incompetech.com) licensed under Creative Commons: By Attribution 3.0 - creativecommons.org/licenses/by/3.0

Sponsors Sentry- use the code “devchat” for $100 credit Netlify Clubhouse CacheFly   Episode Summary   In this episode of JavaScript Jabber, the panelists talk with Tommy Hodgins who specializes in responsive web design. He starts with explaining to listeners what it means by a responsive web layout and goes on to discuss the techniques in using JavaScript in CSS in depth. He elaborates on dynamic styling of components, event-driven stylesheet templating, performance and timing characteristics of these techniques and describes different kinds of observers – interception, resize and mutation, and their support for various browsers. He also talks about how to go about enabling certain features by extending CSS, comparison to tools such as the CSS preprocessor and Media Queries, pros and cons of having this approach while citing relevant examples, exciting new features coming up in CSS, ways of testing the methods, caffeinated stylesheets, along with Qaffeine and Deqaf tools. Links JS in CSS – Event driven virtual stylesheet manager Qaffiene Deqaf Tommy’s Twitter Fizzbuzz   Picks Joe The Captain Is Dead Aimee Developer on Call Tip – Try to follow a low-sugar diet Chris Tommy’s snippets on Twitter – JS in CSS All things frontend blog Gulp project Charles Coaching by Charles in exchange of writing Show Notes or Tags Tommy JS in CSS

Sponsors Sentry- use the code “devchat” for $100 credit Netlify Clubhouse CacheFly   Episode Summary   In this episode of JavaScript Jabber, the panelists talk with Tommy Hodgins who specializes in responsive web design. He starts with explaining to listeners what it means by a responsive web layout and goes on to discuss the techniques in using JavaScript in CSS in depth. He elaborates on dynamic styling of components, event-driven stylesheet templating, performance and timing characteristics of these techniques and describes different kinds of observers – interception, resize and mutation, and their support for various browsers. He also talks about how to go about enabling certain features by extending CSS, comparison to tools such as the CSS preprocessor and Media Queries, pros and cons of having this approach while citing relevant examples, exciting new features coming up in CSS, ways of testing the methods, caffeinated stylesheets, along with Qaffeine and Deqaf tools. Links JS in CSS – Event driven virtual stylesheet manager Qaffiene Deqaf Tommy’s Twitter Fizzbuzz   Picks Joe The Captain Is Dead Aimee Developer on Call Tip – Try to follow a low-sugar diet Chris Tommy’s snippets on Twitter – JS in CSS All things frontend blog Gulp project Charles Coaching by Charles in exchange of writing Show Notes or Tags Tommy JS in CSS

Sponsors Sentry- use the code “devchat” for $100 credit Netlify Clubhouse CacheFly   Episode Summary   In this episode of JavaScript Jabber, the panelists talk with Tommy Hodgins who specializes in responsive web design. He starts with explaining to listeners what it means by a responsive web layout and goes on to discuss the techniques in using JavaScript in CSS in depth. He elaborates on dynamic styling of components, event-driven stylesheet templating, performance and timing characteristics of these techniques and describes different kinds of observers – interception, resize and mutation, and their support for various browsers. He also talks about how to go about enabling certain features by extending CSS, comparison to tools such as the CSS preprocessor and Media Queries, pros and cons of having this approach while citing relevant examples, exciting new features coming up in CSS, ways of testing the methods, caffeinated stylesheets, along with Qaffeine and Deqaf tools. Links JS in CSS – Event driven virtual stylesheet manager Qaffiene Deqaf Tommy’s Twitter Fizzbuzz   Picks Joe The Captain Is Dead Aimee Developer on Call Tip – Try to follow a low-sugar diet Chris Tommy’s snippets on Twitter – JS in CSS All things frontend blog Gulp project Charles Coaching by Charles in exchange of writing Show Notes or Tags Tommy JS in CSS

Episode 16: 1. What is "FizzBuzz"? 2. Go to Python Fu Masters [dot] com for more info about the game FizzBuzz. Next episode: TBD (To Be Determined). Web pythonfumasters.com | Facebook @pythonfumasters | Instagram @masterhun

プレゼンテーション、設計原則、設計のステップアップ、利用者からみたコード、問題の分割、失敗する権利を奪わないこと、直感などについてhidenorigotoさん、しんぺいさん、つっちー、前田さんと話しました。 SOLID飲み会 PHPカンファレンス関西2018で「続・SOLIDの原則ってどんなふうに使うの? オープン・クローズドの原則 センパイのコーディングノート編」を話しました - HITORIGOTO 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く ajitofm 31: Farmed and Wild 5 advanced testing techniques in Go · Segment Blog 設計のステップアップ 失敗する権利を奪わない 何のための原則か Gang Of Four EnterpriseQualityCoding/FizzBuzzEnterpriseEdition: FizzBuzz Enterprise Edition is a no-nonsense implementation of FizzBuzz made by serious businessmen for serious business purposes. マイクロサービスと設計原則 — 設計Night2018 登壇報告 #sekkei_n2018 – FiNC Tech Blog – Medium 騎士団長殺し - Wikipedia ダンス・ダンス・ダンス - Wikipedia 編集後記 プログラマが設計についてどのように成長していくか。その過程でどのように失敗可能な環境をつくり、また原則をショートカットとしながら学んでいくか。話の尽きない会でした。そして収録後、しんぺいさんが早速AJITOにいくやいなや、セッションが始まったのでした。 フィードバックもお待ちしております！番組へのお便り、ダンキンドーナツに関する感想など、 https://ajito.fm/form/ または Twitter: #ajitofm までどうぞ。

Mel chats with Sam about getting into Ember, lessons learned from collaborating at work an in open source, and how to make it easier for JavaScript engineers to use better UI patterns. Topics: 0:00 – How Mel got into Ember at JPMorgan 4:45 – Feeling welcome in the Ember community 7:45 – Investing in Ember for the long-term 9:00 – Communicating vision, removing our ego, and empowering others to do work 17:07 – Learning team projects 19:30 – Improving the native accessibility story for Ember 27:25 – Making it easier for JavaScript engineers to use better UI patterns 34:55 – Ember Styleguide and Ember OSS infrastructure 49:10 – EmberCamp Chicago 51:20 – Leveling up in the Ember community Links: Melanie on Twitter: @melaniersumner EmberCamp, September 21, Chicago: http://embercamp.com Melanie's FizzBuzz in HBS How to talk so kids will listen & listen so kids will talk

Chris (@stoneymonster) and Elecia (@logicalelegance) celebrate the 256th episode with a confusing lack of cupcakes. IAmTheCalvary.org has an excellent Hippocratic Oath for Connected Medical Devices  Make Magazine has some tips to tighten security on DIY IoT Projects. Rockstar Language Specification (and FizzBuzz example)  The C++ episode discussed was #247 with Jason Turner. Topics and Times: 00:00    Zero 00:27    Intro and cupcakes 03:09    Patreon and Slack 04:24    Transcripts, chapter markers? 07:48    Listener question:  ST HAL, Cube, SPL, Bare Metal? 14:22    Hippocratic Oath for Connected Medical Devices 19:32    Make magazine article on DIY IoT Security 22:36    NYC Embedded and Engineering Meetup? 23:42    C++: Expressiveness, optimization vs. good code 30:21    C++: Spec size vs. C#/Java 32:22    A question of parentheses leads to mild violence and ranting 35:43    Rockstar: The Language! 43:59    Wherein we "discuss" Rust for some reason, again. 46:45    Elecia's Projects in Python and JSON 50:18    Elecia's available for gigs! 50:50    Elecia's ML overview blog post 51:38    The end of Embedded 52:42    Wrap up 54:04    Winnie the Pooh continues...  

We meet up around the water cooler for a quick round of lightning talks as Allen and Michael sing FizzBuzz while Joe passes the caching buck.

We meet up around the water cooler for a quick round of lightning talks as Allen and Michael sing FizzBuzz while Joe passes the caching buck.

Добрый день уважаемые слушатели. В гостях RWpod Cafe сегодня Oleg Antonyan: Кто ты? Developer Survey Results 2018 Let's Encrypt releases support for wildcard certificates Atom + Rust = XRay Ruby + Rust = Helix Математика и программирование Amazon thinks it has a fix to Alexa's terrifying laughing issue 30% of all sites now run on WordPress Why your first FizzBuzz implementation may not work Пожелания слушателям. Blog Github Twitter

Are code challenges or quizzes a legitimate practice for hiring developers? We debate whether the method of filtering candidates via whiteboarding or code games is plain lazy or a necessary part of the recruiting process for engineers.

Episode 1 Show Notes (http://pythonoutloud.com/1): pythonoutloud.com/1 (http://pythonoutloud.com/1) These show note were written on the Shinano Train, on Kevin's smartphone, steaming toward the Snow Monkey Park in Nagano, Japan. In Episode 1, we discuss the infamous programming challenge known as FizzBuzz (no space), Fizz Buzz (with a space), or fizz_buzz (in PEP8-friendly syntax). We start off with its origin story, a math game used to teach children division. We then debate whether sitting around in a circle and taking turns saying “one, two, fizz, four, buzz, ...” is as fun in the digital age. Even less fun? Fizz Buzz's reputation as a job interview question. For more about this version, see the well-known blog post by Jeff Atwood at https://blog.codinghorror.com/why-cant-programmers-program/ (https://blog.codinghorror.com/why-cant-programmers-program/) We're still not sure whether Fizz Buzz, or any other math-heavy question, is suitable for determining someone's capacity as a programmer. But as a learning tool, Fizz Buzz does provide a compact way of demonstrating a wide range of programming topics, including variables, conditionals, and loops. The only downside is also needing to learn modular arithmetic: https://nrich.maths.org/4350 (https://nrich.maths.org/4350) And if you need even more math in your Fizz Buzz solution, look no further than this blog post by Joel Grus: http://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/ (http://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/) Rounding out the episode, we share some project updates, including Kevin's recent Medium article on "Automating Surveys with Python, Qualtrics API and Windows Task Scheduler": https://medium.com/@changkevin/automating-surveys-with-python-qualtrics-api-and-windows-task-scheduler-4bffc58726d7 (https://medium.com/@changkevin/automating-surveys-with-python-qualtrics-api-and-windows-task-scheduler-4bffc58726d7) Neither of us is affiliated with Qualtrics in any way, but we did publish a qualtrics-mailer package on PyPI a few months ago: https://pypi.python.org/pypi/qualtrics-mailer/0.1 (https://pypi.python.org/pypi/qualtrics-mailer/0.1) This episode features the song "Happy Ukulele" by Scott Holmes (http://freemusicarchive.org/music/Scott_Holmes/) and the songs "And So Then", "Curiousity", "Manhattan By Moonlight" and "Puzzle Pieces" by Lee Rosevere (http://freemusicarchive.org/music/Lee_Rosevere/). Thank you for your support, and stay tuned for Episode 2. We plan to continue discussing problem solving in Python, focusing on http://www.pythonchallenge.com/ (http://www.pythonchallenge.com/). If you’re still reading, there's a statistically significant chance you want to help us build a community and support our cause! If our prediction is correct, please visit pythonoutloud.com/donate (http://pythonoutloud.com/donate). We want Python Out Loud to be community driven and non-profit oriented, which is why we pledge to be transparent and donate anything in excess of our operating expenses to the Python Software Foundation (PSF). For just $3, we'll even mail you a limited-edition Python Out Loud sticker!

Technical interviews are the worst. They’re hard, they’re scary, and they often feel like they’re designed to make you feel stupid. But no worries! We’re here to help. We take a behind-the-scenes look at the interview process at two very prestigious companies, Etsy and the New York Times. Developers La Vesha Parker and Tiffany Peon break down each part of the interview process, giving you examples and explanations of exactly what they’re looking for, and share their own stories of how they got their roles. We also have a second edition of our Coding Corner where we share more interview tips and dissect how to solve a popular interview question, FizzBuzz. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Go (programming language) CoffeeScript Recurse Center CSS Grids Geeks for Geeks Codeland Conf Codeland 2019

Put on your own jolly Irish brogue. Then sing and dance along with this week's show featuring indie Celtic music from New York Brogue, NUA, Good Foot, Adam Beattie, The Bordercollies, Trinity River Whalers, Taisgeal Clachan, Songs for Ceilidh, The Jolly Rogues, Caledonia Swing, The Kilt Lifters, Dave Wilson and Willie B., Naymedici, Ceann, Mark Saul. If you enjoy this podcast, then please rate the show on iTunes or your favorite podcatcher. Then subscribe to our Celtic Music Magazine. This is our free newsletter and your guide to the latest Celtic music and podcast news. Subscribe today to download 34 Celtic MP3s for free. Remember to support the artists who support this podcast: buy their CDs, download their MP3s, see their shows, and drop them an email to let them know you heard them on the Irish and Celtic Music Podcast. And remember to Vote in the Celtic Top 20 to help me create next year's Best Celtic Music 2016 episode.   Today's show is brought to you by Pirates vs Dragons Marc Gunn's latest album, Pirates vs. Dragons, will be released on July 27, 2016. You'll hear sea shanties interwoven with a Celtic Steampunk musical story about an air pirate that kidnaps a bard to immortalize his dragon treasure hunting in song. What he doesn't realize is that the musician will do anything to protect the dragons. Subscribe to my mailing list to notified when it is released, or go to celticmusic.org/savethedragons   Notes: * Helping you celebrate Celtic culture through music. * The Irish & Celtic Music Podcast is successful thanks to people like you. Your generous pledge of as little as $1 per episode covers the cost of producing the show. And 10% of your pledges go back to non-profits to support and build our Celtic communities. Best of all, whenever we hit a milestone, you get an extra-long episode. We are working towards a two-hour special on Celtic Women. Become a Patron of the Podcast today, because we are helping you celebrate Celtic culture through music. Special thanks our latest Patron, Andrew Scarbro, Aaron Bendavid. * If you enjoy the music in this show, then you might also enjoy our Facebook video shows. The Celtic Music News show goes out on Mondays, and each show is between 3-5 minutes. * I WANT YOUR FEEDBACK: Call 678-CELT-POD to leave a voicemail message. That's 678-235-8763. What are you doing today while listening to the podcast? You can send a written comment along with a picture of what you're doing while listening, or from one of your trips to one of the Celtic nations. John Bartmann wrote on Facebook: "I've been listening to the Irish & Celtic Music Podcast while clearing a forest while on a Workaway experience in Noosa, Australia. We're originally from South Africa and the podcast has just made the shady, quiet surrounds perfect :) thanks" Cathy Gadzo wrote on Facebook: "Listening to show #266 while working on inventory for @Celtique Creations' summer festivals"   This Week in Celtic Music 0:36 "Cul Aodh Jigs" by New York Brogue from Live from the Poor Mouth 6:38 "Fizzbuzz" by NUA from BOLD 10:10 "Home With the Girls in the Morning" by Good Foot from Good Foot 13:37 "The Family Tree" by Adam Beattie from The Road Not Taken 17:30 "Thunderhead Jig Set" by The Bordercollies from The Road from Swannanoa 21:09 CELTIC MUSIC NEWS 21:54 "Jolly Rovin' Tar" by Trinity River Whalers from Both Barrels 24:34 "The Storyteller" by Taisgeal Clachan from Finding the Lost Village 28:25 "Maggie's Cat" by Songs for Ceilidh from Beneath the Waves 32:30 "Maggie May" by The Jolly Rogues from Privateers 36:00 "Cape Breton Set: Cape Breton Reel/Cold Frosty Morn/My Love Is But A Lassie Yet" by Caledonia Swing from Something Like That! 38:16 CELTIC FEEDBACK 39:22 "You Jacobites By Name" by The Kilt Lifters from Jack in the Green 45:17 "Achill Island" by Dave Wilson and Willie B. from Far From home 49:06 "Whiskey John" by Naymedici from Paddy McGee 51:54 "New York Girls" by Ceann from Rant, Rave, Lose Pants 55:16 "It's An Instrument" by Mark Saul from Mixylodian VOTE IN THE CELTIC TOP 20. It's easier than ever to do. Just list the show number, and the name of one or two bands. That's it. You can vote once for each episode help me create next year's Best Celtic music of 2016 episode. The Irish & Celtic Music Podcast was produced by Marc Gunn, The Celtfather. To subscribe, go to iTunes or to our website where you can become a Patron of the Podcast for as little as $1 per episode. You can post feedback in the shownotes at celticmusicpodcast.com.

In order to work professionally as a front end developer, there is always an intense interview process. In this episode, we share our experiences and thoughts on the interviews we’ve done in the past. Not only have we had experience being interviewed, we’ve also had a lot of experience interviewing other engineers for jobs at our companies. We share things we’re looking for when we interview candidates to join our teams. Items mentioned in the episode: Eclipse, Othello, Big O notation, FizzBuzz, Ryan Anklams famous t-shirt, War of the Worlds radio broadcast Panelists: Derrick Showers - @derrickshowers Jem Young - @JemYoung Ryan Anklam - @bittersweetryan Ryan Burgess - @burgessdryan Brian Holt - @holtbt Augustus Yuan - @augburto Sarah Federman - @sarah_federman Picks: Ryan Burgess - Aerial screensaver Ryan Burgess - Amazon Dash Buttons Ryan Burgess - Front End Happy Hour Playlist Ryan Anklam - Escape app Ryan Anklam - Best of Old Time Radio Podcast Ryan Anklam - Dusty Kid - Beyond That Hill Sarah Federman - Lindsey Stirling Sarah Federman - SizeUp (osx windows management) Jem Young - EmpireJS Jem Young - Aphex Swift Jem Young - Netflix Menus Derrick Showers - Code Climate Derrick Showers - Slack themes Augustus Yuan - Massdrop Augustus Yuan - Elevator Saga Augustus Yuan - Pretty Thoughts Alina Baraz & Galimatias Brian Holt - AtHack! Brian Holt - Annie Cannons Brian Holt - Scroobius Pip Brian Holt - Baths Brian Holt - M83

In this years first episode we start off the show with discussion on Lew’s newly updated website, Bowling Game Code Katas and PostgreSQL. We then move on to talk about React-Router, ‘shrinkwrapping’ NPM dependences and Edd’s introduction to the world of Lisp by way of Clojure. Other coding katas are then mentioned (FizzBuzz), along with an interesting project good friend of the show Jimmy Burrell has recently released. Finally, we wrap up the show with ideas on the technologies and languages each of us wishes to explore this year, along with some interesting podcast episodes we have recently listened to.

Programmer Earl Bey has always been a hip hop fan. He’s been rapping since he was ten, and even had his own manager. When he was later introduced to tech, he dove into coding full time. Now, he blends his new passion for code with his love for hip hop. He talks about how he uses rap to retain new programming concepts, and gives us a taste of his lyrical skills in a performance of code-infused rhymes on FizzBuzz and Rails. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) ScriptEd FizzBuzz Stress Management article Canvs (formerly Mashwork) Codeland Conf Codeland 2019

Irish Celtic music from NUA, Olta, The Willis Clan, Poitin, PerKelt, Whiskey Bay Rovers, Telenn Tri, Dr. Rev. Mr. Cheeks Miller, Keltikon, First Highland Watch, The Gleasons, McCrae's Battalion, Brian Boru Irish Pipe Band.  www.celticmusicpodcast.com If you enjoy this show, then subscribe to our Celtic Music Magazine. This is our free newsletter and your guide to the latest Celtic music and podcast news. Remember to support the artists who support this podcast: buy their CDs, download their MP3s, see their shows, and drop them an email to let them know you heard them on the Irish and Celtic Music Podcast. Remember too, when you buy through our affiliates at CD Baby, Amazon, or iTunes, you support the artists AND the podcast.   Today's show is brought to you by Lunarpages Are you in need of a web host? Lunarpages offers basic web hosting to more advanced hosting services such as private cloud hosting, and complete IT infrastructure. It's intelligent web hosting.   Notes: - Join Song Henge!- How to get played on the podcast- Posting podcasts on YouTube and updating the times- New Podcast: The Celtic Geek- Celtic Music Spotlight is having a wee trouble getting going, but it's coming along- I WANT YOUR VOICEMAIL: Post a comment on our Facebook fan page or call 678-CELT-POD to leave a voicemail message. That's 678-235-8763. Today's voicemail is from...   This Week in Celtic Music 0:21"Fizzbuzz" by NUAfrom BOLD (2013) on iTunes 4:33"Love and Freedom" by Oltafrom Step It Out (2014) on iTunes 6:43"Blast O'Reels" by The Willis Clanfrom Chapter One - Roots (2012) on iTunes 12:26"The Liberty" by Poitinfrom Wish (2014) on iTunes 16:02"Velt Leen" PerKeltfrom Dowry of a Troll Woman (2013) on iTunes 18:32Celtic Music News 22:55"All For Me Grog" by Whiskey Bay Roversfrom Shantyman's Folly (2013) on iTunes 27:02"Si Bheag Si Mhor / O'carolan's Concerto" by Telenn Trifrom Telenn Tri (2011) on iTunes 33:01"8 Bells" by Dr. Rev. Mr. Cheeks Millerfrom My Own Brand of Crazy (2013) on iTunes 37:31Listener Feedback 41:02"Bonnie Ship the Diamond" by Keltikonfrom Agenbite of Inwit (2014) on iTunes 45:20"Battle of Culloden" by First Highland Watchfrom First Highland Watch (2014) on iTunes 49:11"Donegal Moonlight" by The Gleasonsfrom Let It Go (2013) on iTunes 54:07"Billy McConnell" by McCrae's Battalionfrom Armistice Day (2013) on iTunes 58:48"The Salley Gardens" by Brian Boru Irish Pipe Bandfrom Brian Boru Irish Pipe Band 40th Anniversary on iTunes The Irish & Celtic Music Podcast was produced by Marc Gunn, The Celtfather. If you enjoyed the music you heard, support the artists in this show. Buy their music. Then tell your friends to visit CelticMusicPodcast.com

Mark and Gordon talk about the hiring process at thoughtbot, using code exercises in the interview process, and how they manage to keep from being the smartest people in the room. Justified Go Deadwood Aaron Vegh FizzBuzz thoughtbot’s Playbook Jack Nutting’s author page on Amazon Impostor Syndrome

En esta ocasión presentamos un nuevo formato del podcast en donde estaremos realizando una nueva actividad de nombre Coding Dojo, en donde, invitamos a los participantes a realizar un par de Coding Katas: FizzBuzz y StringCalculator. Te invitamos a que conozcas estos ejercicios y que veas la interacción que tuvimos durante la realización de nuestro Dojo. De verdad la pasamos muy bien...

Scott and Carl talk about the "FizzBuzz" test and try to come up with practical techniques for hiring engineers and technical folks.