Guillaume Lemaitre: Probably the best onboarding path is if you have a chance that inside your local community there’s some people that do what we call first-time contribution to open source or coding sprints, go speak to those people, because they will help you to get on board. But then, if you are behind your computer and then you don’t know where to start, it’s where we have documentations that describe what do we call contribution… Because contribution is not only coding. It could be speaking, debugging, documenting, organizing sprints, and those type of things. And we have what we consider as contribution, and how you can help basically, and where you can help.

[00:45:47.16] Of course, the natural thing is to come and code, and then we explain you how to start with that. So this is on the documentation channels, the documentation webpage. And afterwards, everything is online and public. So there’s nothing private. We have different channels of communications. The main one is GitHub, and it’s going through the issue tracker, or the pull request, depending on which side you are… And the core developer will be, I would say, 24 hours over 24, because we are around the world. So if I’m sitting with somebody else, in Australia or in the US, that probably can just answer to you. And then we’ll just give you feedback. And it’s where your journey starts.

You should not be shy, and you should not be scared of making a mistake, because we are not judgmental. We all started by that stage of saying “I don’t know what I’m doing, and I need to ask people what should I do”, and that’s a normal step. And afterwards, you just grow with the community, and then the community brings you over.

But the most difficult thing is the first step, engaging and saying… So I have the imposter syndrome as well, but people say “I don’t want – I mean, those very skilled people, they will never want to speak to me.” And that’s not the case. So just come and just try your best, and then people will just communicate with you, for sure.

Justin Garrison: That collaboration piece I think is huge, because the way that I’ve learned, throughout my career, is just like working next to someone. And back at the data center I learned so much about resiliency. It was like “Yeah, you connect that cable to the switch over there, because if this one fails, and that power supply goes away–” And like being able to “Oh, that makes sense”, because we can figure out why and how these things are going to fail.

And infrastructure as code shifted me to an individual player game, where I just did asynchronous reviews and no one actually reviewed or ran my infrastructure as code. They’re just like “Yeah, it looks good to me. You’re past the lint, so we’re good.” But the feedback loop for learning how to do it was so much harder, because I had to copy and paste that other Jenkins file, to then go do it over here, because I don’t know how to start, I don’t want to write groovy. I don’t want to write Groovy. This is just a necessary evil.

One of the things that – the last time I was excited about an infrastructure diagramming tool was probably eight years ago. I don’t even remember what the product was called, but I remember reading their white paper… And they had this notion of being able to see the history of how the infrastructure has evolved, and being able to go backwards in time and say “What has changed here, and why did it change, or who made the change?” Do you see that as a view capability inside of System Initiative? Because you have these change sets, and you have this way to diff this stuff already… Could I zoom back to six months ago and see what it was like?

John Nunemaker: [51:54] Yeah. Yup. It is. And I love Justin. He got me back into indie stuff. I was completely out of indie. I was at GitHub, and even then, I left and did Box Out, but I was still not – I was not in the indie space, I was not doing other stuff on the side. And then I started listening to Megamaker and some of the other stuff he did, and I was like “Heck yeah.

Why am I not doing this? I should do this again.” So again, I’m like “I want to now have a podcast. I want to have my own.” So I think Garrett and I – we’re going to start our own Fireside podcast, and it’s going to be like… Maybe two. Maybe one is like the building of, and one is like “Here’s how to better –” We interview other podcasters and talk to them about their setup, what they do, what’s different, all that kind of stuff of like things that teach people how to start, or how to get better, or how to improve.

But then we also, the thing I’m passionate about, which you can hear when I’m talking about it - I’m passionate about the company side. I’m super-fascinated about, like you said, the hub and spoke, of like now we have like a nice chunk size business, that can be kind of like a starter… And it’s way easier to buy that than to build that. I’m building that with Flipper. Flipper’s like five figures; mid five figures. So you’re talking, again, partial work on it and stuff like that, but it’s not big. Fireside is like more like mid six figures. Box Out - seven figures, and stuff like that. So I’ve seen the ranges in there and stuff, and it’s way easier to acquire something than to start and build that from scratch. It just takes a long time, and also a lot of right decisions, and stuff like that.

So yeah, I think it can definitely be that kind of centerpiece. And you can’t have a podcast host and not have a podcast, right? You have to.

