Podcasts about QBasic

What drives someone to publish 600+ issues of a Postgres newsletter for over a decade? In Episode 28 of Talking Postgres with Claire Giordano, Peter Cooper—creator of Postgres Weekly—shares how his days of rustic programming and QBASIC fanzines on Usenet led to a newsletter empire that now reaches nearly half a million developers each week. We dig into the BBC's "big tent" editorial influence, an accidental business model that just worked, and the perils of "temporary" hacks. Plus: spam filters, a Photoshop addiction, and one very cheesy story (dairy-free).Links mentioned in this episode:Newsletter: Postgres WeeklyCooperpress: List of newslettersNewsletter: Latest issue of Postgres Weekly on Jun 19, 2025Newsletter: Postgres Weekly issue with horrible graphicNewsletter: Very first issue of Postgres Weekly on Mar 13, 2013Newsletter: Ruby Weekly, the first Cooperpress newsletterBook: Beginning Ruby Third Edition, by Peter CooperPodcast episode: How I got started as a developer (& in Postgres) with David RowleyFeed reader: FeedbinGitHub repo: feedbin/feedbinFeed reader: FeederEmail testing software: LitmusGitHub repo: MGML markup language for emailPaper: The Design of PostgresGitHub repo: PGRX for building Postgres extensions in RustPodcast news: Podnews.net for daily briefings about podcastsWikipedia page: BBC MicroWikipedia page: ZX SpectrumCal invite: LIVE recording of Ep29 of Talking Postgres to happen on Wed Jul 9, 2025

This week, Frank sat down with Dr. Jacob Leverich—Stanford PhD, cofounder of Observe, and a veteran of the Google MapReduce team and Splunk. Jacob's journey, from tinkering with video game code as a kid, to innovating at the cutting edge of distributed systems and energy efficiency, is as inspiring as it is informative.Key TakeawaysEarly Tech Roots: Hear how curiosity with QBasic and classic PCs (think IBM PCXT and Commodore) put Jacob on a path to high-impact data engineering.MapReduce, Dremel, & the Rise of Big Data: Jacob pulls back the curtain on working with some of the most influential data processing tools at Google and how these systems shifted the entire data landscape (hello, BigQuery!).Building Efficient Systems: It's not just about scale—energy efficiency and performance optimization are the unsung heroes of today's data infrastructure. Jacob explains why making things “just work” isn't enough anymore.The Realities of Ops & Observability: Remember the days of grepping logs at 2AM? There's a better way. Jacob shares how platforms like Observe help teams consolidate, visualize, and act on operational data—turning chaos into actionable insight.Bridging Data & Ops: The lines between data observability and traditional ops are blurring, and Jacob's unique experience shows how best practices from data warehousing are finally making ops smoother (and less sleepless).Power Concerns & the Future: As data grows, so does energy consumption in data centers. Find out why optimization isn't just good for performance—it's key to sustainability.Timestamps00:00 Interview with Jacob Levrich05:59 Journey into Game Programming06:43 "Pursuing Fast Video Game Code"10:23 Data Processing and Power Efficiency16:11 Snowflake's Transformative Database Approach19:18 Journey to Data Management Industry21:37 Data Products: Solving Core Challenges27:07 Early Web Log Analysis Techniques28:57 Consolidating Data for Efficiency33:23 Specialized Tools and Context Switching35:43 Unique Dual-Expertise in Tech38:58 User-Centric Business Strategies42:13 IP Data Analysis in Cloud47:23 Electricity Transport Upsets Local Farms48:25 Shift to Parallel Computing52:10 Hardware Specialization & Software Optimization57:32 "Stay Data Driven"

How does an early fascination with coding evolve into a career in the cutting-edge fields of Silicon Valley and aerospace engineering? Nico Zeitlin joins us to share his remarkable journey, starting from his childhood days writing code in QBasic, inspired by his older brother, to earning a degree in computer engineering from the University of Buenos Aires. Through his story, Nico reveals how a sense of freedom and continuous learning keeps him feeling most alive, driving his ambitious career path from Argentina to the heart of the American tech industry.What does it take to navigate career challenges during Argentina's financial crises while juggling a family business and academic pursuits? Listen as Nico recounts his high school job writing software for Palm Pilots, his diverse responsibilities in the family business, and the first transformative experiences with the internet in coffee shops. Nico's reflections provide a poignant reminder of how far technology has come and its profound impact on human learning and evolution.How does one maintain personal growth and resilience through professional highs and lows, particularly when balancing career and parenthood? Nico shares invaluable insights into the importance of alignment and purpose in his work, the emotional impact of professional setbacks, and the joy of pursuing childhood passions. With heartfelt advice on embracing continuous evolution and growth, Nico's story is an inspiring testament to the power of resilience and the Sea Squirt  Effect in making bold decisions and driving positive change.You can reach out to Nico on LinkedIn: https://www.linkedin.com/in/nicozeitlin/There is a wealth of information available and only so much time in the day. Therefore, I truly appreciate you spending some of your valuable time listening to this podcast. Your feedback is very important so please reach out to me on LinkedIn or over email: alla@evolvexlabs.com.You can support us by leaving a review for this podcast, recommending it to a friend or sharing your favorite takeaways by tagging us on IG @theseasquirteffect. Doing so will help us reach more listeners like you!Apply for human performance coaching program.Follow me on IG: @evolvewithallaMusic credits & copyright by "Odin v olen'yem parke" ("Один В Оленьем Парке").

In the latest episode of the "Giant Robots On Tour" podcast, hosts Rémy Hannequin and Sami Birnbaum welcome Marc G. Gauthier, a solopreneur and startup coach, who shares his journey from software development to becoming the founder and developer of The Shadow Boxing App. Marc describes how his interest in software engineering began at a young age with QBasic and evolved through various leadership roles at companies like Drivy (now Getaround) and Back Market. His early passion for gaming led him to learn coding, and over time, he naturally transitioned into management roles, finding excitement in organizing and leading teams while maintaining his love for building products. During the episode, Marc discusses the challenges and intricacies of scaling startups, emphasizing the importance of balancing speed and reliability in software development. He recounts his experiences in leadership positions, where he faced the dual task of managing rapid team growth and maintaining software efficiency. Marc also shares insights into the startup ecosystem, noting that most startups struggle to achieve success due to a combination of market timing, team dynamics, and resource management. His own venture, The Shadow Boxing App, represents his attempt to return to hands-on coding while leveraging his extensive experience in startup coaching and advising. Marc also touches on the role of AI in the future of software development, expressing cautious optimism about its potential to augment human workflows and automate repetitive tasks. He advises current and aspiring developers to embrace AI as a tool to enhance their capabilities rather than a replacement for human ingenuity. Marc concludes by highlighting the importance of realistic expectations in the startup world and the need for continuous learning and adaptation in the ever-evolving tech landscape. Getaround (https://getaround.com/) Follow Getaround on LinkedIn (https://www.linkedin.com/company/getaround/), Facebook (https://www.facebook.com/getaround), X (https://twitter.com/getaround), YouTube (https://www.youtube.com/getaround), or Instagram (https://www.instagram.com/getaround/). Back Market (https://www.backmarket.com/en-us) Follow Back Market on LinkedIn (https://www.linkedin.com/company/back-market/), Facebook (https://www.facebook.com/BackMarketCom), X (https://x.com/backmarket), or Instagram (https://www.instagram.com/backmarket). The Shadow Boxing App (https://shadowboxingapp.com/) Follow Marc Gauthier on LinkedIn (https://www.linkedin.com/in/marcggauthier/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Transcript: RÉMY:  This is the Giant Robots Smashing Into Other Giant Robots podcast, the Giant Robots on Tour series coming to you from Europe, West Asia, and Africa, where we explore the design, development, and business of great products. I'm your host, Rémy Hannequin. SAMI: And I'm your other host, Sami Birnbaum. RÉMY: If you are wondering who we are, make sure you find the previous podcast where we introduced the Giant Robots on Tour series by throwing random icebreakers at each other. And find out that Jared likes it when someone takes the time to understand someone else's point of view. Joining us today is Marc G Gauthier, a Solopreneur and Startup Coach. Marc, you used to be VP of Engineering at Drivy, now known as Getaround, and also Director of Engineering at Back Market. You also have been a coach and advisor to a startup for over a decade. Currently, your current adventure is being the Founder and Developer of The Shadow Boxing App available on the Apple App Store. We always like to go back to the start with our guests. Everyone has a story, and we are interested in your journey. So, Marc, what led you into the world of software engineering in the first place? MARC: Hello. Well, happy to be here. And, yeah, I started getting into software development quite a long time ago. I actually learned software development with QBasic when I was something like seven. And, from there, I just kept on learning, learning, and learning and got into school for it, then worked in different startups, and then moved into more leadership position management. And I'm now, like, coaching people and building my own product. What do you want to get? Because it's broad. I've been doing it for quite a while. Like, I don't think the QBasic days are that insightful. The only thing I remember from that time is being confused by the print comment that I would expect it to print on my printer or something, but it didn't; it just printed on the screen. That's the only thing I have from back then. SAMI: Why at seven years old? And I'm taking you back too far, but at seven years old, I was probably collecting Pokémon cards and possibly like, you know, those football stickers. I don't know if you had the Panini stickers. MARC: Oh yeah, I was doing that as well. SAMI: But you were doing that as well. But then what drove you at that age? What do you think it was that made you think, I want to start learning to code, or play around with the computer, or get into tech? MARC: [laughs] Yeah. Well, I remember, back then, I really wanted a computer to play games. Like, I had a friend who had a computer. He was playing games, and I wanted to do that. So, I was asking my mom to have a computer, and she told me, "Yeah, you can have one." And she found a really old computer she bought from a neighbor, I think. But she told me like, "I don't know anything about it. So, you have to figure it out and set it up." And she just found someone to kind of help me. And this person told me to, like, take the computer apart. She taught me a bit of software development, and I kind of liked it. And I was always trying to change the games. Back then, it was way easier. You could just edit a sound file, and you would just edit the sound file in the game, so yeah, just learning like this. It wasn't really my intent to learn programming. It just kind of happened because I wanted to play video games really. SAMI: That's really cool. It's really interesting. Rémy, do you remember how...how did you first get...do you remember your first computer, Rémy? RÉMY: My first computer, I think I remember, but the first one I used it was, first, a very long time ago. I discovered that it was an Apple computer way, way later when I discovered what Apple was and what computers were actually. And I just remember playing SimCity 2000 on it, and it was amazing. And we had to, you know, cancel people from making phone calls while we were on the computer because of the internet and all the way we had to connect to the internet back then. And after that, just, I think, Windows 95 at home. Yeah, that's the only thing I can remember actually. Because I think I was lucky, so I got one quite early. And I don't really remember not having one, so I was quite lucky with that. And so, I was always kind of in the computer game without being too much [inaudible 05:02] [laughs]. SAMI: Yeah, I think that's similar to me as well. Like, it's interesting because my initial introduction to computers would have been watching my older brothers kind of play computer games and actually being told to get out the room, or like, you know, "We're busy now. Don't bother us." And then, what actually happened is when they left the room, I managed to play what they were playing, which was the first ever GTA. I don't know if anyone ever played this, but it is so cool if you look back on it. You could probably find emulators online, but it was, like, a bird's eye view, like, way of operating. And it was probably also that drive where you get frustrated on a computer because you want to do something, so, like you were saying, Marc, where you went to edit the sound files because you want to change something. You want to do something. I definitely think that is something which I felt as well is that frustration of I want to change this thing. And then, that kind of gets into well, how does it work? And if I know how it works, then I can probably change it. MARC: Yeah. And once you figure out how things work, it's also really exciting. Like, once you figure out the initialization file on Windows, like, you can edit, like, what level is unlocked right away. It's kind of cheat codes but not really. And there are some really fun ones. Like, I would edit sound files for racing games. And, usually, it's just a base sound file, and then they would pitch shift the sound to make it sound like an engine. So, if you record your voice, it's just really funny. RÉMY: So, Marc, you mentioned moving to management positions quite early. Do you remember what made you do this move? Was it for, like, a natural path in your career, or was it something you really wanted from the first part of your career as a developer? What happened at this moment? MARC: Yeah, that was not completely planned. Like, I don't think I really plan my career precisely. It's just something that happens. So, I joined Drivy after, like, I was already a software engineer for, like, five years at that point. I joined as a lead backend engineer. I did that for three years. And after three years, the company went from...I think there was, like, three software engineers to a dozen. There was a need for more structure, and the CTO, at the time so, Nicolas, wanted to focus more on products. And it was hard to do both, like do the product side, the design, the data, and do the engineering, the software, and so on. So, he wanted to get a bit away from software engineering and more into product. So, there was a gap in the organization. I was there. I was interested to try, and I was already doing some more things on the human side, so talking to people, organizing, internal communication. I kind of liked it. So, I was excited to try, give it a try. It was really interesting. I found that it was a different way to have an impact on the team. I just kept doing it. And my plan was to keep doing it until I'm bored with it. And I'm still not bored with it, even though you kind of miss just actually building the software yourselves, actually coding. So, that's also why I'm trying something different right now with my mobile app adventure. SAMI: Right. So, on the side, you've got this Shadow Boxing App, which, in my dedicated research, I downloaded and had a go with it. MARC: Did you actually try it, or did you just click around? SAMI: I did a proper workout, mate. I did. I put myself as, like, the absolute beginner. I did it on my MacBook Pro. I know it's built for iPad or iPhone, but it still worked amazingly well. And it kind of reminded me why I stopped doing boxing because it's hard work. MARC: [laughs] Yeah, it is. SAMI: It's not a gimmick this thing, right? So, it's like, the best way to describe it is it's essentially replacing if I was to go to the gym and have a trainer who's telling me kind of the moves to make or how to do it, then this kind of replaces that trainer. So, it's something you can do at home. It was really cool. I was surprised, actually. I thought, at the beginning, it's not going to be that interactive, or it won't actually be as hard or difficult as a workout, and it really was. So, it's, yeah, it was really cool, really interesting to try it. And going into that, you say you wanted to get back more into coding, and that's why you are doing this kind of, like, app on the side, or it allowed you to kind of do a bit more coding away from the people management. You've been involved in a lot of startups, and I actually often get...as consultants, when we work at thoughtbot, we get a lot of people who come with different startup ideas. When you look back at all the startups you've been involved with, do you think more startups are successful than those that fail? Or have you seen a lot of startups...actually, people come with these great ideas; they want to build this amazing product, but it's actually really hard to be a successful product? MARC: I think it's [inaudible 10:22] how to have the right idea, be at the right spot at the right time, build the right team, get enough momentum. I think most startups fail, and even startups that are successful often can be the result of a pivot. Like, I know companies that pivoted a bunch of times before finding any success. So, it's really hard actually...if I take my past four companies, only two are still alive. Like, the first two went under. Actually, there's even more companies that went under after I left. Yeah, it's just really hard to get anything off the ground. So, yeah, it's complicated, and I have a lot of respect for all the founders that go through it. For The Shadow Boxing App, I worked on it for the past three years, but I'm only working on it almost full-time for the past two months. And it was way safer. I could check the product-market fit. I could check if I enjoyed working on it. So, I guess it was easier. I had the luxury of having a full-time job. Building the app didn't take that much time. But to answer your question, I think, from my experience, most startups fail. And the ones that succeed it's kind of lightning in a bottle, or, like, there's a lot of factors that get into it. It's hard to replicate. A lot of people try to replicate some science, some ideas. They go, oh, we'll do this, and we'll do that. And we use this technique that Google uses and so on, but it's never that straightforward. SAMI: Yeah, I'm so happy you said that because I think it's a real brutal truth that I'd also say most of the startup projects that I've worked on probably have failed. Like, there's very few that actually make it. It's such a saturated market. And I think, I guess, in your role as advising startups, it's really good to come in with that honesty at the beginning and to say, "It's a big investment if you want to build something. Most people probably aren't successful." And then, when you work from that perspective, you can have, like, way more transparent and open discussions from the get-go. Because when you're outside of tech...and a lot of people have this idea of if I could just get an app to do my idea, I'm going to be the next Facebook. I'm going to be the next, you know, Amazon Marketplace. And it just kind of isn't like that. You've got these massive leaders in Facebook, Amazon, Google, Netflix. But below that, there's a lot of failures and a massively saturated market. So, yeah, just, it's so interesting that you also see it in a similar way. MARC: What I saw evolve in the past 10 years is the fact that people got more realistic with it. So, maybe 10 years ago, I would have people coming to me with just the most ridiculous idea, like, you know, I'll do Airbnb for cats. And really think, yeah, I just need a good idea, and that's it. But now I feel like people kind of understand that it's more complicated. There's way more resources online. People are more educated. They also see way more successes. Failures are also a bit more advertised. We saw a bunch of startups just go under. It feels like every month I get an email from a tool I used in the past saying, "Oh, we're shutting down," and so on. So, I think it's not as bad as 10 years ago where weekly I would have just people asking me, "I want to build this app," and the app would be just the most ridiculous thing or something that would be really smart, but it's really like, "Oh, I want to do, like, food delivery but better than what exists." It's like, yeah, that's a really good idea, but then you need...it's not only software. There's logistics. There's so much behind it that you don't seem to understand just yet. But, as a coach, so, what I'm doing is I'm helping startups that are usually before or after series A but not too large of startups just go to the next stage. And people are really aware of that and really worried. Like, they see money going down, market fit not necessarily being there. And they know, like, their company is at risk. And especially when you talk to founders, they're really aware that, you know, everything could be collapsing really quickly. If they make, like, three really bad decisions in a row, you're basically done. Obviously, it depends on the company, but yeah, people are more aware than before, especially nowadays where money is a bit harder to get. Let's say two years ago, there was infinite money, it felt like. Now it's more tight. People are more looking at the unit economics precisely. So, people need to be more realistic to succeed. RÉMY: What's the kind of recurrent struggle the startups you coach usually face? Apparently, it quite changed in the past decade, but maybe what are the current struggles they face? MARC: It really depends. It's kind of broad. But, usually, it would be, let's say, a startup after their first round of funding, let's say, if you take startups that are looking for funding. So, you usually have a group of founders, two to four, usually two or three, that are really entrepreneurs that want to bootstrap some things. They're builders. They're hacking things together, and they're really excited about the product. And, suddenly, fast forward a few years, they're starting to be successful, and they have to lead a team of, you know, like, 50 people, 100 people, and they weren't prepared for that. They were really prepared to, like, build software. Like, especially the CTOs, they are usually really great hackers. They can, like, create a product really quickly. But, suddenly, they need to manage 30 engineers, and it's completely different, and they're struggling with that. So, that's a common problem for CTOs. And then, it creates a bunch of problems. Like, you would have CEOs and CTOs not agreeing on how to approach the strategy, how to approach building a thing. What should be the methodology? Something that worked with 3 engineers around the table doesn't work with 50 engineers distributed in 5 countries. And if it's your first time being a CTO, and often founders of early-stage startups are first-time CTOs, it can be really hard to figure out. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. RÉMY: In your past companies, so you've been VP and CTO. So, in your opinion, what's the best a VP or a CTO can bring to a scaling startup? What are your best tips to share? MARC: I guess it depends [laughs], obviously, like, depending on the stage of the company, the size of the company. For instance, when I was at Drivy, at some point, the most important thing was scaling the team hiring, and so on. But, at some point, we got acquired by Getaround, and the priorities got shifted. It was more like, okay, how do you figure out this new setup for the company and the team? Like, what is good? What is bad? How do you communicate with the team? How do you get people to stay motivated when everything is changing? How do you make sure you make the right decisions? And then, when I joined Back Market, Back Market when I joined, I had a team of a bit less than 12 engineers reporting directly to me. And after a bit more than a year, I had 60, and I hired most of them. So, here the challenge was just scaling insanely fast. Like, the company is really successful. Like, Back Market is selling refurbished electronics in a mission to, you know, provide a viable alternative to buying new electronics. So, it's basically, do you want a smartphone that is both cheaper and more ecologically viable? And most people would say yes to that. So, a company is insanely successful, but it's really hard to scale. So, at that point, the role was, okay, how do you make sure you scale as well as possible with a lot of pressure while still leaving the team in a state that they're able to still build software? Because it's just really chaotic. Like, you can't, like, 5X your team without chaos. But how do you minimize that but still go really fast? SAMI: Yeah. So, not only did I try that Shadow App. I actually went on that Backup website. What's it called? It's not called Backup. What's it called again? MARC: Back Market. SAMI: Back Market. Thank you. Yeah, it was really cool. I checked my old iPhone SE from 2020, which I've kept for about...over three years, I've had this iPhone. And they said they would give me $72 for it, which was really cool. So, it sounds like a really cool idea. MARC: That's something we worked on, which is, basically, if you have any old phones in your drawer, it's a really bad spot for them. And so, there's a service. You go on the website. You say, "I have this, I have that; I have this, I have that." And either we buy it from you, or we just take it away from you, and we recycle them, which is much better than just having them collect dust. SAMI: Yeah, no, it's a great idea. What interested me when you were speaking about kind of these different positions that you've been in, I was almost expecting you to talk about maybe, like, a technical challenge or code complexity difficulty. But, actually, what you've described is more people problems. And how do we scale with regards to people, and how do we keep people motivated? So, I guess using that experience, and this might be counterintuitive to what a lot of people think, but what do you think is the hardest thing about software development? I know there could be many things. But if you had to pick something that is the most difficult, and maybe we can all have an answer to what we think this is, but starting with you, Marc, what do you think is the hardest thing about software development then? MARC: What I saw is how do you build something that works for enough time to bring value to the customers? So, it's easy to hack something together pretty quickly and get it in front of people, but then it might not be reliable. It might break down. Or you could decide to build something perfect and spend, like, two years on it and then ship it, and then it's really stable, but maybe it's not what people want. And finding this balance between shipping something fast, but shipping something that is reliable enough for what you're building. Obviously, if you're building a health care system, you will have more, like, the bar will be higher than if you build, like, Airbnb for cats. Finding this balance and adjusting as you go is really hard. So, for instance, when do you introduce caching? Because, obviously, caching is hard to do right. If you don't do it, your site will be slow, which can be okay for a time. But then if you introduce it too late, then it's really hard to just retrofit into whatever you already have. So, finding the right moment to introduce a new practice, introduce a new technology is tricky. And then, like, I talked a lot about the people, and it's also because I spent quite a bit of time in leadership position. But, at the end of the day, it will be the people writing the code that gets the software to exist and run. So, having people aligned and agreeing on the vision is also key because unless I'm the only developer on the project, I can't really make all decisions on things that are going to get built. So, figuring out how to get people motivated, interested in just building in the same direction is really important. It's really easy. Like, one thing with Drivy, when I was there, that was really fun to see, like, many people have this reaction, especially the more senior people joining the company. They would see the engineering team, and they were really, really surprised by how small it was because we were being really, really efficient. Like, we were paying really close attention to what we would work on. So, kind of technology we would introduce would be quite conservative on both to really be able to deliver what is the most important. So, we were able to do a lot with, honestly, not a lot of people. And I think this is a great mark for success. You don't need a thousand people to build your software if you ask the right question, like, "Do I need to build X or Y?" and always having these discussions. RÉMY: What's your opinion on that, Sami? SAMI: Yeah, I guess it changes. Like, for example, today, the hardest thing about software development was just getting Jira to work. That has literally ruined my whole day. But I've found, for me, what I find is the most difficult thing to do is making code resilient to change. What I mean by that is writing code that's easy to change. And a lot of that, I guess, we try to work on at thoughtbot, as consultants, is following kind of design principles and best practices and certain design patterns that really make the code easy to change. Because that, I think, when I'm writing code is the biggest challenge. And where I feel when I'm working with our clients one of the biggest things they can invest in, which is difficult because there's not a lot of visibility around it or metrics, is ensuring that code that's written is easy to change because, at some point, it will. And I've also worked on systems which are bigger, and when you can't change them, conversations start happening about the cost of change. Do we rewrite it from the ground up again? And that opens a whole different can of worms. So, that, for me, I think, is definitely one of the hardest things. How about yourself, Rémy? RÉMY: I don't know about the most difficult. I mean, there are many things difficult. But I remember something that I had to put extra effort, so maybe it was one of the most difficult for me. When I started being a consultant, when I joined thoughtbot was to understand what's the boundary between executing and giving an advice? So, basically, I discovered that when you're a consultant, but it works also when you're a developer in a team, you know, you're not just only the one who is going to write the code. You're supposed to be also someone with expertise, experience to share it and to make the project and the team benefit from it. So, at some point, I discovered that I should not just listen to what the client would say they want. Obviously, that's what they want, but it's more interesting and more difficult to understand why they want it and why they actually need, which could be different from what they want. So, it's a whole different conversation to discover together what is actually the necessary thing to build, and with your expertise and experience, try to find the thing that is going to be the most efficient, reliable, and making both the client and the customers happy. MARC: Yeah. And as software engineers, it's really easy to get excited about a problem and just go, "Oh, I could solve it this way." But then you need to step back and go, "Well, maybe it doesn't need fixing, or we should do something completely different." At some point, I was working with a customer service organization. In their workflows, they had to go on, let's say, five different pages and click on the button to get something to do one action. And so, what they asked for is to have those five buttons on one single page, and so, they could go, click, click, click, click, click. But after looking at it, what they needed is just automation of that, not five buttons on the page. But it's really easy to go, oh, and we could make those buttons, like, kind of generic and have a button creator thing and make it really fancy. When you step back, you go, oh, they shouldn't be clicking that many buttons. SAMI: Yeah, that makes so much sense because just in that example...I can't remember where I read this, but every line of code you write has to be maintained. So, in that example where you've got five buttons, you're kind of maintaining probably a lot more code than when you've got the single button, which goes to, I don't know, a single action or a method that will handle kind of all the automation for you. And that's also, you know, driving at simplicity. So, sometimes, like, you see this really cool problem, and there's a really cool way to solve it. But if you can solve it, you mentioned, like, being conservative with the type of frameworks maybe you used in a previous company, like, solve it in the most simple way, and you'll thank yourself later. Because, at some point, you have to come back to it, and maintain it, change it. Yeah, so it makes a lot of sense. And, Marc, you said you started when you were 7, which is really young. Through that amount of time, you've probably seen massive changes in the way websites look, feel, and how they work. In that time, what's the biggest change you actually think you've seen? MARC: The biggest thing I saw is, when I started, internet didn't exist or at least wasn't available. Like, I remember being at school and the teacher would ask like, "How many people have a computer at home?" And we'd be like, two or three people. So, people didn't have internet until I was like 14, 15, I'd say. So, that's the biggest one. But, let's say, after it started, they just got more complicated. Like, so, the complexity is getting crazy. Like, I remember, at some point, where I saw I think it was called Aviary. It was basically Photoshop in the browser, and I was just insanely impressed by just the fact that you could do this in the browser. And, nowadays, like, you've got Figma, and you've got so many tools that are insanely impressive. Back then, it was just text, images, and that's it. I actually wrote a blog post a few years ago about how I used to build websites just using frames. So, I don't know if you're familiar with just frames, but I didn't really know how to do divs. So, I would just do frames because that's what I understood back then, again, little kid. But it was kind of working. You were dealing with IE 5 or, like, I remember, like, professionally fixing bugs for IE 5.5 or, like, AOL, like, 9, something ridiculous like this. So, building a website just got way easier but also way more complicated, if that makes sense. Like, it's way easier to do most things. For instance, I don't know, like, 20 years ago, you wanted a rounded corner; you would have to create images and kind of overlay them in a weird way. It would break in many cases. Nowadays, you want rounded corners? That's a non-topic. But now you need, like, offline capabilities of your website. And, in a lot of cases, there's really complex features that are expected from users. So, the bar is getting raised to crazy levels. SAMI: Yeah, I always wonder about this. Like, when you look at how the internet used to be and how people develop for the internet, and, like you're saying, now it's more complex but easier to do some things. I don't know if as developers we're making things harder or easier for ourselves. Like, if you look at the amount of technology someone needs to know to get started, it grows constantly. To do this, you have to add this framework, and you need to have this library, and maybe even a different language, and then, to even host something now, the amount of technologies you need to know. Do you think we're making things harder for ourselves, or do you think easier? MARC: Well, I guess there's always back and forth, like, regarding complexity. So, things will get really, really complex, and then someone will go, "Well, let's stop that and simplify." That's why, like, I'm seeing some people not rejecting React and so on, but going a simpler route like Rails has options like this. There's people using HTMX, which is really simple. So, just going back to something simpler. I think a lot of the really complex solutions also come from the fact that now we have massive teams building websites, and you need that complexity to be able to handle the team size. But it's kind of, then you need more people to handle the complexity, and it's just getting crazy. Yeah, honestly, I don't know. I'm seeing a lot of things that feel too complex for...like, the technology feels really complicated to accomplish some things that should be simple or at least feel simple. But, at the same time, there are things that got so simple that it's ridiculous like just accepting payment. I remember, like, if you wanted to accept payment on a site, it would be months of work, and now it takes a minute. You just plug in Stripe, and it works. And it's often cheaper than what it used to be. So, it's kind of...or deploying. You mentioned deploying can be really hard. Well, you don't need to have a physical server in your room just eating your place up to have your website, your personal website running. You just push it to Vercel, or Heroku, or whatever, or just a static page on S3. So, this got simpler, but then, yeah, you can get it to be so much more crazy. So, if you host your static website on S3, fairly simple. But then if you try to understand permissions on S3, then, you know, it's over. RÉMY: I don't know if it's really in the path of our discussion. I just wanted to ask you, so this is the on tour series, where we...so, usually, the Giant Robots podcast used to be a little bit more American-centric, and this on tour is moving back to the other side of the Atlantic with, again, Europe, West Asia, and Africa. You've been part of a company, Drivy, which expanded from France to neighboring countries in Europe. What could you tell our listeners about how to expand a business internationally? MARC: That's a tough question, especially in Europe. Because I know looking from the outside, like, if you're from the U.S. and you look at Europe, it feels like, you know, a uniform continent, but really, it's very different. Like, just payment methods are different. Culture is very different. For instance, when I was working at Back Market in France, one of the branding aspects of Back Market was its humor. Like, we would be making a lot of jokes on the website, and it would work really well in France. Like, people would love the brand. But then you expand to other countries, and they just don't find that funny at all. Like, it's not helping at all, and they're expecting a different tone of voice. So, it's not just, okay, I need to translate my own page; it's I need to internationalize for this market. I guess my advice is do it country by country. Sometimes I see companies going like, oh, we opened in 20 different countries, and you go, how even do you do that? And spend some time understanding how people are using your product or, like, a similar product locally because you would be surprised by what you learn. Sometimes there's different capabilities. For instance, when Drivy went to the UK, there's so much more you can learn. There's the government database that you can look up, and it really helps with managing risk. If people are known to steal cars, you can kind of figure it out. I'm simplifying a bit, but you can use this. You don't have that in France because we just don't have this solution. But if you go to Nordic countries, for instance, they have way more electric vehicles, so maybe the product doesn't work as well. So, it's really understanding what's different locally and being willing to invest, to adapt. Because if you go, okay, I'm going to open in the Netherlands but you don't adopt the payment methods that are used in the Netherlands, you might as well not open at all. So, it's either you do it properly and you kind of figure out what properly means for your product, or you postpone, and you do it well later. Like, right now, I'm struggling a bit with my app because it's open. So, it's on the App Store, so it's open globally. And it's a SaaS, so it's simpler, but I struggle with language. So, it's in French and English. I spoke both of this language, obviously, French better than English. But I think I'm doing okay with both. But I also built it in Spanish because I speak some Spanish fairly poorly, and I wanted to try to hit a different market like the Mexican market that are doing boxing quite a lot. But the quality doesn't seem there. Like, I don't have the specific boxing lingo, so I'm contemplating just rolling it back, like, removing the Spanish language until I get it really well, maybe with a translator dedicated to it that knows boxing in Spanish. Because I work with translators that would translate, but they don't really know that, yeah, like a jab in boxing. In Spanish, they might also say, "Jab." They won't translate it to, like, [inaudible 38:31]. SAMI: Yeah. At thoughtbot, we have one of our clients they wanted to release their app also internationally. And so, we had also kind of a lot of these problems. We even had to handle...so, in some languages, you go from left to right, right to left. So, that kind of also changed a lot of the way you would design things is mainly for people who are going from left to right. I mean, that's thinking kind of more Europe, U.S.-centric. And then, you could be releasing your app into a different country where they read the other direction. So, yeah, a lot of this stuff is really interesting, especially the culture, like you're saying. Do they find this humor funny? And then, how do they translate things? Which, in my head, I think, could you use AI to do that. Which is a nice segue into, like, the mandatory question about AI, which we can't let you go until we ask you. MARC: [laughs] SAMI: So, okay, obviously, I'm going to ask you about your thoughts on AI and where you think we're headed. But I've seen something interesting, which I don't know if this is something that resonates with you as well. I've seen a bit of a trend where the more experienced developers or more senior developers I talk to seem to be a bit more calm and less concerned. Whereas I would consider myself as less experienced, and I feel, like, kind of more anxious, more nervous, more jumping on the bandwagon sort of feeling of keeping an eye on it. So, I guess, with your experience, what are your thoughts on AI? Where do you think we are headed? MARC: That's a big question, and it feels like it's changing month to month. It feels way more interesting than other trends before. Like, I'm way more excited about the capabilities of AI than, like, NFTs or stuff like this. I'm actively using AI tooling in my app. I was using some AI at Back Market. So, it's interesting. There's a bunch of things you can be doing. Personally, I don't think that it's going to, like, make programming irrelevant, for instance. It will just change a bit how you will build things just like...so, we talked about what changed in the past. For instance, at some point, you would need a team of people moving around physical computers and servers and just hooking them up to be able to have a website. But now, most people would just use a cloud provider. So, all those people either they work for the cloud provider, or they're out of a job. But really what happened is most shifted into something different, and then we focused on something different. Instead of learning how to handle a farm of servers, we learned how to, I don't know, handle more concurrency in our models. And I think when I look back, I feel like, technically, maybe, I don't know, 70%, 80% of what I learned is now useless. Like, I spent years getting really good at handling Internet Explorer as a web developer. Now it's just gone, so it's just gone forever. And it feels like there's some practice that we're having right now that will be gone forever thanks to AI or because of AI, depending on how you look at it. But then there'll be new things to do. I'm not sure yet what it will be, but it will create new opportunities. There are some things that look a bit scary, like, or creepy. But I'm not worried about jobs or things like this. I'm a bit concerned about people learning programming right now because, yeah, there's a lot of hand-holding, and there's a lot of tools that you have to pay to get access to this hand-holding. So, if you're a student right now in school learning programming and your school is giving you some AI assistant, like Copilot or whatever, and this assistant is really good, but suddenly it goes away because you're not paying anymore, or, like, the model change, if you don't know how to code anymore, then it's a problem. Or maybe you're not struggling as much. And you're not digging deep enough, and so you're learning slower. And you're being a bit robbed of the opportunity to learn by the AI. So, it's just giving you the solution. But it's just, like, the way I use it right now, so I don't have an assistant enabled, but I usually have, like, a ChatGPT window open somewhere. It's more like a better Stack Overflow or a more precise Stack Overflow. And that helps me a lot, and that's really convenient. Like, right now, I'm building mostly using Swift and Swift UI, but I'm mainly a Ruby and JavaScript developer. So, I'm struggling a lot and being able to ask really simple questions. I had a case just this morning where I asked how to handle loading of images without using the assets folder in Xcode. I just couldn't figure it out, but it's really simple. So, it was able to tell me, like, right away, like, five options on how to do it, and I was able to pick the one that would fit. So, yeah, really interesting, but yeah, I'm not that worried. The only part I would be worried is if people are learning right now and relying way too much on AI. RÉMY: Well, at least it's positive for our job. Thank you for making us believe in a bright future, Marc. MARC: [laughs] RÉMY: All right. Thank you so much, Marc, for joining us. It was a real pleasure. Before we leave, Marc, if you want to be contacted, if people want to get a hold of you, how can you be contacted? MARC: There's two ways: either LinkedIn, look up Marc G Gauthier. Like, the middle initial is important because Marc Gauthier is basically John Smith in France. My website, which is marcgg.com. You can find my blog. You can find a way to hire me as a coach or advisor. That's the best way to reach out to me. RÉMY: Thank you so much. And thank you, Sami, as well. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have any questions or comments, you can email us at hosts@giantrobots.fm. You can find me on social media as rhannequin. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening, and see you next time.  AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Maggie, Linus, Geoffrey, and the LS crew are reuniting for our second annual AI UX demo day in SF on Apr 28. Sign up to demo here! And don't forget tickets for the AI Engineer World's Fair — for early birds who join before keynote announcements!It's become fashionable for many AI startups to project themselves as “the next Google” - while the search engine is so 2000s, both Perplexity and Exa referred to themselves as a “research engine” or “answer engine” in our NeurIPS pod. However these searches tend to be relatively shallow, and it is challenging to zoom up and down the ladders of abstraction to garner insights. For serious researchers, this level of simple one-off search will not cut it.We've commented in our Jan 2024 Recap that Flow Engineering (simply; multi-turn processes over many-shot single prompts) seems to offer far more performance, control and reliability for a given cost budget. Our experiments with Devin and our understanding of what the new Elicit Notebooks offer a glimpse into the potential for very deep, open ended, thoughtful human-AI collaboration at scale.It starts with promptsWhen ChatGPT exploded in popularity in November 2022 everyone was turned into a prompt engineer. While generative models were good at "vibe based" outcomes (tell me a joke, write a poem, etc) with basic prompts, they struggled with more complex questions, especially in symbolic fields like math, logic, etc. Two of the most important "tricks" that people picked up on were:* Chain of Thought prompting strategy proposed by Wei et al in the “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models”. Rather than doing traditional few-shot prompting with just question and answers, adding the thinking process that led to the answer resulted in much better outcomes.* Adding "Let's think step by step" to the prompt as a way to boost zero-shot reasoning, which was popularized by Kojima et al in the Large Language Models are Zero-Shot Reasoners paper from NeurIPS 2022. This bumped accuracy from 17% to 79% compared to zero-shot.Nowadays, prompts include everything from promises of monetary rewards to… whatever the Nous folks are doing to turn a model into a world simulator. At the end of the day, the goal of prompt engineering is increasing accuracy, structure, and repeatability in the generation of a model.From prompts to agentsAs prompt engineering got more and more popular, agents (see “The Anatomy of Autonomy”) took over Twitter with cool demos and AutoGPT became the fastest growing repo in Github history. The thing about AutoGPT that fascinated people was the ability to simply put in an objective without worrying about explaining HOW to achieve it, or having to write very sophisticated prompts. The system would create an execution plan on its own, and then loop through each task. The problem with open-ended agents like AutoGPT is that 1) it's hard to replicate the same workflow over and over again 2) there isn't a way to hard-code specific steps that the agent should take without actually coding them yourself, which isn't what most people want from a product. From agents to productsPrompt engineering and open-ended agents were great in the experimentation phase, but this year more and more of these workflows are starting to become polished products. Today's guests are Andreas Stuhlmüller and Jungwon Byun of Elicit (previously Ought), an AI research assistant that they think of as “the best place to understand what is known”. Ought was a non-profit, but last September, Elicit spun off into a PBC with a $9m seed round. It is hard to quantify how much a workflow can be improved, but Elicit boasts some impressive numbers for research assistants:Just four months after launch, Elicit crossed $1M ARR, which shows how much interest there is for AI products that just work.One of the main takeaways we had from the episode is how teams should focus on supervising the process, not the output. Their philosophy at Elicit isn't to train general models, but to train models that are extremely good at focusing processes. This allows them to have pre-created steps that the user can add to their workflow (like classifying certain features that are specific to their research field) without having to write a prompt for it. And for Hamel Husain's happiness, they always show you the underlying prompt. Elicit recently announced notebooks as a new interface to interact with their products: (fun fact, they tried to implement this 4 times before they landed on the right UX! We discuss this ~33:00 in the podcast)The reasons why they picked notebooks as a UX all tie back to process:* They are systematic; once you have a instruction/prompt that works on a paper, you can run hundreds of papers through the same workflow by creating a column. Notebooks can also be edited and exported at any point during the flow.* They are transparent - Many papers include an opaque literature review as perfunctory context before getting to their novel contribution. But PDFs are “dead” and it is difficult to follow the thought process and exact research flow of the authors. Sharing “living” Elicit Notebooks opens up this process.* They are unbounded - Research is an endless stream of rabbit holes. So it must be easy to dive deeper and follow up with extra steps, without losing the ability to surface for air. We had a lot of fun recording this, and hope you have as much fun listening!AI UX in SFLong time Latent Spacenauts might remember our first AI UX meetup with Linus Lee, Geoffrey Litt, and Maggie Appleton last year. Well, Maggie has since joined Elicit, and they are all returning at the end of this month! Sign up here: https://lu.ma/aiuxAnd submit demos here! https://forms.gle/iSwiesgBkn8oo4SS8We expect the 200 seats to “sell out” fast. Attendees with demos will be prioritized.Show Notes* Elicit* Ought (their previous non-profit)* “Pivoting” with GPT-4* Elicit notebooks launch* Charlie* Andreas' BlogTimestamps* [00:00:00] Introductions* [00:07:45] How Johan and Andreas Joined Forces to Create Elicit* [00:10:26] Why Products > Research* [00:15:49] The Evolution of Elicit's Product* [00:19:44] Automating Literature Review Workflow* [00:22:48] How GPT-3 to GPT-4 Changed Things* [00:25:37] Managing LLM Pricing and Performance* [00:31:07] Open vs. Closed: Elicit's Approach to Model Selection* [00:31:56] Moving to Notebooks* [00:39:11] Elicit's Budget for Model Queries and Evaluations* [00:41:44] Impact of Long Context Windows* [00:47:19] Underrated Features and Surprising Applications* [00:51:35] Driving Systematic and Efficient Research* [00:53:00] Elicit's Team Growth and Transition to a Public Benefit Corporation* [00:55:22] Building AI for GoodFull Interview on YouTubeAs always, a plug for our youtube version for the 80% of communication that is nonverbal:TranscriptAlessio [00:00:00]: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, partner and CTO at Residence at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:15]: Hey, and today we are back in the studio with Andreas and Jungwon from Elicit. Welcome.Jungwon [00:00:20]: Thanks guys.Andreas [00:00:21]: It's great to be here.Swyx [00:00:22]: Yeah. So I'll introduce you separately, but also, you know, we'd love to learn a little bit more about you personally. So Andreas, it looks like you started Elicit first, Jungwon joined later.Andreas [00:00:32]: That's right. For all intents and purposes, the Elicit and also the Ought that existed before then were very different from what I started. So I think it's like fair to say that you co-founded it.Swyx [00:00:43]: Got it. And Jungwon, you're a co-founder and COO of Elicit now.Jungwon [00:00:46]: Yeah, that's right.Swyx [00:00:47]: So there's a little bit of a history to this. I'm not super aware of like the sort of journey. I was aware of OTT and Elicit as sort of a nonprofit type situation. And recently you turned into like a B Corp, Public Benefit Corporation. So yeah, maybe if you want, you could take us through that journey of finding the problem. You know, obviously you're working together now. So like, how do you get together to decide to leave your startup career to join him?Andreas [00:01:10]: Yeah, it's truly a very long journey. I guess truly, it kind of started in Germany when I was born. So even as a kid, I was always interested in AI, like I kind of went to the library. There were books about how to write programs in QBasic and like some of them talked about how to implement chatbots.Jungwon [00:01:27]: To be clear, he grew up in like a tiny village on the outskirts of Munich called Dinkelschirben, where it's like a very, very idyllic German village.Andreas [00:01:36]: Yeah, important to the story. So basically, the main thing is I've kind of always been thinking about AI my entire life and been thinking about, well, at some point, this is going to be a huge deal. It's going to be transformative. How can I work on it? And was thinking about it from when I was a teenager, after high school did a year where I started a startup with the intention to become rich. And then once I'm rich, I can affect the trajectory of AI. Did not become rich, decided to go back to college and study cognitive science there, which was like the closest thing I could find at the time to AI. In the last year of college, moved to the US to do a PhD at MIT, working on broadly kind of new programming languages for AI because it kind of seemed like the existing languages were not great at expressing world models and learning world models doing Bayesian inference. Was always thinking about, well, ultimately, the goal is to actually build tools that help people reason more clearly, ask and answer better questions and make better decisions. But for a long time, it seemed like the technology to put reasoning in machines just wasn't there. Initially, at the end of my postdoc at Stanford, I was thinking about, well, what to do? I think the standard path is you become an academic and do research. But it's really hard to actually build interesting tools as an academic. You can't really hire great engineers. Everything is kind of on a paper-to-paper timeline. And so I was like, well, maybe I should start a startup, pursued that for a little bit. But it seemed like it was too early because you could have tried to do an AI startup, but probably would not have been this kind of AI startup we're seeing now. So then decided to just start a nonprofit research lab that's going to do research for a while until we better figure out how to do thinking in machines. And that was odd. And then over time, it became clear how to actually build actual tools for reasoning. And only over time, we developed a better way to... I'll let you fill in some of the details here.Jungwon [00:03:26]: Yeah. So I guess my story maybe starts around 2015. I kind of wanted to be a founder for a long time, and I wanted to work on an idea that stood the test of time for me, like an idea that stuck with me for a long time. And starting in 2015, actually, originally, I became interested in AI-based tools from the perspective of mental health. So there are a bunch of people around me who are really struggling. One really close friend in particular is really struggling with mental health and didn't have any support, and it didn't feel like there was anything before kind of like getting hospitalized that could just help her. And so luckily, she came and stayed with me for a while, and we were just able to talk through some things. But it seemed like lots of people might not have that resource, and something maybe AI-enabled could be much more scalable. I didn't feel ready to start a company then, that's 2015. And I also didn't feel like the technology was ready. So then I went into FinTech and kind of learned how to do the tech thing. And then in 2019, I felt like it was time for me to just jump in and build something on my own I really wanted to create. And at the time, I looked around at tech and felt like not super inspired by the options. I didn't want to have a tech career ladder, or I didn't want to climb the career ladder. There are two kind of interesting technologies at the time, there was AI and there was crypto. And I was like, well, the AI people seem like a little bit more nice, maybe like slightly more trustworthy, both super exciting, but threw my bet in on the AI side. And then I got connected to Andreas. And actually, the way he was thinking about pursuing the research agenda at OTT was really compatible with what I had envisioned for an ideal AI product, something that helps kind of take down really complex thinking, overwhelming thoughts and breaks it down into small pieces. And then this kind of mission that we need AI to help us figure out what we ought to do was really inspiring, right? Yeah, because I think it was clear that we were building the most powerful optimizer of our time. But as a society, we hadn't figured out how to direct that optimization potential. And if you kind of direct tremendous amounts of optimization potential at the wrong thing, that's really disastrous. So the goal of OTT was make sure that if we build the most transformative technology of our lifetime, it can be used for something really impactful, like good reasoning, like not just generating ads. My background was in marketing, but like, so I was like, I want to do more than generate ads with this. But also if these AI systems get to be super intelligent enough that they are doing this really complex reasoning, that we can trust them, that they are aligned with us and we have ways of evaluating that they're doing the right thing. So that's what OTT did. We did a lot of experiments, you know, like I just said, before foundation models really like took off. A lot of the issues we were seeing were more in reinforcement learning, but we saw a future where AI would be able to do more kind of logical reasoning, not just kind of extrapolate from numerical trends. We actually kind of set up experiments with people where kind of people stood in as super intelligent systems and we effectively gave them context windows. So they would have to like read a bunch of text and one person would get less text and one person would get all the texts and the person with less text would have to evaluate the work of the person who could read much more. So like in a world we were basically simulating, like in 2018, 2019, a world where an AI system could read significantly more than you and you as the person who couldn't read that much had to evaluate the work of the AI system. Yeah. So there's a lot of the work we did. And from that, we kind of iterated on the idea of breaking complex tasks down into smaller tasks, like complex tasks, like open-ended reasoning, logical reasoning into smaller tasks so that it's easier to train AI systems on them. And also so that it's easier to evaluate the work of the AI system when it's done. And then also kind of, you know, really pioneered this idea, the importance of supervising the process of AI systems, not just the outcomes. So a big part of how Elicit is built is we're very intentional about not just throwing a ton of data into a model and training it and then saying, cool, here's like scientific output. Like that's not at all what we do. Our approach is very much like, what are the steps that an expert human does or what is like an ideal process as granularly as possible, let's break that down and then train AI systems to perform each of those steps very robustly. When you train like that from the start, after the fact, it's much easier to evaluate, it's much easier to troubleshoot at each point. Like where did something break down? So yeah, we were working on those experiments for a while. And then at the start of 2021, decided to build a product.Swyx [00:07:45]: Do you mind if I, because I think you're about to go into more modern thought and Elicit. And I just wanted to, because I think a lot of people are in where you were like sort of 2018, 19, where you chose a partner to work with. Yeah. Right. And you didn't know him. Yeah. Yeah. You were just kind of cold introduced. A lot of people are cold introduced. Yeah. Never work with them. I assume you had a lot, a lot of other options, right? Like how do you advise people to make those choices?Jungwon [00:08:10]: We were not totally cold introduced. So one of our closest friends introduced us. And then Andreas had written a lot on the OTT website, a lot of blog posts, a lot of publications. And I just read it and I was like, wow, this sounds like my writing. And even other people, some of my closest friends I asked for advice from, they were like, oh, this sounds like your writing. But I think I also had some kind of like things I was looking for. I wanted someone with a complimentary skillset. I want someone who was very values aligned. And yeah, that was all a good fit.Andreas [00:08:38]: We also did a pretty lengthy mutual evaluation process where we had a Google doc where we had all kinds of questions for each other. And I think it ended up being around 50 pages or so of like various like questions and back and forth.Swyx [00:08:52]: Was it the YC list? There's some lists going around for co-founder questions.Andreas [00:08:55]: No, we just made our own questions. But I guess it's probably related in that you ask yourself, what are the values you care about? How would you approach various decisions and things like that?Jungwon [00:09:04]: I shared like all of my past performance reviews. Yeah. Yeah.Swyx [00:09:08]: And he never had any. No.Andreas [00:09:10]: Yeah.Swyx [00:09:11]: Sorry, I just had to, a lot of people are going through that phase and you kind of skipped over it. I was like, no, no, no, no. There's like an interesting story.Jungwon [00:09:20]: Yeah.Alessio [00:09:21]: Yeah. Before we jump into what a list it is today, the history is a bit counterintuitive. So you start with figuring out, oh, if we had a super powerful model, how would we align it? But then you were actually like, well, let's just build the product so that people can actually leverage it. And I think there are a lot of folks today that are now back to where you were maybe five years ago that are like, oh, what if this happens rather than focusing on actually building something useful with it? What clicked for you to like move into a list and then we can cover that story too.Andreas [00:09:49]: I think in many ways, the approach is still the same because the way we are building illicit is not let's train a foundation model to do more stuff. It's like, let's build a scaffolding such that we can deploy powerful models to good ends. I think it's different now in that we actually have like some of the models to plug in. But if in 2017, we had had the models, we could have run the same experiments we did run with humans back then, just with models. And so in many ways, our philosophy is always, let's think ahead to the future of what models are going to exist in one, two years or longer. And how can we make it so that they can actually be deployed in kind of transparent, controllableJungwon [00:10:26]: ways? I think motivationally, we both are kind of product people at heart. The research was really important and it didn't make sense to build a product at that time. But at the end of the day, the thing that always motivated us is imagining a world where high quality reasoning is really abundant and AI is a technology that's going to get us there. And there's a way to guide that technology with research, but we can have a more direct effect through product because with research, you publish the research and someone else has to implement that into the product and the product felt like a more direct path. And we wanted to concretely have an impact on people's lives. Yeah, I think the kind of personally, the motivation was we want to build for people.Swyx [00:11:03]: Yep. And then just to recap as well, like the models you were using back then were like, I don't know, would they like BERT type stuff or T5 or I don't know what timeframe we're talking about here.Andreas [00:11:14]: I guess to be clear, at the very beginning, we had humans do the work. And then I think the first models that kind of make sense were TPT-2 and TNLG and like Yeah, early generative models. We do also use like T5 based models even now started with TPT-2.Swyx [00:11:30]: Yeah, cool. I'm just kind of curious about like, how do you start so early? You know, like now it's obvious where to start, but back then it wasn't.Jungwon [00:11:37]: Yeah, I used to nag Andreas a lot. I was like, why are you talking to this? I don't know. I felt like TPT-2 is like clearly can't do anything. And I was like, Andreas, you're wasting your time, like playing with this toy. But yeah, he was right.Alessio [00:11:50]: So what's the history of what Elicit actually does as a product? You recently announced that after four months, you get to a million in revenue. Obviously, a lot of people use it, get a lot of value, but it would initially kind of like structured data extraction from papers. Then you had kind of like concept grouping. And today, it's maybe like a more full stack research enabler, kind of like paper understander platform. What's the definitive definition of what Elicit is? And how did you get here?Jungwon [00:12:15]: Yeah, we say Elicit is an AI research assistant. I think it will continue to evolve. That's part of why we're so excited about building and research, because there's just so much space. I think the current phase we're in right now, we talk about it as really trying to make Elicit the best place to understand what is known. So it's all a lot about like literature summarization. There's a ton of information that the world already knows. It's really hard to navigate, hard to make it relevant. So a lot of it is around document discovery and processing and analysis. I really kind of want to import some of the incredible productivity improvements we've seen in software engineering and data science and into research. So it's like, how can we make researchers like data scientists of text? That's why we're launching this new set of features called Notebooks. It's very much inspired by computational notebooks, like Jupyter Notebooks, you know, DeepNode or Colab, because they're so powerful and so flexible. And ultimately, when people are trying to get to an answer or understand insight, they're kind of like manipulating evidence and information. Today, that's all packaged in PDFs, which are super brittle. So with language models, we can decompose these PDFs into their underlying claims and evidence and insights, and then let researchers mash them up together, remix them and analyze them together. So yeah, I would say quite simply, overall, Elicit is an AI research assistant. Right now we're focused on text-based workflows, but long term, really want to kind of go further and further into reasoning and decision making.Alessio [00:13:35]: And when you say AI research assistant, this is kind of meta research. So researchers use Elicit as a research assistant. It's not a generic you-can-research-anything type of tool, or it could be, but like, what are people using it for today?Andreas [00:13:49]: Yeah. So specifically in science, a lot of people use human research assistants to do things. You tell your grad student, hey, here are a couple of papers. Can you look at all of these, see which of these have kind of sufficiently large populations and actually study the disease that I'm interested in, and then write out like, what are the experiments they did? What are the interventions they did? What are the outcomes? And kind of organize that for me. And the first phase of understanding what is known really focuses on automating that workflow because a lot of that work is pretty rote work. I think it's not the kind of thing that we need humans to do. Language models can do it. And then if language models can do it, you can obviously scale it up much more than a grad student or undergrad research assistant would be able to do.Jungwon [00:14:31]: Yeah. The use cases are pretty broad. So we do have a very large percent of our users are just using it personally or for a mix of personal and professional things. People who care a lot about health or biohacking or parents who have children with a kind of rare disease and want to understand the literature directly. So there is an individual kind of consumer use case. We're most focused on the power users. So that's where we're really excited to build. So Lissette was very much inspired by this workflow in literature called systematic reviews or meta-analysis, which is basically the human state of the art for summarizing scientific literature. And it typically involves like five people working together for over a year. And they kind of first start by trying to find the maximally comprehensive set of papers possible. So it's like 10,000 papers. And they kind of systematically narrow that down to like hundreds or 50 extract key details from every single paper. Usually have two people doing it, like a third person reviewing it. So it's like an incredibly laborious, time consuming process, but you see it in every single domain. So in science, in machine learning, in policy, because it's so structured and designed to be reproducible, it's really amenable to automation. So that's kind of the workflow that we want to automate first. And then you make that accessible for any question and make these really robust living summaries of science. So yeah, that's one of the workflows that we're starting with.Alessio [00:15:49]: Our previous guest, Mike Conover, he's building a new company called Brightwave, which is an AI research assistant for financial research. How do you see the future of these tools? Does everything converge to like a God researcher assistant, or is every domain going to have its own thing?Andreas [00:16:03]: I think that's a good and mostly open question. I do think there are some differences across domains. For example, some research is more quantitative data analysis, and other research is more high level cross domain thinking. And we definitely want to contribute to the broad generalist reasoning type space. Like if researchers are making discoveries often, it's like, hey, this thing in biology is actually analogous to like these equations in economics or something. And that's just fundamentally a thing that where you need to reason across domains. At least within research, I think there will be like one best platform more or less for this type of generalist research. I think there may still be like some particular tools like for genomics, like particular types of modules of genes and proteins and whatnot. But for a lot of the kind of high level reasoning that humans do, I think that is a more of a winner type all thing.Swyx [00:16:52]: I wanted to ask a little bit deeper about, I guess, the workflow that you mentioned. I like that phrase. I see that in your UI now, but that's as it is today. And I think you were about to tell us about how it was in 2021 and how it may be progressed. How has this workflow evolved over time?Jungwon [00:17:07]: Yeah. So the very first version of Elicit actually wasn't even a research assistant. It was a forecasting assistant. So we set out and we were thinking about, you know, what are some of the most impactful types of reasoning that if we could scale up, AI would really transform the world. We actually started with literature review, but we're like, oh, so many people are going to build literature review tools. So let's start there. So then we focused on geopolitical forecasting. So I don't know if you're familiar with like manifold or manifold markets. That kind of stuff. Before manifold. Yeah. Yeah. I'm not predicting relationships. We're predicting like, is China going to invade Taiwan?Swyx [00:17:38]: Markets for everything.Andreas [00:17:39]: Yeah. That's a relationship.Swyx [00:17:41]: Yeah.Jungwon [00:17:42]: Yeah. It's true. And then we worked on that for a while. And then after GPT-3 came out, I think by that time we realized that originally we were trying to help people convert their beliefs into probability distributions. And so take fuzzy beliefs, but like model them more concretely. And then after a few months of iterating on that, just realize, oh, the thing that's blocking people from making interesting predictions about important events in the world is less kind of on the probabilistic side and much more on the research side. And so that kind of combined with the very generalist capabilities of GPT-3 prompted us to make a more general research assistant. Then we spent a few months iterating on what even is a research assistant. So we would embed with different researchers. We built data labeling workflows in the beginning, kind of right off the bat. We built ways to find experts in a field and like ways to ask good research questions. So we just kind of iterated through a lot of workflows and no one else was really building at this time. And it was like very quick to just do some prompt engineering and see like what is a task that is at the intersection of what's technologically capable and like important for researchers. And we had like a very nondescript landing page. It said nothing. But somehow people were signing up and we had to sign a form that was like, why are you here? And everyone was like, I need help with literature review. And we're like, oh, literature review. That sounds so hard. I don't even know what that means. We're like, we don't want to work on it. But then eventually we were like, okay, everyone is saying literature review. It's overwhelmingly people want to-Swyx [00:19:02]: And all domains, not like medicine or physics or just all domains. Yeah.Jungwon [00:19:06]: And we also kind of personally knew literature review was hard. And if you look at the graphs for academic literature being published every single month, you guys know this in machine learning, it's like up into the right, like superhuman amounts of papers. So we're like, all right, let's just try it. I was really nervous, but Andreas was like, this is kind of like the right problem space to jump into, even if we don't know what we're doing. So my take was like, fine, this feels really scary, but let's just launch a feature every single week and double our user numbers every month. And if we can do that, we'll fail fast and we will find something. I was worried about like getting lost in the kind of academic white space. So the very first version was actually a weekend prototype that Andreas made. Do you want to explain how that worked?Andreas [00:19:44]: I mostly remember that it was really bad. The thing I remember is you entered a question and it would give you back a list of claims. So your question could be, I don't know, how does creatine affect cognition? It would give you back some claims that are to some extent based on papers, but they were often irrelevant. The papers were often irrelevant. And so we ended up soon just printing out a bunch of examples of results and putting them up on the wall so that we would kind of feel the constant shame of having such a bad product and would be incentivized to make it better. And I think over time it has gotten a lot better, but I think the initial version was like really very bad. Yeah.Jungwon [00:20:20]: But it was basically like a natural language summary of an abstract, like kind of a one sentence summary, and which we still have. And then as we learned kind of more about this systematic review workflow, we started expanding the capability so that you could extract a lot more data from the papers and do more with that.Swyx [00:20:33]: And were you using like embeddings and cosine similarity, that kind of stuff for retrieval, or was it keyword based?Andreas [00:20:40]: I think the very first version didn't even have its own search engine. I think the very first version probably used the Semantic Scholar or API or something similar. And only later when we discovered that API is not very semantic, we then built our own search engine that has helped a lot.Swyx [00:20:58]: And then we're going to go into like more recent products stuff, but like, you know, I think you seem the more sort of startup oriented business person and you seem sort of more ideologically like interested in research, obviously, because of your PhD. What kind of market sizing were you guys thinking? Right? Like, because you're here saying like, we have to double every month. And I'm like, I don't know how you make that conclusion from this, right? Especially also as a nonprofit at the time.Jungwon [00:21:22]: I mean, market size wise, I felt like in this space where so much was changing and it was very unclear what of today was actually going to be true tomorrow. We just like really rested a lot on very, very simple fundamental principles, which is like, if you can understand the truth, that is very economically beneficial and valuable. If you like know the truth.Swyx [00:21:42]: On principle.Jungwon [00:21:43]: Yeah. That's enough for you. Yeah. Research is the key to many breakthroughs that are very commercially valuable.Swyx [00:21:47]: Because my version of it is students are poor and they don't pay for anything. Right? But that's obviously not true. As you guys have found out. But you had to have some market insight for me to have believed that, but you skipped that.Andreas [00:21:58]: Yeah. I remember talking to VCs for our seed round. A lot of VCs were like, you know, researchers, they don't have any money. Why don't you build legal assistant? I think in some short sighted way, maybe that's true. But I think in the long run, R&D is such a big space of the economy. I think if you can substantially improve how quickly people find new discoveries or avoid controlled trials that don't go anywhere, I think that's just huge amounts of money. And there are a lot of questions obviously about between here and there. But I think as long as the fundamental principle is there, we were okay with that. And I guess we found some investors who also were. Yeah.Swyx [00:22:35]: Congrats. I mean, I'm sure we can cover the sort of flip later. I think you're about to start us on like GPT-3 and how that changed things for you. It's funny. I guess every major GPT version, you have some big insight. Yeah.Jungwon [00:22:48]: Yeah. I mean, what do you think?Andreas [00:22:51]: I think it's a little bit less true for us than for others, because we always believed that there will basically be human level machine work. And so it is definitely true that in practice for your product, as new models come out, your product starts working better, you can add some features that you couldn't add before. But I don't think we really ever had the moment where we were like, oh, wow, that is super unanticipated. We need to do something entirely different now from what was on the roadmap.Jungwon [00:23:21]: I think GPT-3 was a big change because it kind of said, oh, now is the time that we can use AI to build these tools. And then GPT-4 was maybe a little bit more of an extension of GPT-3. GPT-3 over GPT-2 was like qualitative level shift. And then GPT-4 was like, okay, great. Now it's like more accurate. We're more accurate on these things. We can answer harder questions. But the shape of the product had already taken place by that time.Swyx [00:23:44]: I kind of want to ask you about this sort of pivot that you've made. But I guess that was just a way to sell what you were doing, which is you're adding extra features on grouping by concepts. The GPT-4 pivot, quote unquote pivot that you-Jungwon [00:23:55]: Oh, yeah, yeah, exactly. Right, right, right. Yeah. Yeah. When we launched this workflow, now that GPT-4 was available, basically Elisa was at a place where we have very tabular interfaces. So given a table of papers, you can extract data across all the tables. But you kind of want to take the analysis a step further. Sometimes what you'd care about is not having a list of papers, but a list of arguments, a list of effects, a list of interventions, a list of techniques. And so that's one of the things we're working on is now that you've extracted this information in a more structured way, can you pivot it or group by whatever the information that you extracted to have more insight first information still supported by the academic literature?Swyx [00:24:33]: Yeah, that was a big revelation when I saw it. Basically, I think I'm very just impressed by how first principles, your ideas around what the workflow is. And I think that's why you're not as reliant on like the LLM improving, because it's actually just about improving the workflow that you would recommend to people. Today we might call it an agent, I don't know, but you're not relying on the LLM to drive it. It's relying on this is the way that Elicit does research. And this is what we think is most effective based on talking to our users.Jungwon [00:25:01]: The problem space is still huge. Like if it's like this big, we are all still operating at this tiny part, bit of it. So I think about this a lot in the context of moats, people are like, oh, what's your moat? What happens if GPT-5 comes out? It's like, if GPT-5 comes out, there's still like all of this other space that we can go into. So I think being really obsessed with the problem, which is very, very big, has helped us like stay robust and just kind of directly incorporate model improvements and they keep going.Swyx [00:25:26]: And then I first encountered you guys with Charlie, you can tell us about that project. Basically, yeah. Like how much did cost become a concern as you're working more and more with OpenAI? How do you manage that relationship?Jungwon [00:25:37]: Let me talk about who Charlie is. And then you can talk about the tech, because Charlie is a special character. So Charlie, when we found him was, had just finished his freshman year at the University of Warwick. And I think he had heard about us on some discord. And then he applied and we were like, wow, who is this freshman? And then we just saw that he had done so many incredible side projects. And we were actually on a team retreat in Barcelona visiting our head of engineering at that time. And everyone was talking about this wonder kid or like this kid. And then on our take home project, he had done like the best of anyone to that point. And so people were just like so excited to hire him. So we hired him as an intern and they were like, Charlie, what if you just dropped out of school? And so then we convinced him to take a year off. And he was just incredibly productive. And I think the thing you're referring to is at the start of 2023, Anthropic kind of launched their constitutional AI paper. And within a few days, I think four days, he had basically implemented that in production. And then we had it in app a week or so after that. And he has since kind of contributed to major improvements, like cutting costs down to a tenth of what they were really large scale. But yeah, you can talk about the technical stuff. Yeah.Andreas [00:26:39]: On the constitutional AI project, this was for abstract summarization, where in illicit, if you run a query, it'll return papers to you, and then it will summarize each paper with respect to your query for you on the fly. And that's a really important part of illicit because illicit does it so much. If you run a few searches, it'll have done it a few hundred times for you. And so we cared a lot about this both being fast, cheap, and also very low on hallucination. I think if illicit hallucinates something about the abstract, that's really not good. And so what Charlie did in that project was create a constitution that expressed what are the attributes of a good summary? Everything in the summary is reflected in the actual abstract, and it's like very concise, et cetera, et cetera. And then used RLHF with a model that was trained on the constitution to basically fine tune a better summarizer on an open source model. Yeah. I think that might still be in use.Jungwon [00:27:34]: Yeah. Yeah, definitely. Yeah. I think at the time, the models hadn't been trained at all to be faithful to a text. So they were just generating. So then when you ask them a question, they tried too hard to answer the question and didn't try hard enough to answer the question given the text or answer what the text said about the question. So we had to basically teach the models to do that specific task.Swyx [00:27:54]: How do you monitor the ongoing performance of your models? Not to get too LLM-opsy, but you are one of the larger, more well-known operations doing NLP at scale. I guess effectively, you have to monitor these things and nobody has a good answer that I talk to.Andreas [00:28:10]: I don't think we have a good answer yet. I think the answers are actually a little bit clearer on the just kind of basic robustness side of where you can import ideas from normal software engineering and normal kind of DevOps. You're like, well, you need to monitor kind of latencies and response times and uptime and whatnot.Swyx [00:28:27]: I think when we say performance, it's more about hallucination rate, isn't it?Andreas [00:28:30]: And then things like hallucination rate where I think there, the really important thing is training time. So we care a lot about having our own internal benchmarks for model development that reflect the distribution of user queries so that we can know ahead of time how well is the model going to perform on different types of tasks. So the tasks being summarization, question answering, given a paper, ranking. And for each of those, we want to know what's the distribution of things the model is going to see so that we can have well-calibrated predictions on how well the model is going to do in production. And I think, yeah, there's some chance that there's distribution shift and actually the things users enter are going to be different. But I think that's much less important than getting the kind of training right and having very high quality, well-vetted data sets at training time.Jungwon [00:29:18]: I think we also end up effectively monitoring by trying to evaluate new models as they come out. And so that kind of prompts us to go through our eval suite every couple of months. And every time a new model comes out, we have to see how is this performing relative to production and what we currently have.Swyx [00:29:32]: Yeah. I mean, since we're on this topic, any new models that have really caught your eye this year?Jungwon [00:29:37]: Like Claude came out with a bunch. Yeah. I think Claude is pretty, I think the team's pretty excited about Claude. Yeah.Andreas [00:29:41]: Specifically, Claude Haiku is like a good point on the kind of Pareto frontier. It's neither the cheapest model, nor is it the most accurate, most high quality model, but it's just like a really good trade-off between cost and accuracy.Swyx [00:29:57]: You apparently have to 10-shot it to make it good. I tried using Haiku for summarization, but zero-shot was not great. Then they were like, you know, it's a skill issue, you have to try harder.Jungwon [00:30:07]: I think GPT-4 unlocked tables for us, processing data from tables, which was huge. GPT-4 Vision.Andreas [00:30:13]: Yeah.Swyx [00:30:14]: Yeah. Did you try like Fuyu? I guess you can't try Fuyu because it's non-commercial. That's the adept model.Jungwon [00:30:19]: Yeah.Swyx [00:30:20]: We haven't tried that one. Yeah. Yeah. Yeah. But Claude is multimodal as well. Yeah. I think the interesting insight that we got from talking to David Luan, who is CEO of multimodality has effectively two different flavors. One is we recognize images from a camera in the outside natural world. And actually the more important multimodality for knowledge work is screenshots and PDFs and charts and graphs. So we need a new term for that kind of multimodality.Andreas [00:30:45]: But is the claim that current models are good at one or the other? Yeah.Swyx [00:30:50]: They're over-indexed because of the history of computer vision is Coco, right? So now we're like, oh, actually, you know, screens are more important, OCR, handwriting. You mentioned a lot of like closed model lab stuff, and then you also have like this open source model fine tuning stuff. Like what is your workload now between closed and open? It's a good question.Andreas [00:31:07]: I think- Is it half and half? It's a-Swyx [00:31:10]: Is that even a relevant question or not? Is this a nonsensical question?Andreas [00:31:13]: It depends a little bit on like how you index, whether you index by like computer cost or number of queries. I'd say like in terms of number of queries, it's maybe similar. In terms of like cost and compute, I think the closed models make up more of the budget since the main cases where you want to use closed models are cases where they're just smarter, where no existing open source models are quite smart enough.Jungwon [00:31:35]: Yeah. Yeah.Alessio [00:31:37]: We have a lot of interesting technical questions to go in, but just to wrap the kind of like UX evolution, now you have the notebooks. We talked a lot about how chatbots are not the final frontier, you know? How did you decide to get into notebooks, which is a very iterative kind of like interactive interface and yeah, maybe learnings from that.Jungwon [00:31:56]: Yeah. This is actually our fourth time trying to make this work. Okay. I think the first time was probably in early 2021. I think because we've always been obsessed with this idea of task decomposition and like branching, we always wanted a tool that could be kind of unbounded where you could keep going, could do a lot of branching where you could kind of apply language model operations or computations on other tasks. So in 2021, we had this thing called composite tasks where you could use GPT-3 to brainstorm a bunch of research questions and then take each research question and decompose those further into sub questions. This kind of, again, that like task decomposition tree type thing was always very exciting to us, but that was like, it didn't work and it was kind of overwhelming. Then at the end of 22, I think we tried again and at that point we were thinking, okay, we've done a lot with this literature review thing. We also want to start helping with kind of adjacent domains and different workflows. Like we want to help more with machine learning. What does that look like? And as we were thinking about it, we're like, well, there are so many research workflows. How do we not just build three new workflows into Elicit, but make Elicit really generic to lots of workflows? What is like a generic composable system with nice abstractions that can like scale to all these workflows? So we like iterated on that a bunch and then didn't quite narrow the problem space enough or like quite get to what we wanted. And then I think it was at the beginning of 2023 where we're like, wow, computational notebooks kind of enable this, where they have a lot of flexibility, but kind of robust primitives such that you can extend the workflow and it's not limited. It's not like you ask a query, you get an answer, you're done. You can just constantly keep building on top of that. And each little step seems like a really good unit of work for the language model. And also there was just like really helpful to have a bit more preexisting work to emulate. Yeah, that's kind of how we ended up at computational notebooks for Elicit.Andreas [00:33:44]: Maybe one thing that's worth making explicit is the difference between computational notebooks and chat, because on the surface, they seem pretty similar. It's kind of this iterative interaction where you add stuff. In both cases, you have a back and forth between you enter stuff and then you get some output and then you enter stuff. But the important difference in our minds is with notebooks, you can define a process. So in data science, you can be like, here's like my data analysis process that takes in a CSV and then does some extraction and then generates a figure at the end. And you can prototype it using a small CSV and then you can run it over a much larger CSV later. And similarly, the vision for notebooks in our case is to not make it this like one-off chat interaction, but to allow you to then say, if you start and first you're like, okay, let me just analyze a few papers and see, do I get to the correct conclusions for those few papers? Can I then later go back and say, now let me run this over 10,000 papers now that I've debugged the process using a few papers. And that's an interaction that doesn't fit quite as well into the chat framework because that's more for kind of quick back and forth interaction.Alessio [00:34:49]: Do you think in notebooks, it's kind of like structure, editable chain of thought, basically step by step? Like, is that kind of where you see this going? And then are people going to reuse notebooks as like templates? And maybe in traditional notebooks, it's like cookbooks, right? You share a cookbook, you can start from there. Is this similar in Elizit?Andreas [00:35:06]: Yeah, that's exactly right. So that's our hope that people will build templates, share them with other people. I think chain of thought is maybe still like kind of one level lower on the abstraction hierarchy than we would think of notebooks. I think we'll probably want to think about more semantic pieces like a building block is more like a paper search or an extraction or a list of concepts. And then the model's detailed reasoning will probably often be one level down. You always want to be able to see it, but you don't always want it to be front and center.Alessio [00:35:36]: Yeah, what's the difference between a notebook and an agent? Since everybody always asks me, what's an agent? Like how do you think about where the line is?Andreas [00:35:44]: Yeah, it's an interesting question. In the notebook world, I would generally think of the human as the agent in the first iteration. So you have the notebook and the human kind of adds little action steps. And then the next point on this kind of progress gradient is, okay, now you can use language models to predict which action would you take as a human. And at some point, you're probably going to be very good at this, you'll be like, okay, in some cases I can, with 99.9% accuracy, predict what you do. And then you might as well just execute it, like why wait for the human? And eventually, as you get better at this, that will just look more and more like agents taking actions as opposed to you doing the thing. I think templates are a specific case of this where you're like, okay, well, there's just particular sequences of actions that you often want to chunk and have available as primitives, just like in normal programming. And those, you can view them as action sequences of agents, or you can view them as more normal programming language abstraction thing. And I think those are two valid views. Yeah.Alessio [00:36:40]: How do you see this change as, like you said, the models get better and you need less and less human actual interfacing with the model, you just get the results? Like how does the UX and the way people perceive it change?Jungwon [00:36:52]: Yeah, I think this kind of interaction paradigms for evaluation is not really something the internet has encountered yet, because up to now, the internet has all been about getting data and work from people. So increasingly, I really want kind of evaluation, both from an interface perspective and from like a technical perspective and operation perspective to be a superpower for Elicit, because I think over time, models will do more and more of the work, and people will have to do more and more of the evaluation. So I think, yeah, in terms of the interface, some of the things we have today, you know, for every kind of language model generation, there's some citation back, and we kind of try to highlight the ground truth in the paper that is most relevant to whatever Elicit said, and make it super easy so that you can click on it and quickly see in context and validate whether the text actually supports the answer that Elicit gave. So I think we'd probably want to scale things up like that, like the ability to kind of spot check the model's work super quickly, scale up interfaces like that. And-Swyx [00:37:44]: Who would spot check? The user?Jungwon [00:37:46]: Yeah, to start, it would be the user. One of the other things we do is also kind of flag the model's uncertainty. So we have models report out, how confident are you that this was the sample size of this study? The model's not sure, we throw a flag. And so the user knows to prioritize checking that. So again, we can kind of scale that up. So when the model's like, well, I searched this on Google, I'm not sure if that was the right thing. I have an uncertainty flag, and the user can go and be like, oh, okay, that was actually the right thing to do or not.Swyx [00:38:10]: I've tried to do uncertainty readings from models. I don't know if you have this live. You do? Yeah. Because I just didn't find them reliable because they just hallucinated their own uncertainty. I would love to base it on log probs or something more native within the model rather than generated. But okay, it sounds like they scale properly for you. Yeah.Jungwon [00:38:30]: We found it to be pretty calibrated. It varies on the model.Andreas [00:38:32]: I think in some cases, we also use two different models for the uncertainty estimates than for the question answering. So one model would say, here's my chain of thought, here's my answer. And then a different type of model. Let's say the first model is Llama, and let's say the second model is GPT-3.5. And then the second model just looks over the results and is like, okay, how confident are you in this? And I think sometimes using a different model can be better than using the same model. Yeah.Swyx [00:38:58]: On the topic of models, evaluating models, obviously you can do that all day long. What's your budget? Because your queries fan out a lot. And then you have models evaluating models. One person typing in a question can lead to a thousand calls.Andreas [00:39:11]: It depends on the project. So if the project is basically a systematic review that otherwise human research assistants would do, then the project is basically a human equivalent spend. And the spend can get quite large for those projects. I don't know, let's say $100,000. In those cases, you're happier to spend compute then in the kind of shallow search case where someone just enters a question because, I don't know, maybe I heard about creatine. What's it about? Probably don't want to spend a lot of compute on that. This sort of being able to invest more or less compute into getting more or less accurate answers is I think one of the core things we care about. And that I think is currently undervalued in the AI space. I think currently you can choose which model you want and you can sometimes, I don't know, you'll tip it and it'll try harder or you can try various things to get it to work harder. But you don't have great ways of converting willingness to spend into better answers. And we really want to build a product that has this sort of unbounded flavor where if you care about it a lot, you should be able to get really high quality answers, really double checked in every way.Alessio [00:40:14]: And you have a credits-based pricing. So unlike most products, it's not a fixed monthly fee.Jungwon [00:40:19]: Right, exactly. So some of the higher costs are tiered. So for most casual users, they'll just get the abstract summary, which is kind of an open source model. Then you can add more columns, which have more extractions and these uncertainty features. And then you can also add the same columns in high accuracy mode, which also parses the table. So we kind of stack the complexity on the calls.Swyx [00:40:39]: You know, the fun thing you can do with a credit system, which is data for data, basically you can give people more credits if they give data back to you. I don't know if you've already done that. We've thought about something like this.Jungwon [00:40:49]: It's like if you don't have money, but you have time, how do you exchange that?Swyx [00:40:54]: It's a fair trade.Jungwon [00:40:55]: I think it's interesting. We haven't quite operationalized it. And then, you know, there's been some kind of like adverse selection. Like, you know, for example, it would be really valuable to get feedback on our model. So maybe if you were willing to give more robust feedback on our results, we could give you credits or something like that. But then there's kind of this, will people take it seriously? And you want the good people. Exactly.Swyx [00:41:11]: Can you tell who are the good people? Not right now.Jungwon [00:41:13]: But yeah, maybe at the point where we can, we can offer it. We can offer it up to them.Swyx [00:41:16]: The perplexity of questions asked, you know, if it's higher perplexity, these are the smarterJungwon [00:41:20]: people. Yeah, maybe.Andreas [00:41:23]: If you put typos in your queries, you're not going to get off the stage.Swyx [00:41:28]: Negative social credit. It's very topical right now to think about the threat of long context windows. All these models that we're talking about these days, all like a million token plus. Is that relevant for you? Can you make use of that? Is that just prohibitively expensive because you're just paying for all those tokens or you're just doing rag?Andreas [00:41:44]: It's definitely relevant. And when we think about search, as many people do, we think about kind of a staged pipeline of retrieval where first you use semantic search database with embeddings, get like the, in our case, maybe 400 or so most relevant papers. And then, then you still need to rank those. And I think at that point it becomes pretty interesting to use larger models. So specifically in the past, I think a lot of ranking was kind of per item ranking where you would score each individual item, maybe using increasingly expensive scoring methods and then rank based on the scores. But I think list-wise re-ranking where you have a model that can see all the elements is a lot more powerful because often you can only really tell how good a thing is in comparison to other things and what things should come first. It really depends on like, well, what other things that are available, maybe you even care about diversity in your results. You don't want to show 10 very similar papers as the first 10 results. So I think a long context models are quite interesting there. And especially for our case where we care more about power users who are perhaps a little bit more willing to wait a little bit longer to get higher quality results relative to people who just quickly check out things because why not? And I think being able to spend more on longer contexts is quite valuable.Jungwon [00:42:55]: Yeah. I think one thing the longer context models changed for us is maybe a focus from breaking down tasks to breaking down the evaluation. So before, you know, if we wanted to answer a question from the full text of a paper, we had to figure out how to chunk it and like find the relevant chunk and then answer based on that chunk. And the nice thing was then, you know, kind of which chunk the model used to answer the question. So if you want to help the user track it, yeah, you can be like, well, this was the chunk that the model got. And now if you put the whole text in the paper, you have to like kind of find the chunk like more retroactively basically. And so you need kind of like a different set of abilities and obviously like a different technology to figure out. You still want to point the user to the supporting quotes in the text, but then the interaction is a little different.Swyx [00:43:38]: You like scan through and find some rouge score floor.Andreas [00:43:41]: I think there's an interesting space of almost research problems here because you would ideally make causal claims like if this hadn't been in the text, the model wouldn't have said this thing. And maybe you can do expensive approximations to that where like, I don't know, you just throw out chunk of the paper and re-answer and see what happens. But hopefully there are better ways of doing that where you just get that kind of counterfactual information for free from the model.Alessio [00:44:06]: Do you think at all about the cost of maintaining REG versus just putting more tokens in the window? I think in software development, a lot of times people buy developer productivity things so that we don't have to worry about it. Context window is kind of the same, right? You have to maintain chunking and like REG retrieval and like re-ranking and all of this versus I just shove everything into the context and like it costs a little more, but at least I don't have to do all of that. Is that something you thought about?Jungwon [00:44:31]: I think we still like hit up against context limits enough that it's not really, do we still want to keep this REG around? It's like we do still need it for the scale of the work that we're doing, yeah.Andreas [00:44:41]: And I think there are different kinds of maintainability. In one sense, I think you're right that throw everything into the context window thing is easier to maintain because you just can swap out a model. In another sense, if things go wrong, it's harder to debug where like, if you know, here's the process that we go through to go from 200 million papers to an answer. And there are like little steps and you understand, okay, this is the step that finds the relevant paragraph or whatever it may be. You'll know which step breaks if the answers are bad, whereas if it's just like a new model version came out and now it suddenly doesn't find your needle in a haystack anymore, then you're like, okay, what can you do? You're kind of at a loss.Alessio [00:45:21]: Let's talk a bit about, yeah, needle in a haystack and like maybe the opposite of it, which is like hard grounding. I don't know if that's like the best name to think about it, but I was using one of these chatwitcher documents features and I put the AMD MI300 specs and the new Blackwell chips from NVIDIA and I was asking questions and does the AMD chip support NVLink? And the response was like, oh, it doesn't say in the specs. But if you ask GPD 4 without the docs, it would tell you no, because NVLink it's a NVIDIA technology.Swyx [00:45:49]: It just says in the thing.Alessio [00:45:53]: How do you think about that? Does using the context sometimes suppress the knowledge that the model has?Andreas [00:45:57]: It really depends on the task because I think sometimes that is exactly what you want. So imagine you're a researcher, you're writing the background section of your paper and you're trying to describe what these other papers say. You really don't want extra information to be introduced there. In other cases where you're just trying to figure out the truth and you're giving the documents because you think they will help the model figure out what the truth is. I think you do want, if the model has a hunch that there might be something that's not in the papers, you do want to surface that. I think ideally you still don't want the model to just tell you, probably the ideal thing looks a bit more like agent control where the model can issue a query that then is intended to surface documents that substantiate its hunch. That's maybe a reasonable middle ground between model just telling you and model being fully limited to the papers you give it.Jungwon [00:46:44]: Yeah, I would say it's, they're just kind of different tasks right now. And the task that Elicit is mostly focused on is what do these papers say? But there's another task which is like, just give me the best possible answer and that give me the best possible answer sometimes depends on what do these papers say, but it can also depend on other stuff that's not in the papers. So ideally we can do both and then kind of do this overall task for you more going forward.Alessio [00:47:08]: We see a lot of details, but just to zoom back out a little bit, what are maybe the most underrated features of Elicit and what is one thing that maybe the users surprise you the most by using it?Jungwon [00:47:19]: I think the most powerful feature of Elicit is the ability to extract, add columns to this table, which effectively extracts data from all of your papers at once. It's well used, but there are kind of many different extensions of that that I think users are still discovering. So one is we let you give a description of the column. We let you give instructions of a column. We let you create custom columns. So we have like 30 plus predefined fields that users can extract, like what were the methods? What were the main findings? How many people were studied? And we actually show you basically the prompts that we're using to

You have to find what works for you and Chris Ellis has never been the kind of person that could go and sit in a library—for Chris, the most productive Postgres place is in a coffee shop. In this episode of the Path To Citus Con podcast for developers who love Postgres, Chris Ellis joined Claire and Pino to chat about his path to becoming more (and more) expert at using PostgreSQL. Curiosity may have killed the cat but it's taken Chris places, beginning as a 5 year old playing with QBASIC. Chris shared his journey to becoming a developer, an electronic engineer, a builder, and a PostgreSQL user. This session also delves into Chris's work as a Postgres conference speaker (and organizer!) Importantly, we spent time remembering Simon Riggs, Postgres leader extraordinaire. RIP.Links mentioned in this episode:Chris's first thread on the PostgreSQL mailing listsSlides: IoT with PostgreSQL—by Chris Ellis at PGConf.EU 2023Slides: Advantage PostgreSQL—by Chris Ellis at Nordic PGDay 2024 Video: Should I use JSON in PostgreSQL?—by Boriss Mejías at PGConf.EU 2023 Slides: Fighting the Butterflies & giving your first Postgres conference talk—by Claire Giordano at pgDay Paris 2024 Markus Winand's website, Modern SQLWikipedia: Linus's lawAndres Freund's xz backdoor discoveryAndres Freund's Mastodon Toot about xz backdoorPodcast: Path to Citus Con Ep08: How I got started as a developer (& in Postgres) with Andres Freund & Heikki LinnakangasPodcast: Path To Citus Con Ep11: My Journey into Performance Benchmarking with Jelte Fennema-Nio & Marco SlotPodcast: Oxide and Friends next episode on Mon Apr 08 2024, featuring Andres Freund from MicrosoftJessie Frazelle tweet on LLMVideo of pgDay Paris 2024 lightning talks, including Chris's "Electric Elephants" talkPost about Simon Riggs's tragic passing last week. He will be missed, he is missed, and many are heartbroken Simon Riggs: The Next 20 Years—keynote at PGConf.EU 2023Book: The Art of PostgreSQL by Dimitri FontainePodcast: Path To Citus Con Ep09: Solving every data problem in SQL w/Dimitri Fontaine & Vik FearingBlog: Planet PostgreSQLBlog: Contributing to Postgres 101: A Beginner's Experience by Elizabeth Christensen Book: Linux Kernel Development by Robert Love Chris Ellis's LED PCB ArtBlog: pgDay Paris – Postgres Community, cheese and wine by Boriss MejíasPodcast: LUG RadioCFP for POSETTE: An Event for Postgres (free & virtual event) open until Sunday April 7th 2024 at 11:59pm PDTCal invite for next Ep15 of Path To Citus Con podcast with Michael Christofides

Ken Wheeler is a software engineer with well over a decade of experience. He shares stories about his journey into tech, his life, and his hobbies. Ken fell in love with coding as a kid, building his skills from QBasic to PHP and HTML. He recounts his transition from being a rap producer for a decade to stumbling upon a job listing for a web developer using Flash. After twisting the truth to get through the interview, he spent five years building local restaurant websites with Flash animations. Ken dives into some unfiltered hot takes from TypeScript to CSS and the ongoing debate of sidebar placement in VS Code. He shares his love for inferred types over explicit types, arguing in favor of TypeScript's Hindley-Milner type system. In this episode, Ken talks to Robbie and Chuck about his thoughts on types, Tailwind and VS Code, his coding journey from QBasic to HTML as a kid, and his technique for landing his first job. Key Takeaways [00:48] - Introduction to Ken Wheeler. [01:56] - A whiskey review: Basil Hayden Straight Bourbon Whiskey. [19:03] - Tech hot takes. [40:57] - Ken discusses his New Jersey roots and how he entered the tech field. [49:51] - Chuck, Robbie, and Ken talk about cars. [59:00] - Chuck's plans to move to Italy. [01:04:41] - Chuck, Robbie, and Ken discuss burgers and sandwiches. Quotes [19:20] - “Typescript is good. It's better than Javascript.” ~ Ken Wheeler [34:50] - “A senior at dickhead.com is not the same as a senior at Google.com.” ~ Ken Wheeler [37:48] - “Webpack actually isn't that hard, believe it or not, if you just dig into it.” ~ Ken Wheeler Links Ken Wheeler LinkedIn Ken Wheeler Twitter OpenAI Twitter Formidable Basil Hayden Straight Bourbon Whiskey Sagamore Spirit Rye Whiskey Buffalo Trace Distillery Pappy Van Winkle Maker's Mark Coors Light Topgolf Crocs Timberland The Ritz-Carlton DoorDash Taco Bell Tabasco Cholula Tailwind CSS Vanilla CSS NPM Shepherd JS YAML Serverless UI Syntax.FM Beflo Joe Rogan Podcast All-In Podcast Darknet Diaries Google Amazon Webpack ChatGPT Vite NextJS Airbnb Ruby on Rails Django National Geographic Juul Marlboro Oracle Salesforce jQuery Versace The North Face Red Wing Shoes Thursday Boot Company Porsche Jeep Volvo Solo Stove Flex Seal Inter Milan Five Guys Jersey Mike's USA In-N-Out Shake Shack First We Feast Arby's Burger King McDonald's React Miami The Primeagen Chick-fil-A Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Promos Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io. --- Send in a voice message: https://podcasters.spotify.com/pod/show/whiskey-web-and-whatnot/message

Jamon Holmgren is the founder of Infinite Red, a consultancy specializing in React Native. He discusses his journey and insights into technology and leadership and highlights how Infinite Red stands as a testament that businesses can be run ethically while still achieving success. The conversation shifts to leadership styles and the principle of "one-minute praise" from the book "One Minute Manager." Both Jamon and Will agree that acknowledging others' efforts openly can make a significant difference, enhancing leadership skills and building stronger relationships. Will points out how this simple principle has been a game-changer for him in various aspects of life, including his personal relationships. Towards the end, the focus turns to motivation and long-term strategy. Jamon is driven by his enthusiasm for learning and the thrill of tackling diverse challenges in his consultancy work. He also shares his philosophy of keeping the company "10 degrees above the horizon," emphasizing steady, sustainable growth rather than erratic leaps and bounds. Infinite Red (https://infinite.red/) Follow Infinite Red on LinkedIn (https://www.linkedin.com/company/infinitered/), X (https://twitter.com/infinite_red), YouTube (https://www.youtube.com/channel/UCwpSzVt7QpLDbCnPXqR97-g), GitHub (https://github.com/infinitered), Facebook (https://www.facebook.com/infiniteredinc/), or Instagram (https://www.instagram.com/infinitered_designers/). Follow Jamon Holmgren on LinkedIn (https://www.linkedin.com/in/jamonholmgren/) or X (https://twitter.com/jamonholmgren). Visit his website at jamon.dev (https://jamon.dev/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: WILL: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. And with me today is Jamon Holmgren, Co-Founder and CTO of Infinite Red, a software consulting agency that specializes in React Native. Jamon, thank you for joining me. JAMON: Yeah. Thanks for having me. I really appreciate it. WILL: So, Jamon, what's going on in your life? How's everything going? JAMON: You know, things have been obviously very busy, like, I guess, pretty much everybody. You know, school has started. I have four kids, so that keeps me quite busy, going to various school events, going to volleyball, you know, bringing kids here and there, running the company. I have some side projects I'm doing. I am playing hockey. So, it just seems like every waking hour is filled with something. [laughter] WILL: I totally understand that. I have three kids of my own. So, they're a little bit younger than yours, so mine is 4, 3, and, like, 17 months, so... JAMON: Okay. Yeah, so you're just getting started. And you're doing all of the, like, physical labor associated with being a parent. WILL: Yes, yes, yes. So, I want to start there. Tell me a little bit about your kids. I know their ages are 10 to 18. JAMON: Yeah, so I have a boy, Cedric. He's actually a programmer as well. He's just starting his career. He is the oldest, and then we have three girls. We have a 15-year-old who's a sophomore in high school. And then we have a 12-year-old who's in middle school and a 10-year-old who is in fifth grade in elementary school. And it's a lot. My wife and I both came from very large families, so we're kind of used to it. And it's a lot of fun. A lot of challenges at this age, I mean, teenagers especially, you know, as they kind of all come into that same era, you know, it's more of a challenge. I guess the thing that I think about it is a lot of the skills that I learned as a young kid parent don't really translate super well to being a teenager parent. And I'm having to learn a lot of new skills. And I actually talked to a guy the other day. His kids are, I think, 32 and 28, or something like that. And he said, "Yeah, the learning never stops." [laughs] WILL: So, I'm going to ask you for the secret sauce because I'm still in the temper tantrums and those type of emotions and stuff. So, how is it different in the teenage years from the temper tantrums? JAMON: Well, I think that they can act like adults in a lot of cases, and you start thinking of them as adults, and you start developing a relationship there. But their brains are also not fully developed. And so, they will also do things that are very inexplicable, like, you'll just be like, why? Why would this be a thing? Like, I don't get it. Like, you act like an adult for half the time, and then the other half, you act like a kid. Navigating that, and the fact that they change all the time, and all the other challenges. And they're all different. Like, if we had only had one kid, you know, my boy was pretty easy. He was pretty straightforward. It would have been like, well, shoot, being a parent is pretty easy. Like, I don't know what everybody else is complaining about. Like, he never did tantrums. He was just a really quiet, you know, like, well-behaved kid and kind of went through life like that. But then, obviously, developing a relationship with him is more of the challenge because he's quieter, where with my girls, it's easier to develop the relationship, but then you [laughs] deal with a lot more volatility as well. So, they're all different. Every kid's different. It's hard to really apply that directly. I would say that the thing that I've learned the most in the last few years is just kind of continuing to be, like, even through some of the tougher times, continuing to be there, continuing to develop that relationship. A lot of times, it feels like you're not getting anywhere, but you are. It is actually happening. You just don't see it until later. WILL: I'm writing that down. That's great advice [laughter]. You mentioned hockey. Tell me about it. I've never played hockey. I grew up in the South, so we didn't have that. So, tell me about it. And you're a goalie also, correct? JAMON: Yeah, I play goalie. I didn't discover hockey...I played basketball in high school. I played four years of high school basketball. I even played a little bit at college. And I didn't really discover hockey until I moved to Southwest Washington, about an hour away from where I grew up in the coast of Oregon. When I got there, a lot of my friends that I made were playing hockey. And one friend, in particular, he was a goalie, and he had grown up in Upper Michigan. So, you know, like, he grew up playing hockey. He was a very good skater and things like that. But there was one weekend I was coming to watch him play just rec hockey. And he's like, "You know what? I can't make it. Would you want to jump in and, like, be my sub?" And it was just a pick-up game. So, it wasn't like there was anything on the line. And I was like, "All right, I'll give it a try." You know, put on the gear. He showed me what to do to put on the gear. He kind of gave me some tips. Like, in the living room where we were, he was, like, showing me how to play. We were, like, I would say, 19, I think. Nineteen years old, something like that. Anyway, I show up, and I put on the gear, and I go out there. And I actually had a decent game, considering I barely knew how to skate and barely knew how to do anything. But I'm kind of big; I'm six foot four, almost six foot five. And having all that gear and everything, I filled up a lot of the net. And it wasn't a very high-level game, so I did pretty well. And after that, the team was like, "Well, we'd love to have you back." And then my friend really was not interested in continuing, so he was like, "You can have it, like, just roll with it." I kept playing for about three years, and then, I don't know, I took over a decade off. The team dissolved. It wasn't even a league team. It was just, you know, pick-up hockey. And then a friend called me and was like, "Hey, I'm starting up a game. It's going to be Finnish Americans," because I'm half-Finnish myself. "So, it's going to be all Finnish Americans. We're going to call it the [Foreign language]," which is the Finnish boys in sort of Finnish. It's not exactly supposed to be like that in Finnish. Anybody listening who's Finnish is going to be like, "Yeah, that's bad Finnish." But it kind of means Finnish boys or Finland boys. And we put together the team, and I've been playing for the last three-plus years. It's been kind of, like, a rec league team. We've won the championship four times, which was really fun. This year, I'm actually playing in two leagues. I'm playing in rec league, and I'm also playing the next league up, so a little bit faster, better skaters, better shooters, things like that. And I just love it. It's so much fun. WILL: Wow, that's amazing that you started later and that you're still playing it. Because when I look at hockey, I'm like, that's really hard. I don't know if I could do that. I can skate. I can't stop. JAMON: [laughs] WILL: Like, I can get a lot of speed [laughs]. But it's just something about turning sideways and thinking I'm going to fly over the skates. JAMON: [laughs] WILL: And yeah, it's a whole thing [laughs]. Is goalie harder than playing any of the other positions? JAMON: I would say it's different. Like, I don't have to be as good of a skater, you know, things like hockey stops are still not supernatural for me. I don't skate backwards super-fast. You know, I'm not a fast skater in general. But the difference is, of course, you have to be reading the flow of the game. You have to know the body language of the players that are coming at you. You have to kind of see what's happening. At the end of the day, lots of things can happen, so you try to put yourself in the best position. It's a lot of, like, positional, like, where are you in the net? What does your position look like? And then, once they shoot, how do you react? Are you dropping down, or are you staying up? Are you using your glove? Are you using your blocker? Are you just trying to block with your body using your stick? Then, once the puck hits you, then what do you do? How do you control the rebound? Are you trying to cover it up and ice the puck so they do a face-off? Are you trying to kick it out to one of your skaters? And then, once that happens, you have a little bit of a rest, hopefully, while they're down on the other side. But you're continually alert and watching to see what's going to develop because it could be a breakaway. And then it's just you and the skater and trying to anticipate what they're doing and try to make it so that they have to make a play. Like, just be big, be in position. Don't get out of position. Don't make a mistake. And I've had really great games where I've, you know, had 45 shots on me, and I've only let one in or something like that. And I've had some bad games too. I know there's one game in a championship where they only had six shots on me. But we ended up losing because I let in two, so that was not a fun game. I only had six opportunities, and I failed on two of them. But that happens, and so you just have to be mentally tough. WILL: Wow, that's amazing. The limited knowledge of hockey...I'm going to assume here, so I hope it's right. With you being 6'4, 6'5, I'm guessing that the five-hole, if I'm correct, was probably your toughest position to defend. JAMON: You know, you would think so. And just for the audience, the five-hole is, like, between your legs, you know, the puck going between your legs underneath. But I play a style...a little bit older style of goalie because that's what I watched. You know, in, like, the early 2000s, I watched Patrick Roy of the Colorado Avalanche, one of the greatest goalies of all time, and he played what's called a butterfly style. So, as the play develops, you're standing, but then you go down fairly early, and you're protecting the bottom. You have your stick in front of you protecting the five-hole, and you have your legs, you know, spread out. So, I used my height really more for blocking as I'm down rather than standing because when I'm standing, I'm above the net. It's better for me to get down. And I think that that's worked out pretty well. You know, Patrick Roy was a pretty big goalie as well. Most modern goalies play a more hybrid style. But, you know, we could get into all that. I'm a big kind of hockey nerd in this way. But that's what I do. I play butterfly, so most of the time, people don't beat me five-hole; when they do, it's usually they're picking a corner. WILL: Wow. Now that you've painted the picture, I can see how that's smart because you do have the goal, I mean, the gloves plus the stick and then your height. Yeah, I can see how...that's smart. That's very smart [laughs]. JAMON: Yeah, that's right. Yeah, that's kind of the goal. And also, because I wasn't a great skater, it sort of played into it as well, playing down on the ice where I was just more comfortable that way. It's worked out. I've had a pretty decent record over my career here [laughs]. WILL: That's awesome. Well, let's transition a little bit into consultant agencies. You've been doing it for 18 years. Tell me about that. How did you get started? JAMON: Well, when I started, I was working in construction. I was working for a home builder. And, you know, everybody I knew pretty much worked in construction, including my dad, who owned a business. And I went on my own. I had always dreamed of owning my own business, but I didn't start really thinking about websites. I was coding. I loved coding, and I was coding since I was 12. So, when I got to 23 years old, I thought, I'll start a business, and I'll do home design because that's what I was doing for the builder was, I was drawing homes. I was designing homes and remodels and things like that. And so, I started it doing that. But I also needed a little bit extra work. I didn't have enough work. Like, I had people, you know, sending me work, you know, home design and whatnot, but I didn't have quite enough. So, I would also build websites on the side, PHP and HTML, MySQL, and JavaScript. And I just sort of continued to do that. But in 2008, there was the housing crisis, and all of the design work for homes just dried up. There wasn't much there. In fact, it actually really dried up in 2007 because things kind of started a little early for designers. And so, I was like; I got to do something to stay busy. I've got a wife. I've got a young kid (Actually, at that point, I had two kids.), and I need to make sure that I'm staying busy. And so, I really ramped up trying to find work, you know, as a programmer, as a web developer. And there were plenty of companies at that time that were really trying to drum up business. So, they were putting money into their websites trying to get new projects, and they were all construction companies. And so, that's how I started. And I started doing more things like internal web apps for managing orders and managing sales leads, and that sort of thing. And that led me into web apps and eventually to Ruby on Rails, which became sort of my bread and butter for a while. As I was doing Ruby on Rails, you know, obviously, the iPhone was out, but the iPad came out. And I was more of an Android guy at that point. But I bought an iPad because it looked really cool, and my dad had one. When I started playing around with it, I'm like, I need to build apps for this. This is super cool. So, I took some Stanford courses online, which you could do back in those days, iTunes U, and learned how to use Objective-C. This was previous to Automatic Reference Counting and stuff. So, you had to manage your own memory, and this was a lot of manual work; very different environment than JavaScript, and PHP, and Ruby. But I actually enjoyed it quite a bit and then eventually transitioned into React Native later. But really, getting over to mobile and that sort of thing was...once I found mobile, I really didn't want to do web anymore. Mobile is what I really enjoy doing. WILL: Wow, I love that. If I'm following you correctly, you said in 2007, that's kind of when everything dried up. So, you were almost forced to find something different, correct? JAMON: Yeah, that's right. I mean, I kind of sat around feeling sorry for myself for a while. And then I was like, well, it's my business. I got to figure out what to do. It's not anybody else's fault. Like, you know, it doesn't matter that this is forces out of my control. I do have control. I have the ability to go in there and figure out, okay, what do I do next? Well, I know how to program, and it seems like people want me to program. So, let's lean into that. WILL: Wow. I love that. Because it's funny, that's how I got started in programming. I lost my job. And I was working at Buckle, the clothing store. If you know me, that is not me at all, like, at all [laughter]. I love gym shorts and athletic clothes. Like, fashion is not my thing. It's just not. So [laughs], I got into programming because I was just struggling. And it was a very pivotal moment in my life. And I'm thankful that I lost my job. Losing your job is just hard, and I think it makes you rethink things. JAMON: Yeah, absolutely. It was a growth moment for me as well, one of many. But that was definitely a point that I look back on and say, I mean because I can actually point at almost the day when it all dried up. It was, like, April 2007. And my uncle had been sending me a lot of work, you know, he had extra work. He didn't have barely enough for himself anymore at that point. And I finished up my last project, and he's like, "I don't have anything else." And I had some other clients as well and called them up, and they were like, "No, we don't have anything. Like, nobody is buying right now." And it just kept going like that. And it was weird because 2005, 2006, most of 2007, it felt like things were really rolling, but it just dried up all at once. And so, I was really lucky that I did end up getting a bunch of web work to do in 2008. I was still doing home design till probably late 2008, 2009. But then I eventually just hung that up and was like, okay, this is over. I'm definitely focusing on programming. WILL: Wow, how was the initial traction when you moved into ramping up the web development? JAMON: It was really good because it didn't take much to keep me busy. And I ended up getting some big contracts from, like, a cabinet manufacturer was a big one. I did some other things as well. And I ended up hiring my first employees in 2009. So, really, less than two years later, I was starting to hire employees. And I just hired, like, junior developers who had barely learned to code and taught them to code. So, I hired probably, over the years, next few years, like, ten programmers, many of whom are actually still with me today, and I taught them to code back in the day. And as time went on, they became senior and really high-level programmers who are now leading projects for big companies that you've heard of. But they started with me building, you know, PHP and MySQL and whatnot for small, like, regional construction companies. And we learned together. So, it was definitely a progression you can go look back and see. WILL: Yeah, I saw a tweet that you tweeted, and I loved it because I totally understand. JAMON: [laughs] WILL: And so, I'm glad you mentioned the junior devs and stuff. The tweet that I'm talking about was, "I got into this industry to code; ended up becoming a founder because I was the only person who would hire me." JAMON: [laughs] WILL: I want to ask you about that. [laughter] JAMON: Yeah, it's really that I grew up in a small logging town, like, very tiny logging town in Northwest Oregon. I didn't know...I knew one programmer, and the guy was, like, an incredible genius. And I just thought that that was the only way that you could professionally be a programmer was to be an incredible genius. I was coding, but I was, like, coding games, you know, in QBasic. And so, for me, every time I looked around, it was just, like, construction, or logging or, you know, blue collar, like, working at a mill. Like, these were the things that I saw around me. And so, that was the path I went. And I didn't really think of using this passion that I had for coding to turn it into, like, actual money. And when I did start thinking about it, I was like, I don't know anybody who does software. Like, even when I moved to Southwest Washington, I was closer to Portland. But I thought you had to have a CS degree, and I didn't have a CS degree. So, I was like, okay, well, I'll start my own business then, and that will be the thing that kind of leads me into tech. And that's what ended up happening. And it's kind of funny because I did go to, you know, one semester of community college for basketball and for...until I got cut. And then I studied some things there. But I never finished for the community college. What's kind of cool, though, is today, I'm actually on their, like, tech advisory committee. Like, they actually have me advising their professors on the current state of tech, which is kind of cool. WILL: Wow, that is really cool. It is interesting because I remember when I first started out and that feeling of probably over 300 applications just trying to get a job. And it was just hard. And my first job, to be honest, I think it was because of networking is why I got the job. If I didn't know the person that introduced me to the company, I probably wouldn't have gotten the job, if I'm being honest. But I am very sympathetic for junior devs anytime. If a junior dev asks me a question, I will take time, help them out. Because I remember...it's very hard as a junior dev trying to get that first job. So, when you said that, I was like, yeah, I can see your heart towards junior devs. JAMON: Absolutely. That's where I started. You know, the first developers that I hired were all juniors. We don't hire juniors anymore because of the style of business that we are. But I miss that. I miss that to some degree. We really can't. And we've looked at it from just about every angle. But I did my time [laughs]. I spent a lot of hours teaching junior developers when I could have done it quicker myself. WILL: Definitely. Like, you end up losing some money when you do a junior dev and you're hiring for the future. So, like, in a consultant agency, I totally understand that, yeah. JAMON: Yeah, absolutely. MID-ROLL AD: Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. WILL: So, I want to ask you about the transition from ClearSight Studio to Infinite Red. How did that happen? JAMON: ClearSight was my first company. And it sort of evolved from being a, you know, a home design/website company to just a website and web app company, and then mobile apps. And, at a certain time, we had, I think, around 12 employees, something like that. I had a design department. We were building websites and whatnot. And I was really interested in iOS development. That was really my passion. And so I actually ended up working on some open source with iOS developers across the globe and then got invited to a conference down in San Francisco in 2014. And I went and gave a talk there. It was my first tech conference that I'd ever been to, much less given a talk, and I was the first talk [laughs]. So, that was kind of an interesting little anecdote there. And as I did it, I got to know some other developers. I had one in particular, Todd Werth, who I really hit it off with, and we ended up chatting a lot after the conference. And it felt like he and I had a very similar outlook. And he had an iOS agency. That's all they did. Well, 2015 rolls around, and I had had some rough times toward the end of 2014 in terms of the business, and I was kind of complaining to Todd. He had had some issues as well, and we started commiserating. And he's like, you know, he just started joking. I still have this conversation in Slack way back if I go look. And he's like, "Well, maybe we should just merge our businesses together," because it felt like we had maybe complementary skills. And we had a similar outlook on what we wanted from our businesses. And so, we ended up eventually solidifying that. I flew down there, talked to him and his business partner, Ken, at the time. We ended up making that happen later that year. So, just a few days ago, October 1st was our eighth anniversary running the companies, running the new company, the merged company, which is Infinite Red. So, that was kind of how that all came together. Eventually, Ken left, and we had a new business partner who was our top employee buy-in; that's Gant Laborde. And so, there are still three owners. We have three directors and then the rest of the team. We're about 30 people altogether, and we focus entirely on React Native. WILL: Wow, congratulations on eight years. That's a lot. That's amazing. JAMON: Yeah, thank you. I was just thinking the other day that I ran ClearSight for ten years. Infinite Red is getting close to how long I ran my first business. And, like, my youngest is, like I said, 10. So she was only two years old when I merged the company. She does not remember my old company, which is weird to me. [laughter] WILL: Wow. So, can you walk me through your decision to go here with React Native and specialize in that? Because it sounds like right around the time when React Native was created, and people started using it in production. JAMON: That's right. The iOS technology that we had sort of bonded over at that conference was called RubyMotion. But in 2015, the founder ended up going to work for Microsoft for a while and then went back to Apple. He had been from Apple before. So, it was sort of going down. And we were looking for a different technology, both of our companies were, and then, of course, the merged company. React Native looked interesting, but it didn't have an Android version yet. But then, in September of 2015, Android came out, so it was iOS and Android. So, we were able to take a look at that one month before we ended up solidifying the actual merger. So, basically, day one, October 1st, 2015, we were, like, we are now doing React Native for mobile, but we kept doing web. We kept doing Ruby on Rails. We did some Elixir. We did some Elm. We did some...I think we had some old Ember stuff going on. We had all kinds of things going on. But over time, we got more and more traction with React Native because that's really where our interest was. And so, we ended up saying, okay, well, this is where we really want to be. It took us a few years. It took us probably five years, six years, something like that, to really develop the confidence to say, "Hey, this is all we want to do," because it's a risk. Like, you put yourself on one technology. We had that before with the other technology that went down. But we had the confidence that we knew we could step off of a sinking ship onto another one if we needed to. So, we said, "You know what? Let's do this." And I got to give my co-founder, Todd, a lot of credit because he was the first one to say, "Let's go all React Native. Anywhere that React Native is, React Native is on a lot of different platforms. You can do tvOS. You can do Mac. You can do Windows. You can do web with React Native web, all kinds of things. So, let's just focus on React Native. Our team will just focus on that. We will only hire React Native developers. All of our marketing is going to be around React Native. Let's just focus on that." And it ended up being a great call. We did that. We made that happen. And for probably the last, I would say, three, four years, something like that, that's all we've been doing. WILL: So, what's your opinion on, I guess, the argument that's being held right now with native iOS and Android, even the Flutter, and I think Ionic is the other one that I've heard of, versus React Native? What's your pitch on React Native over those? JAMON: There's definitely reasons to use any of those. But I wrote this article a while back. It was specifically about Flutter, but I think it applies to a lot of the other competitors as well. The title of the article was provocatively titled, "Flutter Is Better Than React Native in All the Ways That Don't Matter." And the idea behind this is that, yes, Flutter gets a lot of things very right. A lot of their developer experience is actually better than React Native; some is worse, but, you know, some is better. But really, when it comes down to it, the things that matter are more business level. React Native is good enough. It's like native views. So, you have the native performance. With Hermes, you have really good performance in JavaScript. So, you know that you can get really high-level JavaScript performance. You can ship JavaScript, which really helps because then you can bring in JavaScript developers, and specifically React developers. So, a lot of companies already use React. It's a no-brainer to then use React Native if you're already using React Web. It doesn't really make sense to go to Flutter. It makes maybe some sense to write it in native, but then you have to write it twice. And you have three teams. You have a web team. You have an iOS team, and you have an Android team. And you also have three codebases, and one's always lagging behind. That's always what's happening. Marketing is like, "Okay, when can we announce this?" "Well, iOS isn't done," or "Android is not done," or "Web is not done." Where if you can combine all of those things and combine just the culture of your team, then it becomes more tight-knit because everybody's working on all aspects at one time. You can take a feature, and you can build it in web, and you can build it in iOS, and you can build it Android with all the same skills. Now, there are some deeper parts of React Native. It goes really deep. But in terms of just being productive out of the gate, a React developer can be productive in week one, and that's, I think, a huge deal. So, it really comes down to is the performance and developer experience good enough? And the answer is absolutely yes. And then, secondly, like, what's the business case for React Native? Well, you can have the same developers doing iOS, Android, and web, and even if you don't, you can share techniques. You can be like, "Hey, here's this cool JavaScript thing," and the Kotlin developers aren't just like, "Ugh, you know, JavaScript." Or you can be like, "Hey, here's our TypeScript configuration across the whole codebase." You can even have a monorepo with everything in it. It just makes a lot of sense that way. And especially now with Expo, it makes it even more that way because Expo removes a lot of the barriers for web developers that they would have coming into native. So, with that in mind, I still see React Native dominating the apps that are at the top of the App Store. One of the Expo developers, Evan Bacon, has put out a bunch of tweets about, you know, like, 24 out of the top 100 food and drink apps are written in React Native, as opposed to 8 in all the other options combined other than native, you know. So, it gives a good sense that React Native is still growing and continuing to. It has a lot of steam behind it. WILL: Yeah, I totally agree with you. I'm a big React Native fan, and I do a lot of React Native work here. So, yes, totally agree with you. And one of the most frustrating things that I've come across is, I'm a big researcher, and so I'll research things, and I'm like, oh, there's an app for this. And I'm a big Android fan, so when I go to them, it's like, oh yes, I can use this app. And then it's like, no, I can't. It's only for iOS. Okay, like, you lost me as a customer. JAMON: [laughs] WILL: I was willing to pay whatever on this because I've been looking for it. So yeah, I like how you said that. JAMON: Yeah. It treats all of the platforms as first-class citizens. WILL: Yes. Yes, yes, yes. Totally agree. How does your company handle the backend? Do y'all do any of the backend, or how is that handled at Infinite Red? JAMON: We used to do that, like I mentioned. But a few years ago...we had a very, very small back-end team by then. Most of the time, and now pretty much 100% of the time, when someone comes to us, they already have a back-end team, so we work directly with them. A lot of our developers were back-end developers, and so they understand the backend really well, but they're obviously React Native specialists now. So, you know, I came from that. I did PHP. I did Ruby, Ruby on Rails, Elixir, Node, all kinds of back-end technology. So, I understand it really well as well. But yeah, we lean on our clients for that. We might partner with an agency like you folks over there at thoughtbot and have them do the backend, or just have the client, you know, come up with their own solution. WILL: Yeah, I love that, yeah. And we've done that with numerous agencies, so yeah, that's awesome. What does success look like for Infinite Red now versus, you know, six months or five years from now? Do y'all have any goals in mind that you're trying to hit? JAMON: In the Infinite Red leadership, we are currently reading John Maxwell's 21 indisputable Laws of Leadership, which is a good book. And we had this really great conversation at our first book club meeting in leadership, which John Maxwell defines success in a very different way than we do. You know, he measured it as, like, McDonald's, or Starbucks, or something like that, like, giant, becoming huge, becoming big, making tons of money. And it was sort of just implicit in the book that that was the case. We had this great talk internally. Why didn't this resonate with us? And that's because we don't really measure success that way. So, I love that question, Will, because measuring success is you really have to start there. Like, you have to start there and say, "What do we want from this?" So, ultimately, we want to build cool things with our friends. I'm a coding nerd. I want to code. I want to be in the code. That's why we're an agency. Like, if we were a product company, if we were building, I don't know, podcasting software or something, we'd have to become experts in podcasting rather than experts in React Native, or experts in TypeScript, or whatever we want to do. So, we really love code. We want to build that. We want to have an amazing family-first environment. We want to treat everybody super well. We want to have really low turnover, which we've been able to achieve. Hardly anybody leaves Infinite Red. Maybe every other year, we might lose one person. And even with those people, they tend to come back [laughs], which is a great sign. They go out and find out that, yeah, actually, Infinite Red is pretty awesome, and they come back. So, we really look for that. We really focus on that. We want that to happen. And it's really less about making the most money we can. Obviously, everybody wants to be well paid. And so, we're going to try to make sure we have a successful business in that way and that we want to be around for a long time. But, really, measuring success is less about business success and it's more about life success. It's really more about family success, being with my four kids, being there for them when they need me to be. That's why we're remote, you know, as another example. So, everything really hinges off of that. It's around happiness. It's around fulfillment. It's not around financial success. WILL: I'm a huge John Maxwell fan, by the way. JAMON: [laughs] There you go. WILL: So, yes, I love it. And I love how you explained, you know, because one of my questions I was going to ask you is about the core values, but I'm going to switch it up a little bit. So, I'm just going to say, in my opinion, I feel like there's almost leadership talk void at times, especially in the tech space. Like, we don't talk about leadership a lot. But it plays a huge part in what we do day to day. Like, you named a couple of core values and principles that you're following because of the leadership. So, for you, why is the leadership so important and I guess you can say have a seat at the table at Infinite Red? JAMON: I'm a strong believer, and I've become more of a strong believer over time, that it all starts at the top. If you don't have buy-in from your top leadership, it does not really matter what happens otherwise because they will continually undermine, and they have the power to continually undermine that. So, these core values have to apply to the top leaders. They have to be held accountable to that. And these leaders also need to be developed. So, we have three owners. We have three directors. And the three directors who are underneath us were not directors when we hired them; you know, they started out as developers. They started out as designers. They started out as project managers. But they became Director of Operations, Director of Engineering, Director of Communications. And we developed them. We poured a lot of time into them, and we continue to do that. In fact, even reading this book with them and going through that exercise is continuing to invest in them. Not that we as owners don't have growth to do; we also do. And so, we learn from them, and we learn from our team. So, you have to start there. And on that same vein, we do have some core values. We call them our foundation and our pillars. We have three foundational things, and we have four pillars. So, the three foundations are: one, we control our own destiny. We are not going to be beholden to some other company. We're not going to ride someone else's coattails. We're not going to be in a situation where someone else can kill us. And it can be easily done that way where we're in a position where, you know, we're too reliant on one whale client or something like that. We just won't do it. The second foundational thing is that we have...it's a word bonitas, which means kindness, friendliness, benevolence, blamelessness. And it's basically just being a good person to everybody and doing the right thing. And the third one is having a significant positive impact. That's why we do so much media. That's why we try to have an impact outside. And we're only 30 people, but people think we're way bigger because of how we kind of present ourselves in the world. And then our pillars all support those things, so high personal support. We support each other. We have high expectations, but we also support each other not just at work but also as a whole person. Long-term viewpoint, we think way beyond this year. We think about what is Infinite Red going to be when I retire? You know, I'm 41; that's a ways out, hopefully. But what's that going to look like? The next one is collaborative creativity. Creativity by yourself is just a solo thing. We're a team, so it has to be collaborative. We have to do it together. All our creative work, whether it's our conference, Chain React, or our work, it's all collaborative, and we love being creative. And the last thing is being pioneers, pioneering spirit. We like to be pioneers in technology. We put out a lot of open source. And we try to bring that pioneering spirit everywhere we go. And then, there's a lot of different things that kind of come out of that. For example, we have this internal saying, which is, "Don't do hard things alone." So, you have a hard thing coming up? And it could be hard in various ways. It could be a technically challenging thing. It could just be hard because of the mood you're in that day. But don't do it alone. Ask someone to help you, you know, jump in with you, pair with you. Do it together. And we love that. That's part of the high personal support and the bonitas. So, all these things come out of the foundation and pillars that we have. WILL: Wow, I love all those. I want to pick one of them out and ask you a question around it. So, you're talking about having an impact. I'm loving this conversation just talking to you. It's just been amazing. So, for you, what do you want the impact on the world to be from your perspective? JAMON: That's a hard question to answer, and it tends to be something that I think about a lot. I'm more of an opportunistic person. I react more than I plan ahead, that sort of thing. But with that said, I think that we have had significant positive impact through a lot of different ways. So, on Twitter, for example, I try to present a...and this is authentically who I am. But I try to present a positive force out there, someone who's excited and enthusiastic about the technology, who supports other people, even who you might consider competitors, for example. I just retweeted recently a Callstack thing. I mean, you might consider them a competitor. They're another React Native agency. But I love Callstack. They're great people. And I retweeted one of their really amazing resources, which is the ultimate guide to React Native performance, which, by the way, is really good. And if you do React Native, you should check it out. So, I think what goes around comes around, and I really want to have that positive impact out there. I want to give talks that inspire people. You know, I'm a nerd, and I'm going to nerd out about stuff. And I feel like that has an impact all of its own. So, that's kind of my personal side of it. And then Infinite Red is a showcase that you can run a company the right way. You can treat people the right way. And the company can be successful along our own metrics of success. WILL: So, one of my biggest principles that I've learned in life that's changed my leadership 100,000% is from this book called One Minute Manager. And I think it's called one-minute praise. And, essentially, the background behind it is, if you think something, just tell the person because so many times...and I get in my head, and I think amazing things about people, but I never say it. JAMON: [laughs] WILL: So, I want to just tell you, like, you said, the impact that you're making. You are doing that. Like, one of the reasons why I invited you on the show was because of your impact that I see that you're having on Twitter and LinkedIn and just everything that you're doing at Infinite Red. So, keep going. I want you to know that you are making a difference. I see you, and it's making a big difference in my life. JAMON: I love that, and it makes me feel great. And I appreciate you sharing that one-minute praise there. It is something that sometimes you put it out there, and you don't really know what the impact is, you know, it's sort of hidden in maybe the likes, or the replies, or whatever. As an example, I just reached out to my friend Aaron Francis last night, and I told him, "Hey, I love your videos." I don't even do the tech that he does. But I watch his videos on YouTube because I just love the vibe that he has. And I told him that. I was like, "You're doing a great job. You're being a very good advocate for your company." And I agree with you; I think that just taking the moment to reach out and say, "Hey, I think you're doing good work," it encourages people to do more of it. So, I appreciate it a lot, Will. That's really nice of you to say. WILL: Yeah, definitely. If you can go back, what is some advice that you would give yourself? We could do both at the beginning when you did ClearSight and whenever you merged and did Infinite Red. Was there any advice that you're like, wow, I learned these lessons, and they were game changers for me? JAMON: [laughs] Boy, this could be a whole nother podcast, to be honest. There are so many different things that I've kind of learned over the years. I feel like, you know, there's value in, you know, there was actually...I forget exactly where I heard this, but it was about Cloudflare, the company. And a long time ago, as they were sort of launching, one of the people that worked on the...I think it was their founder, actually. One of their investors told him, "Hey, running a company is sort of like flying an airplane. You want to make sure that it's well-maintained at all times. And then, when you're flying, you keep the wheel steady and the nose 10 degrees above the horizon so you continue to rise. And you don't need to shoot for the moon. We're not a rocket here. Just continue to execute well, make sure that it's well maintained, make sure that you're continually rising." And Cloudflare is a good example of this, and I think that Infinite Red is as well. Every year, we try to do something where we're continuing to keep that nose 10% above the horizon. That doesn't always mean growing. Like, we don't hire all that often. We don't grow in terms of headcount, but we grow in other ways. And you can see that looking back over the years. Every year, there was something that we continued to, you know, improve, keeping that nose 10 degrees above the horizon. And so, that's a big one. And you can just go do all the little things really well and continue to think long term and where are you headed. And if you do the right things long enough, good things happen. WILL: I love that because, especially when I'm working out, I try to shoot for the moon. JAMON: [laughs] WILL: I go all out. So, that was some amazing advice. I don't even remember who told me, but when I first started programming, I tried to shoot for the moon. And, oh, I crashed and burned so many times [laughs] because it's just something you can't just master it, and just like, I got it, da da da. And I love that advice. That's amazing advice. So, that's perfect. JAMON: Yeah, it really stuck with me, and I have so many more lessons. I have actually kept a notebook of profound things that I've heard over the years, and I actually really enjoy that minute praising you said. And I'm going to look up the quote after this, and I'm going to put it in my notebook. [laughter] WILL: Yeah, yeah. It's been a game-changer because I'm a very straightforward person. And so, a lot of times, like, I don't mind addressing an issue just head-on. But what I found is I'm just always doing that. And I never had equity in the bank at times. This is when I was a very young leader. I didn't have equity. And so, it was just hard to tell people, "Hey, can we tweak this? Can we do that?" And then I had to sit back and say, okay, what can I change to be a better leader? And it's like, I can connect better. And I see so many things. Like, I'm very observant, I think. To be honest, it's helped me in every area, even with my spouse, with my kids, with friends. It's just saying, "Hey, I see what you did. I see that you made breakfast." Or "My kids, I see that you made this beautiful mud pie for me. And it's amazing. So, thank you. Thank you." And so, yeah, it's been a game changer for me. JAMON: Yeah, one of my friends, his goal was...and he's a leader. And he said that his goal with everyone on one was to give them one thing to change and highlight one thing they did well like you said, equity in the bank. He was talking about when he was a leader of, like, a call bank. And he said, "No matter how bad the call was, I wouldn't give them more than two things to improve because there was no way that they could take ten critiques and improve. They would just be defeated." And then, he would review and see if they could improve one more thing, avoided negative language, things like that. So, that's a really interesting concept. WILL: Yeah, definitely, definitely. So, I have one other question for you. What motivates you? What's your wind in your sails? What keeps you going? Because I know running a consultant agency is not easy. What keeps you going? JAMON: For me, motivation tends to be enthusiasm for learning, really more than anything, like going into something new and, like, exploring. I see it more as exploring even than learning. With a consultancy, there's always so many different...it's never the same, you know, there's always some other challenge. And that's one of the reasons I've loved being, you know, a consultancy owner for so many years. You're never dealing with just the same stuff over and over. So, I would say it's really about the exploration that happens, and just loving code, and talking shop, and being around great people. To me, that continues to motivate me. WILL: I love that. Do you have anything that you would like to promote — personally, Infinite Red, anything? JAMON: Well, Infinite Red, of course. If you're looking for React Native, we are all senior-level React Native developers. We've been working together for a long time. So, big companies, the biggest ones you can think of, many of them have hired us to, you know, be the experts with their team. We usually put 2 or 3 people on a project, and then the client will come in with 2 to 10 people or whatever they have on their side. And we work with them side by side, teaching them as well as delivering code. So, that's really our bread and butter. We also put on the biggest and, I think, only U.S.-based React Native conference, and it's called Chain React. It's in Portland. Next year, it's going to be in July. So, go check it out: chainreactconf.com. We'd love to see you all there. I'd love to see you there, Will. And network with all these different React Native developers. There's people from Meta, and Microsoft, Amazon, all over the world, really. And they're some of the best React Native programmers you're going to ever meet, and some great talks, and great food, and a great city. WILL: Yeah, I would love to be there. Let me ask you this: how is Portland in July? JAMON: Portland is amazing in July. Sometimes, it can get hot, but for the most part, it's just beautiful. It'll be like 85 degrees, not really any humidity, nice, little breeze. It's just a beautiful weather pattern around Julyish. That's why we chose that time of year. So, definitely, if you're going to be coming to Oregon, Portland, you know, West Coast, July is a great time to come. It's not going to be super, super hot, usually. Sometimes, I mean, we get over 100 sometimes, but no worries, you know, there's AC as well. But for the most part, it's beautiful. WILL: You sold me already. JAMON: [laughs] WILL: So, I live in South Florida, so...[laughs] JAMON: Yeah, it's going to be different in South Florida in July. [laughter] WILL: Awesome. Well, this has been an amazing chat, and just great getting to know you and learning more about Infinite Red. Thank you for being a part of the podcast. JAMON: Yeah. Thanks for inviting me, Will. It was a lot of fun, and you're a great host. I appreciate it. WILL: I appreciate it. JAMON: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions. Special Guest: Jamon Holmgren.

An airhacks.fm conversation with Axel Fontaine (@axelfontaine) about: starting with 8086 and 640 kB, starting with GW Basic, enjoying Alley Cat and Monkey Island on Sega Master, switching to QBasic, protecting the lemmings, the cyber cafe Cyberia in London, learning Turbo Pascal, impressed by Java Applets, starting in 1998 at IBM Global Services, using Visual Age for Java, travelling the world, the envy version control for Visual Age for java, attending JavaPolis, qcon, first talk at JUG Augsburg about Continuous Delivery, the Continous Delivery Book, Ruby DSL migrations, “data will outlive the code”, database outlives the code, the travel report website, Flyway - the migration path for birds, using JDBC metadata for schema migrations, promoting FlywayDB, paid features and support contracts, running migrations on application startup, the Java EE simplicity Axel Fontaine on twitter: @axelfontaine

That's why SwaraLink Technologies created the Bluetooth Low Energy Developer's Checklist. In this podcast, the CEO and Co-Founder of SwaraLink Technologies, Sandeep Kamath, breaks down BLE and the checklist they've created, including various topics, from optimizing throughput and power consumption to ensuring secure connections and supporting over-the-air firmware updates. These aren't necessarily must-dos, but they're essential considerations to keep in mind as you design, develop, and test your product.Sandeep was initially a self-taught programmer, playing around with QBASIC and Visual C++ in high school, but then shifted his interest from software to hardware while at the university level. He received his Bachelor's and Master's degrees in Electrical Engineering from the University of California, San Diego, focusing on Analog and RF Integrated Circuit Design. His educational background in hardware and RF systems and personal interest in software eventually led him to the world of embedded wireless systems. After graduating, Sandeep spent over a decade in the semiconductor industry, including eight years working for Texas Instruments Wireless Connectivity group. During his career at TI, Sandeep worked in various technical, management, and business roles, all related to TI's Bluetooth Low Energy product line. In 2017 Sandeep took his knowledge of Bluetooth Low Energy from both a technology and market standpoint and founded SwaraLink Technologies to help companies build high-quality products with great user experiences.SwaraLink Technologies is a services and solutions company focused on Bluetooth Low Energy (BLE) systems and software. Their flagship product, the SwaraLink Bluetooth Low Energy Platform, is a cross-platform middleware solution that reduces the cost of developing high-quality products that use Bluetooth Low Energy technology. SwaraLink was founded and incorporated in the State of California in 2017, with headquarters in San Diego. Since its founding, SwaraLink has helped numerous customers with various services, including architecture, development, testing, and debugging complex hardware and software systems that use Bluetooth and Bluetooth Low Energy Technology.

A look at various approaches for keyboard input and graphics display in QBasic. Demo code – https://github.com/levidsmith/QBasicShooter Links and Notes QBasic.net – https://www.qbasic.net/ ASCII character chart – https://www.qbasic.net/en/reference/general/ascii-table.htm Keyboard scan codes – https://www.qbasic.net/en/reference/general/scan-codes.htm DOSBox special keys – https://www.dosbox.com/wiki/Special_Keys QBasic advanced memory functions  – http://www.petesqbsite.com/sections/tutorials/tuts/memory.htm Sprites in QBasic – http://www.tedfelix.com/qbasic/sprites.html Introduction to QBasic – http://www.petesqbsite.com/sections/tutorials/tuts/dandd/ WikiBooks … Continue reading QBasic IO and Graphics, Knox Game Design, December 2022 →

It was great to be able to talk to Andrey for this episode. He shared some of his journey to becoming a professional software developer (starting off with QBasic and Delphi), teaching software development to school kids, before moving to JetBrains to be the lead designer of the Kotlin language.Links Design Patterns: Elements of Reusable Object-Oriented Software (The Gang of Four book) Object-Oriented Analysis and Design with Applications by Grady Booch Refactoring by Martin Fowler Kotlin JetBrains QBasic Delphi Guests: Andrey Breslav (@abreslav).Hosted By: Matthew Setter.Thanks for tuning in to Free the Geek. If you'd like to be a guest on the podcast or know someone who'd make a great guest, email me: matthew@matthewsetter.com. This podcast is produced by Matthew Setter. SupportIf you want to support the show, you can always buy me a coffee. I'd greatly appreciate your financial support.

Dave Zohrob is the co-founder of Chartable (a podcast analytics startup), talks about selling his company to Spotify in February 2022. Highlights (go straight to

Our guest from Episode #067, Parag Shah, foresaw the death of penmanship - something he happily announced at age 8. That didn't save him from having to write a page of QBasic code each day before he could go out to play! Topics discussed include how serious you get about studying when you are paying your own tuition, decoupling storage and compute, and handling turnover at the top.   https://learn.dvorak.nl/ https://www.umass.edu/living/residence/northeast https://en.wikipedia.org/wiki/Necco https://www.forcepoint.com/cyber-edu/shadow-it

Benj Edwards - journalist, tech historian, and recovering retro computer hoarder - teaches us a little about MS-DOS and QBasic through their How-To Geek article: GORILLA.BAS: How to Play the Secret MS-DOS Game From Your Childhood. Frank and Benj reminisce back to day zero, Snacks 'n Jaxson gets swatted, we hack a powerful secret instead of learning our lesson, and Frank sings the theme song for history. Mentioned in the show: Computer History Museum in Mountain View, California - https://computerhistory.org/ https://oldcomputers.net/ https://www.vintagecomputing.com/ See more from Benj Edwards: Twitter: @benjedwards Website: http://vintagecomputing.com/ How-To Geek: https://www.howtogeek.com/author/benjedwards/ Video Game History Foundation Podcast Twitter: @gamehistoryhour Email: podcast@gamehistory.org Twitter: @GameHistoryOrg Website: gamehistory.org Support us on Patreon: /gamehistoryorg

Array Cast - January 22, 2022 Show NotesMany thanks to Adám Brudzewsky and Bob Therriault for collecting these links.0:01:35 APL logo Voting https://aplwiki.com/wiki/APL_logo 0:02:20 Conor's Voting Video https://www.youtube.com/watch?v=Jxu4nWh1214 0:02:47 Vector Dojo https://community.kx.com/t5/KX-Technology/User-Feedback-Request-The-Vector-Dojo/td-p/116450:07:09 Q Basic https://en.wikipedia.org/wiki/QBasic 0:10:47 Scheme Manual https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-user.pdf Chez Scheme https://www.scheme.com/ 0:14:27 Indiana University C.S. Department https://cs.indiana.edu/ 0:15:00 Kent Dybvig Dissertation http://www.cs.unc.edu/xcms/wpfiles/dissertations/dybvig.pdf 0:15:26 Schneider, Fred B. On concurrent programming. 1997. Springer-Veriag: New York. ISBN 0-387-94942-9 https://link.springer.com/book/10.1007/978-1-4612-1830-2 0:16:20 Game of Life Scholes https://apl.wiki/John_Scholes'_Conway's_Game_of_Life 0:17:00 APLX https://apl.wiki/APLX 0:20:00 K https://k.miraheze.org0:21:37 Arthur Whitney https://apl.wiki/Arthur_Whitney0:22:06 J incunabulum https://code.jsoftware.com/wiki/Essays/Incunabulum0:22:57 Arthur Whitney Comparing APL and Lisp - https://kparc.com/lisp.txt 0:27:50 Bullet Journalling https://bulletjournal.com/pages/learn0:30:00 Chinese Language Forms https://en.wikipedia.org/wiki/List_of_Chinese_classifiers0:36:15 Notation as a Tool of Thought https://www.eecg.utoronto.ca/~jzhu/csc326/readings/iverson.pdf 0:39:33 PL Wonks Co Dfns Talk https://www.youtube.com/watch?v=9NR3sz4D4zc 0:44:21 Reversible Computing Roshan P. James https://scholar.google.com/citations?user=0sGAm4sAAAAJ&hl=en 0:47:45 Devoxx - Refactor your language knowledge portfolio https://www.youtube.com/watch?v=zajUPJI19ZQ 0:49:50 SQL https://en.wikipedia.org/wiki/SQL0:50:50 Functional Conf 2018 Live Coding https://www.youtube.com/watch?v=Gsj_7tFtODk&t=1158s 0:51:43 Aaron Hsu Resource Page https://aplwiki.com/wiki/Aaron_Hsu 0:53:00 A Data Parallel Compiler Hosted on the GPU https://scholarworks.iu.edu/dspace/handle/2022/24749 0:54:00 Patterns and Anti-patterns Dyalog https://dyalog.tv/Dyalog17/?v=9xCJ3BCIudI 0:54:17 Patterns and Anti-patterns Functional Conf 2017 https://www.youtube.com/watch?v=v7Mt0GYHU9A1:01:40 TryAPL https://tryapl.org/1:02:40 Spenserian Script https://en.wikipedia.org/wiki/Spencerian_script1:06:24 Englebart Group Cognition https://dougengelbart.org/content/view/194/ 1:11:30 Chronicles of Thomas Covenant https://en.wikipedia.org/wiki/The_Chronicles_of_Thomas_Covenant 1:12:52 ADSP podcast #56 Leetcode in BQN https://adspthepodcast.com/2021/12/17/Episode-56.html 1:17:50 A Programming Language - Iverson https://www.jsoftware.com/papers/APL.htm 1:18:00 Aaron's Website - https://www.sacrideo.us/

The Elixir Outlaws now have a Patreon (https://www.patreon.com/user?u=5332239). If you're enjoying the show then please consider throwing a few bucks our way to help us pay for the costs for the show. On today's episode of the Elixir Outlaws, Sean Cribbs and Amos King are going to talk about Sports of Sorts. Amos shares some driving wisdom and his fondness for silent thoughts. Sean and Amos will share some random and interesting experiences. Episode Highlights: Amos reveals how he developed his creativity and problem-solving skills from driving. Sean has recently resigned from his job, and he is about to join a new company after 12 days. As per Sean, one spends a lot of your time sleeping because their dreams help them to work through problems Amos loves jogging around the river next to the hotel early in the morning when nobody is up. For him, it is nice and quiet. Brittany Matthews is a co-owner of the women's soccer team. She has been big in promoting women's sports in Kansas City, but especially soccer, and Patrick and Brittany broke ground on a new training center earlier this year. Then, three or four weeks ago, they revealed their new team name. The stadium is first of its kind for the women's soccer team, which is huge because this team has only been here a year. They just announced that they were going to have a team this January 2021. For those not in Kansas City, the streetcar is absolutely free , which is really awesome with all the buses because buses are free too. So you can go anywhere for free in Kansas City. We have one of the best women soccer players in Samuels who has been on the national team. An Incredible midfielder, dynamic player, and she is going be exciting to watch, says Sean. While talking about the new company where Sean is going to join. He explains that the company is doing motion graphics or motion design. People really want the ability to collaborate to provide feedback on designs, work on different iterations, compare them, and build out a portfolio for you, says Sean. There are multiple companies out there called Fable, so if you want to go look it up, it is Fable, not Fable dot IO, not fable com. It is the Fable Dot app. It is one of those easy, easy ones to find. Amos says he doesn't know how possible it would be, but it would be interesting if, two designers could work on the same like image or animation at the same time, doing the same kind of ideas of passing changes back and forth. Part of the reason why Sean's friend wanted to hire him is because he has distributed systems experience, where all the bodies are buried, where all the problems are gonna be like what if we want to have real time collaboration or like something like Miro where people are dragging things around on the on the project at the same time. What always kills me on the front end in the browser, or even if you are compiling and making things faster, is that you really have zero control over the quality of the computer it is running on and the problems like the interactions between the things, says Amos. Sean says that they are going to write C+ code because it was mostly C code, but using the C ++compiler and very few features of C and like the Windows API and like working with it directly to build a 2D kind of Zelda light game. Sean says that the JavaScript community is huge. You have a lot of people experience in JavaScript. It doesn't take that many of them to make a good customization. Amos shares that his first editor for code other than the QBasic editor was Emacs and that was 22 years ago. Amos says that his first experience with C not running everywhere was in an AI class and they had to write a chess engine and then they all played the developed chess engines against each other. Sean says there is a bytecode format that you can take from running on a Intel being VM and run it on an ARM beam VM or on some other processor that is running your nerves project. 3 Key Points Those of you who don't know anything about Kansas City, but Patrick Mahomes is a big deal here quarterback for the Chiefs and his fiance Brittany Matthews is kind of influential in her own. Sean says that Figma has changed the way people do collaborate on static web design, this is going to be collaboration on motion design. Motion design would include things like just regular animations you might see on the web. It could include things like advertisements, logo, animations. There are a lot of different ways that we could do collaborate. Another area that he talked about us wanting to do is so a lot of this is like you do in the browser, You draw your shapes, you animate them you set the keyframes, you know you set all that stuff up. But that only produces us a level of quality that the browser can produce. But if you want to do 4K video of this animation that you just created, you are not going to produce that with your browser, says Sean. Tweetable Quotes “I am a big fan of silent thoughts” – Sean “When they introduce the team that the players that are going to start for the match. They had some incredible motion designs on the video board.“- Sean “It is not movies, it is more about the animation than about video editing. It is like making an animated logo.” - Sean “There are some pretty interesting problems how to isolate yourself from these, they are doing something very quick and then suddenly they open another program on their desktop, but that hangup.” – Amos “90% of your life was spent formatting exactly how that professor wanted it formatted, which is like a huge waste of time.” - Amos Resources Mentioned: Podcast Editing Elixir Outlaws: Website

Sorry Again, The Car is Back, COVID-19 Booster, Free Guy, The Wanting Mare, Finch, No Time to Die, Dune, Dexter: New Blood, UFO, Angela Black, The Haunting of Bly Manor, Foundation, The Lost Symbol, Gamesmaster, Star Trek: Discovery, Dean Stockwell, Shure SM7B, Shure SM58, Behringer XM8500, Audio-Technica AT875R, Elgato Wave Mic Arm (HR) vs. RODE PSA1 Boom Arm, awk, sed, vi, QBasic, Old Disk Treasure Trove, Lock Picking a Locked Box of Disks, Browsers No Longer Supporting FTP, Digital Preservation, Vim, Busybox, More Backyard Astronomy

Sorry Again, The Car is Back, COVID-19 Booster, Free Guy, The Wanting Mare, Finch, No Time to Die, Dune, Dexter: New Blood, UFO, Angela Black, The Haunting of Bly Manor, Foundation, The Lost Symbol, Gamesmaster, Star Trek: Discovery, Dean Stockwell, Shure SM7B, Shure SM58, Behringer XM8500, Audio-Technica AT875R, Elgato Wave Mic Arm (HR) vs. RODE PSA1 Boom Arm, awk, sed, vi, QBasic, Old Disk Treasure Trove, Lock Picking a Locked Box of Disks, Browsers No Longer Supporting FTP, Digital Preservation, Vim, Busybox, More Backyard AstronomyShow notes at RoyMathur.com/blog.html

Jeremiah Schugt graduated with Full-time Web Development Cohort 47. Started coding using QBasic, back in the day. I've been interested in how programs work, taking on their challenges and the satisfaction of solving and learning.

An airhacks.fm conversation with Mohamed Taman (@_tamanm) about: AMD PC in 1997 with 200 MHz hot AMD, exploring the DOS and QuickBasic, drawing sceneries, photography as hobby, assembling PCs from parts, AS-400 and RPG, QBasic and C++ on Windows 3.11 and Windows 95, to shutdown windows you had to push the start, Windows Millenium Edition, equations in QBasic, starting with Java 1.1, the Sun Certified Java Programmer certification was hard to pass, impressed with Java, Java hides the low-level boilerplate for convenience, catching up with J2EE 1.4 and Java EE, building mazes with OpenGL and Java, working for Silicon Experts, staring with Sun Enterprise Server, later BEA WebLogic, recreating Struts from scratch, the problem with early EJB, working on JD Edwards, Oracle and Siebel integration, using ADF at Oracle, Sun Microsystems was acquired by Oracle, starting at eFinance, efinance is private, but founded by the government, started a United Nations (UN) project for donations management, Java EE 7 with Glassfish was used as the stack, finding bugs in GlassFish, working with the latest versions in mission critical projects, presenting at JavaOne keynote, JBoss to quarkus migration on openshift, "Java EE: Future Is Now, But Is Not Evenly Distributed Yet" at JDD, scaling with hardware, Mohamed Taman on twitter: @_tamanm

All super heroes have an origin story. And, *so do nerds*. Many of us can remember back to that moment when we realized that there was magic in the world - magic that we could be part of; and, magic that we could help create. This week, we get personal with the crew and learn more about where they came from, what kind of stuff makes them tick, and what it is that they love about being web application developers. This Part 1 of a two-part series. Part 1 includes Tim and Ben. Part 2 will include Carol and Adam. *Triumphs & Fails* * *Adam's Triumph* - He moved mountains of data using "pivot tables" in Google Sheets in order to build summaries of his newly-rolled-out test coverage at work! He's a hair's breadth away from fully converting his codebase over to an open-source platform. * *Ben's Triumph* - He totally built something without JavaScript ! I know, it sounds crazy: in the age of Single-Page Applications (SPA) and JavaScript frameworks, reaching for JavaScript is the default. But he managed to build something useful with just HTML and CSS ! * *Carol's Triumph / Failure* - She just passed the 4-month mark at her new job, like a boss! But, she been a little bit down in the mouth, concerned that she's not getting enough done and that she's not learning enough. She managed to turn the week around, however, getting some productive "Design Buddy" work (think "pair programming" for the planning phase) done. * *Tim's Triumph* - He checked his old Coinbase account from 2015 and the $15 he left in there is now worth $85. He's about to wine and dine himself! *Notes & Links* * :target ( https://developer.mozilla.org/en-US/docs/Web/CSS/:target ) - CSS selector that matches elements whose id matches the URL fragment. * Coinbase ( https://www.coinbase.com/ ) - a place to buy, sell, and manage your cryptocurrency portfolio. * Lost Passwords Lock Millionaires Out of Their Bitcoin Fortunes ( https://www.nytimes.com/2021/01/12/technology/bitcoin-passwords-wallets-fortunes.html ) - New York Times article about a millionaire who has two more chances to remember his password for quarter-billion in Bitcoin. * Google Sheets: Pivot tables ( https://support.google.com/docs/answer/1272900 ) - creating and using pivot tables in Google Sheets. * Aqua Data Studio ( https://www.aquafold.com/aquadatastudio ) - a versatile database IDE with data management and visual analytics for relational, cloud, and NoSQL databases. * ELIZA ( https://en.wikipedia.org/wiki/ELIZA ) - an early natural language processing computer program. * Zork ( https://en.wikipedia.org/wiki/Zork ) - one of the earliest interactive fiction computer games. * Kaypro ( https://en.wikipedia.org/wiki/Kaypro ) - a computer manufacturer from the 1980s known for their line of rugged, "luggable" computers. * dBase ( https://en.wikipedia.org/wiki/DBase ) - one of the first database management systems for microcomputers. * CP/M ( https://en.wikipedia.org/wiki/CP/M ) - an early operating system. * Ultima Online ( https://uo.com/ ) - one of the first MMO (Massively Multi-player Online) games. * Adobe ColdFusion ( https://www.adobe.com/products/coldfusion-family.html ) - a modern web development language. * Lucee CFML ( https://www.lucee.org/ ) - the leading open-source CFML application server / engine - it's so good you might just freak out! * Sierra Entertainment ( https://en.wikipedia.org/wiki/Sierra_Entertainment ) - game company famous for King's Quest, Space Quest, and Leisure Suit Larry. * Hackers ( https://www.imdb.com/title/tt0113243/ ) - one of the best movies in the computer / hacker genre - Hack the planet! * X-Files ( https://www.imdb.com/title/tt0106179/ ) - 1990s tv drama about the FBI's paranormal phenomena research - the truth is out there ! * QBasic ( https://en.wikipedia.org/wiki/QBasic ) - an early programming language and interpreter. * TI-82 ( https://en.wikipedia.org/wiki/TI-82 ) - a programmable calculator. Follow the show! Our website is workingcode.dev ( https://workingcode.dev/ ) and we're @WorkingCodePod on Twitter ( https://twitter.com/WorkingCodePod ) and Instagram ( https://www.instagram.com/workingcodepod/ ). New episodes weekly on Wednesday. And, if you're *feeling the love* , support us on Patreon ( https://www.patreon.com/workingcodepod ). Your heart matters.

An airhacks.fm conversation with Lukas Eder (@lukaseder) about: a Unisys 8086, don't break your dad's computer, playing with "format", starting with QBasic and 12 years, serial cable chat programs in QBasic, Turbo Pascal with 15, changing the font in the BIOS, starting CMS with PHP and MySQL, no transactions, no connection pools in PHP, the beginning with serverless and CGI, Java is not a website technology, Java static pages vs. PHP includes, enterprise PHP: Zend Framework, from PHP to Java, PHP 4 to PHP 5 migration and the assignment operator, enjoying Java 1.3, Ant vs. Maven 1, a reporting project for a telco company with Java and Hibernate, writing backends in SQL and frontends with XSLT, stateless, functional programming with XSQL and SQL, jooq manual was built with XSLT, apache Cocoon and XSLT, Servlets and Java Message System (JMS) with WebLogic, from Hibernate query builder to jooq in 2006, cascading interfaces which feel like SQL, everyone built a query builder, rewriting jooq - jooq2 in 2008, queryDSL - the abstraction across multiple query language, jooq only abstracts SQL, dynamic "where" clauses with criteria query, jooq stands for: j-object oriented query, jooq started with stored procedure support, SQLJ the preprocessor, PRO-C* -> the C preprocessor for Oracle to generate boring glue code, jooq 1 was a procedural query builder, jooq 2 DSL API looks like SQL and uses the query builder layer, the database first design, SQL is not composable, SQL: different syntax on different levels, 1000 lines of jooq code is not unusual, DSLContext - the starting point, commercial support for jooq is available, database migrations with jooq, opensource vs. commercial edition, dependency on products, saving costs with opensource, focus on Jakarta EE, Java EE, MicroProfile API vs. direct runtime dependencies, working with dynamic SQL and jooq, database vs. Java first Lukas Eder on twitter: @lukaseder

An airhacks.fm conversation with Ashish Chhabria (@ashishc1) about: Compaq Presario, Windows 95 Pentium 1 with MMX, 2 GB harddrive and 16 MB RAM, QBasic and GW-Basic, playing virtual cricket, creating calculator from scratch, fascianation with math, learning C and C++, algorithms as hobby, rewriting SMTP server in C and berkeley sockets, starting with Java 1.6, starting at Morgan Stanley in New York, starting at Microsoft in Seattle, product manager on azure messaging team, Microsoft Azure Service Bus, Microsoft Azure Event Hubs, Microsoft Azure Event Grid, Microsoft Azure Relay, Azure Service Bus supports Java Message Service (JMS), JMS 2.0 is just a set of interfaces, Project Darkstar and JMS debate, AMQP with JMS 2.0, JMS is not a protocol, AMQP is the protocol, Active MQ uses AMQP, Azure Service Bus Java SDK comes as a Maven dependency, Microsoft Azure Logic Apps listens to Azure Service Bus, Microsoft Azure Functions as an integration system, Azure Service Bus passes over 90% JMS 2.0 TCKs (Test Compatibility Kit), QueueBrowsers and Message Selectors are supported by Azure Service Bus, 1k topics and queues combined, 2k subscriptions, 5k concurrent AMQP connections per namespace / instance, a namespace comes with 2,4 or 8 a messaging units, Azure Service Bus SDK comes with built-in retry mechanism, idempotent messages are supported, Azure Service Bus uses Azure Storage for replication, Azure Service Bus vs. Apache Kafka, events vs. messages, kafka is not a queue, Ashish Chhabria on twitter: @ashishc1, and github.com/axisc

An airhacks.fm conversation with Vlad Mihalcea (@vlad_mihalcea) about: the romanian HC computer, running QBasic on HC, GOTO 30 and typing programs from a book, designing 8 by 8 images, building the first video game with 11-12 years, the spider is walking, learning turbo pascal at high school, mathematics and physics at high school, studying telecommunications in bucharest and Cluj, Technical University of Cluj-Napoca, the beautiful city of Brasov Palm Pilot, the unstructured Java programming classes, the object oriented programming excitement, "Thinking in Java" book by Bruce Eckel, Chomsky Hierarchy, Information Theory by Shannon, starting with Java 1.3 / 1.4, starting at www.artsoft-consult.ro, full stack Java developer in 2005, developing fourier tranformation in JavaScript, fft.js, participating in math olympics, Sun Certified Java Programmer, starting a blog and becoming freelancer in 2013, the "High-Performance Java Persistence", working as developer advocate for RedHat with focus on Hibernate, using NHIbernate in diploma, JDBC, JPA and jooq, High-Performance SQL, the Hypersistence Optimizer, Hibernate Types, airhacks.tv and the JDBC pool question, flexy pool, the proper size of connection pool is hard to estimate, moving away from consulting - or trading time for money, Vlad Mihalcea on twitter: @vlad_mihalcea

An airhacks.fm conversation with Alexey Golub (@Tyrrrz) about: playing doom on the 200 mHz Pentium 2 PC, watching the "Social Network" movie with 16 years, learning with 10 years QBasic, Pascal and Delphi at school, starting with C# and the free Visual Studio Express, starting to learn C# with Jetbrains Rider and .net core, .net core is the lightweight, cross platform alternative, .net core replaced .net, rebranding .net core back to .net in 2020, Java from Oracle vs. openJDK, commercially supported openJDK, programming a chat bot in C# and MS Access, .net core ships with Entity Framework core, MS SQL server runs on Linux, NHibernate and Dapper ORM, java.net was before dot.net, starting with .net dot.net, using Visual Studio Code for C# development, Resharper is an extension to Visual Studio, Rider is going to replace Visual Studio with Resharper, building applications as freelancer for social networks, building an enterprise-oriented monzo, learning Java after C#, strange C# coding and naming conventions, react over angular, .net vs. Java popularity, .net is getting more popularity, ASP.net core is one of the most popular frameworks, ASP.net is a consolidated project, razor comes with a templating engine, blazor is based on WebAssembly, the 80 percent coverage rule, pointless unit tests for accessors, enums and constructors, high coupling with JAX-RS tests, test pyramid is problematic for the majority of backend projects, free code coverage for unit tests, integration- and system- tests ship ofter without code coverage, mutation testing and pitest, mutation testing uncovers pointless asserts, definition of unit testing, integration testing, system testing, test coverage with sonar, the most useful tests are blackbox tests, identifying forgotten code with test coverage, codecov.io visualizes code coverage results, coverlet is a library - a "private" .net library, jacoco agent in Java, writing stress tests for robustness, identifying memory leaks with stress tests, "Unit Testing is Overrated" article, Alexey Golub's website: https://tyrrrz.me, Alexey on twitter: @Tyrrrz

In today’s episode, we chat about system architecture, Ruby, Elixir, and everything in between with Greg Mefford, the senior back-end engineer for the Bleacher Report. We open the conversation by asking Greg about his start in coding, leading to a story about how Greg was that bored kid pressuring a math teacher to teach him QBasic. He shares how he fell in love with Ruby before discovering Elixir and Nerves. Having faced some challenges when learning Nerves, Greg talks about how he began documenting his pain points and writing documents to help onboard newcomers. We discuss Greg’s work with Nerves, his project aspirations, and his recommended resources for anyone looking to get into Nerves or Elixir. After providing his hot take on the latest Code BEAM V conference, we ask Greg what system architecture means to him. From there we get super meta about the meaning of architecture and what it means to translate design into practice. We touch on the struggle of understanding domain-driven design and Greg’s approach to pre-code planning before delving into how the Bleacher Report is set up. As Greg goes into details, you’ll hear why their servers now run on Elixir and not Ruby. Near the end of the episode, we talk about Poncho versus Umbrella apps, and Greg shares his passion for multi-user dungeons (MUDs). Tune in to learn more about Greg and his role in the Elixir and Nerves landscape. Key Points From This Episode: Greg’s start in coding and his transition from electronics design into IT. Why Greg loves Ruby and how he discovered the magic of Elixir. Greg’s contribution to the Elixir and Nerves community by helping onboard newcomers. What Greg’s job as a senior engineer for Bleacher Report looks like. Greg recommends resources for beginners getting into Nerves and Elixir. Creating a kid’s game using Nerves and Greg’s Blinkchain library. Greg’s take on the Code BEAM V conference and hating on the Whova app. What architecture means to Greg. This one gets deep. How translating designs into software has changed over the years. Why Greg struggles with the idea of domain-driven design. The state of Extreme Programming practices and how they synergize together. How Greg views pre-code planning; something that’s become his specialty within his latest job. The many elements that contribute to how the Bleacher Report’s IT is set up. Ruby servers versus Elixir servers and why the Bleacher Report uses Elixir. Why the Poncho system was designed to fix Nerves issues not covered by Umbrella apps. Greg’s history creating multi-user dungeons (MUDs) and playing DragonRealm. Links Mentioned in Today’s Episode: Greg Mefford LinkedIn — https://www.linkedin.com/in/ferggo/ SmartLogic — https://smartlogic.io/ SmartLogic Jobs — https://apply.workable.com/smartlogic/ ElixirConf — https://elixirconf.com/2020 Blinkchain GitHub — https://github.com/GregMefford/blinkchain Justin Schneck GitHub — https://github.com/mobileoverlord Le Tote — https://www.letote.com/ James Smith — https://twitter.com/st23am Garth Hitchens, ElixirCof 2015 — https://www.youtube.com/watch?v=kpzQrFC55q4 Nerves Project — https://www.nerves-project.org/documentation Bleacher Report — https://bleacherreport.com/ Programming Elixir — https://www.amazon.com/Programming-Elixir-1-6-Functional-Concurrent/dp/1680502999 Elixir in Action — https://www.amazon.com/Elixir-Action-Sa%C5%A1a-Juri-cacute/dp/1617295027 Chris Keathley — https://codesync.global/speaker/chris-keathley/ Code BEAM V Conference — https://codesync.global/conferences/code-beam-sto/ Whova App — https://whova.com/ Amos King — https://twitter.com/adkron?lang=en Christopher Keele — https://github.com/christhekeele Steve Bussey Episode — https://smartlogic.io/podcast/elixir-wizards/s4e3-bussey/ Mark Windholtz — https://github.com/mwindholtz Extreme Programming — http://www.extremeprogramming.org/ Adopting Elixir: From Concept to Production — https://www.amazon.com/Adopting-Elixir-Production-Ben-Marx/dp/1680502522 Live Elixir Wizards - Betweenisode — https://www.youtube.com/watch?v=kEwxhGYEGts Twirp GitHub — https://github.com/twitchtv/twirp Frank Hunleth — https://github.com/fhunleth Elixir Supervisor Behavior — https://hexdocs.pm/elixir/Supervisor.html Elixir Poncho Projects — https://embedded-elixir.com/post/2017-05-19-poncho-projects/ Titans of Text — https://www.titansoftext.com/ Miriani — https://www.toastsoft.net/ DragonRealms — https://www.play.net/dr/ Justus Eapen Twitter — https://twitter.com/justuseapen Eric Oestrich — https://twitter.com/EricOestrich Special Guest: Greg Mefford.

From a modempunk adventure running from an AI written in QBasic, to Daniel Radcliffe as a wizard assassin, by way of an engineer who knows parkour and must stop a speeding mag-lev monorail - this week's episode of Bit Storm will take you places!

How can we re-imagine the role of programming and computer science in our school curricula? How can we equip Indian students with the skills and the knowledge necessary to thrive in the 21st century? Ramya Bhaskar and Sridhar Pabbisetty talk to Ganesh Chakravarthi and Pavan Srinath about reimagining school education for Industry 4.0 on Episode 58 of the Thale-Harate Kannada Podcast.Ramya Bhaskar is founder of Givemefive.in, an AI and Programming learning platform for young minds of India. Givemefive's mission is to skill current generation of young students with skills required for Industry 4.0 era. She also worked as Product Manager at Byju’s and played an instrumental role in releasing “Byju’s The Learning App”.Sridhar Pabbisetty is a public policy and urban governance specialist, and runs the Centre for Inclusive Governance. He has previously been in leadership roles of the Namma Bengaluru Foundation & IIM Bangalore's Centre for Public Policy, and has been a part of numerous government committees on Bengaluru's lakes, the state's Sakaala mission, a state tourism vision group and more.ಫಾಲೋ ಮಾಡಿ. Follow the Thalé-Haraté Kannada Podcast @haratepod.Facebook: https://facebook.com/HaratePod/Twitter: https://twitter.com/HaratePod/Instagram: https://instagram.com/haratepod/ಈಮೇಲ್ ಕಳಿಸಿ, send us an email at haratepod@gmail.com and tell us what you think of the show.Subscribe & listen to the podcast on iTune, Google Podcasts, Castbox, AudioBoom, YouTube, Soundcloud, Saavn or any other podcast app. We are there everywhere. ಬನ್ನಿ ಕೇಳಿ!You can listen to this show and other awesome shows on the IVM Podcasts app on Android: https://ivm.today/android or iOS: https://ivm.today/ios, or any other podcast app.You can check out our website at http://www.ivmpodcasts.com/

I would say go for it. ... Learning any of anything is gonna help you more than wondering what to learn or trying to pick the perfect thing. Spoiler alert: there is no perfect thing. Everything has huge problems with it that are gonna cause you a lot of frustration. But if you just have perspective, well, you're able to do some really amazing things that you couldn't without it. Hosts Karin Thorne and Kelly Corey chat with Gus Cost, programmer at Density and Careers in Code instructor, about using hardware to win a hackathon, lessons learned from teaching at a tech bootcamp for the first time, and his surprising recommendation on where to start your own programming journey. This is our most technical episode so far and features mentions of QBasic, Logo, Lisp, and PyTorch. This episode is part II of our new series: Catching Up with Careers in Code! We chat with founders, instructors/TAs, and students of the first CiC cohort about their experience and where they'd like to see the program go in the future. Connect with Gus GusCost.com (https://guscost.com/) | Density (https://www.density.io/) | Hack Upstate VIII Grand Prize: Red Light Bell (https://medium.com/@hackupstate/hack-upstate-viii-the-results-are-in-4c4f4fb1abf#.sr32x4f28) Episode References Learn C the Hard Way by Zed Shaw (https://www.amazon.com/Learn-Hard-Way-Practical-Computational/dp/0321884922/ref=sr_1_1?keywords=learn+c+the+hard+way&qid=1582060151&sr=8-1) Code: The Hidden Language of Computer Hardware and Software by Charles Petzold (https://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319/ref=sr_1_1?crid=1KTB0CI77BY4&keywords=code+by+charles+petzold&qid=1582060166&sprefix=code+by%2Caps%2C175&sr=8-1) Spongebob Meme (https://img.devrant.com/devrant/rant/r_1464512_LrfhG.jpg) Music This episode features "Brain Power" by Mela (https://freemusicarchive.org/music/Mela/Mela_two) from the album Mela two. Follow Karin kethorne.com (http://www.kethorne.com/) | Twitter (https://twitter.com/kaythorne) | Instagram (https://www.instagram.com/karin_thorne/) | E-mail (mailto:contact@kethorne.com) JSWebb Development, LLC jswebbdevelopment.com (https://jswebbdevelopment.com/) | Twitter (https://twitter.com/JSWebb_Dev) | Instagram (https://www.instagram.com/jswebbdev/) | E-mail (mailto:jswebbdevelopment@gmail.com) Follow Kelly kell.dev (https://kell.dev/) | Twitter (https://twitter.com/kellytoearth) | Instagram (https://www.instagram.com/kellytoearth/) | E-mail (mailto:hello@kell.dev) Follow Salt City Code Twitter (https://twitter.com/saltcitycode) | Instagram (https://www.instagram.com/saltcitycode/) | E-mail (mailto:saltcitycode@gmail.com) --- Special Guest: Augustine (Gus) Cost.

An airhacks.fm conversation with Matthias Reining (@MatthiasReining) about: Power Basic is not QBasic and was comparable with Turbo Pascal, game high score manipulation as programming motivation, C 64 was the first computer encounter, writing a "Jump and Run" game in Power Basic, Power Basic IDE as Christmas present, the menu bar fascination, using GW-Basic at high school, call by value vs. call by reference in Power Basic and Turbo Pascal, the Comal programming language, learning C, the University of Wuerzburg, learning Visual C++ and object oriented programming at university, C over C++, learning Java during internship at Nobiscum, writing a Java frontend with AWT for CVS as proof of concept, renaming com.sun.swing to javax.swing, switching to Lotus Notes as consultant, improving Lotus Notes user interface with Java, accessing Lotus Notes with JDBC, CouchDB the Lotus Notes "successor" created by Damien Katz - a former Lotus Notes developer, Lotus Notes the NoSQL database before the popularity of NoSQL, Transact-SQL, PL/SQL and back to Java, JSPs, Servlets, Tomcat and Apache Struts, from Java back to Pearl, the strategy of spending as much time as possible in a single project, writing fronted code with "this and that" or ES 5-the ancient JavaScript, the Java EE 5 fascination, xdoclet code generation for early EJB versions was slow, annotation-based programming with Java EE 5 improved the productivity, building a freelancer portal with Java EE 5 as proof of concept, a Java EE workshop in 2011, learning politics in Java insurance projects with "C-structs" as design pattern, enjoying PowerPoint time, founding a startup with Java EE 8 / Jakarta EE 8 and MicroProfile as technology choice, WildFly and Keycloak are the perfect technologies for a startup, focus on the business and not the technology, considering OpenLiberty and Quarkus as migration target caused by slow support of MicroProfile APIs by WildFly, saving memory with Quarkus, making WARs thinner by moving to MicroProfile JWT from proprietary Keycloak libraries, building the heart of an insurance company - an insurance platform, cloud-ready and private clouds are a common deployment model, migration from COBOL systems to tech11 insurance platform, team of 8 people is incredibly productive, it is hard to find good developers in Germany, hiring pragmatic developers from Afrika with the "ThinWAR" mindset, the "airhacks stack", polyglot programming is chaos, using Java EE 8 as the baseline, all other dependencies require permission, an average tech11 ThinWAR is a few hundreds kB, code snippets from 2005 gave Java EE a bad name, implement whatever you can today and care about potential problems tomorrow, the time to first commit has to be as low as possible, projects and products require different approaches, the "getting things done" developer, long-term maintenance is key to product success, every company has the right technology at certain time, Java EE is not the only "right" technology, projects are also barely dependent on Java EE, tech11 does not sell technology, tech11 sells solutions, using plain WebStandards with WebComponents, ES 6 in the frontend, Custom Elements looks like ReactJS, lit-html is one of the few dependencies in frontend, tech11 started with hyperHTML, then migrated to lit-html, open-wc comes with lots of examples with LitElement what is not necessary, using Parcel for packaging without any transpiling, rollup.js is great for packaging, Jenkins transpiles for older browsers, on developer machines not even npm is necessary, airhacks.io workshop about WebComponents: webcomponents.training, tech11 uses a BPM engine to manage processes, tarifs claims, policies are the names of microservices (ThinWARs), the episode #36 with Markus Kett mentions the JCon keynote, Matthias Reining on twitter: @MatthiasReiningand his startup: https://tech11.com

My guest today is Rami Ismail, a Dutch/Egyptian video game developer, creator of presskit() and one half of one of the most prolific and successful independent video game studios of the past few years, Vlambeer. We talk about his very early fascination with how games worked and pulling apart code in QBasic, why the Polystation was a blessing in disguise, questionable tactics in Starsiege: Tribes, why he enjoys giving talks so much, the runway train that is Vlambeer and the mystery of it's logo, "I do what I do for many reasons, and those reasons are life and influence and impact and death and responsibility and legacy and also videogames." PATREON! - patreon.com/checkpoints iTunes HERE - SUBSCRIBE / RATE / REVIEW Games discussed: Gorillas.bas, Destiny, Nuclear Throne, Starsiege: Tribes, Transport Tycoon, Uncharted 4, Golden Sun, Tiltbrush, Job Simulator, Split/second, Blue Dragon, Metal Gear Solid, Deus Ex, Killer Loop, Contra, Doom, Starcraft. RSS HERE Twitter - twitter.com/CheckpointsShow Cover design: Craig Stevenson - http://onedinosaurandhisballoon.blogspot.co.uk Music: Samuel Baker - http://soundcloud.com/furoshiki

Podcast Sem Freio, de Dimitri Kozma. Conteúdo deste episódio: - Convidado: Roberto Caldeira - Programa especial nostálgico com as recordações da adolescência no Colégio - Historias dos tempos de colegio - Fenasoft - jogos piratas - Qbasic - jogos antigos vs novos - História do carro Verona batido - Fita isolante no farol - Jogos piratas do "Felipão" - Os professores do colégio - Professor fumando na classe - Professor de inglês q nao dava aula - Amigos do colégio - Programacao em Cobol, Clipper, Visual Basic - Fomos professores na SOS Computadores - Jogos do Dimitri - Parece q foi ontem. Tudo passa muito rapido. - e muito mais! PODCAST SEM FREIO #10 - NOSTALGIA: HISTÓRIAS DA ADOLESCÊNCIA NO COLÉGIO O Podcast Sem Freio fala sobre qualquer assunto, incluindo cinema, séries, música, histórias bizarras, ciência, quadrinhos, literatura, tecnologia, games, filosofia, artes, curiosidades, crítica de filmes, cultura pop, coisas nerd, polêmica e muito mais! São conversas informais e divertidas. Junte-se a Dimitri Kozma e eventuais convidados, fazendo parte de nossa roda de discussões. E-MAIL DE CONTATO ► semfreiopodcast@gmail.com ---------------------------------------------------------------------------- ACOMPANHE O ESTRANHO MUNDO DE DIMITRI KOZMA: YOUTUBE ► http://goo.gl/BZ9mA9 INSTAGRAM ► https://www.instagram.com/dimitrikozmaart SPOTIFY ► https://spoti.fi/2UYEhcj APPLE PODCASTS ► https://apple.co/2Va7f95 ANCHOR ► http://bit.ly/2VGABAd FACEBOOK ► https://www.facebook.com/dimitrikozmaart TWITTER ► https://twitter.com/dimitrikozma CANAL É A VIDA, MEUS QUERIDOS ► https://goo.gl/kjxmcG CANAL KOZMA GAMES ► http://goo.gl/K5Ibrb CANADÁ DIÁRIO: YOUTUBE ► https://youtube.com/canadadiario SITE ► http://www.canadadiario.com.br FACEBOOK ► https://www.facebook.com/canadadiario INSTAGRAM ► https://instagram.com/canadadiario TWITTER ► https://twitter.com/CanadaDiario ---------------------------------------------------------------------------- CAMISETAS DO DIMITRI ► http://bit.ly/2XS3eeQ APOIE O CANAL pelo PAYPAL com qualquer quantia e contribua para criação de novos vídeos ► http://goo.gl/f4XRLS ---------------------------------------------------------------------------- Se você gostou desse vídeo e de nosso canal, pode nos ajudar de várias maneiras! Sua participação é muito importante para fazer o canal crescer e melhorar a cada dia mais! ► INSCREVA-SE NO CANAL PARA RECEBER AS NOVIDADES - http://goo.gl/BZ9mA9 ► CLIQUE EM CURTIR - Dê seu "LIKE" sempre ► COMENTE - Lemos todos os comentários e tentamos responder sempre que possível. ► ADICIONE O VÍDEO AOS SEUS FAVORITOS - Isso ajuda muito ao canal e você sempre vai encontrá-lo para assistir novamente depois ► ATIVE A NOTIFICAÇÃO - Clique no sininho ao lado do botão "Inscrever-se" e marque "Enviar para mim todas as notificações deste canal" para receber o aviso de vídeo novo. ► COMPARTILHE O VÍDEO - Conhece alguém que possa gostar deste vídeo? Conhece alguém que possa gostar do canal? Mostre para os amigos. Compartilhe também nas mídias sociais, como Facebook, Twitter, etc #Podcast

Chris and Serge take a walk down memory lane of old computers, programming environments and the command line. During this trip, they deconstruct the appeal of the command line, unix culture and ways that the aesthetics of the terminal have held us back.Links:Commodore VIC-20 (wikipedia)Commodore 64 (wikipedia)MS DOS (wikipedia)Freedos (a Free Software DOS replacement)QBasic (wikipedia)FreeBASIC (a Free Software BASIC)GEOS (wikipedia)Unix Philosophy (wikipedia)REPL (wikipedia)In the Beginning... Was the Command Line (wikipedia)8-Bit Guy's Dream Computer (the8bitguy.com)Adafruit Circuit Playground Express (learn.adafruit.com)Microsoft MakeCode (github.com)ScratchThe UNIX-HATERS HandbookThe Mycroft Personal Voice AssistantThe Blender Project

Chris and Serge take a walk down memory lane of old computers, programming environments and the command line. During this trip, they deconstruct the appeal of the command line, unix culture and ways that the aesthetics of the terminal have held us back.Links:Commodore VIC-20 (wikipedia)Commodore 64 (wikipedia)MS DOS (wikipedia)Freedos (a Free Software DOS replacement)QBasic (wikipedia)FreeBASIC (a Free Software BASIC)GEOS (wikipedia)Unix Philosophy (wikipedia)REPL (wikipedia)In the Beginning... Was the Command Line (wikipedia)8-Bit Guy's Dream Computer (the8bitguy.com)Adafruit Circuit Playground Express (learn.adafruit.com)Microsoft MakeCode (github.com)ScratchThe UNIX-HATERS HandbookThe Mycroft Personal Voice AssistantThe Blender Project

Chris and Serge take a walk down memory lane of old computers, programming environments and the command line. During this trip, they deconstruct the appeal of the command line, unix culture and ways that the aesthetics of the terminal have held us back.Links:Commodore VIC-20 (wikipedia)Commodore 64 (wikipedia)MS DOS (wikipedia)Freedos (a Free Software DOS replacement)QBasic (wikipedia)FreeBASIC (a Free Software BASIC)GEOS (wikipedia)Unix Philosophy (wikipedia)REPL (wikipedia)In the Beginning... Was the Command Line (wikipedia)8-Bit Guy's Dream Computer (the8bitguy.com)Adafruit Circuit Playground Express (learn.adafruit.com)Microsoft MakeCode (github.com)ScratchThe UNIX-HATERS HandbookThe Mycroft Personal Voice AssistantThe Blender Project

Follow us on Social Media! | LinkedIn | Facebook | Twitter | Instagram |

I veckans avsnitt pratar Pelle och Bartek också om de problem som kan uppstå med gatekeepers inom sociala nätverk. Stora företag har mycket makt och möjligheter att kunna göra saker som att kunna filtrera och blockera våra inlägg och profiler om vi har ett suspekt beteende eller om de anser att vi uttrycker oss fel. Detta är mycket bra i många lägen, för att bland annat förhindra hackers och rasistiska åsikter och liknande. Men det kan också vara dåligt eftersom man i själva verket inte har lika stor yttrandefrihet längre. Var går de moraliska gränserna för hur mycket de stora företaget får eller bör filtrera? En mycket intressant diskussion om den makt som de stora företagen inom sociala medier har och vilka moraliska förpliktelser det egentligen innebär. Häng med och lyssna! Veckans gäst Pelle har kodat ända sedan lågstadiet – resan började med QBasic i DOS, men sedan länge är det såklart webben som gäller. Nyfiken som han är har han testat på mycket – frilansande, byrå, konsult, startup, storföretag – men genom allt har en röd tråd ändå funnits: Fascinationen över webbens demokratiserande effekt och en vilja att bidra till att pusha den längre för att möjliggöra mer och större kreativitet. Talking points: Distribuerade sociala nätverk Från bloggar till mikrobloggar Hur bygger man webbsidor från grunden Problem med gatekeepers inom sociala nätverk Länkar IndieWeb Citerbara citat “Idag kan dom som vill börja med webbutveckling och börja vara en som bygger webben inte riktigt göra det, för de måste i så fall först skaffa sig en anställning på Twitter, Facebook eller något för att överhuvudtaget kunna bidra till att de sociala medierna utvecklas.” “Om du centraliserar allting till ett ställe, då får det centrala stället möjligheter att göra saker och ting, som att till exempel blocka dig för att du har ett suspekt beteende. Och man får möjligheter att göra saker och ting, som att filtrera och blockera, då får du också en moraliskt förpliktelse att göra det.” “Sen är frågan ur det lite större perspektivet om det är rimligt att en person eller företag som innehar makten, att så hårt kunna styra hur folk uttrycker sig och om vad som är rätt och vad som är fel.”

I veckans avsnitt pratar Pelle och Bartek också om de problem som kan uppstå med gatekeepers inom sociala nätverk. Stora företag har mycket makt och möjligheter att kunna göra saker som att kunna filtrera och blockera våra inlägg och profiler om vi har ett suspekt beteende eller om de anser att vi uttrycker oss fel. Detta är mycket bra i många lägen, för att bland annat förhindra hackers och rasistiska åsikter och liknande. Men det kan också vara dåligt eftersom man i själva verket inte har lika stor yttrandefrihet längre. Var går de moraliska gränserna för hur mycket de stora företaget får eller bör filtrera? En mycket intressant diskussion om den makt som de stora företagen inom sociala medier har och vilka moraliska förpliktelser det egentligen innebär. Häng med och lyssna! Veckans gäst Pelle har kodat ända sedan lågstadiet – resan började med QBasic i DOS, men sedan länge är det såklart webben som gäller. Nyfiken som han är har han testat på mycket – frilansande, byrå, konsult, startup, storföretag – men genom allt har en röd tråd ändå funnits: Fascinationen över webbens demokratiserande effekt och en vilja att bidra till att pusha den längre för att möjliggöra mer och större kreativitet. Talking points: Distribuerade sociala nätverk Från bloggar till mikrobloggar Hur bygger man webbsidor från grunden Problem med gatekeepers inom sociala nätverk Länkar IndieWeb Citerbara citat “Idag kan dom som vill börja med webbutveckling och börja vara en som bygger webben inte riktigt göra det, för de måste i så fall först skaffa sig en anställning på Twitter, Facebook eller något för att överhuvudtaget kunna bidra till att de sociala medierna utvecklas.” “Om du centraliserar allting till ett ställe, då får det centrala stället möjligheter att göra saker och ting, som att till exempel blocka dig för att du har ett suspekt beteende. Och man får möjligheter att göra saker och ting, som att filtrera och blockera, då får du också en moraliskt förpliktelse att göra det.” “Sen är frågan ur det lite större perspektivet om det är rimligt att en person eller företag som innehar makten, att så hårt kunna styra hur folk uttrycker sig och om vad som är rätt och vad som är fel.”

This month’s topic is game development history featuring QBasic.  We discuss how we got started with game development and the first tools and languages that we used.  Levi D. Smith shows how to setup QBasic using DOSBox and a brief overview of the language.  We also show the Knoxville GameMaker games created for GM48 last … Continue reading QBasic and GM48 Entries – Knoxville Game Design, February 2019 →

Prolific composer 2Mello (Regular Human Basketball, Read Only Memories, Waypoint) joins us to talk about his early experiences with QBasic and NES, and his journey into becoming a full time musician and his unlikely route into composing game soundtracks. We talk about his releases Return of the Soul and Memories of Tokyo-To, and he shares exclusive details on his upcoming Silent Hill-inspired concept album.Also, we talk faking piety to play Super Metroid, what sets Hollow Knight apart from its peers, the tenets of good horror, and the joy of Hideki Naganuma and Shibuya-kei.Follow Matthew on Twitter @MelloMakes, check out his own Podcast The Sample Study, and please consider backing his Patreon.Note: Since the recording of this podcast, Mello released D&B album Trunk Fiction, which you should definitely hear.Intro Music "Summer Vacation in Scanline" by NurvussOutro Music "トワイライトでHEART-BEAT" by パフェ♥カフェｐａｒｆａｉｔ♥ｃａｆｅ

In this weeks episode we are lucky to be joined by Neal Brooks, a fellow developer of Edd’s at MyBuilder. We start off by discussing how he got into programming, QBasic and video driver shenanigans. From here, we move on to introduce his SymfonyLive London talk ‘Running Symfony on AWS Lambda’. We highlight what drew him to Lambda, and the new tooling that is making it easier to run PHP and frameworks (such as Symfony) on it. This leads us to cover his demo application, and explore handling assets using S3, database migrations and AWS resources using CloudFormation. Finally, we debate using catch-all gateway endpoints vs. dedicated gateway endpoints and Lambda performance.

An interview with Adam Wathan, co-creator of the Tailwind CSS library and author and video producer. Adamwathan.me Test-Driven Laravel Refactoring to Collections Advanced Vue Component Design Tailwind CSS Alberta Oil Sands Reaper Conestoga College Vehikl Desire2Learn Tighten Nitpick CI Adam Wathan's $100k product launch Full-Stack Radio Mark Rippetoe - Starting Strength 5/3/1 Video of Adam lifting tons of weight 5/3/1 calculator Matt's WeightXReps Training Journal Agile Principles, Patterns, and Practices in C# Adam on Twitter Refactoring UI Editing sponsored by Larajobs Transcription sponsored by Tighten Matt Stauffer: Welcome back to the Laravel podcast, season three. Today we're talking to Adam Wathan; author, video maker, teacher of the things, power lifter. Stay tuned. Matt Stauffer: All right, welcome back to the Laravel podcast, season three. This is the version of the Laravel podcast where we get to know less about tech and more about the people behind the tech, and today my guest is none other than Adam Wathan who has taught us all about testing, collections, view, components and many other things. One of things I love about Adam is that he's never satisfied with what's happening around him and he's always taking in stuff from other places, and we'll talk about this more probably later in the podcast, but when I describe Adam to other people, I say he's the guy who basically finds what's good everywhere else and brings it to us in the Laravel world. So if you haven't heard of Adam, my mind is blown. You should go consume everything he's ever made; it's all gold. I will say to some of y'all that his name is pronounced Wa-than, right? That's right? Adam Wathan: Yeah, you got it. Matt Stauffer: Wa-than. Not Way-thin, not Way-than. I'm trying to think about other things I've heard, but Adam Wathan. So Adam, say hi to the people, and the first question I always ask everybody is when you meet somebody in the grocery store how do you introduce yourself? How do you tell them what you do? Adam Wathan: Cool. Yeah, so thanks for having me on. I'm Adam. I usually explain ... It depends on what people ask, because some people ask like what do you do? I say I'm a software developer, although I don't actually get paid to write code, I get paid to teach people about code. So I either describe myself as a software developer who creates courses and e-books and training products for other software developers who are looking to kind of level up. So that's kind of the shortest version that I try and give to people that usually is enough that they kind of either are interested in it and ask me more questions or aren't interested and don't want to hear anymore. Matt Stauffer: Yeah, so I'm already going to cheat a little because I want to ask one little thing about your motivation that I've been curious about for a while and hopefully they'll still come out when we talk about your background but, you know, you're really smart guy, you learn a lot of stuff, but you're also a teacher and you also have like marketing kind of like sensibility, and you just gave an elevator pitch that would make someone who doesn't even understand programming want to go sign up for your product and I don't think that that's really common for a lot of us to know how to talk about it that well, so ... And if this is going to come out later that's cool, but do you have a sense for where your ability to kind of understand how to market something and how to ... And you talk a lot about how to do it in a non-skeezy way, but where did that come from? Is that something you had to work on, or do you feel like you've got some experience that's kind of taught you that? Adam Wathan: That's a good question and I don't think I have a great answer for it. I think I've always just really liked creating things that I was proud of and putting them out into the world with enthusiasm and I think that's been kind of like the simplest version of how I have always tried to share what I've been working on and then I think with the marketing stuff too, I guess I just care just as much about the quality of that as I do about everything I do. I just really like to make everything I do as good as I possibly can and that comes down to even things like, you know, landing pages and how things look on stuff like that. To me, the marketing is a product too and I want it to be good and I want to be proud of it, so it's just something that I just put a lot of effort into I guess the same way I would with something else. Matt Stauffer: Yeah, I mean, I tell this story to people all the time, but when you first joined Tighten, one of the things we were talking about was working on some open source projects together, and we immediately found a conflict in our ways of working where I was like, so what I do with this thing Symposium is I figure out a feature and I spit out the feature as fast as possible and then I move on to the next feature, and you're like what I do is I try to figure out exactly the best way to do this feature and I ponder on it and I make plans and I make diagrams and I get it exactly right so people will really get their needs met and then and only then do I actually build out a feature. Matt Stauffer: And we kind of had this like little head butt moment, and I think that I've kind of ... I would say I've shifted to your way of thinking, but I've been influenced by it a lot. Do you have a sense for where your kind of desire for excellence ... I think you were just talking about like where that comes from, is that just a personality trait? Is that something from your family, and what's that ... Where does that come from? Adam Wathan: I think it's just a personality trait. I've been like that with basically everything that I've ever been interested in my entire life. Like I would sit and play guitar and play the exact same seven notes for four hours straight until I played them perfectly, you know what I mean? So I think I just get a little bit obsessive over the sorts of things that I get interested in. Matt Stauffer: Yeah, I just want to get really good at it. All right, well, I'm sure we'll dip into the stuff a little bit more, but I do want to make sure that I actually have the space for your back story. So the second question I always ask everybody is, where was it that you ... Or what was the context in which you first had interactions with a computer? How old were you and kind of what was your interaction like at that point? Adam Wathan: Yeah, so I have sort of conflicting memories for a lot of some of the stuff. Not necessarily conflicting, but sometimes I have a hard time figuring out like what the timeline was, but some of my earliest memories of working with computers, probably the earliest one that I can think of. is when I was in grade ... It must have been probably grade two, maybe grade three, but I had this librarian at my school who worked with like some of the gifted kids to do little projects and stuff and me and him were working on the super old Mac that we had at the ... It was new at the time I'm sure, right, but like my memory of it's like the old school Mac where everything's black and white and stuff like that. Using hypercard to make this little project we went around and it was actually pretty cool. Adam Wathan: We got to like drive around the neighborhood and I got to like ask questions like different business owners about things and we put together this like little presentation in hypercard, and that's probably like my earliest memory of working with a computer and we got a computer in my family when I was pretty young too, probably grade four or grade five. It was just like kind of your standard ... It was like an Acer or Compaq PC or something with four megs of RAM and, you know, I can't even think, a 500 megabyte hard drive, and we got- Matt Stauffer: Yeah, a 486 or something like that. Adam Wathan: Like our internet a couple years later. Yeah, it was a 486 and I used to dick around on that, you know, looking up game tutorials for my Sega Genesis at GameFacts.com and stuff like that and- Matt Stauffer: What's the best game on the Genesis? What's your favorite, do you remember? Adam Wathan: Favorite Genesis game. I used to play the hockey games a lot. That was probably what I got- Matt Stauffer: You're so Canadian. Adam Wathan: The most fun out of. The funny thing is like I'm not super into hockey, but those were just the most fun like multiplayer games that you could play. That and like Mortal Combat and Street Fighter. Matt Stauffer: Yeah, of course. Adam Wathan: And all the classics. I didn't do much of the single player stuff, just mostly hanging out with friends and playing. Matt Stauffer: No Sonic and Knuckles and things like that? Adam Wathan: I did play Sonic, but I wouldn't say like I have, you know, nostalgic memories about how much I loved that game or whatever. It was a fun game but, yeah. Matt Stauffer: Yeah, I feel like not a lot of people have the same level of memories of Sonic as they did at Mario. I just never quite connected in the same way. Adam Wathan: No, Mario definitely has a more special place in people's hearts, I think. Matt Stauffer: Yeah, you actually got into this a little bit, but my next question is going to be kind of what was your first exposure to the internet? So was that primarily it at least at the start? Adam Wathan: I'm not sure if it would have been at school or at home, but yeah, it would have been most of the time that I spent on the internet would have been at my home desktop computer on our 14.4 connections we used to use. Matt Stauffer: Yeah. So when you were in middle school and high school, what do you think you wanted to do with your life? Did you know? Adam Wathan: I had some conflicting thoughts, so at one point when I was a kid I wanted to be a cartoonist, that was my dream actually. Matt Stauffer: I had no idea. Adam Wathan: I used to draw all the time and I used to like ... You know how you'd have like the book fairs at school, I don't know if you had those in the States. Matt Stauffer: Yeah yeah, Scholastic. We had them here. Adam Wathan: The Scholastic Book Fairs. Matt Stauffer: Yeah. Adam Wathan: I'd always be ordering like the how to draw this or the how to draw that books and I never got really good at it, but it was fun and then eventually I got into like playing guitar and stuff like that and I wanted to be like an audio engineer, but I also wanted to be a programmer and I really liked my programming classes in high school, so I ended up going to university for computer science, but I also considered going to college for music industry arts, which is a program that actually Steve Schoger, who some people might know actually did go to at the college that I used to go to. Matt Stauffer: Oh, he did? Adam Wathan: But I decided against it because it just didn't seem like a profitable career path, so I eventually chose computer science. Matt Stauffer: So you had programming classes in high school. Was this Java or C++ or what kind of stuff were you guys doing there? Adam Wathan: Let me think. So I think we ... I don't think we had computer programming classes 'till like grade 10 and we did a lot of like Pascal and we did C, and we did Java and then we have a web one which was later, which was kind of weird because the Java stuff was ... Even the Java stuff isn't ... When I think back to the fact that we did Java in high school, I don't remember doing any of the stuff that I know about Java now. Like I didn't know what object oriented programming was when I came out of high school, even though Java is an object oriented language. We just would write procedural code in like our main- Matt Stauffer: Good job, yeah. Adam Wathan: Java file or whatever, right? Matt Stauffer: Yeah. Adam Wathan: And stuff like that, but yeah. Matt Stauffer: What made you choose those classes? Adam Wathan: I think I just thought it was really fun to be able to make the computer do stuff. Matt Stauffer: Yeah. Adam Wathan: So I remember like one of my earliest memories of programming actually is when I was a kid I was like super obsessed with pro wrestling, that was like my thing. And I used to download all these like wrestling simulators so you could like ... It's so funny because they weren't ... they're not like games, right? They're like you create characters, you choose their move sets, you give them the statistics and stuff and then you like run simulations and it would spit out like texts, like this guy punched this guy, then this guy powerbombs this guy- Matt Stauffer: Right, and you're not actually controlling what they did, right? Adam Wathan: No, no, no. It's just a computer simulation based on random events- Matt Stauffer: That's fascinating. Adam Wathan: As well as like, you know, the statistics and attributes of the different wrestlers. There's a couple different programs that you could use to do that and I was always looking for different ones to test them out, and then one day I stumbled upon a tutorial online that was like make your own wrestling simulator in QBasic. Matt Stauffer: Oh, nice. QBasic, yes. Adam Wathan: And I was like, okay. And that was my first exposure to QBasic. I followed the tutorial and got everything set up and I didn't know how to like do random stuff or anything like that, so I never got very far with it. It was all just very like ... It was not like conditional logic or anything, you would just do this, this, this. Matt Stauffer: It just takes input- Adam Wathan: I couldn't figure out how to make it do exactly what the other things are doing, but I could make the computer do stuff, and that kind of got me interested in the whole QBasic programming stuff and then I just started looking into more like QBasic tutorials and finding out stuff that you could do, and I remember getting really into ... I don't think I'll ever remember the actual name of it. I found a site that I think might have been it, which is Pete's QBasic tutorials, which I don't know if that was the site for sure, but some of the content looked really familiar, but it had lots of tutorials on like making like tile scrolling RPG engines in QBasic and stuff and- Matt Stauffer: What? Adam Wathan: Where you could create like little sprite characters and you'd make these like 20 pixel by 20 pixel squares and lay them all out and make it scroll as you use the keyboard and stuff like that. So one summer I had this dream of making an RPG, which of course never even remotely happened, but I had a lot of fun just hacking around on the computer getting it to render this stuff and do stuff like that. So I think that's where I really got excited about programming because I don't know if I have a specific passion for programming more than anything else, but it was just like a really perfect kind of platform for just doing creative things, you know what I mean, and making stuff. It's the most like powerful tool for just like making interesting things that I know of so far, right? Matt Stauffer: Yeah. Adam Wathan: So I think that's what kind of got me into that. So I did a bunch of QBasic stuff messing around with that and eventually I started making my own little websites on Geocities an Angelfire and stuff like that and yeah, I've kind of been doing that ever since, so. Matt Stauffer: Yeah, I was thinking about how creation was definitely a trend for you. I mean between music creation, you know, as a guitarist and music production, you know, and the art and everything like this is it's wanting to make things happen and figure out what the tools are, so it's interesting hearing you say, you know, it's the most powerful tool that you can use for that. Adam Wathan: Yeah. Matt Stauffer: Do you ever draw still? Adam Wathan: No, not at all. Matt Stauffer: Do you have any of your old drawings anywhere? Adam Wathan: I might. My parents just sold their house and gave me a big box of like crap lying around that was mine. Matt Stauffer: You got to find something, man. Adam Wathan: I think there's a couple sketchbooks in there so I should maybe- Matt Stauffer: That would be amazing. Adam Wathan: Dig through those. Matt Stauffer: Please. Okay, so you went off to school for computer science and did you have a sense ... Did you have any shifts during school with what kind of aspect of CS that you were interested in or if ... And yes or no, what did you think you were going to do afterwards? Adam Wathan: Yeah, so I actually only went to the university for a single semester, so I did the first semester a bunch of the classes I did find fun like the ones that were direct programming, so we had like a C class where we'd basically get these weekly kind of projects that we have to work on where just have to go through a bunch of problems to get the computer to do that stuff, and that was the stuff that I was really interested in and really excited about, but then we also had classes that weren't as interesting, like digital fundamentals and stuff related to more like computer engineering sides of stuff which is interesting, but it didn't get me excited and want to work on it. Adam Wathan: That stuff was like a chore, and at the time I was also playing in a band and we ... That was all I wanted to do. Like we were playing shows and recording demos and stuff like that, so the computer stuff was not really a big focus for me at the time and I was commuting to school which was about a 45 minute drive away and living at home, so I didn't really get like embedded into the sort of university community that was there. Adam Wathan: So I didn't really like make any friends or meet anyone, I was only there for classes and that was it. So it was really hard for me to sort of, you know, become a university student. That was like this thing on the side I felt like for rest of my life, where my friends were and my hobbies were and stuff like that, so I only stuck with that for a single semester and then dropped out to just basically work full time while I reconsidered what I wanted to do, because it just ... I just wasn't enjoying university and I don't think it was the programming that I wasn't enjoying, it was just the educational side of it and having to get pulled away from the things that I was actually excited about to work on that. So I don't remember what the original question was, but that's kind of that story. Matt Stauffer: Well, no, and that's actually perfect and before I move on from that, I want to ask one question which is, was the distinction between doing versus learning abstract theory, was it about how concrete something was that was the difference between what you did and didn't like, or did I kind of miss that a little bit? Adam Wathan: No, I think that's true. I think the other thing is there's just a lot of classes that you have to take in university that aren't as ... they're not all really like cohesive, you know what I mean? I don't know what the system is like in the U.S., but in Canada we have university and college, which I think is kind of like college and community college in the U.S. Matt Stauffer: I think so, yeah. Adam Wathan: But the way that you pick your classes and stuff a lot of it is you have to go into the school and you have to go and sign up for different classes and you have different requirements, and you have to get credits and different things, but a lot of it is kind of up to you and they don't really put together like a cohesive curriculum. So I had to have X Math credits, X Elective credits, so I took like this history of music class, which is the only class I've ever failed in school in my entire life. Matt Stauffer: Oh, my God. Adam Wathan: And you would think that I ... Just because it's so damn boring, right? Matt Stauffer: Yeah. Adam Wathan: And I just like couldn't get into it at all. But everything was just kind of disconnected. There was like some math over here, some physics over here, and because at the early stages of things it's kind of like when you're in like first year of high school or something, they're just trying to teach you all these fundamental concepts- Matt Stauffer: Basics, yeah. Adam Wathan: Without kind of tying them back to the goal they you're trying to get into and I ended up going back to college years later which we can talk about maybe a little bit later, where the curriculum was much more cohesive and everything is sort of designed to teach you to be a programmer, and I really liked that experience. So yeah, I think it is just the fact that there was only one class that I actually liked, which was the programming class and everything else just felt like high school all over again, you know. Matt Stauffer: Yeah, yeah. No, I totally hear that. I mean there's a lot of conversations happening these days and I'll wait to go into them until we talk more about your later school experience, but around trade school versus university, versus whatever else and what are the pros and cons of each and I think a lot of it ... You know, one of the things I've come down to recently is that I've always been a pro university person with lots of caveats, and one of them is just like the school you're at really makes a big difference, and the classes you take and the professors you have. You know, there's a lot of factors that can give you a very, very, very, varied experience, even in the same type of program in the same type of school. So where did you go from there? You said you kind of were reconsidering your working full time, you were recording with your band and were you doing any touring at that point, too? Adam Wathan: No, we never got successful enough to do anything interesting like that. I was local shows and stuff, but yeah, so I was just working like crappy factory jobs basically. I'm trying to think what was the first job that I got after I left university. I have to try and reconstruct a time line, but the one I remember most specifically was working for a company where I was basically just in a factory building really high-end like antique looking stoves. Adam Wathan: So I did that for like a year while I still played in bands and did stuff like that and then eventually a friend of mine was working up in the Alberta oil sands like way up north and I would have all these construction projects to extract all the oil out of the sand and sell it of all over the world, and his dad actually ran the site up there so he had a lot of pull and one day he just called me and he was like, "Hey, do you want a job up here?" And I was like, "Sure." He's like, "Someone's going to call you tomorrow and offer you a job." And I didn't know- Matt Stauffer: That's awesome. Adam Wathan: What it's going to be. Like I had never seen the job description or anything, but this is just this guy's kind of style and so ... Yeah, I ended up working up there for two years doing like basically data entry stuff for the materials team, so I worked in an office in the frigid cold in Fort McMurray where it's like minus 50 degrees Celsius in the winters. Matt Stauffer: Holy crap! Adam Wathan: Our offices are these little portable trailers on the construction site and I was just there basically in Excel reconciling like purchase orders and invoices and making sure that, you know, we received the materials that we had paid for and that all this ... Just a bunch of really kind of monotonous data entry stuff, but for being like a 20 year old kid it paid really well and I did that for like two years until kind of that whole industry and economy started to suffer a little bit more because gas prices and oil prices dropped and they did a bunch of big layoffs which was ... So I got laid off, which was like a blessing in disguise really because I know a lot of people that basically just stayed up there forever because you can never get paid the same thing to come home. And I would work up there for 14 days straight, 10 hours a day and then they would fly you back to where you lived for seven days off. So I was constantly flying back and forth. which just made it really hard to have like a normal life, right? Matt Stauffer: Yeah. Adam Wathan: So yeah, I got laid off from that, came home, decided I would use that chance to try and get into like the recording stuff, because I was getting into recording a lot when I was up there and doing it when I was coming home just as kind of a hobby, but I thought why don't I try and like find some bands and record and like mix EPs for them and stuff. So I did that for like a year, which is a dumb industry to get into because bands don't have money, especially local bands, so you can't make a lot of money doing that, but what I found is while I was doing that I was using this tool called Reaper, which I still use out of my podcast and stuff like that, and I found that there was a bunch of features that I wished it had that it didn't have, and it was created by the guy who created Winamp originally, and it's like a very hacker friendly tool, so it lets you like extend it with Python or C++ or Lua now as well, so you can write all these sorts of like plugins and extensions for it and the API that they give you to do that stuff is like very powerful, you can access basically everything in the tool and write your own menu options and dialog boxes and all sorts of features and stuff. Adam Wathan: So I started getting into like hacking around with that doing really simple things and then one of the guys in the IRC chat for the software, kind of like this elite group of people who are like hacking on stuff there. I made this thing using Python and he was like, "You should port this to C++ so we can include it in this big extension that they maintain." and I was like, "I'd love to do that, I just don't have any idea how." and he's like "Well, okay, I'll help you." So for the next little while he would kind of like ... He kind of put together like a playground in this extension source code for me to like write my features in and help me figure out how to get XCode compiling it and all this different stuff, and that's when I kind of really like reignited my excitement and passion for programming because I was just having so much fun adding features to this tool and making it easier for me to do my work to the point where I was having way more fun adding features to the tool than I was actually using the tool to record bands. Adam Wathan: And I didn't even get back into web development or anything at that point. I hadn't made a website since like high school. So that's when I decided you know what, I think I'm going to go back to college and do this programming thing again, but I decided to do college and study university specifically because I knew like what I didn't like about university and I wanted to do something that was a lot more practical and focused on making you into a programmer than it was, you know, educating you about computer science. Matt Stauffer: So I had been meaning to ask and that's helpful. Are you familiar with the concept of a trade school? Adam Wathan: Yeah, like where you would go to learn to become like an electrician or something like that? Matt Stauffer: Yeah, that's not the same thing, right? You're more talking about it's a school, but it's more like single focus sort of like our community colleges, but I was wondering whether colleges like a little bit different than communities or if it's just- Adam Wathan: Yeah, I'm not sure. So the college I went to is Conestoga College. I'm going to pull up the website now, but basically here college programs are usually two-year programs and you get a diploma, and university are four years and you get a degree, that's kind of the fundamental difference. So I'm going to try and pull up like the actual program that I did here so I can kind of talk a little bit about the actual curriculum because I think it's kind of interesting. Matt Stauffer: While you do that, this is definitely similar to community college. It literally even in the Google preview says your community ... Ontario Community College and this is definitely not trade school, definitely community college, if that makes sense. Adam Wathan: Yeah, so I did the software engineering program there, and not the computer programmer course, which I got kind of turned on to that by asking around to friends who had gone to the school to kind of figure out like, you know, what are you supposed to do, but if you look at the actual program courses here we can maybe like link to this and then show it to people that are interested, but like in the first year we had classes like software engineering fundamentals, operating system fundamentals, C, C++ programming, computer security, object oriented programming, some of this has changed, but then year two we did like web design and development, relational databases, Windows and mobile programming, microprocessors and embedded systems, software quality, so like in school we learned about automated testing, which is pretty cool. Matt Stauffer: Nice. Adam Wathan: You never learn that in university. Advanced computer security, mobile application and development. Yeah, so it was just like all programming. Every class was programming, but it was just focused around some different kind of element of it using different technologies and stuff like that. So the nice thing about that is that college is really close to my house and unlike university where the schedule it's like really weird, sometimes I'd go to a three-hour lecture and then have seven hours off then have to go back in the night for a one-hour class. Like this is structured so much similar to high school, you know what I mean? Adam Wathan: Like you'd get there in the morning, you'd leave in the afternoon, so you're there for a long period of time, you get to like meet people, you get put on projects with people, and I really got into what I was doing there in terms of like I made a lot of friends, you know, that kind of became like my focus which was I think what made me not stick it out in university. It was just like such a side project, whereas I was able to really sort of like embed myself into what we're doing in this program, so- Matt Stauffer: That's really interesting. Adam Wathan: Yeah, that went really for me. So I did that for two years. It's a three-year program, but the way they do it is kind of weird. They have like three years with co-op, I don't know if people use that term in the U.S. It's kind of an internship- Matt Stauffer: I don't think so. Adam Wathan: Like paid internship. Matt Stauffer: Oh, yeah. Adam Wathan: So if they do like two years of schooling and then for 18 months you go out into the workforce. There was like four work terms across those 18 months I think, something like that. And some people do them all the same company, some people do four different ones, some people split up however, but you get paid to do that, which is pretty cool like 18 bucks an hour or more depending on who the employer is, and then once you're done that kind of co-op internship stuff, you go back and do your third year of schooling and then you get your diploma and then you're done. Matt Stauffer: Oh, cool. Adam Wathan: So I just did the first two years, and then I did my co-op at Vehikl who were called Chrome Media at the time, and I think I was like the only person to apply for that job because everyone else was trying to get a job at Desire2Learn which is a company that makes like education student management software, and it's all C# and Windows stuff and that's what they teach us in school so that's what everyone was excited about and they were kind of like the cool, hip company in the area, but I was like the only kid in my class that used a Mac, so doing the Windows stuff was painful for me. I had to like boot up a VM and do stuff like that, so even with all our projects I would do in school I was always trying to find technologies that I could work with easier on my Mac. Adam Wathan: Because we had a lot of like web based projects, even though we didn't have a lot of web specific courses, but in the later years we'd have like a project that was a two-month project and you could choose the technology, which is cool, so some people did C#, some people did, whatever. I chose PHP because that was the only programming language I knew of that you could do dynamic stuff on the server. Like at the time I didn't know that oh, you can use Ruby to do that or Java or any of these other languages, I just knew from like trying to create PHP scripts I could accept form submissions when I was 16 years old that like PHP was the language that you do ... I used to do stuff on the server, so I started looking into, you know, tools for PHP that could compare with like ASP or C#. Matt Stauffer: Like MVC. Yeah. Adam Wathan: That like framework and I found my code igniter and stuff like that and so we started messing around with those sorts of things, and I was lucky enough to find a handful of people that wanted to work on those technologies with me instead of doing the C# stuff and they were all pretty bright people, so we did a bunch of projects using that stuff and then when it came time to look for co-op opportunities I applied to Desire To Learn and they never got back to me, which is great because if they had and I had gotten a job there I'd probably still be a C# developer now. Adam Wathan: Instead I saw this tiny, little company that was only three people at the time that was doing like Magento sites and some custom app development in PHP, and I was like you know what, I'll apply for that and I ended up being like the only person in my class who applied there and that ended up being like the best way it could have ever possibly worked out because I met some really cool, talented people there that really helped me get my career to where it is now and encouraged me to speak at user groups and get involved in open source and stuff like that. Matt Stauffer: That's awesome. Adam Wathan: So after I went and worked there I did my whole kind of internship co-op stuff there and I just never went back to school because I had a mortgage and stuff like that. I was like 26 at the time or 25, 26, and I couldn't really afford to like not get paid for another year or going back to school and the whole point of going to school was to be able to get a job. and now I had a job and even if I wanted to leave there, well, I had a job doing programming for a living on my resume now so it didn't really matter, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: So I got what I needed out of it and then kind of got into the workforce doing PHP stuff and actually like even when I started there, that's when I really got seriously into Laravel stuff. We actually started using Laravel 4 on a client project before it was officially released when it was still like in a beta, which is cool, so I was getting paid to write Laravel code on my very first programming job. Matt Stauffer: Which is amazing. Adam Wathan: Pretty neat. Matt Stauffer: That's very cool. And who are the three? It was Chris and Grant and who was the third person, do you remember? Adam Wathan: Chris, Grant and Caryn, who is like a ... She's a product designer. Matt Stauffer: Product designer, yeah. Adam Wathan: A UX person there. Matt Stauffer: I didn't know she was employee number one. Adam Wathan: I don't think she was employee number one. They kind of went through a couple different iterations of the company doing different stuff- Matt Stauffer: Got it. Okay. Adam Wathan: Over time, but when I got there it was the three of them and they kind of had their thing figured out. Matt Stauffer: Very cool. All right, so the story from there you did at Vehikl ... So when did you start speaking? Was it the Laracon EU testing talk? Was that your first kind of big conference, or what was your speaking journey like? Adam Wathan: So the first talk that I ever gave was like an intro to Laravel talk at a Meetup that we created so that I could give that talk basically like the vehicle we created like the Kitchener-Waterloo Laravel Meetup which only survived like a few Meetups because we also had this like Guelph PHP user group which half the time we were doing Kitchener anyways and that eventually just became like oh, we'll just do everything there because we'd meet up once a month there. But yeah, so I gave a talk at that user group to about like 30 people or something, which was my first time doing any speaking like that, and I may have done another talk after that to like a local Meetup, but yeah, the first conference talk I think was the community day at Laracon EU 2015 or maybe '14, yeah, and I did the talk- Matt Stauffer: I remember it, but I don't remember the year so, yeah. Adam Wathan: Yeah, I can't remember what the talk was called, TDD the good parts, I think, and then after that I think I gave a talk at True North PHP in Toronto at Chris Hartjes and Peter Meth's conference and from there I just kind of got into it more and more. Once you kind of have one conference under your belt, it's a lot easier to get into the other ones, especially if you make the effort to get them filmed and post them online and be able to use that stuff to help show people hey, I can actually do this and it'll be fun. I'm a grown up I can do a good job. Matt Stauffer: Cool. So at some point you were using Laravel, and you became more aware of some of the world's around there. You were looking into things in Rails, you were talking about Ruby some. What was that journey like from Laravel being the thing that you were spending all your time in, to kind of expanding your exposure to the rest of the web world, I guess. Adam Wathan: I can't say ... I can't think of a specific ... I can't remember exactly how I heard about some of these other things, because like I said, I only remember being in college and being like well, PHP is what I use on a server. I didn't even know Rails existed. Like in some ways, in a lot of ways I wish I had known, because I probably would have never become a Laravel programmer. Not because I don't have ... I have anything against Laravel, but throughout the years it's become pretty clear that philosophically I'm much more aligned with the way people think in kind of the Ruby world, right? Adam Wathan: So I was already kind of like deep into Laravel stuff and feeling like pretty fast and productive with it and I'm sure all I was doing was poking around the internet looking for tutorials, reading things about how to do this and that and somewhere in there someone said similar to how this works in Rails blah, blah, you know what I mean? Like eventually you just kind of like start hearing about these things. Matt Stauffer: Yeah, yeah, yeah. Start hearing it, yeah. Adam Wathan: And the Laravel community was a lot less mature than it is now at that point, so a lot of the really good content that was out there was focused on Rails. Like Rails had a big head start on a lot of what we're doing in the Laravel world. Rails came out in like 2004 I think originally. And there's blog posts written in like 2008, 2009 that are still really useful blog posts for people writing Laravel stuff now, so it was actually really interesting for me to discover that kind of whole world because at the time this was like 2013, 2014 when I was learning Laravel originally. Maybe ... Yeah, probably 2013, there was like eight years worth of high quality Rails content out there. So if I could just figure out- Matt Stauffer: Yeah, sitting out there already. Adam Wathan: How to translate the syntax from Ruby to PHP, you know, there was all this content out there that could make me a better Laravel developer, basically. So I got really, really deep into all that stuff and that's when I discovered companies like Thoughtbot that had done tons of blogging and written books and put together video tutorials or Gary Bernhardt's Destroy All Software, which is all Rails stuff. There was just so much good stuff out there and that's where I basically focused all my learning at that point was taking everything that people had already ... Like I make this joke a lot of the time that any time like someone runs into a problem with Laravel, like a design decision where you're like okay, well, what's the best way to do this in Laravel, take the current year subtract four years, include that in your search query and look for how to do that in Rails and there will be like 100 quality blog posts out there. Adam Wathan: So yeah, I got really into just kind of researching what people were doing in these other ecosystems and finding out what made sense to try to port back and apply to what we were doing in PHP stuff and yeah, that's kind of been like my shtick, I guess. I'm always looking outside my existing community to see if ... I think of myself as like Christopher Columbus like going across the sea to the foreign lands and bringing back treasures for people. Matt Stauffer: Nice. Yeah, so let's see. So you worked at Vehikl for a while and do you know how big Vehikl was when you left? Adam Wathan: So it was still actually just the four of us- Matt Stauffer: Oh, yeah? Okay. Adam Wathan: When I left, which was kind of like my motivation for leaving. I still was really enjoying the work that I was doing there, but I had this like nagging feeling that I was missing out on the ability to grow faster by not being part of a bigger team where there was more ... Not more experienced developers like developers with more experience, but just more developers- Matt Stauffer: More people, yeah, yeah. Adam Wathan: That were experienced- Matt Stauffer: With different experiences, yeah. Adam Wathan: To learn from, right? Matt Stauffer: Yeah. Adam Wathan: And that was kind of stressing me out at the time, so I ended up leaving to go work for a company that did Rails consulting, but when I got there I got dumped onto a project doing C# and Angular, so I only stayed there for like three months because I want to blow my brains out ,and I soon ... Like within the first week of working I was like I can't believe I left my other job, this sucks so bad. And then after being there for a couple months Tighten, this company out of Chicago that does some Laravel stuff, I don't know, people might have heard of them, posted a job posting on the old Laravel job site and I applied for that and ended up going to work there for a while. Matt Stauffer: It's so weird because I've been trying to figure out how to ask you questions about that time, and it's really tough. I don't know how, but maybe I'll just try and throw a broad one at you and see if that goes somewhere. What was the area you grew in the most while you're working at Tighten? I think that may be a question to start with. Adam Wathan: That's a hard one. I can't think exactly what ... I think the biggest changes for me are the things that I had to figure out the most was like the remote working thing. That was like a new thing for me and figuring out how to ask for help with things and get stuff done and get help from people in a way where like I'm just so used to ... I was just so used to working in an office where if you're frustrated with a problem, like the people sitting around you can tell, you know what I mean? Matt Stauffer: Yeah, yeah, yeah. Adam Wathan: And that's not as easy in a remote company, so you have to figure out ways to manage that sort of thing, especially when people are not always like available at the same time because everyone's kind of working ... Like even though you have kind of standard-ish hours, there's still a lot of a synchronicity to it, right? Matt Stauffer: Yeah, yeah. Adam Wathan: Everyone has different calendars with different things going on, which is very different than being in an office. Yeah, people have stuff scheduled and calls and stuff, but you can like see when someone is available. So figuring that out was probably ... That was probably the biggest change and area for me to kind of figure out how to work that way, and yeah, it was good though. I think the remote working set up is the way to do it, as long as you can make sure people are able to communicate when they need to communicate and feel ... You have to be more deliberate about asking for help, which can be hard, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: If you can just be frustrated and people can tell and people offer to help, that's one thing, but sometimes it's like you feel like you have to ask for help every 15 minutes with something, especially when you're starting, right? Matt Stauffer: Yeah. Adam Wathan: And that could be like ... It's like a degree of shame or something like associated with that. That's hard to get over. Matt Stauffer: We've been working ... That's probably been the biggest barrier with bringing on juniors is that the combination of junior, plus remote, it's really an extra level of shame. Adam Wathan: Plus new job, right? Matt Stauffer: Yeah. Adam Wathan: Which is hard for even for like an experienced person, yeah. Matt Stauffer: New job, remote, new tech, I don't know what I'm doing, everybody else here has got it and I'm asking for questions every 15 minutes, I feel like I'm bothering people. Adam Wathan: Yeah. Matt Stauffer: That's definitely tough. Adam Wathan: Yeah. Matt Stauffer: So this is the last question I'll ask about your time at Tighten, but one of the things that was really impactful from our perspective was that you had a lot of thoughts about how a company should be run and a lot of them came from watching Base Camp and and Thoughtbot, and thinking about concepts that you've talked about in the podcasts and some of the times I've talked with you about on podcasts of things like no estimates and stuff like that, where there's a certain way of thinking, and I think that Dan and I say often that your time at Tighten was really impactful in terms of just kind of like sharing those things with us, but it wasn't always just as easy as Adam comes in and teaches something. Matt Stauffer: Often it happened in the context of, you know, there was a ... Not necessarily there was a conflict, but there was sort of like well, why is it not happening this way and we'd be like, "Oh well, I don't know. We'll figure that out." So I was wondering during your time at Tighten, do you feel like you learned anything about what you wanted to kind of do when you grew up kind of vibe in terms of teaching, or were there things that you learned about how you think software should be written or something that happened in the context of those learning moments and those conflicts and everything that we had during those times? Adam Wathan: Yeah, I'm try to think if there's anything specific I can take away as like a learning ... Matt Stauffer: And if not, no worries, I'll just edit out the question. Adam Wathan: Yeah, I think like ... I mean, what I like working on the most at Tighten was being able to create projects for companies, build stuff for other people. I think if anything, what I maybe took away is that ... What's the best way to say this? I like having control I guess of like my own destiny in that sense because working with companies to build new projects for them there's like this of course this whole layer of stuff that comes with that that isn't there when you're just building something for yourself of course, right? Matt Stauffer: Yeah. Adam Wathan: And it can be a real challenge sometimes to get people on board with building something in a way that is in their best interests, even though they might not understand why or agree why, and that's just like a whole thing that you have to figure out how to navigate that can just get in the way of what you want to do which is just like creating the best thing for solving a problem for them, right? Matt Stauffer: Yeah. Adam Wathan: So I think being able to get into what I'm doing now where I get to like create training stuff and stuff like that has been a nice change in that sense, because it lets me focus on just doing ... Creating the thing that I want to create. But yeah, like you said, like I think a lot of the reason that I cared so much at Tighten and everywhere I worked about how to try and run these projects successfully is for that same reason because I just want to make the great project, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: And I think everyone is on the same page there, right? Like you want to figure out a way to navigate the other stuff and minimize it so that you can just focus on doing the work, but because I just care so much about doing the work and that's what I want to do, that it kind of pulls me down this path of figuring out like okay, what is stopping us from being able to just do the work and what ideas are out there in the world that people have that can help us focus on- Matt Stauffer: Help us, yeah. Adam Wathan: Just doing the work for people. So I don't know if that really answers your question in terms of I guess like a specific kind of learnings or take aways, but in terms of, you know, that sort of project management side of things, I think that's sort of like where my motivations at least come from to care about that stuff. Matt Stauffer: Well, it's funny because you say everyone feels that way and of course everyone, you know, hopefully wants to really do a good job for the client, but it also reflects a little bit back on what we were talking about earlier about you love doing things to the best they can possibly be done and it's not just your things, you know, it's also other people's things. Like every project you have a hand in, you want it to be the best possible thing, and if there's stuff getting in the way of that, well, then that's stuff that you need to kind of shave off so that it can just be the optimal it will be. So I totally hear that and that makes a lot of sense. Thanks for answering that kind of convoluted question. Matt Stauffer: So the transition from there was it was during your time there that you wrote your book and you released it and you were able to transition it to be doing your own educational stuff full time. So in terms of that switch, when and what was the process like for you to start thinking you know what, working at somebody else's consultancy may just not end up being the thing for me and I want to try info products or I want to try my own products or something like that? Like what was that journey like for you? Adam Wathan: Yeah, so I think for me what really happened there as I put together this book and released it, I didn't really have crazy expectations for it or anything like that. Again, it was just one of those things where I've always just really liked making polished things that are finished that you can look at and be like this is done and this is tidy and this feels nice. And I used to do that with even like trying to contribute tutorials to Game Facts and stuff back in the day. I never got anything on there, but I would just like agonize over like making some sweet like ASCII art title at the top of these like stupid plain text files- Matt Stauffer: That's perfect. Adam Wathan: And I just wanted it to feel like a polished thing, right? So that was kind of like one of my biggest motivations for making the book was first of all, I've always been interested in like creating something and selling it and seeing like what it's like to make your own money on the internet sort of thing, but I also just like ... It's hard to think back to it now because I have a few products now, but back then I kind of felt like I just had never got to finish anything, if that makes sense? Matt Stauffer: Yeah, definitely. Adam Wathan: And this is a common thing that I think like agencies deal with a lot in general, right? As you get to work with a client, you do a lot of really great work for them, but you're not necessarily like always around 'till the end of the project because maybe eventually they hire their own team which is one of their goals from the beginning, right? They're trying to get like a head start on something so that once they have a little bit of traction they can build their own team around it, because of course that's more economical way to handle that. Adam Wathan: Or the other end of the spectrum is you start working on a project for someone and it turns out that they just aren't able to hold up their end of the bargain really and the project is just not going to work out and you do work for them for six weeks and then they realize like you know what, I'm not ever going to be able to make an app company properly, so you kind of just say okay, thanks for your work, you did a great job, but like that's the end of the project. Like I've worked on so many projects that never even went to production, you know? Matt Stauffer: Yeah. Adam Wathan: Or got any users or anything like that and that's kind of like a ... At the time that was kind of "I just want to finish something. I just want to have something that's done." I did that with my Nitpick too, that little SaaS something- Matt Stauffer: Yeah, I remember. Adam Wathan: That I built, and the whole goal there was just the same thing, like I want to build an app 'till it's done and then put it out on the internet, and that was just like a cool feeling. So I did the same thing with the book and then the book ended up being, you know, pretty successful, and before I worked on that book, I had the idea all along that what I really wanted to do was some sort of testing thing, like some TDD book or course or something, but it was just like ... Sounded like so daunting, it just sounded like a big project. Adam Wathan: So I stumbled on this idea to the collections thing, and that seemed so much more manageable, so once I had finished that and, you know, it was pretty successful, I thought you know what, if I want to do this like testing product, this is the best possible chance that I'm going to have to be able to spend the time on that because the book did well enough that like I can take six months off and focus on this thing. So I thought you know what, I'm not going to get a chance like this again. If I don't do it now then this money is just going to go into an RSP or something and it's just going to ... Yeah, of course that's good, I should have money saved away for a time. Matt Stauffer: Right, right. Adam Wathan: I'm not going to ... Like it's not going to change my life in any way, I'm just going to keep doing the exact same thing that I'm doing. The book's going to be out there, but I'm not like seizing the moment to use it as an opportunity to try something. So I thought you know what, this is like the only chance that I'm going to get to probably do this, so why don't I try it out. So that's when I decided to move on to try and to just do something for myself and see how it panned out and I did the testing course, which was way bigger than I even was worried about it being originally. Adam Wathan: So it's a good thing that I didn't try and put it together when I was still working, but that did really well too, and that's been able to let me focus on continuing to do more stuff like that. I'm always able to stay just like a little bit enough ahead of where I need to be that I have some time to figure out what the next thing is going to be, you know, and I'm just kind of like building the bridge as I try and cross the river. Matt Stauffer: Yeah, that's awesome. I remember one of the things that you said when you let us know that you were going to be going off to do the thing full time and you said, "You know, I don't know how this is going to work out, but I know that if it totally flops in six months I can apply to one of a myriad programming jobs, but if I don't try this, there's no guarantee I'll ever have this chance ever again where there's the traction for my book and I have enough money to kind of try this thing and so I got at least try it." And that really stuck with me, just the idea that like ... And I mean I've had that happen where I've had an influx of cash and it just kind of goes and spreads out across retirement savings and health expenses and whatever else, and your life is exactly the same even though you put all that work into it, and so that idea of those are those moments and it's scary, but like what's the worst thing that's going to happen? I'll use up all the money and then apply for jobs on the other end. Matt Stauffer: You know I'm a little less stable because I'll have to be applying for a job versus having once settled, but there's no guarantee that your job's not going to shut down the next day, you know, and so like the idea that oh well, everything's perfect now, I'll be put ... No, no. You know, I really love that kind of thinking and obviously at least so far it's working out really well for you, so I'm hoping that's an inspiration for other people to kind of consider taking some of those leaps. Matt Stauffer: I would love to ask you a million questions about how you think about product and stuff like that, but we're longer than usual, and thankfully other people have asked you that on their podcasts, so I'm going to try and link some of your stuff with Justin Jackson and some other people, also Full Stack Radio, even though it's you interviewing other people, you do learn a lot about the interviewer by the questions they ask. So all this super interesting stuff that we don't have time for, I hope that we'll be able to ... People will be able to kind of suss that information out anywhere else. Matt Stauffer: But I think one of the things we have not talked about, so every time I'm going to be interviewing somebody in the Laravel podcasts I go into Tighten Slack and I say I'm about to interview this person and I'm actually opening my Slack right now to make sure that new questions ... Yep, a couple of new questions came in, and I say, "Are there any particular questions that y'all want to ask them?" And so I ask that question in Tighten Slack, which is kind of funny because you are still in some of our Slacks and you used to work there, but there's still some questions. Matt Stauffer: So the first question came up for you is, "Do you even lift, bro? Which first of all is fantastic, but second of all in our Slack that actually triggers a gif of you doing a lift, so it's perfect. So we haven't gotten to talk about that at all. Adam Wathan: Yeah. Matt Stauffer: Where did that fit into your whole world? Can you tell everybody a little bit about kind of that part of your life? Adam Wathan: Yeah, so when I was working up in Fort McMurray in Alberta, I've always been kind of like an overweight kid. Matt Stauffer: Same. Adam Wathan: And like most people, like you just want to look better, right? Matt Stauffer: Yeah. Adam Wathan: So when I was working up there, you're just like so bored and you're not using your willpower for basically anything else that it was like an opportunity to finally try and do that seriously, right? It's actually funny because if you follow along with like the bootstrap podcast like Ian and Andre, Andre is kind of doing the same sort of thing. Like he decided to basically take off some time during the year from any really like mentally sort of straining work. Like I think he's just mostly focused on doing some consulting stuff and I'm not even sure if he's working the same amount of hours and stuff that he was doing normally, but he decided like, you know, I want to take this opportunity with this kind of reserve of mental energy that I have and focus on something like really life changing thing, which for him was like getting in shape, right? Matt Stauffer: Yeah. Adam Wathan: And it's funny because I never really thought about it that way, but when I heard him phrase it that way it's like you know what, that's exactly like why I was able to do it originally, because I just didn't have anything else pulling at my brain. So when you're going to make dinner or even going out for dinner with your friends it's easy to order the vegetables instead of the fries because like I just haven't used any of that brainpower, you know what I mean? Matt Stauffer: Yeah. Adam Wathan: So when I was working out there, I just ... It was easier for me to start eating a lot better and get into like home workouts and stuff like that and that led me down this whole path of eventually discovering like strength training. Pro tip; if you're a programmer who wants to like start exercising, the terms that you should be Googling are strength training. That is the term that's going to find you ... At least I think is going to find you the stuff that's going to resonate most with how your brain works in terms of things being really measurable and being able to like science the shit out of everything with lots of percentages and math. Adam Wathan: But eventually I kind of stumbled onto this like form of exercise where you're just focusing on like lots of really high bang for your buck compound exercises like multi joint movements like squats and deadlifts and bench press and overhead press and chin ups and barbell rows and stuff like that, and once I finally found the good stuff online which was like Mark Rippetoe's content and stuff like that, you learn like what you should be doing is progressively trying to increase the weight that you're lifting. Like a lot of people just go to the gym and they just like pick whatever they think is going to be like a good weight to lift that day and just do it or whatever, but they're not actually tracking their progress, so they don't really make progress, but if you can develop a plan where you know like okay, this week this is what I'm lifting, next week I have to try and lift this and it goes up and up and up. Adam Wathan: For me that's what was able to keep me kind of motivated because I was seeing progress on paper because seeing progress in the mirror is a lot harder, it takes a lot longer and it's a lot more subtle and gradual, and if you're not taking the pictures of yourself topless in the mirror every week to compare like okay, do I actually look like I'm getting in better shape, but if you're just like blogging stuff in a notebook it's easy to say okay, I bench pressed 185 for six reps last week and this week I did it for eight reps, that's pretty cool. So I've kind of gone into this whole thing of getting stronger and lifting and eventually started competing in power lifting competitions because like with everything I do I have to take it to the extreme. Adam Wathan: So what started as like 185 pound like skinny fat kid to trying to like look better without his shirt off, turned into like a 260 pound dude deadlifting 600 pounds and winning nationals power lifting gold bells. That was just something ... I would still be doing that, but it's a hard ... Once you get there's like a point of diminishing returns, which I think I definitely hit, where you're just more likely to get injured than you are to make progress, and I've hurt myself a couple times and I have a nagging back injury now that doesn't bother me day to day, but any time I get back into lifting, no matter how light I start, after a couple weeks I do one rep not 100% perfect and my back is messed up for a week, it's really frustrating. Adam Wathan: So it's hard for me to really stay motivated into it these days because the thing that kept me going was like getting stronger. So going to the gym to lift less than I did before is like, whatever. I still need to get back into it more, but yeah, that was a big thing for me for a while. Matt Stauffer: It's funny because as you were saying that, a light was going off in my head. I switched to a new trainer about four months ago and it was the first time the trainer has been trying to teach me the skills to be able to stop working with him versus just kind of like giving himself job security by just kind of telling me what to do. And he's a Mark Rippetoe guy and he just moved to Chicago, or he's moving to Chicago this weekend and so he's like here's everything I know and he set me up with this thing called ... Have you ever heard of the 5-3-1? Adam Wathan: Yep, that's what I always used to do. Jim Wendler. Matt Stauffer: That's literally what I started it this week at the new gym on my own and I've got a 5-3-1 calculator. Adam Wathan: That's awesome. Matt Stauffer: I plug all my information in. Adam Wathan: It's amazing. Jim Wendler is like he's the DHH of weight lifting. Like he's just got that same like everyone over complicates things attitude and there's this quote that I ... So this is so funny because like so many people who get into power lifting are like super nerds about this stuff, right? Like the amount of like just nerds that get into this stuff is outrageous just because of the fact that you get to make spreadsheets, you get to calculate like your estimated one rep max based on how many reps you lift this way or whatever. Adam Wathan: And I'll never forget there's like a F.A.Q. section in one of Jim Wendler's books where someone asks a question and it's like, what is the best ... I can't remember exactly how it was phrased, but basically the question is like what incline should I be using on like

Panel: Charles Max Wood Guest: Kyle Simpson This week on My JavaScript Story, Charles speaks with Kyle Simpson. Kyle is most well-known for being the writer of You Don’t Know JS. He first got into programming because his friend’s dad was a programmer and he was hooked by the software side of computers. He grew up writing games with QBasic and Turbo Pascal and then in his teens did some client projects. He was very much a self-taught programmer and ended up sticking with it into his career today. They talk about what led him to JavaScript and what he is doing currently. In particular, we dive pretty deep on: Kyle intro You Don’t Know JS How did you first get into programming? Dad’s friend was a programmer Dad built computers Wrote games with QBasic and Turbo Pascal Some client projects in teen years Very much self-taught programmer CS degree in college First professional job at a biotech company Do you feel people need to get a CS degree these days? Grateful for his degree What engineering taught him Striving to understand why and how things work Don’t need a CS degree but you do need a certain mindset Valuable but not necessary What led you to JavaScript? Web Portal at his college What made you want to deepen your knowledge of JS? What are you working on now? And much, much more! Links: You Don’t Know JS JavaScript Kyle’s GitHub Functional-Light JavaScript @getify Kyle on Front-end masters Picks Charles Template Weeks Working Out Kyle Fluent Conf Node RSA

Panel: Charles Max Wood Guest: Kyle Simpson This week on My JavaScript Story, Charles speaks with Kyle Simpson. Kyle is most well-known for being the writer of You Don’t Know JS. He first got into programming because his friend’s dad was a programmer and he was hooked by the software side of computers. He grew up writing games with QBasic and Turbo Pascal and then in his teens did some client projects. He was very much a self-taught programmer and ended up sticking with it into his career today. They talk about what led him to JavaScript and what he is doing currently. In particular, we dive pretty deep on: Kyle intro You Don’t Know JS How did you first get into programming? Dad’s friend was a programmer Dad built computers Wrote games with QBasic and Turbo Pascal Some client projects in teen years Very much self-taught programmer CS degree in college First professional job at a biotech company Do you feel people need to get a CS degree these days? Grateful for his degree What engineering taught him Striving to understand why and how things work Don’t need a CS degree but you do need a certain mindset Valuable but not necessary What led you to JavaScript? Web Portal at his college What made you want to deepen your knowledge of JS? What are you working on now? And much, much more! Links: You Don’t Know JS JavaScript Kyle’s GitHub Functional-Light JavaScript @getify Kyle on Front-end masters Picks Charles Template Weeks Working Out Kyle Fluent Conf Node RSA

Panel: Charles Max Wood Guest: Kyle Simpson This week on My JavaScript Story, Charles speaks with Kyle Simpson. Kyle is most well-known for being the writer of You Don’t Know JS. He first got into programming because his friend’s dad was a programmer and he was hooked by the software side of computers. He grew up writing games with QBasic and Turbo Pascal and then in his teens did some client projects. He was very much a self-taught programmer and ended up sticking with it into his career today. They talk about what led him to JavaScript and what he is doing currently. In particular, we dive pretty deep on: Kyle intro You Don’t Know JS How did you first get into programming? Dad’s friend was a programmer Dad built computers Wrote games with QBasic and Turbo Pascal Some client projects in teen years Very much self-taught programmer CS degree in college First professional job at a biotech company Do you feel people need to get a CS degree these days? Grateful for his degree What engineering taught him Striving to understand why and how things work Don’t need a CS degree but you do need a certain mindset Valuable but not necessary What led you to JavaScript? Web Portal at his college What made you want to deepen your knowledge of JS? What are you working on now? And much, much more! Links: You Don’t Know JS JavaScript Kyle’s GitHub Functional-Light JavaScript @getify Kyle on Front-end masters Picks Charles Template Weeks Working Out Kyle Fluent Conf Node RSA

An interview with Marcel Pociot, creator of BotMan and co-founder of Beyond Code. Marcel on Twitter API Doc generator BotMan BeyondCode Laravel Notification Channels Marcel's Laracon EU talk Night Night Baby | Träum Süss BotMan slack invite Editing sponsored by Larajobs Transcription sponsored by GoTranscript.com [music] Matt Stauffer: Welcome back to the Laravel podcast, today we're talking to Marcel Pociot, the founder of BotMan, the framework agnostic PHP chatbot package. Try saying that two times, 10 times fast. Stay tuned. [music] Welcome back to the Laravel podcast. This is season three where we're doing interviews. It's the people you know—getting to know aspects of them you never understood. Or it's also finding some people who you probably have used their tools or you've seen them but you don't actually, necessarily know who they are. Those names who you've been putting in GitHub require or to Composer require for ages but never actually known who the person is. The guy we have in front of us today, I'm actually curious to see what his entire history of working with Laravel is, but the current most present one that's going on right now is connecting Laravel to chatbots and slackbots, and all that kind of stuff, and this is called BotMan but there's a lot more going on here. First of all, we start with the point where I massacre somebody's name and then we move on to the next point where I ask that person to say their name correctly and then introduce themselves a little bit. Marcel Pociot, that's close, not perfect. He's still smiling, so I didn't massacre it too badly. Can you tell us-- and I'm probably ending up calling you just Marcel through this podcast. Marcel Pociot: Yes, that's fine. Matt Stauffer: That's because it is easier for me to say. Thank You. Can you tell us a little bit about-- just real quick, you don't have to tell us your whole life story, I'll ask those questions but—who are you? What are you doing? What are you about? What's BotMan? What is your new company? Just give us the basics of what should we know about you. Marcel Pociot: Okay. Yes, my name is Marcel Pociot. I think that's at least the German pronunciation. I co-founded a company in December last year. Matt Stauffer: Congratulations. Marcel Pociot: Thank you. Very fresh still. I think you're one of the first people that I actually tell this in person that's not from my family- Matt Stauffer: I got the insider track then. [laughter] Marcel Pociot: -and friends because the website isn't finished yet. Yes. I think I'm quite around in the Laravel community for a bit. Matt Stauffer: You've been working-- I've known you just generally in the Laravel community, but you're one of those people where I know that I've known you but I don't even know how we originally connected. Now, you mentioned that we spoke together at a conference so that it may have been it, but do you have any early claim to fame in the Laravel community? Were there any packages that you did earlier on it that were more popular or is it just that you've been around for a while that you're known? Do you know? Marcel Pociot: Well, I did a few. There is one, I think it's called teamwork, for some user/team association package. Matt Stauffer: I remember that. Marcel Pociot: But they're all a bit older. Matt Stauffer: Where did first start using Laravel? Marcel Pociot: Two and a half years ago, I think. I wasn't doing that much PHP back in the days, at least not with frameworks. At the companies I work with, they were using self-built frameworks which are usually crap. You do this once in your lifetime and never again. Well, I ended up at companies that did it all the time. At one point, we decided that we'd built a SaaS application and we were looking for framework to use. This is pretty much the story I tell everyone when they ask me how I got into Laravel. My boss was really into Zend because of the whole Zend ecosystem, with the Zend Studio and the Zend server. I looked into the Zend framework, I think it was two. I gave it a week, I gave it really my best shot. I even bought a book and to gave it a try. In the meantime, I looked around for other frameworks and discovered Laravel. What I did with Zend framework in a week, I did with Laravel in an hour in the evening on the couch. This was the main motivation to use Laravel then. Matt Stauffer: Got it. Okay. I do remember that one of the things that, originally I saw, is that you were doing the Laravel notifications thing. Did you help co-manage that? Marcel Pociot: Yes. Matt Stauffer: Or manage or- Marcel Pociot: With Mohamed and Freek, yes. Matt Stauffer: Okay. Cool. Got it. Stepping back for a second, it's so funny because I try not to go too deep in my own ethnological and linguistic curiosities in the podcasts because nobody else isn't quite as interested as I am, so one of the things I actually ask myself before we were on a call is how was your English so good, we went to that little bit but I must admit that based on your name, it's sounds French to me, but I know that you live in Germany. Are you French origin living in Germany or I'm I just totally? Marcel Pociot: No. I hear that a lot. I think it's also because of my first name. People try to pronounce it French, like Marcel Pociot or something like that. Matt Stauffer: That's exactly what I expected you to say when you first told me, yes. Marcel Pociot: As far as I can tell, the name-- we can't trace it back that much. I think it's just two generations and it's from Eastern Europe, so that's pretty much all I can say. Matt Stauffer: Okay, but you're German, you live in-- where do you live in Germany? Marcel Pociot: Near Dusseldorf, which is near Cologne so, yes. Matt Stauffer: I took a little bit of German in high school and college and probably forgot the majority of it, but just enough that I can read a couple of German story books to my kids and to try to get a little bit of German heritage in for them. My sister was in a little bookstore, a local bookstore and found this-- what's it called? It's like sweet dreams or something like that - Träumt Suss? Marcel Pociot: Susse Träume? Matt Stauffer: Anyway, it's this cute little blue book so I read it to my son over and over and over again, and my pronunciation was really bad at day one, but over time I got good at it. Then at some point, my wife found the exact same book in English and so now, with both of my kids, I read them both of the books back and forth, but my daughter is understanding enough English right now that when I read the German version to her she's like, "Wait a minute, I don't understand this one". She gets mad at me [laughs] because she prefers the English version. Anyway, cool. I do remember there was another big one, the API documentation generator, tell me a little bit about that project. Marcel Pociot: Well, it's a tool that you can pull into your Laravel application and it will basically just reads the routes that you define, so you can call it and give it the prefix of the routes that you want documentation for and will scan the routes and create this Stripe like documentation. So that you have the documentation on the left and then code examples how you can interact with the API on the right, and it does it by just pausing the routes and then reading the documentation of the code. Matt Stauffer: Is it its own thing or is generating like one of the preexisting styles? You know what I mean? Because I've never got to use it, but we are always looking for API documentation generators. Marcel Pociot: It's a theme that's called slate, so it's using this. Matt Stauffer: Cool. Very cool. I'll put links in the show notes. But the main two that I see associated with your name right now are the API doc generator and then, of course, BotMan, which we'll talk about in a minute. Those are the things and then we've got your company. Let's real quick talk about what is BotMan, where did it come from and then also, what's your company and then we're going to dig into the back story. BotMan, what is BotMan? What does it do and where did it come from? Marcel Pociot: Okay, I'll start with where it came from. It was really just coincidence. Late 2016, Slack announced that they now have a new HTTP based API, it's called event API. Basically, before that when you wanted to react to Slack events, like new messages, you had to connect through web sockets and the new API was basically just webhooks. Whenever a new action appears-- yes. Well, I mean, if you have a large Slack team it will blast a lot of events to your server. When I heard that Slack announced this API, I just thought that it would be cool to have a PHP API that wraps around it and have an elegant API around it, it's sort of what Laravel is all about, then apply this to Slack. Then I did this, I open sourced it. It was called just SlackBot at the time. It lay around there for three or four months, I didn't do anything with it and then, I came up with the idea that it might be cool to connect multiple services to it, not just Slack, but also Telegram and Facebook Messenger. That's the main thing with BotMan. It's one of the only-- maybe it's the only —PHP library that actually allows you to connect to multiple messenger services. Matt Stauffer: Yes. If it not the only, it's the only one that matters. That's what I think. [laughs] Marcel Pociot: It allows you to connect to these services with one API and reuse your code. Matt Stauffer: One of the hardest things for people to think about, chatbots— everyone hears "Chatbot is the cool new thing", whatever and often, it's really difficult to understand in what context would I actually want to use this, what are some--? Some of the simplest ones we've seen are, "Oh well, when I hook into a CodeShip integration, something that already exists but, what are some of the-- either in your personal use of it or in seeing other people use it, what are some of the most compelling uses of chatbots? Whether it's in Slack or Telegram, or whatever else that you've seen to help people's imagination get started a little. Marcel Pociot: Yes, I think the problem is that people always associate chatbots with these super artificial intelligence systems that understand whatever the user wants. In my opinion, it's just a different interface for your application. It's a conversational interface for your application and what I've seen that was built with BotMan, a lot is like websites, for example, for insurance companies. On their website, they have this chat bubble, that you know maybe from Intercom, and what it does is it guides you through the website. When you click on a button, the chatbot opens and asks you a question related to the action that you triggered when you clicked on the button. That's one-use case and I think- Matt Stauffer: I want to stop you for a second. When I think of a chatbot, what I think about is something that allows someone to use a preexisting chat system, like Facebook Messenger or something else, to interact with their backend API. What you're describing sounds like an entirely manual process where you just used webhooks to hook in your app, right? Am I missing what you're talking about? Marcel Pociot: No. That's also possible. With BotMan, it is the web drivers, so you can just connect it to your own API and then you send the message from your user to your own API and reply back. Matt Stauffer: Okay. Got it. Marcel Pociot: But in the end, that's what happens with Telegram or Facebook too. Yes. Matt Stauffer: So really, anything that has to do with sending and receiving messages to your user in a chat-like format. Marcel Pociot: Yes, right. Matt Stauffer: Regardless of which chat format they're usbing. Okay. I think the on page one is just so clear of an example. Everyone has used a website with Intercom on it or one of Intercom's competitors at some point. I get that one. I think that's super compelling. I'm happy to know that if I need to build that, still reach for BotMan, that's cool. I wouldn't have known that until you said that. Have you seen people use-- I think the hard thing for me is that when I think about Telegram or when I think about Facebook Messenger, I very infrequently think about interacting with someone who has enough money to have an API. I think of my friends. I'm sending a message to my friend, my friend messages me back. Have you seen or heard of really compelling use cases where people are using traditional chats systems, outside of Slack? We'll talk about Slack in a second, but has anybody done anything interesting that you know of with Telegram or Messenger or are those little more aspirational at this point? Marcel Pociot: Messenger is used a lot for more marketing kind of services. For example, TechCrunch has this, well, it's a chatbot where you can-- when you sign up you can register for different topics from their RSS feeds. Matt Stauffer: Intere-- wow. Marcel Pociot: Then you get- Matt Stauffer: They are using it to publish information out and people are subscribing. Marcel Pociot: Yes, every evening-- so you can select topics and then the time. Every evening, I get the top 10 stories from TechCrunch into the Messenger. Matt Stauffer: You just blew my mind. My son just started a podcast www.stauffersonscience.com, and I have a whole bunch of people who I grew up with, who are completely un-computer savvy and they're all saying, "How do I subscribe to a podcast?", I'm like, "Oh Gosh, how am I going to handle this?". I could build a little light Laravel or Lumen app that subscribes to the RSS feed of the podcast and allows people to enter their-- authenticate their Messenger information and pushes every new episode to their Messenger inbox. Marcel Pociot: Yes, right. Matt Stauffer: Holy crap, you just blew my mind. That's amazing. That is so cool, that's so clever. That opens up so many things for people to subscribe because everybody, all your non-tech savvy friends, your mom, your grandma, all of them, they all have Facebook which means they all have Messenger. Marcel Pociot: Yes. I think even more like the younger generation because they don't have MacBooks or laptops, they just have smartphone and use Messenger to communicate. Matt Stauffer: Do you know-- I'm sorry I'm just going into the weeds here, but I am so fascinated. If somebody doesn't use Messenger and they send something to a Messenger authenticated thing, does it show up on the web interface in their little messages thing in Facebook website? Marcel Pociot: You mean if they don't use the Messenger application? Matt Stauffer: Like if somebody doesn't have an iPhone but they go to facebook.com on their browser every day, can they do Messenger interactions using the little- Marcel Pociot: Yes. Matt Stauffer: Okay, so it's the same thing as Facebook. Man, I need to pause for a moment, this is so cool. Okay, broadcasting makes a ton of sense. Broadcasting information, this—in some ways, you have some of the value but a lot more configurability of like an RSS feed through a multiple-medium subscription. That makes a ton of sense and I get that now. Marcel Pociot: Plus, I think. maybe this will change over time, but right now the click rates are much higher because it's not that overused as e-mail newsletters. For example, with the TechCrunch- Matt Stauffer: They feel more personal too? Marcel Pociot: Yes. It feels-- even though you know that you're not actually talking to someone at the company, it feels like you're interacting with the company, well, with its brand. The whole market taking thing is really popular on Facebook, also for artists, they have chatbots that you can ask, "where's the next concert?", and the user feels like they are talking to, I don't know, Beyoncé, whatever. Matt Stauffer: Interesting. I was just going to ask about questions. That one right there would feel like a little bit of natural language processing. If you can do some of that then you can have like ask questions of our whatever bot, or whatever, and that makes sense too. You imagine that you are working for some big company, like an insurance company maybe, and they say, "You want to ask us a question? Here, hook up to our messenger bot and you can ask--" blah, blah, blah. The messenger bot parses out using some basic natural language processing. So, the messenger bot is basically BotMan hooked in your API. The API, your Laravel app takes the questions tries to process them, tries to look up an answer and then sends the message back to that person. So that BotMan would be the interface layer in between. Marcel Pociot: Yes, right. Matt Stauffer: Okay, that makes sense. Slack makes the most sense for our context. I think we're all sitting and using cycle work every day, and it seems like Slack is adding more and more things you can do every time. Buttons at the bottom and stuff like that. What is the most interesting thing that you have built or seen built with Slack integrations on BotMan? Marcel Pociot: It's also interesting because Slack got-- I think they moved away from the term chatbots a while ago, and I think they just called it application. They even integrated like forms that open up, like select boxes, drop downs. I haven't seen that many slackbots using BotMan. There's one, I forgot the name who built it, but he built a slack game, it's like a dice rolling game, it's called Liar's dice. Matt Stauffer: I, obviously, could talk about BotMan the whole time. But this isn't actually about BotMan, this is about you. BotMan is amazing, there's all sorts of interesting stuff. You also have given-- do you know if your Laravel EU talk is online? I didn't actually watch those. Marcel Pociot: Yes, it's online. Matt Stauffer: Okay, great. I'll put a link up to your BotMan talk which is called From zero to multi-platform Chatbot with BotMan. I'll put the link up to that one as well. Let's move on to you. The first place I always start with everybody is, when did you first get interested in computers? Or when did you first get access to a computer? What did your original kind of exposure to computers? Marcel Pociot: I think the first memory that I have from a computer was, I was sitting, I might be like 6 or 7, sitting in the living room with my father, and I don't remember what kind of computer it was. But we had a book with games, so if you wanted to play a game that was the source code of the game in the book. Matt Stauffer: Was it BASIC? Marcel Pociot: Yes, it was. You had to type it in and then you got the game. What I remember, maybe that's also the reason why I remembered it is, my father was sitting there and typing everything in, and I just came at the power adapter and the whole thing crashed. [laughter] He was frustrated. Matt Stauffer: Yes, I believe it. I assume that was like one of those black and green old-- those boxes. Very cool. Marcel Pociot: This is the first memory of sitting in front of a computer. Matt Stauffer: I try not to call at people's ages too much, but I think that you're around my age, around 33, is that right? Marcel Pociot: Yes. 32 and in April 33. Matt Stauffer: We're almost exactly the same age. In our generation it was not all that common, at least in the US, I don't know about Germany, for people to have a home computer when we were that young. Since your father was the one doing this. Was your father-- was he a geek or is he a programmer? Marcel Pociot: Not at all, no. He was always interested in it, but well not so much that he really wanted to write more code than there was in the book. [laughs] Matt Stauffer: At what point did your interaction with the computer go from pulling out the plug from your dad typing in BASIC program to you creating things on your own? Marcel Pociot: I think it was-- in school we had, at the programming class, we wrote Turbo Pascal. Matt Stauffer: Wait, what age of school are you talking about? Marcel Pociot: I think this is seventh grade, so I must have been like 12, 13. Matt Stauffer: You had programming class when you were 13 years old? Marcel Pociot: Yes. Matt Stauffer: That's fascinating. When I was in seventh grade, we had typing class and I- Marcel Pociot: With typewriters or--? Matt Stauffer: They were on Macs, but they were old Macs and we'd all sit around and I would finish the Mavis Beacon thing in five minutes and then I'd go try to learn Applescript and write programs that would infect all the other computers in the network and shut them all down at the same time without the teacher noticing, but there's no formal programming education even in high school. The best we had was an engineering class where the teacher would let us go hack around and stuff, but certainly, nothing formal. So, you learned Turbo Pascal in seventh grade? Marcel Pociot: Yes, pretty much and then- Matt Stauffer: How did that go? Marcel Pociot: Well, I think we moved quite fast from there to Delphi where also-- in the class, there were a handful of people that were always very fast with all the tasks and, just as you said, had a lot of time. We developed like a Trojan, a Trojan Horse [laughter] to open the CD trays from the other computers and stuff like that. Matt Stauffer: Exactly. That's exactly what I was trying to do. That's awesome. Okay, early on you were deep in the computers, you were writing code, you were hacking at it. When did you first get into the web? Marcel Pociot: I don't really remember what age I was, but it was like the Geocities sites. All this crappy-- Matt Stauffer: Yes, man. I still remember, mine was MA slash 1984. My first two letters in my name and then the birth year. [laughter] What was your first Geocities site, you remember? Marcel Pociot: No, I just remember that I had this cool hacker name. Matt Stauffer: What? Like 1337 speak?? Marcel Pociot: Yes. Matt Stauffer: One, three, three, seven, four, four, whatever. Marcel Pociot: It was Delta2K, I don't know. Matt Stauffer: Nice. Marcel Pociot: It sounded cool. Matt Stauffer: Yes, of course, with 2k especially. Okay, it's funny because it seems like I'm either picking people to interview who are old head PHP dorks or there's something consistent about folks who are helping lead in our community that a lot of us are from similar generation. I'm curious to see where that goes, but-- you were doing that, you were playing around with it at the side, what did you study? Did you study that in university or--? Marcel Pociot: No. Here in Germany after you finish school, you can either go to a university or you can do training. You go to a company and then you have three years at the company and besides working at the company, you also go to school. Matt Stauffer: Is it a school provided by the government or provided by the company? Marcel Pociot: No, it's just a public school for learning the- Matt Stauffer: For that specific career? Marcel Pociot: -specific profession. Yes. Matt Stauffer: Got it, okay. Marcel Pociot: I did that to become a software engineer and I ended up in a company in Bochum, here in Germany, and- Matt Stauffer: I don't even know how to spell that. I'll put that down on the show notes [laughs]. Okay, cool. Marcel Pociot: Yes, that's what I did. I wasn't that much into liking school that much back in the days. So pretty early on, I decided to skip the school part and rather work five days a week, so that I can hack on some code. That's what I did and then just did the tasks on my own and learned from them on my own. Matt Stauffer: Got it. You have a pretty straight line from being a little kid watching your dad enter QBASIC programs in. Through learning in school and doing your own Geocities stuff, to being a software engineer and going straight in the industry. Have you at any point felt like, "Oh my gosh, this is not what I want to do"? Or is it just been pretty clear since early on- Marcel Pociot: Yes, it's been really clear since early on. Matt Stauffer: - "I'm a programmer, this is my thing"? Marcel Pociot: That's always what I wanted to do. It's always a bit funny when I talk to people that don't really know what they want to do with their lives and what direction they want to go because it was always really clear for me that I want to go to that direction. Matt Stauffer: Interesting. If you today-- and I know that you just started your own company in December, so hopefully this is really fresh in your head. If you today were to be able to pick exactly what you were doing day to day, if your company was successful in exactly all the ways you want it to be, what would you be doing with your time? Marcel Pociot: Right now, I would say I would still love to write code. I heard that you talked about this also with a few other people, what to do when you're 40 or 50 years old. Well, right now, I would say that I hope that I still want to write code at that time Matt Stauffer: If you found yourself in a situation where your company just-- and we will talk about you company in a second, but you just took off and it's going really well. You decide to hire five people and all the sudden, you're spending all your time doing administrative work. At that point, you think you might say, "I gotta fix this, I got to get back into the code"? Is that your sense of it right now? Marcel Pociot: Right now, it is, yes, but I'm just so refreshed and I'm really just coming from a lead developer role. Matt Stauffer: Yes. Okay. All right. Tell me about your company. You went right into that internship, what's your work history look like? You don't have to tell me every company, but what kind of stuff you've been doing. Have you been working primarily for software firms or have you've been working for non-software companies as a software programmer? Marcel Pociot: No. I just worked for agencies, like web agencies. Matt Stauffer: Got it. Marcel Pociot: The first one was very small, four people when I started there which was very cool because I got to do everything. I had to talk to customers and the clients. We had-- it was very small so we had to do things like setting up e-mail accounts for them. They called if they couldn't set up the email account on their mobile phone. Then they would come in with their phone and stuff like that. Yes, the second company was also a bigger agency but still an agency, where I did-- At the first one, I did PHP and then I got a lot into Appcelerator Titanium. Matt Stauffer: That's why I thought you'd done Titanium. Let's talk about Titanium for a second. Titanium, I feel like was one of the first used JavaScript to write multi-platform apps. How is it different and similar from something like Ionic? Marcel Pociot: The main difference is that while Ionic is just html that gets executed on the phone in the browser, or in the web view, Titanium used the JavaScript code that you wrote and they had proxies for the native languages for java or Objective C. Then the JavaScript code would call the native proxy objects that would then execute native code. When you wanted [crosstalk]- Matt Stauffer: It is more of like a predecessor of React Native. Marcel Pociot: Yes, right. It's like- Matt Stauffer: Okay. Got it. Is it still around? Marcel Pociot: It is. The company got acquired and they still develop it but the time Facebook announced React Native, the community just ran away and went to Facebook, yes. Matt Stauffer: Got it. Okay. I'm sorry, I interrupted. You were doing that at that company and then--? Continue. Marcel Pociot: Yes. Titanium was also my main motivation to work on open source in the first place. I haven't done that before and I started developing Titanium modules. Just small user interfaces- Matt Stauffer: Like packages. Marcel Pociot: Yes. Right. User interface libraries to share and I put them open source and I think I did Titanium for, maybe, one and a half years. Mostly Titanium and then also some Java and Objective C to work on some native modules. During that time, I got bit away from PHP because also, at the time, there was no Composer. The whole ecosystem wasn't as stable as it is right now. Matt Stauffer: Yes. What brought you back? Marcel Pociot: Well, I think it was just a client project. [laughs] Matt Stauffer: Okay. Did they say PHP or it was a web and you had to pick and you just pick PHP because you knew it? Marcel Pociot: Yes, because I knew it and also because of React Native. When React Native was announced, Titanium just pretty much died. Matt Stauffer: Yes. But that was pretty recently, right? Marcel Pociot: Well-- Matt Stauffer: Like a year [crosstalk] Marcel Pociot: No. Native is more around more than a year, I think. Matt Stauffer: Is that real? I believe you, I don't actually know. Okay. Yes, let's say, it may be as long time as 2015 but-- because a lot of times when I hear people talk about "I stepped away from PHP--", blah, blah, blah, "and I finally came back", and they are in the Laravel community. A lot of them came back right around the time when Laravel 4 came out. Maybe I just got the timeline on that wrong in my head. When did Laravel 4 come out? Marcel Pociot: When I started working with their Laravel, 5 came out. I think I worked with 4 for about a month. Matt Stauffer: That is what I was expecting then. Okay. Marcel Pociot: Yes. We started this SaaS product at our company and we chose to use Laravel 5 because-- I think the main reason was the form requests, which just blew my mind. I thought they were super cool to validate stuff and then we decided to pick up, there Laravel 5 during the development with the beta, there was no good decision. Matt Stauffer: I didn't say and it was also bad decision. Marcel Pociot: We had to fix several things every day and at some point we just pinned the dependency to one specific commit, so we knew, “okay, this is working” Matt Stauffer: And you built against that commit until you released it until and then deal with all the fixes at once. Marcel Pociot: And then it stays that way for a long time Matt Stauffer: It's funny. This timeline does line up here is what I have seen, as four came out in 2013, five came out in 2015 and React Native was announced probably at some point in 2015. So you were deep in titanium, you were off in that world and interestingly you were doing a lot of other mobile stuff. You talked about getting into Java, getting into objective C a little bit it, so it was both Titanium, which is JavaScript but then also the adapter worlds, which means you got to know a little bit of Java from Android, a little objective C for Apple and then you all of a sudden come and jump back into PHP and it was Laravel 5, things were modern and Composer all that kind of stuff, were you still working for that same consultancy at that point? Marcel Pociot: Yes, must have been sort of at the same time that I switched jobs, yes. And I didn't do that-- I always did PHP in the afternoon on the couch Matt Stauffer: Got it. It was still always like your fun time favorite language because I know a lot of people would say they left, they're like "oh well, I got tired of PHP I left for rails, I got tired of PHP and I left for .NET or whatever, so you still had a soft spot in your heart for PHP the whole time. Marcel Pociot: Yes right, but not with the framework at the time. Matt Stauffer: You ever rolled your own? You said your company rolled their own, Marcel Pociot: Yes, of course. Matt Stauffer: Does it have a name? Marcel Pociot: No, it didn't really have a name, no. Matt Stauffer: Never got that far? Marcel Pociot: No. Matt Stauffer: Okay. You got a pretty classic story here, obviously everyone's different but a lot of us left at some point a lot of us came back at some point but it's interesting for the amount of impact you have made with BotMan you came up to Laravel pretty recently and BotMan isn't really a Laravel framework either. I feel like it was tied to Laravel at some point, is it basically just a PHP framework that does it even have a Laravel convenience layer on top of it right now? Marcel Pociot: Yes it does. It is framework agnostic but there's a piece that's called BotMan Studio which is basically a blank Laravel 5.5 installation with some additional BotMan service provider and additional commands, a Tinker page to play around with it but it's not tied to Laravel. Matt Stauffer: Got it. Okay we've caught up, you switched consultancies, you got in Laravel 5, you built BotMan, you talked about how you built BotMan so let's talk about your company. We chatted on and off about it but let's pretend that we haven't chatted at all. In December you formed your own company, you went out on your own. Tell me about it, what's your motivation, what's your goal, what's your desire; what made you want to get out of working for other consultancies and start your own thing and what is your own thing? Marcel Pociot: Okay. I'm not doing this alone, I'm doing this with a former colleague, he has been a freelancer for a year now already and already a year ago when he left the company, we were already thinking about doing something on our own and I think the main motivation was- when we started this SaaS application at our company, we thought about turning it into its own company, which they eventually did. I ended up sitting in a new office with my now business partner and the CEO from this new company and we basically sat together for 2 years, just the two of us working on the product and we just knew that the CEO back at the time was a sales person and- how can I put it, a sales person as the CEO of a software product is difficult. This was like the main motivation because we had a different idea of the product, the way we wanted to get with it and it didn't turn out into that direction so we thought that, well if we do something on our own, we can give it our best shot. Matt Stauffer: Okay. Is it a similar product to what you originally planned but since it didn't go the way you originally planned you're going to go build, are you doing product work then? Marcel Pociot: Right now the company is called Beyond Code and we are, it's sort of a split. We have, on the one hand, we do projects, project work mostly we try to do it for Chatbots obviously. Matt Stauffer: Your consultancy that builds Chatbots for people as a part of what you're doing. Marcel Pociot: Yes, right. On the other hand, we have BotMan as the library and we want to focus around building a whole product ecosystem around it so that it becomes easier for people to pick it up and use it like analytics, bot building systems. Matt Stauffer: So Beyond Code GMBH, what does that stand for by the way? I've never known that. GMBH. I assume it means limited liability corporation but the Germany version. Marcel Pociot: Yes. Matt Stauffer: Let's test my German. Gesellschaft mit beschränkter Haftung. Marcel Pociot: Yes, that's quite good. Matt Stauffer: All right. I did okay. All right. Beyond Code is a consultancy that builds primarily applications that have Chatbots on them and also uses the finances that come from that to further build the ecosystem around BotMan which is a PHP framework agnostic library to make it easy to build the type of applications that Beyond Code is building for people. Right? Marcel Pociot: Right. Exactly. Matt Stauffer: It makes sense. It's like that, not quite, like the Discourse model where like hey, there's a free or then Wordpress model. There's a free piece of software, there's also the way to pay us to do it, the money that you pay us to do it makes the free piece software better. Everything fits and everything else. Okay. That totally makes sense. All right, that's going forward. A success for the next couple years of your life would mean that the work that you're doing or consultancy work, the work you're doing for clients basically allows you to make BotMan better, is that the general? Marcel Pociot: Yes. Matt Stauffer: You mentioned analytics, you mention understanding what's going on. Are there any other big next goals or features or things that you want that you feel like you can share with us that aren't the secret sauce? Marcel Pociot: No. Not that I can share them. No. Matt Stauffer: Okay, cool. But you've got big plans, it's not just sitting where it is, it is something you want to grow. Marcel Pociot: Yes. Matt Stauffer: Okay, that's cool. I think that the ability to compellingly get someone excited about the possibilities with a Chatbot obviously is going to be a big part of your doing. I'm glad we had the opportunity for that. Like I said, I'm literally going to get off this call and go see how fast I can hack together something to send that one woman who went church with me growing up. Facebook Messenger notifications when my son's podcast goes out. I'm super geeked about that. Okay, let's see. What else, what do you do in your free time? One of the things is that you have such a straight line through programming that I think that I want to know more about what is not programming you. What motivates you? I know you've got a family, I know you've got one kid? Marcel Pociot: Yes, one kid. Matt Stauffer: One kid. How old is your kid? Marcel Pociot: Four. Matt Stauffer: Four. Okay. Obviously spending time with your family is significant but whether with your family or on your own, what do you do outside of coding? What motivates you? What excites you? What do you do when you're away from the computer? Marcel Pociot: I think I have to re-calibrate myself a bit because when I was working at the consultancy, what I was doing in the afternoon was BotMan and now I'm doing this during the day job. Matt Stauffer: Actually I got to stop you for a second. You keep mentioning the afternoon as your free time, what does your schedule look like? Marcel Pociot: It's mostly nine to five. Matt Stauffer: When you say in the afternoon, do you mean after five? Marcel Pociot: Yes, right. Sorry, in the evening. Matt Stauffer: In the evening. Got it. Okay. What you mean is basically your free time, hacking time in your old job you're doing consultancy during the day and then BotMan stuff at night but now the BotMan is your day job. How do you reorient? Marcel Pociot: Yes, I still have to figure that out myself. I'm not that much of like a sports person or anything. I think really my main motivation was to program still. Matt Stauffer: You just love coding. Marcel Pociot: Yes. Well and other than that it's mostly, beside my family of course, playing some video games but- yes. Matt Stauffer: Yes. I'm not a gamer but I gotta ask what kind of games are, I don't even know what questions gamers ask, is it a PC or console that the question they would ask what game you are into? Marcel Pociot: No, it is console but also it's funny and also a bit sad that I just realized that I'm getting old because I'm no longer good at these games. I no longer can play these games longer. I have always liked these big games that pull you in like big RPGs but now with a kid, I don't really have the time to do that. Matt Stauffer: You don't have much time. Marcel Pociot: I don't want to play for five consecutive hours and if I come back after a few days, I don't want an hour to find out where was I or what I'm supposed to do. Matt Stauffer: That's why I loved Nintendo, that's one of many reasons why I love Nintendo. Because for people with families, Nintendo is good. A, because there's games that you can play with your kids, and also user interfaces you can play with the kids, but B, there's games that are like you can dip in and out. Marcel Pociot: Yes, you can just pick them up and then play for half an hour and then your're done. Matt Stauffer: Even Zelda as an extremely immersive game. You can still pick it up for 20 minutes here or there. Marcel Pociot: That is also too big for me. Matt Stauffer: Zelda is. I mean I can understand it. I've played more video games when I played through-- I'm not done with Zelda, but I played more video games when I first got the Switch and Zelda than I have in years. And even so, it was 20 minutes here and there. Because of the Switch, I just put it down and it just pauses it, but I hear you. Super Mario Odyssey is pretty small. And of course, Mario Kart I play with my son nearly every day. Marcel Pociot: Yes, [laughs] me too, yes. Matt Stauffer: Nice. Marcel Pociot: So now we have this rule that we play every other day. [laughter]. Matt Stauffer: Yes, yes. Every night became a problem, so I was like, "You need to get off." The good thing is my son is super, super active. I was a lazy kid, I didn't want to do anything, I just wanted to sit around. My kid, if I let him, we would be outside running around every day, I don't don't have any problems. Marcel Pociot: Yes, my son too. Yes, when I came home from work, usually the first thing that he would tell me was, "Okay, you can leave your shoes on, we go out and play some soccer." [laughter] Matt Stauffer: I love it, that's very cool. Yes, I think my biggest bummer about the neighborhood we live in right now is that-- the best thing about it is the houses are really close and everybody gets to know each other very well, so he's got tons of friends. But the bummer is the yards are so small that there's nowhere for us to play without getting in the car and driving somewhere. Like, play soccer or baseball or something like that. But what we end up doing is just running around in the house like crazy people anyway. Marcel Pociot: [laughs]. Matt Stauffer: It's his favorite game right now. Marcel Pociot: We have people living underneath so we can't do this all the time. Matt Stauffer: My son's favorite game right now is turn on some music really loud, some really hype pop music or something like that, and then run around and chase each other and throw bouncy balls at each other or try to tickle each other or something like that while the music plays really loud. I'm like, "Okay." Marcel Pociot: [laughs]. Yes, haven't done that in a while. Matt Stauffer: What keeps you from getting stuck when you're coding? Or what tools do you use, or what book or what languages. How do you keep either on a single problem, or on a single framework, or single language? What broadens your perspectives? Whether it's in the programming world, like some other programming language, or whether it's something about your family or your life. What helps you keep your brain out of just the really narrow focus of, "I work in one language, one package, all day long." What gives you inspiration? Marcel Pociot: Recently, when we had in mind that we're going to start the company, I focused a lot on the organizational things and on how to get this even up and running. During that time I was not that much focused on code, or on frameworks, or anything else, because it also meant for me just to get out of the comfort zone and start a company, and not have the safety as an employee. What I'm trying to tell is that, during this time, I sort of stepped away from being too close to the coding world a bit, and now I'm just catching up again. But I think it's mostly just talking to other people and exchanging with my business partner, things like that. It's not that I use other languages and look into them specifically to see new things, so it's not that I really have the plan on how to broaden my view. I don't know, I think it just happens this way. And if I'm stuck at a specific problem, I just try to go out for a bit and [chuckle] step away from the code. Matt Stauffer: Yes. All right. I feel like I promised every time that I'm not going to say I could talk for hours and then I do it every time anyway. Oh well, I failed, I did it. Marcel Pociot: [laughs]. Matt Stauffer: We are nearing time, so I don't want to start anything new and big. Are there any other big parts of you, your life, your motivation or your work that you feel like we haven't got a chance to cover? Marcel Pociot: No, I think we covered the important parts, most of all, yes. Matt Stauffer: Okay, I like it. What's your favorite candy? Marcel Pociot: Candy? [laughs]. After the whole Christmas candy mess-- we set ourselves as a family goal to not eat any candy for a week. Matt Stauffer: I like that. Marcel Pociot: My son is doing great. Matt Stauffer: [laughs]. He's doing better than you, huh? Marcel Pociot: Yes, right. [laughter] Marcel Pociot: I cheated but he doesn't know. Matt Stauffer: All right. Well, hopefully, he doesn't listen to this. Marcel Pociot: Well, he doesn't understand English. So-- Matt Stauffer: There you go, that's the way to do it. Reveal your secrets in the other language. Marcel Pociot: [laughs]. Yes. Marcel Pociot: But other than that-- favorite candy-- I'm mostly into some sour candy. Matt Stauffer: Like what? Marcel Pociot: Skittles in sour, they're pretty good. Matt Stauffer: Really? Skittle Sour-- I had no idea. Marcel Pociot: Yes. Matt Stauffer: All right, Skittle Sour, favorite candy. Marcel Pociot: How about you? Matt Stauffer: I ask this question to people all the time and I don't know if I know the answer. The first thing that came to my mind was Snickers. I think that I like candies with chocolate, and I think if it's chocolate plus some things that rounded it out, those are high in my list. I mean I really like Almond Joys, and Mounds as well. But I think Snickers is probably my top one. Marcel Pociot: We all like bread with Nutella, but is it really candy? Matt Stauffer: Yes, but I mean, it's basically candy. Marcel Pociot: Yes. [laughs]. Yes. Matt Stauffer: Yes. It's funny, my wife likes to put Nutella on sweet things. I'm like, "No, no, no, the Nutella is the sweet, I want it on bread or toast.", just plain piece of multi-grain bread, put some Nutella on top of it, good to go. Marcel Pociot: And peanut butter, and then you basically have Snickers. Matt Stauffer: Wait, do you put peanut butter and Nutella on the same thing? Marcel Pociot: Sure. That's literally Snickers, right? Matt Stauffer: Oh my god [whispers]. I had never thought of that. Alright last story and then I got to let you go. My dad worked for a German company when I was growing up, and he was the president of the US distributor of a German-based company. So he would fly over to Germany pretty frequently, and he would bring Levi's jeans and peanut butter to Germany, because it was hard for them to get, and he'd bring back German chocolate and Nutella, because it was hard for us to get. You can get Nutella in the grocery stores now, but back then you couldn't. And so, every time dad came home, we would get Nutella and we tried to keep these couple of jars of Nutella to last until the next time he went to Germany. Marcel Pociot: Okay. Next time I see you, can you get some Nutella? Matt Stauffer: Yes, I mean, we've got a lot of Nutella here, so you have to pick something up to trade with. Marcel Pociot: But not the German one. [laughs]. Matt Stauffer: Yes, it's true, it's true. All right, Marcel, this was a ton of fun talking to you. Thanks for taking some time. Thank you for BotMan, I'm seriously going to go distribute my son's podcasts using it. So you can expect me to bother you with requests for help sometime soon. Marcel Pociot: No problem. Thank you for inviting me. Matt Stauffer: How can people follow you? And, I guess, go start BotMan. What is following after you look like? Marcel Pociot: Well I think the easiest way to connect with me is on Twitter. Matt Stauffer: All right. I'll make sure your handle is linked to the show notes. Marcel Pociot: Okay. Or, if people want to talk about BotMan, I have the Slack team of BotMan where you can join, I think we're nearly 500 people in there. Matt Stauffer: All right, we'll link that in the show notes too. Got it. Marcel Pociot: Yes. Matt Stauffer: Cool. All right, well thanks for your time, was a pleasure talking to you. Until next time everyone. See you later. Marcel Pociot: Bye.

MJS 031: Mike Hostetler Today's episode is a My JavaScript Story with Mike Hostetler. Mike talked about his contributions to the JavaScript community. Listen to learn more about Mike! [00:50] – Introduction to Mike Hostetler Mike was on episode 133 which was like 2.5 years ago. [01:45] – How did you get into programming? First computer Mike got their first computer when he was 5 or 6 years old. 286 IBM Clone had a command prompt that he spent several years trying to figure out how to code with it until he stumbled on a few basic books at their local public library in junior high. He began teaching himself how to code with QBasic and Borland C++. He, then, found the internet early high school and downloaded the Mosaic browser. He started coding HTML and early JavaScript, late 90’s. Then, he went off to college to get a Computer Science degree. First job When Mike was late high school, he decided that he knew enough coding that he was going to try to get a job. He ended up finding web development companies in the phone book and calling each one of them, trying to explain that his 16-year-old self could help them code and build websites. He ended up landing a job and was paid minimum wage to build HTML sites - a lot of 1x1 pixels transparent gifs, coding HTML by hand and notepad. Then, he ended up working for that company for his first couple of years of college as well. [05:30] – How did you wind up doing JavaScript? After college, the job that Mike landed was spent on learning Microsoft technologies and then half on the open-source side of learning the LAMP stack. At that time, it required hand-coding JavaScript. His next role is building a custom mapping application which was a single page application that heavily relied upon JavaScript. This was client-side object-oriented. There were no frameworks but it was enough script to build a URL that called a custom CGI to render the map. So, he immediately jumped in and started using the early JavaScript frameworks and prototypes. The role that Mike was in next was building a touchscreen capable device. They needed custom plug-ins to provide the highlight focus effect around the button. He needed to write a plugin to do that and jQuery has just been released. So, he stripped all the prototype code, throw JQuery in there, and then, write a plug-in to navigate this interface by keyboard. [09:20] – Contributions with JavaScript jQuery Mike’s first participation was on the JQuery project. If you ever use the JQuery plug-ins site, the old site, that was his contribution. He ended up running infrastructure for JQuery for several years. JQuery launched his business career. He switched into an entrepreneur around 2009. Since then, he’s contributed in numerous ways through speaking, leading training, and writing articles. He was a co-author of the JQuery Cookbook. Node.js As Node began to get more popular, Mike switched his attention to Node and found passion around the Sails.js project. It was a Node framework that made it easy to build Express-powered apps with Node and limit a lot of the convention over configuration elements of the Sails framework. That morphed into ES6 rewrite of Sails called the Trails framework. Currently, he is an organizer of the Chicago Node.js Meetup and he’s a contributor to the Trails framework. [11:50] – JQuery challenges and experiences jQuery 1.4 Mike and the team made community’s problems their problems so the gravity of what they were working didn’t hit them very much until jQuery 1.4. They had an online conference. They all recorded talks and they’re releasing a talk a day for jQuery that will be going to accommodate the 1.4 release. He remembered that he was setting up, managing the servers, and was doing some last-minute configuration. Then, John had tweeted that 1.4 was ready, pointing to jQuery.com. The web server just ground to a halt as he saw the traffic come in off a tweet. Open-source community Mike remain friends with a lot of them. According to Mike, they were just normal people who made a choice to lean in, contribute, where those contributions ended up becoming popular. Looking forward, he said that he’s going to continue to contribute to the open-source community. He wants to help the junior developer that is learning ES6 for the first time and is solving a syntax error. From Mike’s perspective, technologies come in waves. jQuery was a wave but jQuery’s wave focuses its energy into JavaScript’s wave. Certain people catch a contribution wave. React is on the upswing. Node is in an interesting spot because they’ve been on the upswing for many years but there’s new work that could be done. He said that had a shot to be at the forefront of the wave and got to see it. Advice For anybody else that maybe listening, find a spot where there’s new ground that you can contribute to and just dive in and do what you can to solve a problem to make it better. You’ll catch your wave. [21:00] – How to pick frameworks Node frameworks There was a Reddit thread about Node frameworks in 2017 that listed out all the possible frameworks. The classic answer is to use the right tool for the right job but Mike’s answer is: Node has grown so big that different frameworks are built to different people on the learning curve of Node. The other thing that Node has done is they have this culture of really running away from any Monolithic one-size-fits-all solution. The community of Node has made sure that they make space for an incredible diversity of solutions and frameworks. Antipattern The anti-pattern is: what is the best framework of 2017. That’s the wrong question in the Node culture. Look at your team, look at your project, what framework can you be most productive in and what framework can you contribute back into the community with? That is one of the key reasons that Node itself has remained and continued to grow in popularity. [23:40] – Role in Sails and Trails Mike’s not contributing to the Sails project at the moment. He has been focusing on the Trails project. He has written a couple of Trails packs or the equivalent of plug-ins, messed around with GraphQL. He is also helping answer questions in the Gitter chat – small ways. [24:25] – Best ways to contribute Stack Overflow Go on to Stack Overflow. Subscribe to tags where you can answer questions. Every answer on Stack Overflow is a contribution. Go, watch, subscribe to the issue queues for the projects that you use. Just even sharing your experience with how you solve a problem, there is somebody that you could reach down to and answer their questions that take their burden off. Gitter Get involved in the Gitter chat. Listen, watch, stand on the sidelines, and see what’s going on how the community works. Pull request The next step, if you see a problem, submit a pull request, listen to see what the roadmap is, and see what you can contribute. Infrastructure A lot of projects need help in infrastructure in their build scripts to produce better-written code. You can document for them. If you wait for the next sexy thing to do, you’ll never get there. Be humble. Fun Remember that open-source is fun. If it becomes a drag, you are doing it wrong. Look for the opportunities that are aligned with what you do so it’s a fun, happy experience. [26:45] – What are you working on now? Raise Marketplace Currently, Mike is taking on a new role as Director of Front-end Engineering at Raise Marketplace. It is a marketplace start-up in Chicago. His focus is rebuilding the front-end of Raise on a micro service Node.js in Go service architecture. They have also been listed to help some folks at Google in the web performance team. They are always hiring. If you are looking for a remote role for a start-up. Feel free to reach out to him on Twitter or on Raise. ModernWeb Mike’s side-project now is a website called ModernWeb.com, where they help connect companies with teams of software developers and tell the stories of those software projects. A lot of developers are great at writing code but are terrible at telling the awesome things that we do. So, ModernWeb exists to tell the stories of development. The great side effect is companies want to work with you when you tell your stories. They help complete that circle. Go over to ModernWeb.com and you can contact them through the website or you can drop him an email at mike@modernweb.com. Picks Mike Hostetler App: OmniFocus App: Sleep Cycle App: Life Cycle Zapier Twitter: @mikehostetler Mike-hostetler.com Charles Max Wood Talk: Setting up and Contributing to Open-source Projects by Kent C. Dodds JavaScript Jabber Slack  

MJS 031: Mike Hostetler Today's episode is a My JavaScript Story with Mike Hostetler. Mike talked about his contributions to the JavaScript community. Listen to learn more about Mike! [00:50] – Introduction to Mike Hostetler Mike was on episode 133 which was like 2.5 years ago. [01:45] – How did you get into programming? First computer Mike got their first computer when he was 5 or 6 years old. 286 IBM Clone had a command prompt that he spent several years trying to figure out how to code with it until he stumbled on a few basic books at their local public library in junior high. He began teaching himself how to code with QBasic and Borland C++. He, then, found the internet early high school and downloaded the Mosaic browser. He started coding HTML and early JavaScript, late 90’s. Then, he went off to college to get a Computer Science degree. First job When Mike was late high school, he decided that he knew enough coding that he was going to try to get a job. He ended up finding web development companies in the phone book and calling each one of them, trying to explain that his 16-year-old self could help them code and build websites. He ended up landing a job and was paid minimum wage to build HTML sites - a lot of 1x1 pixels transparent gifs, coding HTML by hand and notepad. Then, he ended up working for that company for his first couple of years of college as well. [05:30] – How did you wind up doing JavaScript? After college, the job that Mike landed was spent on learning Microsoft technologies and then half on the open-source side of learning the LAMP stack. At that time, it required hand-coding JavaScript. His next role is building a custom mapping application which was a single page application that heavily relied upon JavaScript. This was client-side object-oriented. There were no frameworks but it was enough script to build a URL that called a custom CGI to render the map. So, he immediately jumped in and started using the early JavaScript frameworks and prototypes. The role that Mike was in next was building a touchscreen capable device. They needed custom plug-ins to provide the highlight focus effect around the button. He needed to write a plugin to do that and jQuery has just been released. So, he stripped all the prototype code, throw JQuery in there, and then, write a plug-in to navigate this interface by keyboard. [09:20] – Contributions with JavaScript jQuery Mike’s first participation was on the JQuery project. If you ever use the JQuery plug-ins site, the old site, that was his contribution. He ended up running infrastructure for JQuery for several years. JQuery launched his business career. He switched into an entrepreneur around 2009. Since then, he’s contributed in numerous ways through speaking, leading training, and writing articles. He was a co-author of the JQuery Cookbook. Node.js As Node began to get more popular, Mike switched his attention to Node and found passion around the Sails.js project. It was a Node framework that made it easy to build Express-powered apps with Node and limit a lot of the convention over configuration elements of the Sails framework. That morphed into ES6 rewrite of Sails called the Trails framework. Currently, he is an organizer of the Chicago Node.js Meetup and he’s a contributor to the Trails framework. [11:50] – JQuery challenges and experiences jQuery 1.4 Mike and the team made community’s problems their problems so the gravity of what they were working didn’t hit them very much until jQuery 1.4. They had an online conference. They all recorded talks and they’re releasing a talk a day for jQuery that will be going to accommodate the 1.4 release. He remembered that he was setting up, managing the servers, and was doing some last-minute configuration. Then, John had tweeted that 1.4 was ready, pointing to jQuery.com. The web server just ground to a halt as he saw the traffic come in off a tweet. Open-source community Mike remain friends with a lot of them. According to Mike, they were just normal people who made a choice to lean in, contribute, where those contributions ended up becoming popular. Looking forward, he said that he’s going to continue to contribute to the open-source community. He wants to help the junior developer that is learning ES6 for the first time and is solving a syntax error. From Mike’s perspective, technologies come in waves. jQuery was a wave but jQuery’s wave focuses its energy into JavaScript’s wave. Certain people catch a contribution wave. React is on the upswing. Node is in an interesting spot because they’ve been on the upswing for many years but there’s new work that could be done. He said that had a shot to be at the forefront of the wave and got to see it. Advice For anybody else that maybe listening, find a spot where there’s new ground that you can contribute to and just dive in and do what you can to solve a problem to make it better. You’ll catch your wave. [21:00] – How to pick frameworks Node frameworks There was a Reddit thread about Node frameworks in 2017 that listed out all the possible frameworks. The classic answer is to use the right tool for the right job but Mike’s answer is: Node has grown so big that different frameworks are built to different people on the learning curve of Node. The other thing that Node has done is they have this culture of really running away from any Monolithic one-size-fits-all solution. The community of Node has made sure that they make space for an incredible diversity of solutions and frameworks. Antipattern The anti-pattern is: what is the best framework of 2017. That’s the wrong question in the Node culture. Look at your team, look at your project, what framework can you be most productive in and what framework can you contribute back into the community with? That is one of the key reasons that Node itself has remained and continued to grow in popularity. [23:40] – Role in Sails and Trails Mike’s not contributing to the Sails project at the moment. He has been focusing on the Trails project. He has written a couple of Trails packs or the equivalent of plug-ins, messed around with GraphQL. He is also helping answer questions in the Gitter chat – small ways. [24:25] – Best ways to contribute Stack Overflow Go on to Stack Overflow. Subscribe to tags where you can answer questions. Every answer on Stack Overflow is a contribution. Go, watch, subscribe to the issue queues for the projects that you use. Just even sharing your experience with how you solve a problem, there is somebody that you could reach down to and answer their questions that take their burden off. Gitter Get involved in the Gitter chat. Listen, watch, stand on the sidelines, and see what’s going on how the community works. Pull request The next step, if you see a problem, submit a pull request, listen to see what the roadmap is, and see what you can contribute. Infrastructure A lot of projects need help in infrastructure in their build scripts to produce better-written code. You can document for them. If you wait for the next sexy thing to do, you’ll never get there. Be humble. Fun Remember that open-source is fun. If it becomes a drag, you are doing it wrong. Look for the opportunities that are aligned with what you do so it’s a fun, happy experience. [26:45] – What are you working on now? Raise Marketplace Currently, Mike is taking on a new role as Director of Front-end Engineering at Raise Marketplace. It is a marketplace start-up in Chicago. His focus is rebuilding the front-end of Raise on a micro service Node.js in Go service architecture. They have also been listed to help some folks at Google in the web performance team. They are always hiring. If you are looking for a remote role for a start-up. Feel free to reach out to him on Twitter or on Raise. ModernWeb Mike’s side-project now is a website called ModernWeb.com, where they help connect companies with teams of software developers and tell the stories of those software projects. A lot of developers are great at writing code but are terrible at telling the awesome things that we do. So, ModernWeb exists to tell the stories of development. The great side effect is companies want to work with you when you tell your stories. They help complete that circle. Go over to ModernWeb.com and you can contact them through the website or you can drop him an email at mike@modernweb.com. Picks Mike Hostetler App: OmniFocus App: Sleep Cycle App: Life Cycle Zapier Twitter: @mikehostetler Mike-hostetler.com Charles Max Wood Talk: Setting up and Contributing to Open-source Projects by Kent C. Dodds JavaScript Jabber Slack  

MJS 031: Mike Hostetler Today's episode is a My JavaScript Story with Mike Hostetler. Mike talked about his contributions to the JavaScript community. Listen to learn more about Mike! [00:50] – Introduction to Mike Hostetler Mike was on episode 133 which was like 2.5 years ago. [01:45] – How did you get into programming? First computer Mike got their first computer when he was 5 or 6 years old. 286 IBM Clone had a command prompt that he spent several years trying to figure out how to code with it until he stumbled on a few basic books at their local public library in junior high. He began teaching himself how to code with QBasic and Borland C++. He, then, found the internet early high school and downloaded the Mosaic browser. He started coding HTML and early JavaScript, late 90’s. Then, he went off to college to get a Computer Science degree. First job When Mike was late high school, he decided that he knew enough coding that he was going to try to get a job. He ended up finding web development companies in the phone book and calling each one of them, trying to explain that his 16-year-old self could help them code and build websites. He ended up landing a job and was paid minimum wage to build HTML sites - a lot of 1x1 pixels transparent gifs, coding HTML by hand and notepad. Then, he ended up working for that company for his first couple of years of college as well. [05:30] – How did you wind up doing JavaScript? After college, the job that Mike landed was spent on learning Microsoft technologies and then half on the open-source side of learning the LAMP stack. At that time, it required hand-coding JavaScript. His next role is building a custom mapping application which was a single page application that heavily relied upon JavaScript. This was client-side object-oriented. There were no frameworks but it was enough script to build a URL that called a custom CGI to render the map. So, he immediately jumped in and started using the early JavaScript frameworks and prototypes. The role that Mike was in next was building a touchscreen capable device. They needed custom plug-ins to provide the highlight focus effect around the button. He needed to write a plugin to do that and jQuery has just been released. So, he stripped all the prototype code, throw JQuery in there, and then, write a plug-in to navigate this interface by keyboard. [09:20] – Contributions with JavaScript jQuery Mike’s first participation was on the JQuery project. If you ever use the JQuery plug-ins site, the old site, that was his contribution. He ended up running infrastructure for JQuery for several years. JQuery launched his business career. He switched into an entrepreneur around 2009. Since then, he’s contributed in numerous ways through speaking, leading training, and writing articles. He was a co-author of the JQuery Cookbook. Node.js As Node began to get more popular, Mike switched his attention to Node and found passion around the Sails.js project. It was a Node framework that made it easy to build Express-powered apps with Node and limit a lot of the convention over configuration elements of the Sails framework. That morphed into ES6 rewrite of Sails called the Trails framework. Currently, he is an organizer of the Chicago Node.js Meetup and he’s a contributor to the Trails framework. [11:50] – JQuery challenges and experiences jQuery 1.4 Mike and the team made community’s problems their problems so the gravity of what they were working didn’t hit them very much until jQuery 1.4. They had an online conference. They all recorded talks and they’re releasing a talk a day for jQuery that will be going to accommodate the 1.4 release. He remembered that he was setting up, managing the servers, and was doing some last-minute configuration. Then, John had tweeted that 1.4 was ready, pointing to jQuery.com. The web server just ground to a halt as he saw the traffic come in off a tweet. Open-source community Mike remain friends with a lot of them. According to Mike, they were just normal people who made a choice to lean in, contribute, where those contributions ended up becoming popular. Looking forward, he said that he’s going to continue to contribute to the open-source community. He wants to help the junior developer that is learning ES6 for the first time and is solving a syntax error. From Mike’s perspective, technologies come in waves. jQuery was a wave but jQuery’s wave focuses its energy into JavaScript’s wave. Certain people catch a contribution wave. React is on the upswing. Node is in an interesting spot because they’ve been on the upswing for many years but there’s new work that could be done. He said that had a shot to be at the forefront of the wave and got to see it. Advice For anybody else that maybe listening, find a spot where there’s new ground that you can contribute to and just dive in and do what you can to solve a problem to make it better. You’ll catch your wave. [21:00] – How to pick frameworks Node frameworks There was a Reddit thread about Node frameworks in 2017 that listed out all the possible frameworks. The classic answer is to use the right tool for the right job but Mike’s answer is: Node has grown so big that different frameworks are built to different people on the learning curve of Node. The other thing that Node has done is they have this culture of really running away from any Monolithic one-size-fits-all solution. The community of Node has made sure that they make space for an incredible diversity of solutions and frameworks. Antipattern The anti-pattern is: what is the best framework of 2017. That’s the wrong question in the Node culture. Look at your team, look at your project, what framework can you be most productive in and what framework can you contribute back into the community with? That is one of the key reasons that Node itself has remained and continued to grow in popularity. [23:40] – Role in Sails and Trails Mike’s not contributing to the Sails project at the moment. He has been focusing on the Trails project. He has written a couple of Trails packs or the equivalent of plug-ins, messed around with GraphQL. He is also helping answer questions in the Gitter chat – small ways. [24:25] – Best ways to contribute Stack Overflow Go on to Stack Overflow. Subscribe to tags where you can answer questions. Every answer on Stack Overflow is a contribution. Go, watch, subscribe to the issue queues for the projects that you use. Just even sharing your experience with how you solve a problem, there is somebody that you could reach down to and answer their questions that take their burden off. Gitter Get involved in the Gitter chat. Listen, watch, stand on the sidelines, and see what’s going on how the community works. Pull request The next step, if you see a problem, submit a pull request, listen to see what the roadmap is, and see what you can contribute. Infrastructure A lot of projects need help in infrastructure in their build scripts to produce better-written code. You can document for them. If you wait for the next sexy thing to do, you’ll never get there. Be humble. Fun Remember that open-source is fun. If it becomes a drag, you are doing it wrong. Look for the opportunities that are aligned with what you do so it’s a fun, happy experience. [26:45] – What are you working on now? Raise Marketplace Currently, Mike is taking on a new role as Director of Front-end Engineering at Raise Marketplace. It is a marketplace start-up in Chicago. His focus is rebuilding the front-end of Raise on a micro service Node.js in Go service architecture. They have also been listed to help some folks at Google in the web performance team. They are always hiring. If you are looking for a remote role for a start-up. Feel free to reach out to him on Twitter or on Raise. ModernWeb Mike’s side-project now is a website called ModernWeb.com, where they help connect companies with teams of software developers and tell the stories of those software projects. A lot of developers are great at writing code but are terrible at telling the awesome things that we do. So, ModernWeb exists to tell the stories of development. The great side effect is companies want to work with you when you tell your stories. They help complete that circle. Go over to ModernWeb.com and you can contact them through the website or you can drop him an email at mike@modernweb.com. Picks Mike Hostetler App: OmniFocus App: Sleep Cycle App: Life Cycle Zapier Twitter: @mikehostetler Mike-hostetler.com Charles Max Wood Talk: Setting up and Contributing to Open-source Projects by Kent C. Dodds JavaScript Jabber Slack  

MRS O11 Greg Baugues This episode of My Ruby Story features Greg Baugues. Greg has been on two previous episodes, episode 142 where he discussed mental illness, and episode 258 where he discussed Twilio. Greg has been at Twilio for three and a half years. He worked on the developer/evangelism team for three years. A couple of months ago he became the lead developer of the community team. He lived in Chicago for eleven years, where he first started using Ruby. He moved to Brooklyn, New York a year ago. How did you get into programming? When he was five or six his parents owned a TRS-80 when he was five or six. It had a cassette drive and when turned on it booted into basic. He wrote programs in basic on this computer and it was an instant gratification to him. On a back cover of a magazine, he read there would be a code printed in basic that he would copy line by line. Later, his family bought a PC that had MS-DOS with QBasic, and his friends introduced him to Pascal, C, and C++. When he graduated high school he started PHP and got into web stuff. How did you get from PHP and web stuff to Ruby? In 1999 Greg used PHP to start a dot-com company with which they sold eight months later for all equity. He jokes that he “started and sold a company and all I got was a polo shirt out of it.”  This reinforced that he always wanted to work in programming but that he would never be happy just programming. He wanted to be involved working on the people side of things, too. He got a job at a consulting agency at Table XI where he was a sales guy. He claims that he wasn’t good at sales, so stopped programming for one and a half to two years in order to become better. Then he traveled with his wife in Europe for a while. This showed him that he spent his free time programming. After this he picked up Ruby for the first time. Ruby was his first language of choice because Table XI and most of Chicago was using Ruby at the time. He also fell in love with it. What was it about Ruby that you thought was cool? Greg finds Ruby beautiful and expressive. He believes that it makes more sense than for loop and believes that you can explain it to someone who’s never done coding before and it makes sense to them. Writing Ruby is the closest you can come to writing pseudo code that actually runs. Ruby doesn’t look much different from pseudo code. He thinks it is a joy to write in Ruby. What contributions do you feel like you’ve made to the Ruby community? Greg believes that his biggest contribution would be in the vein of mental health. He has Bipolar Disorder and was on a Ruby Rogues podcast where he spoke about it. Because of his disorder, he failed out of college, had trouble with relationships, getting out of bed, paying bills, and a lot of guilt. He finally got treatment in 2007 where medication slowly helped. Four years ago he had a coworker who overdosed that had been showing symptoms of the same disorder. The next day instead of doing a lightening talk he had scheduled about fantasy football, he gave a talk about mental illness and started giving talks about mental illnesses everywhere in the Ruby community. Charles tells Greg that he heard someone speak about him and said he’d decided to go get help and have a relationship with his family again. He said that Greg’s episode of the podcast had helped him, and others have emailed him about it too. He explains that changing the way someone lives is just as important as writing source code. Greg says that he has learned that we are not alone in this community. There is a value of sharing your story and being vulnerable. It is easy to underestimate the compassion and empathy people have in the Ruby community. What are you working on now? Greg just had a conference called Signal for Twilio two weeks ago. There were 2,000 developers and 100 speakers at the conference. He was part of the team that organized speakers. Two months ago he started a leadership role with the developer community team for the first time. He’s trying to learn how to be in a management role for the first time. There were a million developers that signed up for Twilio so he is trying to figure out how to organize a community of developers instead of just having customers. Picks Greg: Phil Nash: https://philna.sh/ The Manager’s Path by Camille Fournier: http://shop.oreilly.com/product/0636920056843.do The Tim Ferriss Podcast with Jamie Foxx: https://www.youtube.com/watch?v=YGnnEfmP8K4 The Ezra Klein Show: https://www.vox.com/ezra-klein-show-podcast Charles: Ruby Dev Summit: https://rubydevsummit.com/ Links: Email: gb@twilio.com Twilio Voices: https://www.twilio.com/docs/api/twiml/say Twitter: https://twitter.com/greggyb

MRS O11 Greg Baugues This episode of My Ruby Story features Greg Baugues. Greg has been on two previous episodes, episode 142 where he discussed mental illness, and episode 258 where he discussed Twilio. Greg has been at Twilio for three and a half years. He worked on the developer/evangelism team for three years. A couple of months ago he became the lead developer of the community team. He lived in Chicago for eleven years, where he first started using Ruby. He moved to Brooklyn, New York a year ago. How did you get into programming? When he was five or six his parents owned a TRS-80 when he was five or six. It had a cassette drive and when turned on it booted into basic. He wrote programs in basic on this computer and it was an instant gratification to him. On a back cover of a magazine, he read there would be a code printed in basic that he would copy line by line. Later, his family bought a PC that had MS-DOS with QBasic, and his friends introduced him to Pascal, C, and C++. When he graduated high school he started PHP and got into web stuff. How did you get from PHP and web stuff to Ruby? In 1999 Greg used PHP to start a dot-com company with which they sold eight months later for all equity. He jokes that he “started and sold a company and all I got was a polo shirt out of it.”  This reinforced that he always wanted to work in programming but that he would never be happy just programming. He wanted to be involved working on the people side of things, too. He got a job at a consulting agency at Table XI where he was a sales guy. He claims that he wasn’t good at sales, so stopped programming for one and a half to two years in order to become better. Then he traveled with his wife in Europe for a while. This showed him that he spent his free time programming. After this he picked up Ruby for the first time. Ruby was his first language of choice because Table XI and most of Chicago was using Ruby at the time. He also fell in love with it. What was it about Ruby that you thought was cool? Greg finds Ruby beautiful and expressive. He believes that it makes more sense than for loop and believes that you can explain it to someone who’s never done coding before and it makes sense to them. Writing Ruby is the closest you can come to writing pseudo code that actually runs. Ruby doesn’t look much different from pseudo code. He thinks it is a joy to write in Ruby. What contributions do you feel like you’ve made to the Ruby community? Greg believes that his biggest contribution would be in the vein of mental health. He has Bipolar Disorder and was on a Ruby Rogues podcast where he spoke about it. Because of his disorder, he failed out of college, had trouble with relationships, getting out of bed, paying bills, and a lot of guilt. He finally got treatment in 2007 where medication slowly helped. Four years ago he had a coworker who overdosed that had been showing symptoms of the same disorder. The next day instead of doing a lightening talk he had scheduled about fantasy football, he gave a talk about mental illness and started giving talks about mental illnesses everywhere in the Ruby community. Charles tells Greg that he heard someone speak about him and said he’d decided to go get help and have a relationship with his family again. He said that Greg’s episode of the podcast had helped him, and others have emailed him about it too. He explains that changing the way someone lives is just as important as writing source code. Greg says that he has learned that we are not alone in this community. There is a value of sharing your story and being vulnerable. It is easy to underestimate the compassion and empathy people have in the Ruby community. What are you working on now? Greg just had a conference called Signal for Twilio two weeks ago. There were 2,000 developers and 100 speakers at the conference. He was part of the team that organized speakers. Two months ago he started a leadership role with the developer community team for the first time. He’s trying to learn how to be in a management role for the first time. There were a million developers that signed up for Twilio so he is trying to figure out how to organize a community of developers instead of just having customers. Picks Greg: Phil Nash: https://philna.sh/ The Manager’s Path by Camille Fournier: http://shop.oreilly.com/product/0636920056843.do The Tim Ferriss Podcast with Jamie Foxx: https://www.youtube.com/watch?v=YGnnEfmP8K4 The Ezra Klein Show: https://www.vox.com/ezra-klein-show-podcast Charles: Ruby Dev Summit: https://rubydevsummit.com/ Links: Email: gb@twilio.com Twilio Voices: https://www.twilio.com/docs/api/twiml/say Twitter: https://twitter.com/greggyb

MRS O11 Greg Baugues This episode of My Ruby Story features Greg Baugues. Greg has been on two previous episodes, episode 142 where he discussed mental illness, and episode 258 where he discussed Twilio. Greg has been at Twilio for three and a half years. He worked on the developer/evangelism team for three years. A couple of months ago he became the lead developer of the community team. He lived in Chicago for eleven years, where he first started using Ruby. He moved to Brooklyn, New York a year ago. How did you get into programming? When he was five or six his parents owned a TRS-80 when he was five or six. It had a cassette drive and when turned on it booted into basic. He wrote programs in basic on this computer and it was an instant gratification to him. On a back cover of a magazine, he read there would be a code printed in basic that he would copy line by line. Later, his family bought a PC that had MS-DOS with QBasic, and his friends introduced him to Pascal, C, and C++. When he graduated high school he started PHP and got into web stuff. How did you get from PHP and web stuff to Ruby? In 1999 Greg used PHP to start a dot-com company with which they sold eight months later for all equity. He jokes that he “started and sold a company and all I got was a polo shirt out of it.”  This reinforced that he always wanted to work in programming but that he would never be happy just programming. He wanted to be involved working on the people side of things, too. He got a job at a consulting agency at Table XI where he was a sales guy. He claims that he wasn’t good at sales, so stopped programming for one and a half to two years in order to become better. Then he traveled with his wife in Europe for a while. This showed him that he spent his free time programming. After this he picked up Ruby for the first time. Ruby was his first language of choice because Table XI and most of Chicago was using Ruby at the time. He also fell in love with it. What was it about Ruby that you thought was cool? Greg finds Ruby beautiful and expressive. He believes that it makes more sense than for loop and believes that you can explain it to someone who’s never done coding before and it makes sense to them. Writing Ruby is the closest you can come to writing pseudo code that actually runs. Ruby doesn’t look much different from pseudo code. He thinks it is a joy to write in Ruby. What contributions do you feel like you’ve made to the Ruby community? Greg believes that his biggest contribution would be in the vein of mental health. He has Bipolar Disorder and was on a Ruby Rogues podcast where he spoke about it. Because of his disorder, he failed out of college, had trouble with relationships, getting out of bed, paying bills, and a lot of guilt. He finally got treatment in 2007 where medication slowly helped. Four years ago he had a coworker who overdosed that had been showing symptoms of the same disorder. The next day instead of doing a lightening talk he had scheduled about fantasy football, he gave a talk about mental illness and started giving talks about mental illnesses everywhere in the Ruby community. Charles tells Greg that he heard someone speak about him and said he’d decided to go get help and have a relationship with his family again. He said that Greg’s episode of the podcast had helped him, and others have emailed him about it too. He explains that changing the way someone lives is just as important as writing source code. Greg says that he has learned that we are not alone in this community. There is a value of sharing your story and being vulnerable. It is easy to underestimate the compassion and empathy people have in the Ruby community. What are you working on now? Greg just had a conference called Signal for Twilio two weeks ago. There were 2,000 developers and 100 speakers at the conference. He was part of the team that organized speakers. Two months ago he started a leadership role with the developer community team for the first time. He’s trying to learn how to be in a management role for the first time. There were a million developers that signed up for Twilio so he is trying to figure out how to organize a community of developers instead of just having customers. Picks Greg: Phil Nash: https://philna.sh/ The Manager’s Path by Camille Fournier: http://shop.oreilly.com/product/0636920056843.do The Tim Ferriss Podcast with Jamie Foxx: https://www.youtube.com/watch?v=YGnnEfmP8K4 The Ezra Klein Show: https://www.vox.com/ezra-klein-show-podcast Charles: Ruby Dev Summit: https://rubydevsummit.com/ Links: Email: gb@twilio.com Twilio Voices: https://www.twilio.com/docs/api/twiml/say Twitter: https://twitter.com/greggyb

My JS Story Justin Meyers On this week’s episode of My JS Story, Charles Max Wood interviews Justin Meyers Co­founder and CEO of Bitovi, a Javascript consulting firm focused on simplifying Javascript development through the use and creation of open source tools as well general consulting, training, and web applications. He was on Episode 202 and talked about DoneJS and CanJS. Tune in to hear Justin’s full story! 7th Grade and a TI­82 [3:02] Justin’s discovery of conditional statements and methods on a classic TI­82 was his first taste of programming. With a little guidance, he soon learned to program games on the TI­82 and then later moved onto bigger and better mediums like C and QBasic. Grunt work is good for you. [4:51] While studying Computer Science, Justin finds out that professors often have grunt work, and although they may not pay well now, sometimes they can in time lead to loads of experience and maybe even a bigger job. After 4 years of working on websites and writing documentation, he gets his first real job at Accenture. Open Source and reducing waste. [6:23] Accenture, while giving him a great chance to make some impressive projects, provoked Justin to see the efficiency in sharing code. Justin and a college friend get together to work on a project to build a platform that…builds. Although their project was unsuccessful, the tools they started to create for the project had plenty of potential. The Last desperate gasp. AKA shaving his head. [9:40] Justin talks about the Ajaxian blog and conference. Ten years ago, the Ajaxian blog was one of the best online resources for Javascript news. Justin was running low on funds and struggling and as his “last desperate gasp” he heads to the Ajaxian conference with his head shaved. Leaving only “Javascript MVC” shaped out of his hair. This stunt gets him remembered by many of the important attendees and also scores him his big break with a consulting job with T­-Mobile. Two to Three weeks later, Justin had a stroke. Justin talks about how incredible the timing was. How Javascript MVC came to be. [13:23] Justin talks about starting with JSJunction and modeling after it. Their first steps were to add a model layer as well as Event Delegation. Javascript MVC reflects some of Ruby on Rails. Justin worked with Peter Svensson from Dojo, with a methodology that at the time seemed crazy. Justin reminisces when Steve Jobs “Killed” Flash with HTML5 and CSS. Bitovi begins. [17:24] Justin talks about how the T­-Mobile job meant that he would need an official business. Originally dubbing it JupiterIT. Justin found that MVC was too encompassing and that programmers enjoyed a sense of creativity. By pulling Javascript MVC’s tools apart and creating single frameworks from the tools, Justin then created tools like CanJS and DoneJS. Who does the heavy lifting at Bitovi? [20:48] As the CEO of Bitovi, Justin has less time to program as before. Working with Open Source, development is a mix between contributors and full time employees. The majority being the employees. Justin talks about not having a sales force and focusing on their product to drive sales. Mainly, long term cost of ownership and the ability for the framework to last, working hard to make sure that clients that have committed to Javascript MVC years ago still have a relevant use for the framework. Exploring HTTP2 and Push. [23:42] With the emergence of HTTP2 and Push, Justin talks about working on and exploring different ways for streaming/server side rendering. Justin describes one of the experiments with building an empty skeletons, javascript assets, but also pushing instructions on how to mutate the page to the client. Before the javascript payload is fully loaded, the page starts to mutate. Allowing for optimal performance on slower connections, fantastic for mobile. Problems they are looking at for the future include things like different ways that CDNs can work with HTTP2 and Push. Justin has also worked with using Fetch to enable streaming by building tools around that. He suggests that HTTP2 and Push will maybe bring a renaissance in the developer world. Justin’s side Parsing Project. [28:45] Additional to his other work, Justin is working on a generic parsing project. Similar to BISON or JISON. Designed for simple parsing at faster speeds. He describes how to compiles to the code that parses your code. Working in runtime. A way other companies can learn from Bitovi. [29:52] We don’t know what the future is going to be for code, so packaging the framework into separate repos allows for better scheduling and a better way to manage long term. Updating a segment of a framework can sometimes break another segment if having it all happen together. Picks [34:26] Justin: Dean Radcliff’s Antares Framework Charles: Boom Beach Clash of Clans BlueTick.io Nimble Keeping up with Justin’s work. Bitovi.com’s Blog Justin’s Twitter. Sponsors Cachefly.com Newbie Remote Conf 2017

My JS Story Justin Meyers On this week’s episode of My JS Story, Charles Max Wood interviews Justin Meyers Co­founder and CEO of Bitovi, a Javascript consulting firm focused on simplifying Javascript development through the use and creation of open source tools as well general consulting, training, and web applications. He was on Episode 202 and talked about DoneJS and CanJS. Tune in to hear Justin’s full story! 7th Grade and a TI­82 [3:02] Justin’s discovery of conditional statements and methods on a classic TI­82 was his first taste of programming. With a little guidance, he soon learned to program games on the TI­82 and then later moved onto bigger and better mediums like C and QBasic. Grunt work is good for you. [4:51] While studying Computer Science, Justin finds out that professors often have grunt work, and although they may not pay well now, sometimes they can in time lead to loads of experience and maybe even a bigger job. After 4 years of working on websites and writing documentation, he gets his first real job at Accenture. Open Source and reducing waste. [6:23] Accenture, while giving him a great chance to make some impressive projects, provoked Justin to see the efficiency in sharing code. Justin and a college friend get together to work on a project to build a platform that…builds. Although their project was unsuccessful, the tools they started to create for the project had plenty of potential. The Last desperate gasp. AKA shaving his head. [9:40] Justin talks about the Ajaxian blog and conference. Ten years ago, the Ajaxian blog was one of the best online resources for Javascript news. Justin was running low on funds and struggling and as his “last desperate gasp” he heads to the Ajaxian conference with his head shaved. Leaving only “Javascript MVC” shaped out of his hair. This stunt gets him remembered by many of the important attendees and also scores him his big break with a consulting job with T­-Mobile. Two to Three weeks later, Justin had a stroke. Justin talks about how incredible the timing was. How Javascript MVC came to be. [13:23] Justin talks about starting with JSJunction and modeling after it. Their first steps were to add a model layer as well as Event Delegation. Javascript MVC reflects some of Ruby on Rails. Justin worked with Peter Svensson from Dojo, with a methodology that at the time seemed crazy. Justin reminisces when Steve Jobs “Killed” Flash with HTML5 and CSS. Bitovi begins. [17:24] Justin talks about how the T­-Mobile job meant that he would need an official business. Originally dubbing it JupiterIT. Justin found that MVC was too encompassing and that programmers enjoyed a sense of creativity. By pulling Javascript MVC’s tools apart and creating single frameworks from the tools, Justin then created tools like CanJS and DoneJS. Who does the heavy lifting at Bitovi? [20:48] As the CEO of Bitovi, Justin has less time to program as before. Working with Open Source, development is a mix between contributors and full time employees. The majority being the employees. Justin talks about not having a sales force and focusing on their product to drive sales. Mainly, long term cost of ownership and the ability for the framework to last, working hard to make sure that clients that have committed to Javascript MVC years ago still have a relevant use for the framework. Exploring HTTP2 and Push. [23:42] With the emergence of HTTP2 and Push, Justin talks about working on and exploring different ways for streaming/server side rendering. Justin describes one of the experiments with building an empty skeletons, javascript assets, but also pushing instructions on how to mutate the page to the client. Before the javascript payload is fully loaded, the page starts to mutate. Allowing for optimal performance on slower connections, fantastic for mobile. Problems they are looking at for the future include things like different ways that CDNs can work with HTTP2 and Push. Justin has also worked with using Fetch to enable streaming by building tools around that. He suggests that HTTP2 and Push will maybe bring a renaissance in the developer world. Justin’s side Parsing Project. [28:45] Additional to his other work, Justin is working on a generic parsing project. Similar to BISON or JISON. Designed for simple parsing at faster speeds. He describes how to compiles to the code that parses your code. Working in runtime. A way other companies can learn from Bitovi. [29:52] We don’t know what the future is going to be for code, so packaging the framework into separate repos allows for better scheduling and a better way to manage long term. Updating a segment of a framework can sometimes break another segment if having it all happen together. Picks [34:26] Justin: Dean Radcliff’s Antares Framework Charles: Boom Beach Clash of Clans BlueTick.io Nimble Keeping up with Justin’s work. Bitovi.com’s Blog Justin’s Twitter. Sponsors Cachefly.com Newbie Remote Conf 2017

My JS Story Justin Meyers On this week’s episode of My JS Story, Charles Max Wood interviews Justin Meyers Co­founder and CEO of Bitovi, a Javascript consulting firm focused on simplifying Javascript development through the use and creation of open source tools as well general consulting, training, and web applications. He was on Episode 202 and talked about DoneJS and CanJS. Tune in to hear Justin’s full story! 7th Grade and a TI­82 [3:02] Justin’s discovery of conditional statements and methods on a classic TI­82 was his first taste of programming. With a little guidance, he soon learned to program games on the TI­82 and then later moved onto bigger and better mediums like C and QBasic. Grunt work is good for you. [4:51] While studying Computer Science, Justin finds out that professors often have grunt work, and although they may not pay well now, sometimes they can in time lead to loads of experience and maybe even a bigger job. After 4 years of working on websites and writing documentation, he gets his first real job at Accenture. Open Source and reducing waste. [6:23] Accenture, while giving him a great chance to make some impressive projects, provoked Justin to see the efficiency in sharing code. Justin and a college friend get together to work on a project to build a platform that…builds. Although their project was unsuccessful, the tools they started to create for the project had plenty of potential. The Last desperate gasp. AKA shaving his head. [9:40] Justin talks about the Ajaxian blog and conference. Ten years ago, the Ajaxian blog was one of the best online resources for Javascript news. Justin was running low on funds and struggling and as his “last desperate gasp” he heads to the Ajaxian conference with his head shaved. Leaving only “Javascript MVC” shaped out of his hair. This stunt gets him remembered by many of the important attendees and also scores him his big break with a consulting job with T­-Mobile. Two to Three weeks later, Justin had a stroke. Justin talks about how incredible the timing was. How Javascript MVC came to be. [13:23] Justin talks about starting with JSJunction and modeling after it. Their first steps were to add a model layer as well as Event Delegation. Javascript MVC reflects some of Ruby on Rails. Justin worked with Peter Svensson from Dojo, with a methodology that at the time seemed crazy. Justin reminisces when Steve Jobs “Killed” Flash with HTML5 and CSS. Bitovi begins. [17:24] Justin talks about how the T­-Mobile job meant that he would need an official business. Originally dubbing it JupiterIT. Justin found that MVC was too encompassing and that programmers enjoyed a sense of creativity. By pulling Javascript MVC’s tools apart and creating single frameworks from the tools, Justin then created tools like CanJS and DoneJS. Who does the heavy lifting at Bitovi? [20:48] As the CEO of Bitovi, Justin has less time to program as before. Working with Open Source, development is a mix between contributors and full time employees. The majority being the employees. Justin talks about not having a sales force and focusing on their product to drive sales. Mainly, long term cost of ownership and the ability for the framework to last, working hard to make sure that clients that have committed to Javascript MVC years ago still have a relevant use for the framework. Exploring HTTP2 and Push. [23:42] With the emergence of HTTP2 and Push, Justin talks about working on and exploring different ways for streaming/server side rendering. Justin describes one of the experiments with building an empty skeletons, javascript assets, but also pushing instructions on how to mutate the page to the client. Before the javascript payload is fully loaded, the page starts to mutate. Allowing for optimal performance on slower connections, fantastic for mobile. Problems they are looking at for the future include things like different ways that CDNs can work with HTTP2 and Push. Justin has also worked with using Fetch to enable streaming by building tools around that. He suggests that HTTP2 and Push will maybe bring a renaissance in the developer world. Justin’s side Parsing Project. [28:45] Additional to his other work, Justin is working on a generic parsing project. Similar to BISON or JISON. Designed for simple parsing at faster speeds. He describes how to compiles to the code that parses your code. Working in runtime. A way other companies can learn from Bitovi. [29:52] We don’t know what the future is going to be for code, so packaging the framework into separate repos allows for better scheduling and a better way to manage long term. Updating a segment of a framework can sometimes break another segment if having it all happen together. Picks [34:26] Justin: Dean Radcliff’s Antares Framework Charles: Boom Beach Clash of Clans BlueTick.io Nimble Keeping up with Justin’s work. Bitovi.com’s Blog Justin’s Twitter. Sponsors Cachefly.com Newbie Remote Conf 2017

In a podcast far far away, you asked for it & this week we delivered. It’s code review time, with a twist! Plus the FUD seems strong with the second Oracle v Google trial, we attempting to do some busting, Dropbox falling back to reality & 30 years later why we still love QBasic.

Hoy hablamos con Isabel Cabezas, Evangelista Técnico de Microsoft. Te va a contar su experiencia y cómo consiguió, tras mucho esfuerzo, ser MVP (Most Valuable Person) en el año 2014 y posteriormente trabajar para Microsoft como Evangelista Técnico en el 2015. Hablaremos de tecnologías relacionadas con Windows y te daremos un montón de recursos gratuitos que ofrece Microsoft para estudiantes, starups, empresas e gente con ganas de aprender a programar.Recuerda que tenemos activa la encuesta para los oyentes. Cualquier duda nos la puedes hacer llegar a través del formulario de contacto, por Twitter y Facebook. La lista de distribución te está esperando, serás el primero en saber los temas que abordaremos las próximas semanas.Esta vez se nos ha ido un poco el tiempo y el capítulo dura más de lo normal, esperamos que no te importe, pero no podíamos cortar nada de lo que dice Isabel, es muy interesante. Es de Granada, su nombre completo es Isabel Cabezas Martín. Actualmente reside en Madrid, donde desempeña labores de Technical Evangelist (Evangelista Técnico) en Microsoft. La puedes encontrar en Twitter (@isabelcabezasm) y en Linkedin.Ella, como tantos otros, se inició en la programación con lenguajes com QBasic, Pascal, C y ActionScript, el lenguaje de Adobe Flash. Todo esto ocurrió a finales de los años 90, cuando la crisis de las .com interrumpían en la escena de Internet.Durante la primera década de este siglo se aficionó a la informática y, como muchos de nosotros, decidió convertir su afición en su profesión. Estudió Ingeniería Técnica de Informática en Granada (capital del mundo :) ), entre los años 2003 y 2006 y, como bien nos cuenta, no era una alumna aventaja ni destacada, pero si que muy activa y constante. Ya en la Universidad comenzó a moverse entre grupos de usuarios del desarrollo web con tecnologías Microsoft y, poco a poco, fue profundizando en la materia.Tras mucho esfuerzo y horas de dedicación le llegó el reconocimiento cuando, en el 2014, le otorgan el MVP de Microsoft por su aportación en el desarrollo web. Aunque ha trabajado para varias empresas como programador y analista programador, la oportunidad le llego, y comenzó a trabajar para una de las empresas tecnológicas más importantes del mundo, Microsoft. Por fin podría ver la fábrica de donde se nutría todo su aprendizaje. Es como entrar en la fábrica de chocolate de Willy Wonka.Todo este bagaje profesional tiene una palabra clave, constancia. Es un patrón que se repite en todo aquel que se quiere dedicar al mundo de la programación y tiene inquietudes tanto personales como profesionales.Pero no solo de programar vive el informático, Isabel también tiene otras aficiones, viajar, la astronomía, la fotografía, leer y la publicidad creativa. Los programadores también sabemos hacer otras cosas además de desarrollar software ;).Durante nuestra conversación hemos hablado de la paridad en el mundo informático y en Microsoft, la nueva tendencia de la compañía por el código abierto, herramientas y servicios gratuitos para aprender y formarse en las tecnologías de Microsoft, el futuro de WPF y por último hemos abordado el tema de Xamarin y Mono.Aquí te dejamos los enlaces que han salido en el pdocast:Trabajar en MicrosoftGitHub MicrosoftCodePlex.NET FoundationVisual StudioDream Spark para estudiantesBiz Spark para empresasPor no alargar más el podcast, esta semana no tendremos el famoso recurso del día, la próxima semana volveremos a la duración y normal y podrMuchas gracias a todos por los comentarios y valoraciones que nos hacéis en iVoox, iTunes y en Spreaker, nos dan mucho ánimo para seguir con este proyecto.

This week:From the lost annals of PAX East mayhem, we discover how to share Steam games. It involves QBasic, double-clicking digital cartridges, and all of the Titanfalls.Find us at:@DaliDimovski@TheMikeBachmann@TaylorBlissFollow the podcast: @JustTheTipShowMusic provided by:Rolemusic - The Journalist (Live)Goto80 - This Machine ThinksNeed a tip? Video game advice? Contact us at: JustTheTip@sidequesting.comSUBSCRIBE VIA iTUNES!

Was ist QBasic? "Basic" hört sich irgendwie einfach an... Warum war es mal so verbreitet? Das muss doch einen Grund haben... Und warum ist QBasic aus heutiger Sicht keine "richtige" Programmiersprache? Diese und andere Fragen beantwortet Euch die heutige Folge. Links: www.QBasic.de www.qb-wettbewerb.de www.lelie.de/markus