Daniel Whitenack: I guess on that front, maybe one of the big confusions that I’ve seen floating around these days is the kind of data that’s relevant to some of these workflows. So it might be easy for people to think about a labeled dataset for a text classification problem, . here’s this text coming in, I’m going to label it spam or not spam, or in some categories… But I think sometimes a sentiment that I’ve got very often is “Hey, our company has this big file store of documents.” And somehow I’m going to fine-tune, quote-unquote, a generative model with just this blob of documents, and then it will perform better for me. And there’s two elements of that that are kind of mushy. One is - well, to what end, for what task? What are you trying to do? And then also how you curate that data then really matters. Is this a sentiment that you all are seeing? Or how for this latest wave of models – how would you describe if a company has a bunch of documents, and they’re in this situation, they’re like “Hey, we know we have data, and we know that these models can get better… And maybe we could even create our own private model with our own domain of data.” What would you walk them through to explain where to start with that process, and how to start curating their data maybe in a less general way, but towards some end?

Adam Jacob: So there was a couple of those things happening. And then Red Hat, of course, happened. And I loved Red Hat, and they treated everyone so well in that era, really… And when Red Hat IPO’ed, they made a ton of people wealthy, and I was just like “Yeah, that’s the way. We should figure that out.” And it was obvious to me that it was important on a philosophical level, because it had made such an impact on my life. I had this career, I was making more money than any of my friends were… We were doing well, and that was all because of Linux, and it was all because of open source… That ISP that I was running Red Hat on - they loved me, because I had saved them tons of money.

And I think what evolved over time was that there was a – I love that strain of human goodness that lives inside of open source. I love that ethic of sharing, and that more is more. The pie can get bigger and then everyone can eat. That’s such an ingrained thing in me now. But yeah, it was very motivating and very, very real, and it felt achievable… But then you have to figure out how to do it, and so it was like – we tried to start a half a dozen businesses, and failed… But eventually, basically, those same guys that I worked for for a long time at Marchex… Marchex went public, and I had a pile of stock, and I hadn’t made any money (not meaningful money) from any of those companies I had worked for… And so they had IPO-ed, and my stock basically vested, and for the first time it was also above water. So I would have made - yuo know, not life-changing money, but meaningful money. It would have been life-changing at the time, because I didn’t have a savings account, because whatever, I was a kid and spending every dollar…

[00:40:32.24] But in order to sell my shares, I needed to get a signature from the chief legal officer. And there was this coterie of executives who had been doing this together this whole time, and they had all become fabulously wealthy… And so I went into their office and I was like “Hey, can you sign this piece of paper for me so I can finally sell these shares for my decade of dutiful service?” or whatever. And he was like “No.” And I was like “Well, but I don’t have any proprietary information about it. I don’t know any special secrets or whatever. Please, can you do this?” And he was like “No, because it would inconvenience me.” This is what he said. “It would inconvenience me, and our CEO, and all my friends.

So no.” And I was like “Just no?” He was like “Yeah, just no.” And so I picked up my piece of paper and I left their office and I walked out of the building and I called my best friend who had built that ASP with me in Arizona, and I was like “Hey man, you hate working for IBM. These people obviously don’t give a **** about me, you know? So we should start a consulting company. I’m done. I’ll go find us clients and pay your bills, so you don’t have to quit your job until I find us people who will pay us. But we’ll go build automation and we’ll build fully automated infrastructure for startups.”

And so I walked, and started a consulting company. And we started building fully automated infrastructure for startups.

And that became HJK Solutions. So me and [unintelligible 00:42:05.26] And then we added some more people, Barry Steinglass and a few others. And eventually, that became Chef.

But it was the same people dreaming about how do we figure out how to start a business, how do we figure out how to build a company that IPOs? How do we figure out how to do all of this? We wanted it, but we didn’t know how to get it, and so we just kept taking shots, you know?

Break: [00:42:34.25]

Philipp Burckhardt: So if they’d like to stop by, and if they just have questions for how to start contributing, for example, they can do that. And yeah, we’d just be very excited to see.

Anurag Goel: I mean, I have felt that pain many times myself. And AWS’es whole spiel is “Look, we’re going to give you these Legos, and we’re really good at building hardware, and data centers, and keeping machines up and running at all times, and then giving you these storage, networking and compute primitives that are really general-purpose, and then you have to cobble together what works for you on top.” And yes, AWS will give you a managed Kubernetes solution, but you still have to go learn Kubernetes. You still have to go figure out what a container, a pod, a deployment, a stateful set, a replica set, all of those things are… And really, when you’re trying to get started, you don’t have time for any of that. You don’t need to deal with any of that. So you have to make it really easy for people to be able to get started within minutes. So that’s what Render does at the start. So that’s the first part, where you can just connect your GitHub repo to Render, and we automatically detect and suggest even sort of how to build your app, how to start your application… And we spin it up. And a lot of people are able to go live within minutes from signup. And I think that has been incredibly powerful in terms of helping us grow. We now have well over a million developers on the platform. There’s over a million and a half applications running on the platform as well.

Whenever you make something easy to do, people do more of it. And so that’s the starting point. But the way we differentiate beyond that is even more important… Because when you think about the history, the evolution of platforms, Heroku was great when it started, 2005… 2007 was sort of when it publicly launched, and it made it so magical to deploy a Rails app… And that’s why it took off, and Rails was taking off around the same time, and all of that worked well.

But then, after its acquisition by Salesforce, development of the platform and adding functionality to the platform to allow applications and companies to continue to grow on Heroku - that stopped, and kind of slowed down to a crawl. And ultimately, Heroku got to a point where they just weren’t giving people what they wanted as their applications became more complex.

Neha Batra: And so if you just have one command center, and you’re able to send out what you need, and get back what you need without having to move, you’re able to stay a lot more focused and a lot more productive. So that’s like your IDE, that’s your editor. But then there’s also a lot of Copilot features that we’ve had in Copilot Enterprise on github.com, that I think are really interesting… And that’s the area that I have a lot of my team working on. So it is thinking about every single step of your developer workflow, and how do we lower the barrier and make it easier with AI.

For example, if you were opening up a pull request - which you could see some of that loading at the end of that demo - it will based on the commits, based on the files, and based on the code that you’ve changed, it’ll give you a suggestion for how to start your pull request message. That description of the body. And it’s a tiny thing, but every single time you open a pull request, you should probably describe what you did. Half of that can already be known, and AI can do that, and then you can take it from there. And if your team prefers screenshots of what you did with the before and after, or whatever, you can add that in. But it gets you started, and it does all of the monotonous work. So that’s where the beauty starts to come in.

Adam Jacob: Yeah, definitely. And I’m trying to write down – I’m in the middle of trying to write down how… What I’m starting to come to understand is that when we talk about these as problems, we tend to conflate what I call the open source hippie side of it, which is about principles and about the nature of software, and about how it impacts the lives of other people… All of which is incredibly important. And then we also conflate the business side of it, which is “How do you construct a business model that makes sense where the incentives stay aligned over a long period of time?” And when we conflate those two, we make it very difficult to talk about either one. And I think we’ve been conflating them sort of as an industry, certainly the whole time I’ve been around, which is – whatever, I’m 46. I started at 16, so I’ve been around long enough.

My suspicion is that we have to separate those two, and we have to start talking to people about “Here’s how you align the incentives of your business model over time, in order to use open source in a way that as you grow and you get to the MongoDB level or you get to the HashiCorp level or you get to the whatever level, those incentives don’t flip on you.” And that’s a business model construction problem. It’s a question of “Who’s my target market? What price do I sell it at? How does that impact my serviceable addressable market? [SAM] How do all of those things align, so that the price point of what I’m selling is high enough that I don’t need to eat my young, eventually?”

[20:12] And I think what we see in a lot of these things is that in fact that $0 price anchor that we’re setting when we typically do open source is a mistake. And it’s actually kind of easy to show, because the calculation for total addressable market [TAM] is the absolute number of people who could ever buy your product multiplied by the average selling price. And the trick we love to pull when we’re starting open source companies is we don’t count the zero. The $0 part in calculating the average – we don’t put that in the average. We only look at the part that we sell, and we go “What’s the average selling price for that?” But that’s not true. Obviously, the price actually starts with the – you have to factor in the numbers that are zero. And when you do that – suddenly, you watch the TAM shrink somewhat dramatically. Because the right-hand side there – the left-hand side of the equation is kind of fixed. The birth rate is what it is; there’s only so many people, there’s only so many companies, there’s a global, let’s call them 3000, 5000 companies that are going to buy your enterprise software. That’s kind of it. The right-hand side of the equation though, how much I sell it for – that’s in your control. And that’s what drives the difference between MongoDB and let’s call it Chef, where MongoDB is making 1.58 billion, or something like that… That sounds really specific, because I read it the other day; I think I’m right-ish… But they’re still growing like 30% year over year, on $1.5 billion… That’s a big company. That’s a big, healthy company. And that’s because the right hand side of that TAM equation is high. It’s not because they magically discovered more businesses to sell MongoDB to. It’s because the price they sell for MongoDB continues to go up. And it starts high. Stays high. But we don’t talk about that when we talk about open source and business, right? We talk about how you should relate to the community, we talk about all kinds of stuff, but we don’t talk about how to start the business side of it. So I’m starting to think about “How do I talk about the business side of it?” in a way that I can explain to people how the dynamics actually work.

Kris Brandow: Yeah, that’s one of the nice aspects of having seven of us that are panelists on this show, is that we can more easily kind of rotate through and spread it out. I think that is also why the show has had such good longevity over the years, is because we can kind of shift and move around the people who are hosting. And if you listener have noticed any of us disappear for a while, as Jon said - you know, sometimes life happens. Most of the time we do come back, which is always exciting. It’s always fun to be like “Ah, I’ve been gone for a while, but I’m back now! Hurray!”

But yeah, one of the big changes we’ve started making - we held our first one, we have our second one in the books, is that we’re doing - for a little kind of behind the scenes meta of how Go Time gets made - we’re doing writers’ rooms now, which is a thing borrowed from the television industry. We kind of all get together in a big meeting, we kind of brainstorm episode ideas, and kind of dispatch them for people to pick up and carry forward… Which I don’t know if there’s other podcasts that are doing something similar to this, but it’s definitely one of the things that’s excited me about this year, is that we actually started doing them… And the first one went so great, and we’re actually going to have another one. Because the first two are always the toughest to set the pattern of how to start doing things…

Dominik Klotz: But this is a journey, and I think when somebody would now ask me how to start, I would answer in a completely different way [unintelligible 00:35:07.03]

Mark Kurtz: So I’d say there’s two big trends right now. One is around the focus on post training. Our principal research scientist, Dan Alistarh - him along with his lab came up with this algorithm called OBC/OBQ, which we actually have a webinar which will have already aired by the time that this comes out… It’s airing tomorrow. But that algorithm specifically is where a lot of effort’s going around, which is requiring as little data as possible, and no retraining, and trying to increase sparsity as much as possible. So that’s one of the key things that people are trending down, is trying to do that.

The second one I would say is a large push around quantization in terms of getting to lower bits. And that’s something that’s been around for a while, but it’s something that’s becoming more and more prevalent as we’re looking at the larger models… Mainly because their execution time is mainly dominated by trying to pull in these large matrices of weights.

So there’s been a big push there now around trying to get down to – you know, pass int8 down to int4, int3, int2 quantization on these active representations. I’d say that’s the other trend.

The final kind of bonus trend that I’d throw in there, because I said two - the third one would be more research around sparse training. So specifically trying to figure out how to start with an unoptimized and untrained model, and be able to make it sparse from the start. And then [unintelligible 00:33:35.11] throughout training is generally what we do to guarantee accuracy. We’ll start from a dense converged model, and then iteratively print on top of that, which adds training time, right? So now there’s a lot of research going into trying to figure out how quickly the model can be pruned, and then be able to carry that over as it’s straining. So that’s where the other big piece is. And all three of these are definitely active areas that we’ve been investing heavily in, especially looking at the journey of AI space now, going through that.

V Körbes: [26:30] I think a good first step is to answer, you know, the W questions. So like who, what, why, when… And how doesn’t start with a W, but you know… This is basically a narrative structure. I think if you google “narrative structure”, you’re gonna come across how to start a story. This is the same thing if you’re writing a movie script, or a novel, or like any narrative structure is the same. So you need somebody, in a situation, with a problem. It’s always like that. You don’t need to tell the solution of the problem in your abstract. And often you shouldn’t, because it’s more interesting if we don’t know. But of course, the reviewing committee needs to know that you know what you’re talking about, so that they trust that you are going to deliver the solution.

But it’s a person, in a place, with a problem. And of course, the person doesn’t have to be a person; it can be a role, or it can be a profession, or anything like that. The place doesn’t have to be a place; it can be a situation, or anything like that. And the problem - once again, all those things are figurative. But if you think in terms of “There’s always someone, somewhere, with a problem.” Start from there and go from that starting point. If I read your abstract, and I know who is this for, what situation are they facing, and what’s their mindset about it, most times that tells me enough. So I would say that’s the first step.

I think a lot of people - they get too much into poetry when it comes to writing abstracts, which is like “Oh, if I make this sound perfect, if I channel my Shakespeare spirit here…” They focus too much on the words. And the fact is we don’t care about the words, but we care about the story. So if you tell me a compelling story, but your writing skills are terrible, that’s fine. We don’t want you to be a writer; you’re not here to replace Shakespeare and write the next great American novel, or whatever it is. It’s a story. It’s like someone, in a situation, with an interesting problem.

So if your writing skills are terrible, just give me a really interesting problem. I don’t care if you’re really bad at writing that problem down, but just give me an interesting problem. A problem I haven’t seen before, or a situation… Like, maybe it’s a silly problem that everybody faces it, but you’re facing that problem in a very unique situation. That makes it interesting. So it’s always the story. And the first thing Johnny said 10 minutes ago was “Well, it starts with a story.” And yes, it’s always the story.

Natalie Pistunovich: So another question to you both… When you adopt a project, and you kind of lay out your plan on how to start working with it, what are the steps and what are the important things that you lay out first for the purpose of long-term maintainability?

Michael Gearon: I couldn’t sum that better up. Like I said, CSS is probably, or definitely - I’m not gonna go with definitely, but I’m pretty sure it’s not gonna go away anytime soon. So I feel like I can be confident in saying “Yeah, you can pick up this book, you learn one of the three underlying principles of a website; you know, HTML, JavaScript, and then CSS.” And you should be able to get a little bit more the idea of how to start a web page, what’s going on, kind of understand that magic a little bit better. You kind of know what’s going on, rather than being that developer or that person who said, “Oh, can you make this change?” and you’re trying to hack it together. You can get a bit of a better idea of what is actually going on.

Jerod Santo: Josh Collinsworth knows how to start a flame war. Are you ready? Josh says, “React isn’t great at anything except being popular.”

Nick Nisi: The TED talk I think it’s called “How to start a movement.”

Natalie Pistunovich: So it’s interesting that you said that it was easy to get involved in and easy to contribute to. That sounds like a fun place for starters. Can you tell a little bit more about this for people who want to get involved and are not sure how to start, what to start, what makes starting easy…?

Woody Zuill: Yeah. I listened to a podcast that you did with Jessica, and I think she mentioned Leonard Freeden in Sweden. And I’ve talked with him quite a bit about these things. He was one of the earliest adopters of this concept. As a matter of fact, the earliest teams outside of the US that were doing this, that I know of, were in Sweden. Somebody in Sweden saw a recording of me or read a blog post that I wrote and they started experimenting with it, I think, in the latter part of 2012. So they were already doing it. I saw them post a conference talk, a 17-minute talk about mob programming, and I was surprised. And I looked at what they were doing; I couldn’t understand Swedish, but I kind of saw they were talking about what we were doing. I think they even had a picture of me in there, which of course, made me feel like they’re either making fun of me or they’re actually honoring me.

So I got to know them, and an interesting thing happened… Somebody who was at that conference and watched their talk wrote a blog post in English - somebody in Sweden - and in there somewhere, they said this: “I’ve never tried this. I think we’d better try this.” That is like a big step. But most people say, “That won’t work.”

Now, I learned this lesson – before I heard about pair programming, I learned this lesson when I was a bit younger than that. If somebody I respect says “This is worth doing”, I don’t question it. If they say it’s worth doing, then I’m going to do it. As soon as I get exposed to pair programming, I said, “I’m going to learn how to do this well enough to make a decision as to whether I should do it or not.” I think that is a way to work and think that’s well worth trying. Most people who’ve tried pair programming or test-driven development and they quit, they’ve only done it for a very short amount of time.

So Leonard had this technique where if he’s brought in to help a team, he would set up their work area for mob programming. There’s kind of good ways to make it comfortable. It’s got to be comfortable. If it’s not comfortable, you won’t do it for very long. You’ve got to be spread out a little bit. You can’t all be huddled around the computer. You spread out. So you want more than one keyboard; maybe two or three keyboards. So you set up an environment where it’s easy to work together. But then he would set up a second work area that would be empty. I hope you can see what he’s setting this up for. People would come by, notice the teams working as a team, and ask about it. And he would say, “Well, why don’t you just join us for a little while? You’ll see how it works.”

After a while, they’ll come by someday and they’ll say, “My team wants to try this. We noticed that it’s empty over there. Can we use that space? So he’s created a space - this is just brilliant - where they can be drawn into it. They’re not hidden away doing it. They’re in the open and they have an empty space for you to come try it. Now, that’s a nice thing.

I knew another guy who was a coach who said he would show the video– “We have a video of us working back in 2012 of us mob programming”, and he would show it and say, “Look at this. It’s crazy.” He said, “Nobody would do this. This is ridiculous.” So the team would look at it and they’d talk about it, and he’d say “It looks like a fun thing to try. Can we set aside some time to try this, more as a fun experience?” So he kind of draws them in by saying, “Look at this. It must be crazy.” I don’t think he’s actually being deceptive, because it looks crazy. When we posted this first on YouTube in 2012, this three-minute time-lapse video, most of the comments were, “This looks like the worst way in the world to work.” And so I would respond to them and just say, “Yeah, it does, doesn’t it? It seems crazy.”

[52:09] There’s a famous quote that’s attributed to Einstein where he said, “If at first an idea doesn’t seem absurd, it’s probably not a good idea.” If that’s true, then I think we hit the jackpot. This just seems preposterous. How could this possibly work? But now, again, I know hundreds and hundreds of teams that are actually doing this in their daily work. And dozens and dozens of companies, going from the very tiniest to a couple of the really big financial firms with thousands of programmers who have lots of teams… And in all their training, they now train mob programming for new team members. So yeah, there’s a lot – from the smallest companies to the biggest, people working this way. So that didn’t really tell you how to start, but that’s kind of you’re giving it a little bit about–

Zac Smith: So there’s usually a story about how everybody gets into this industry. Mine happened to be I was a Juilliard grad, I went to school for classical music, and like most classical musicians, I needed a real job… [laughs] So just after I left school, I ended up working at a bank, and I was working the 6 PM to 4 AM night shift, doing PowerPoint work… And I had a lot of free time, because the bankers wouldn’t usually come around; and I had access to the internet, but not much else. And I couldn’t leave. So I started thinking about how to start a business, and a family friend of mine, a guy by the name of John LaRue. He was the only guy I’d known who had ever started a business. My parents were in construction, education, things like that, so I didn’t know much about starting a business, but I thought “Okay, I’ll call John…” He had started a telecom company in the ‘90s, when that was deregulated… And I said “Hey, John, should I get into the phone business?” and he’s like “Absolutely not. It’s a terrible business. But you should get into the recurring revenue business. Something where if you sell once and you treat people well, the customers will keep paying you every month.” I said “What could that be?”, so I started reselling hosting to all of my musician friends. I started to put up homepages; everybody needed a homepage.

Daniel Whitenack: Maybe it is worthwhile for our listeners to kind of talk a little bit – I’m sort of taking note that conferences are happening again, and at least in a hybrid sense; of course, virtual conferences happened through COVID times, but normal conferences are happening again, and maybe it would be worth for our listeners to just kind of talk through a bit of the landscape of conferences… Because occasionally, I get questions about, “Hey, I’m starting my interest in AI” or “Our team is working in AI, and we’ve done some cool things.” I’d like to disseminate that somehow to the community, “How do I do that?” So some teams are getting into this, they don’t know what conferences there are, and how to start involving themselves in that community…

So yeah, one thing to note is that there’s sort of research-focused conferences that are primarily involving academics, although industry researchers as well from groups like Google or other places. And then there are kind of industry conferences — well, they used to have O’Reilly AI, but—

Amal Hussein: Yeah, how to start a blog site, or what Babel transform are you missing, ma’am who has yet to know what even JavaScript is, or something… Like, it’s crazy. So yeah, I know, the barrier to entry is very real.

I think we’ve kind of skirted around a bunch of things on this site, so can I – just for the sake of it… In your own words, what is this project about, what were the goals…? And then we are gonna take a break after that, because there’s so much to dig into, I think, off of that discussion. So… Close this out, Rachel Nabors.

Gerhard Lazu: So I hear a lot of tooling, different names… For someone just wanting to get started, what would you recommend? Which is the best way of getting started, to understand wha they are, how they fit together, how to start using all these tools?

Marwan Sulaiman: Yes. Ashley at some point tweeted about how to start learning - for beginners, how to start learning programming - and I made the suggestion and said “I did a coding bootcamp and it worked out for me”, and it kind of turned into complete opposite opinions. Some people said it was the worst, some people said it was the best.

I think it’s totally true. Some people have had terrible luck, and I am one of the very lucky people that ended up enjoying it, and it kind of worked out. I honestly don’t have a scientific answer to why. All I did is really try my best to learn as much as possible about the bootcamp, because I did hear in the beginning a lot of companies don’t trust them, they don’t know how much you know… There’s all sorts of preconceptions about that, so really I just think I lucked out.