Mintbean and Fullstack Education with Monarch Wadia
Monarch Wadia discusses Mint Bean's apprenticeship program for new developers, programming language evolution, and why fullstack JS frameworks echo Rails' best ideas.
Episode Description
Monarch Wadia discusses Mint Bean's apprenticeship program for new developers, the evolution of programming languages, and why full stack JavaScript frameworks echo Ruby on Rails' best ideas.
Episode Summary
In this episode of the Full Stack Jamstack podcast, Monarch Wadia, founder of Mint Bean (Midtbyen), joins hosts Anthony Campolo and Christopher Burns to discuss his mission of bridging the gap between new developers and their first professional opportunities. The conversation opens with reflections on nontraditional paths into software development, with Monarch sharing how he transitioned from a finance degree during the 2008 financial crisis into a self-taught programming career spanning Java, JavaScript, Rails, and numerous modern frameworks. The discussion moves into how Mint Bean operates — through hackathons, mentorship, and a newly launched apprenticeship program that pairs junior developers with real production projects funded by sponsor companies like Feature Peak and Edgio. A spirited debate about bootcamps versus traditional university education surfaces tensions around practical skills versus theoretical foundations like algorithmic complexity. The hosts then trace the evolution of programming languages from assembly through C, Java, and JavaScript, with Monarch arguing that developer experience and understandability have become the primary selection criteria for language adoption now that CPU power is abundant. This leads into enthusiasm for convention-based full stack JavaScript frameworks like Redwood, which Monarch sees as recapturing the philosophy that made Ruby on Rails transformative. The episode closes with thoughts on TypeScript's trade-offs, specialist versus generalist career paths, and Conway's Law shaping developer identity.
Chapters
00:00:00 - Nontraditional Paths Into Development
The episode kicks off with Monarch Wadia reflecting on a recent interview with a developer who pivoted from Arab studies to software development, using it as a springboard to discuss the diversity of backgrounds entering the field. He shares examples of people he has hired — from neuroscience PhDs to Japanese translators to fine arts designers — emphasizing that fresh perspectives enrich the software industry.
Anthony picks up the thread, arguing that the nontraditional background has essentially become the norm, since JavaScript is rarely taught in university computer science programs. Even CS graduates are often self-taught in the practical technologies they use professionally, while people from unrelated fields frequently pick up scripting through their own discipline's data analysis needs.
00:02:34 - Monarch and Anthony's Origin Stories
Monarch describes his own nontraditional journey, graduating with a finance degree right as the 2008 financial crisis made that field nearly impossible to break into. With no mentorship and a borrowed Java textbook, he taught himself to code through relentless daily study while managing retail stores, eventually building a career as a software architect across numerous frameworks and languages.
Anthony shares his parallel path, explaining that he was a music teacher and summer camp director before entering Lambda School's bootcamp program. He discusses the structure of Lambda's curriculum — HTML/CSS, React, Node, and computer science fundamentals — and the challenge of balancing work and learning. The two bond over their shared experience of grinding through self-directed technical education while holding down other jobs.
00:08:12 - Mint Bean's Mission and Programs
The conversation shifts to Mint Bean (Midtbyen), which Monarch describes as a bridge for developers breaking into the industry. He explains that the organization runs hackathons where participants build projects in teams of one to three within a week, developing both hard skills and professional networks simultaneously.
Monarch details how hackathons serve as a pipeline to identify standout developers who then receive mentorship, career coaching, and ultimately placement in the apprenticeship program. He describes the recently launched apprenticeship system, where junior developers get paid positions working on real production code under senior guidance, with their first apprentice placed at a fintech company called Edgio working on trucking industry invoicing software.
00:14:32 - Bootcamps, Universities, and the Future of Developer Education
A lively debate unfolds about the merits of bootcamps versus traditional four-year degrees. Monarch declares himself a strong bootcamp supporter, arguing that universities are already following the bootcamp model with shorter programs. Christopher offers a UK university perspective, noting that professors always emphasized teaching programming philosophy over specific languages.
Anthony pushes back thoughtfully, suggesting the ideal path would combine both — a four-year degree for theoretical depth in areas like algorithmic complexity followed by a bootcamp for practical skills. Christopher counters that neither approach effectively teaches the most essential skill: encountering a problem and finding the fastest, most resource-efficient solution. The group also discusses gaps in Lambda's curriculum around fundamental web APIs and the importance of learning to read documentation.
00:19:10 - The Real Value of Universities and Mint Bean's Apprenticeship Model
Christopher points out that UK universities derive much of their revenue not from tuition but from PhD departments solving complex problems for corporations and governments. Monarch builds on this, arguing that what software development lacks compared to academia is deep, decades-long expertise — and that Mint Bean aims to fill that gap on the practical side.
He explains the apprenticeship model in more detail: developers who demonstrate grit and ability through hackathons are invited to work on real production projects sponsored by companies. The value proposition for sponsors is access to senior architectural guidance combined with eager junior talent at a fraction of typical consulting rates, creating a mutually beneficial arrangement that gives new developers the production experience they desperately need.
00:23:00 - Sponsors, Feature Peak, and Programming Language Tangents
Monarch highlights Mint Bean's key sponsors, particularly Feature Peak, a tool enabling designers, product managers, and developers to collaborate on front-end deployments without being co-located. Anthony recognizes the company from a Software Engineering Daily interview, and the two discuss its Dockerized Golang stack.
This leads into a freewheeling tangent about programming languages — Go as a potential Java replacement, Rust's borrow checker as an adoption hurdle, the ML language family's influence on Rust, and the distinction between functional and object-oriented paradigms. Monarch compares Go to Muay Thai for its minimal but effective feature set, while Anthony reveals he is learning memory management for the first time through Rust, which Monarch advises against in favor of plain C.
00:27:19 - The Evolution of Languages and Why Full Stack Jamstack Matters
Monarch delivers an extended argument about programming language evolution, tracing the arc from assembly through C, Java, and JavaScript. He contends that as Moore's Law rendered CPU power largely irrelevant for most developers, the primary selection criterion for languages shifted to understandability and ease of use — how quickly you can teach someone a framework or language.
He argues that Ruby on Rails represented a peak of developer-friendly convention-based design, which JavaScript disrupted for a decade with constant tooling churn — Webpack, Bower, Gulp, Grunt, and eventually TypeScript. Full stack Jamstack frameworks like Redwood represent a return to Rails' convention-based philosophy in the JavaScript ecosystem, which Monarch believes has massive implications for developer education and bootcamp accessibility.
00:35:52 - Is Full Stack Jamstack Ready for Production?
Christopher raises the provocative question of whether full stack Jamstack frameworks are ready for mass adoption. He shares his own struggles with serverless cold starts during payment processing and describes having to run Redwood on PM2 with an Ubuntu droplet — a path that gets complex quickly for developers unfamiliar with Linux server administration.
Monarch counters that readiness depends on how you define the category, noting that Next.js could be considered part of the movement. Anthony draws a sharp distinction, arguing that the absence of an integrated database layer is what makes newer frameworks like Redwood genuinely novel. The discussion touches on architecting reliable serverless applications and how different developer personalities approach problem-solving — bootstrappers who fix things pragmatically versus those who prefer philosophical, cathedral-style approaches.
00:40:10 - Conway's Law, Developer Identity, and Specialist vs. Generalist
The conversation turns to Conway's Law — the idea that software structures mirror the communication patterns of the organizations that build them. Monarch extends this principle to individual developer careers, arguing that your working style and team preferences inevitably shape the kind of developer you become, just as his own trajectory shifted after joining a company with collaborative practices.
Christopher asks what Mint Bean teaches its apprentices to be — generalists who can do everything or specialists focused on specific domains. Monarch resists making that choice for developers, instead advocating for observing their natural inclinations and guiding them accordingly. He gives examples of steering solo-minded developers toward monolithic frameworks and enterprise-oriented developers toward Java or C#, emphasizing that the developer's own interests should drive their path.
00:44:22 - JavaScript, TypeScript, and Closing Thoughts
Christopher humorously declares his loyalty to JavaScript as the one language that does everything, which Monarch likens to a pidgin language — borrowing from everywhere and becoming surprisingly expressive. The group debates TypeScript's value, with Anthony praising it for large team projects, Christopher appreciating its IntelliSense but noting the burden it places on library creators, and Monarch describing his strategy of isolating untyped dependencies.
Monarch closes by pitching Mint Bean's sponsorship model one final time, explaining how companies benefit from senior guidance at junior rates while helping new developers gain crucial production experience. He shares that developers entering the program have reached intermediate skill levels within six months thanks to real-world project exposure, and invites listeners to connect with him on LinkedIn or Twitter to learn more about supporting the mission.
Transcript
00:00:00 - Monarch Wadia
Yeah, it's unfortunate because Borat just came out again, and I'm never going to live it down, am I? He's from the Republic of Wadiya, I think.
00:00:08 - Anthony Campolo
Yeah. I remember my dad thought that the first Borat movie was the funniest movie he'd ever seen in his entire life.
00:00:24 - Monarch Wadia
I interviewed a developer just recently. He's Arab. He's American, though, and being of Arab descent, he was always fascinated by Arab perspectives on Arab culture. You don't always get that in the English-speaking world.
So his Ph.D., his thesis, was basically Arab studies and the perspective of Arab people from their own internal point of view. He wanted to publish that stuff. But before he could get there, he decided he had a change of heart and decided to get into dev.
Somebody coming in with a master's degree in arts, a minority background, a nontraditional background, trying to get into development. And you know me. I've hired people who had PhDs in neuroscience. I've had people who did seven years as a Japanese translator before coming into development. I've hired people who came in from a fine arts background as designers, and they wanted to become developers.
It's always just really interesting, the stories you hear when you're dealing with people who are not geeks in the traditional sense, who are coming in with a different perspective.
I can safely say we need a lot more perspective in software dev.
00:01:32 - Anthony Campolo
Yeah, I think it's really interesting because once I started to listen to a lot of podcasts and hear a lot of different developers tell their story, I realized that the nontraditional background is becoming the traditional background.
If you think about it, they don't teach JavaScript in college. Essentially everyone has taught themselves JavaScript or learned it in a bootcamp. Even the people who are going through computer science degrees are still not necessarily learning how to build projects. Or people who are in a non-CS degree are doing some sort of statistical analysis of random biochemistry stuff. They learn R and they can script like nobody's business.
So it's really interesting to see how all these people come in from these different areas and perspectives. On that note, I'd love to get your background. Monarch Wadia, thank you for joining us for the Full Stack Jamstack podcast. You are the owner of a company called Midtbyen, which we're going to get into, and you are a programmer yourself.
Tell us a little about yourself, your background, and how you got here.
00:02:37 - Monarch Wadia
Yeah, for sure. A long time ago, I was also nontraditional. I did my undergrad in finance, and this was just around the time when the entire world collapsed financially in 2008. Yeah, 2008 to 2012, that was around the period when I graduated.
I had all the perspective in the world about how the economy collapsed, how it worked, subprime debt, all of that. When they started doing documentaries, I was like, yeah, I know this stuff. But when I graduated, it was a really, really, really bad year to graduate in finance because nobody was hiring. It's like the dot-com bubble. Nobody's hiring developers after that.
I had a long-term dream to make my own video game. I decided, well, I'm managing a few retail stores, not really paying any rent, paying my own bills, living with my parents. Might as well spend some time and learn how to code. So I picked up a Java reference book, fourth edition.
It was already like four or five years out of date at that point.
00:03:41 - Anthony Campolo
Why Java?
00:03:42 - Monarch Wadia
Honestly, I just needed to start somewhere. I didn't know where to start, so I picked up Java. A friend had a Java book. I didn't know any better. I didn't have any mentorship. She was a database person, not a Java person.
I picked up Java. That book was like this thick. It's almost 2000 pages, a few pounds in weight. And I paced through it, cover to cover. And that's how I taught myself how to program.
I would get up in the morning, 6:00 in the morning. I'd get up, I'd start reading, learning, coding, go to work, come back in the evening, another two, three hours at night, just coding and reading and coding and reading.
One thing led to another. I started doing very lightweight freelance gigs at a very low rate. I was charging under minimum wage at that point. One thing kind of led to another. Now, almost ten years later, I've been a software architect for large companies doing their Angular and React UI projects.
All said and done, I've worked with more than 100 developers, giving them technical advice and guidance. I've worked on Java, JavaScript, Rails, Python. I've worked on React, Angular, Vue, Backbone in production. All this is in production. I'm not even counting the stuff that I've played around with. I won't even count FSJam because I haven't used it in production yet.
Back then it was hard getting into it. But yeah, I'm really happy that I made the switch. So that's kind of a nutshell of how I got into programming.
00:05:07 - Anthony Campolo
That's a super awesome story, especially for someone like me. What you just described of working, coding, working, coding, that's where I am. The progression of technologies you've worked on is really incredible. It sounds like you've seen essentially the entire evolution of JavaScript over the last decade.
00:05:23 - Monarch Wadia
What are you working on? Where do you work? What do you do?
00:05:26 - Anthony Campolo
Well, I'm a bootcamp student, so I'm in Lambda School right now, doing remote learning. I'm like two-thirds of the way through that program. I've done the whole web development part, which is four months, or eight if you're part time.
You do HTML, CSS, JavaScript for a month, then you do React for two months, and then you do Node back end for a month. So I'm finishing up that right now. Then we have a month of computer science, Python, data structures, algorithms type stuff. Then we have kind of an internship type thing that comes after that.
It's been really great. It's been a struggle, just learning to code in general, having work at the same time, and balancing a lot of different stuff. You definitely have to really think about how you spend your time, spend your money, spend your attention.
00:06:18 - Monarch Wadia
And what's your professional background before you got into coding?
00:06:22 - Anthony Campolo
I was originally a music teacher. I got my degree in instrumental music education, and I spent a year teaching high school band and wasn't really that into it. Then I spent four years running a performing arts summer camp.
I got a pretty good taste of running a business. I was doing the admin work, really heavy logistical, high stakes type work. Some people enjoy that work, and I wanted something a little more creative. I found my way to programming. I've always been into computers my whole life, but never quite made it over that hump into coding.
I always say we're the Oregon Trail generation, right in between social media on one end and actually working with a terminal, DOS kind of thing, on the other end. We're kind of in that middle between the two. It's funny, I used Neopets, I used Myspace, I used all of these things that all these other people learn to code with. I never made it to any of the coding sections on those websites, so I didn't start coding until I was like 27.
So yeah, I've been learning for a couple of years now. I originally wanted to do data science because I was into machine learning and natural language processing. I learned Python for a while and then eventually was like, all right, the JavaScript thing seems to be the thing to do. If I'm actually just trying to get a job as quick as possible, get out there, it's like JavaScript is the thing to do.
I don't have the job yet. But in terms of opportunity and things like Redwood, learning JavaScript and React especially was definitely the right bet.
00:07:46 - Monarch Wadia
Dude. Yeah, I think you made the right jump. Speaking with you, just getting a feel for you. I work with a lot of bootcamp devs, and just getting a feel for the kind of person you seem to be at first glance, I think it suits your personality.
If you have that curiosity and that drive, 100%. That's what I got into it for. I didn't want to manage stores and deal with customers and paperwork and inventory counts and all that. I wanted something creative.
00:08:12 - Anthony Campolo
I've actually gotten to work a little bit with Mint Bean. You've given me the opportunity to give a couple talks at Mint Bean. I've really enjoyed them. They've been really fantastic.
Mint Bean seems to be doing a lot of different things. You guys are producing content, you're doing meetups, you have career-focused sections. How do you see the different parts of this and how it all fits together?
00:08:34 - Monarch Wadia
First off, we definitely have a mismatch in terms of how we communicate our value and our mission and what we do and why we even exist. We're in the middle of refreshing this and addressing it, and it'll probably take somewhere from two weeks to a month.
But essentially, the thing that people don't yet know, and they will know, is Midtbyen is a bridge. Midtbyen is meant to be a bridge for developers who are breaking into software development like yourself, and who need that first initial push, or support, either emotional, technical, or opportunity.
Once you're at that point where you need that first opportunity and the first job, Midtbyen is here to serve people like you and to help you get your first opportunities in software dev, no matter where you're starting. It starts from your first line of code. The goal is to have Midtbyen be an entity that helps you out.
We aren't quite there yet, but where we do start off usually is a little bit of code. You know, how to put together a script or two. Maybe you've done one front-end project, something simple. At that point you can start coming to our hackathons or workshops or events, start learning more and more about what core development really looks like, not the stuff that's academic.
You can learn that in many different ways, and bootcamps are a fantastic way to learn that. But really, what does actual coding look and feel like? What's the culture like, and what does it mean to be in Silicon Valley without even being in Silicon Valley? What does it mean to be a software developer?
We have a few different programs. You have hackathons, you have the workshops. We're also starting up an apprenticeship system. We've actually already started that a long time ago. We started hiring developers from the community. We've hired almost ten, and we've helped way more in terms of career coaching and mentorship.
We just recently soft launched the apprenticeship system, and we just placed our first apprentice with a company called Edgio, which is a fintech company in Toronto that's looking to revolutionize the way the trucking industry handles invoicing.
And we just placed our first apprentice over there.
00:10:47 - Anthony Campolo
Are they using the blockchain?
00:10:49 - Monarch Wadia
Oh, no. They're not, for better or for worse. They're not.
00:10:55 - Anthony Campolo
I cannot tell you how important what you're doing is and how badly needed it is. There are YouTubers who get hundreds of thousands of views giving this kind of career advice. There's that many people out there looking for it.
And so, yeah, it's really incredible what you're providing. How do you help people? How do you get them across that bridge? What is that bridge?
00:11:18 - Monarch Wadia
The hackathon is the core thing, right? The hackathon is a place where you go to compete within a set time limit. Your goal is to create a project within seven days.
The hackathon helps you learn what you need to do, what gaps you have in order to become job-ready. The hackathon is a place where you go, you interact with other developers. You meet five, ten, 100 different people who are in the industry.
You create friends, you create a network, and out of it comes career skills because you're going to be talking to people and getting tips, learning how to interview. Learning how to write a resume is one of them. You're in that group of people who are like-minded. You upskill your career, you build your network, and most importantly, you build your hard skills, which is the main thing that people need to develop in order to get that job.
Of course, while you're doing the hackathons, you're going to be doing a project a week, roughly, maybe more.
And we used to do it. It used to be nuts. We used to do three hackathons a week. We've kind of dialed it down recently.
00:12:20 - Anthony Campolo
And are these individual people creating a project or group projects?
00:12:24 - Monarch Wadia
So group sizes are 1 to 3. You can do solo. You can do it with a couple of friends. One, two, or three friends can get together.
00:12:31 - Anthony Campolo
So what you're describing definitely sounds a little bit like what Lambda does for their build weeks. You're saying academic versus real world experience and whether you can get that from a bootcamp or not.
I would say for the most part, you're right. Ours is structured in a way where for each month unit, the last week is like what you're describing, where you have a week-long project that you have to build, and you have to build it with a team of like five to six people. The projects don't work at the end, but you learn a lot.
00:12:58 - Monarch Wadia
I would still categorize the hackathons and what you guys are doing at Lambda as academic. I would still classify those as academic, because what we do at the end of those hackathons is we identify the people who are really good at what they do, and we start giving them opportunities.
We make the right connections. We make email introductions, we give them career advice and mentorship, and we give them feedback on their projects.
And the whole goal of hackathons is to take you to the next step, which is an apprenticeship, which is when you get a paying job under somebody who's a senior developer and who has the bandwidth to mentor you on a real life project that's going to be in production, or it has already been launched, and you're going to be inheriting a project.
So the whole goal of the hackathons is to get you to that next step, which is your first job as an apprentice. That is still just part of the bridge, but that's the most essential part of the bridge.
00:13:51 - Anthony Campolo
I would say, actually, you and Lambda are fairly aligned because Lambda has more people working on career services than they do teaching code. Lambda is massive. They have a lot of career development going on.
Their whole thing is their income share agreement, so you have to get a job or they don't get paid. That's how the deal works. So I find that I would describe them as a lot less academic than some bootcamps just because they have this whole overarching model about getting a job.
Yeah, I have a lot of criticisms of Lambda, even though I'm defending them right now. I got a million problems with Lambda. But in general, I think they're doing good work and that they're trying to do the same thing you're doing, just from a different angle.
00:14:32 - Monarch Wadia
Oh yeah, I love every single bootcamp. I think they are a godsend. I think that bootcamps are the future. I don't think that the current system of four-year education is going to survive. I think the model that bootcamps have innovated and brought forward is the right model.
It does not take four years to teach somebody how to code, and universities are following suit too. So just like Lambda, the University of Toronto has a bootcamp now that's a one-year bootcamp. I think Seneca in Toronto also has another six-month or one-year bootcamp.
Yeah, man. Bootcamps, there's a lot that they don't cover, but I think that's a good thing. I think we cover too much in massive four year comp sci degrees and the people who come out of it, a lot of them, they face the same struggles that the bootcamp grads face after they graduate.
So I'm a big supporter of bootcamps. I love bootcamps.
Bootcamps are amazing.
00:15:25 - Christopher Burns
As a graduate of a top young university in the UK, the core principle and philosophy we were always taught by our lecturers was that we are not teaching you necessarily the languages you want to learn and will learn and will use in industry, but the philosophy and the reasons why you program in those ways.
For me, that made no sense. I hated the philosophy. I like to code, and anything explaining how to code is not my stuff. The biggest question is: in Lambda School, do they teach you about O notation of algorithms?
00:16:07 - Anthony Campolo
That's exactly what I was going to ask you. Did you learn O notation in school?
00:16:11 - Christopher Burns
Oh yeah, we learned O notation. Can I remember most of it?
00:16:16 - Anthony Campolo
Yeah. So I was going to say, did you learn it though? Because that's the thing. Ideally, what you're supposed to get is that you actually come out of these programs understanding the fundamentals. You should actually know how to think algorithmically. You should know how to think about time complexity and space complexity.
You should have it ingrained as something you can actually think about because you did it for many years. That's where the actual doing it for many years makes sense for this type of stuff. You're not just learning something super practical, you're learning something bigger long-term.
So I mean, ideally, if you could do a four-year degree and then do a bootcamp at the end, that would be the ultimate. Then you would be able to do anything because you'd have the theory and you'd have the actual practical knowledge too. So I think it's about integrating the two.
00:16:59 - Christopher Burns
I believe the most core principle in both junior development and senior development is this: you've come across a problem. How do you fix that problem? Find a solution to that problem as fast as possible using the least resources.
Does university teach you that? University never taught me that. Does Lambda School?
00:17:23 - Anthony Campolo
Maybe. I think Lambda School is very focused on teaching you tech. So it's like they are going to teach you React, like you're going to be able to write a React Router Link component afterward. And that's really great.
I feel like they're almost missing a little bit too much of the fundamentals because we don't learn things like the fetch API. We don't learn kind of the real fundamental stuff that everyone knows, but no one even knows that they know it because they know it so well.
So there still ends up being a kind of gap because they have a really pure idea of the tech they want to teach and the stack they want to teach. I think it's the right stack, but it ends up skipping over a couple steps that are really important.
But in terms of how do you read docs and stuff like that, it kind of depends on the instructor you get, honestly.
00:18:12 - Christopher Burns
I guess that's the biggest thing. When I went to university, I probably never read a language's documentation because we went by what was taught to us.
00:18:21 - Anthony Campolo
Obviously we had books that you paid hundreds of dollars for.
00:18:25 - Christopher Burns
Yeah, exactly. But did I ever read the documentation for C++ on the internet? No, I had a book.
00:18:33 - Anthony Campolo
Again, hopefully.
00:18:34 - Christopher Burns
I don't actually believe that either of them is going to die or completely disappear because everybody learns differently.
Also, this is something you probably don't know: most universities in the UK, I don't know about America, but most of their money is not made by tuition fees. It's actually made by the universities' PhD departments, the theorists, the people that basically solve really hard problems for big companies and governments and blah blah blah.
00:19:10 - Monarch Wadia
Isn't that software development, though? Abstractions upon abstractions upon abstractions? But jokes aside, I totally agree.
And to Chris's point, the real value universities offer the people who pay them is that they solve really hard problems. These professors are people who've been steeped in their field.
Look, for example, say Noam Chomsky, a linguist, being a political commentator for almost his entire life, starting from the age of probably 20, 25. Now he's, what, 80, 85? And to have an expert in a field that's been in that field 60 years, that's what software development, not computer science, but software development is missing. And that's what we're trying to provide.
If we look at ourselves as a practical, hands-on college or university, whereas most universities do research, we do software development. What we're doing is taking these developers who are new to software development. Maybe they've been here for three months in this industry.
Just graduated bootcamp, a few steps ahead of Anthony maybe. And at that point, for the ones who've shown real grit, real intelligence, the ones who really want to upskill themselves and have shown that track record, we invite them to become apprentices.
At that point, the value that we offer the companies is, hey, we're going to build something for you or we're going to help you in XYZ way. And the only reason we're doing that is to sponsor these apprentices, to give them the education that they need in real production code.
So instead of going to a university, you can teach yourself enough code, enough JavaScript to be dangerous, and then come into Mint Bean and we give you the practical knowledge that you are missing. That's the whole purpose and mission of Midtbyen.
00:20:59 - Anthony Campolo
Where do you make connections with companies?
00:21:01 - Monarch Wadia
Right now we have a group of sponsors that are helping us out and that are helping us get past the current growth phase. We're very early on in our cycle.
We're looking for contributors, sponsors to help us in our mission and to help give these developers more opportunities and to create basically a long-term solution, a really solid highway through which developers can flow and get that real-world education that they need.
00:21:31 - Anthony Campolo
Do you think you've had a decent amount of success in terms of the companies you have gotten a foot in the door with yet? Have you kind of talked to someone, and they've been like, ah, we're not really into this? Or are companies like, we need a feeder program?
00:21:43 - Monarch Wadia
Oh, our sponsors love us. So we are working with, for example, Feature Peak is one of the sponsors that very prominently sponsors our community. Feature Peak, they're sponsoring the community because they get our mission. The CEO and the CTO, they're both developers. They understand what it takes to break into the industry, and they understand the problems that we're facing. And they very generously have given us their support.
It helps them too, right? They're building a CLI tool that helps developers deploy front-end projects very quickly. So think about something like Vercel or Netlify, but custom-built for front-end developers.
The interests are all aligned and they understand what we're trying to do. So they've decided to very generously step in and sponsor us.
Then Navio, who I mentioned before, they're a very generous sponsor as well. They needed an MVP built. They're coming into our community and they're telling us, hey, look, we need help in building this MVP. Of course, we would sponsor an apprentice to come in and help build that MVP.
And I'm very involved in both of those projects, and I'm very involved in helping Feature Peak spread their message and helping Navio build their MVP. I'm involved in architecture meetings, marketing meetings, everything depending on what the sponsor is looking to get out of the engagement.
00:23:00 - Anthony Campolo
That's cool. Yeah, I've actually heard of Feature Peak. They did a Software Engineering Daily interview, which is a show I listened to religiously, and it was one of those companies where, like, if you've worked with Git and just modern deployment and stuff, you immediately get the problem. But if you tried to describe it to someone who doesn't code, it's like, what? But yeah, it's super cool.
00:23:22 - Monarch Wadia
They're super cool. It's crazy. In 2020, before Feature Peak, there's no way for designers, product managers, and developers to collaborate without actually being in the same room at the same time. And they're solving that. It's massive.
I think their stack is beautiful, too. It's all Dockerized. They're using a lot of Golang, and it's a bunch of cool technologies. If you ever talk to the guys, you should totally ask them about it. It's really slick. It's cool stuff.
00:23:51 - Anthony Campolo
Nice. Do you like Go? Are you a Go guy?
00:23:54 - Monarch Wadia
I think Go is probably a contender to replace Java, but I don't know from a language-features perspective. Yeah, I think Go is great. I think it's slick.
I think it's kind of like Muay Thai is what I like to say. It's got just the minimum set of moves needed to knock down your opponent, to knock down those bugs and those issues and those features. It's not like Java at all in that sense. But it depends on the community. Yeah.
00:24:25 - Anthony Campolo
Funny, actually. You say you think of it as a replacement for Java? Because I think people are going from Java either to C or Java, Kotlin, and that people who are going to Go are coming from like C. Or I even hear people who are coming from Python who are having trouble scaling Django and they see Go and it looks a lot like Python. It's very minimal, very syntactically clean language.
I'm a huge language nerd, so I find all this stuff super interesting. I'm a little more interested in Rust than Go personally, but I think both of them are super fascinating technologies.
00:24:59 - Monarch Wadia
My head starts spinning when I think about the memory management system in Rust. What's it called? The borrow checker. I played with it for a week or two, and at the end of it I got it. I understood it, but I still kept running into those issues. And I think that's the main adoption hurdle that Rust is going to face.
00:25:17 - Anthony Campolo
Did you use anything like C before? Had you ever done a language with manual memory management before Rust?
00:25:25 - Monarch Wadia
Yeah, yeah, yeah.
00:25:26 - Anthony Campolo
I haven't, so I'm learning memory management while I'm learning Rust.
00:25:28 - Monarch Wadia
Oh, wow. Rust is not a good language to learn memory management.
00:25:32 - Anthony Campolo
What is a good language then?
00:25:33 - Monarch Wadia
C, just plain old C, really.
00:25:37 - Anthony Campolo
Okay. That's interesting because I've heard that the reason people like Rust is that it allows them to do the same memory management they do in C, but it's simpler.
00:25:46 - Monarch Wadia
It's optional. I would say in Rust what happens is at static compile time, the language itself is built in such a beautiful way that you don't need a garbage collection process at runtime, because it's in static analysis that they do away with all the garbage collection problems and the memory management problems.
00:26:05 - Anthony Campolo
Because it's an ML family language.
00:26:08 - Monarch Wadia
ML? What do you mean? What's an ML family? That's interesting.
00:26:12 - Anthony Campolo
So I've heard of OCaml. Yeah, OCaml is a dialect of ML. So ML is like a bigger subset of languages that OCaml and Rust are both based on. People don't think of Rust as a functional language, but it's actually a functional language. It's an ML language.
00:26:28 - Monarch Wadia
Interesting. What does ML stand for?
00:26:30 - Anthony Campolo
Metalanguage.
00:26:31 - Monarch Wadia
Because it's built on top of C, C++? Is that why they call it a metalanguage?
00:26:34 - Anthony Campolo
No, it's not built on C or C++. It's like Lisp or Haskell or Clojure or any other functional language. It's literally all functions. It's functions all the way down. So you can't build it on an object-oriented language or a language that uses structs or anything like that. The two fundamental paradigms don't play together. You are functional by not being object-oriented.
So all these languages like Reason is another one, they're all built from the ground up to be purely functional. Then you get all these benefits that kind of spin out from that in terms of immutability and knowing your inputs and outputs and stuff like that.
But yeah, we're way off track here.
00:27:13 - Monarch Wadia
Way off track. But it's an interesting conversation. I'll let you guide the way.
00:27:19 - Anthony Campolo
I want to get into this. So you are the most framework-agnostic person we're going to have on this show for a very long time, because we talk a lot about Redwood. We're going to get the Blitz and Bison guys on soon.
But you're not in any of the frameworks. You actually kind of have somewhat of a detached perspective of this whole scene. You've hosted events for full stack Jamstack stuff. You've been really supportive of this super new community that we've kind of been forming.
And you said something that I thought was so interesting. You said you feel like it's changing the economics of education. When you said it to me, I got the impression you've made this pitch to other people and they didn't get what you were talking about. Whereas when you said it to me, my reaction was, I can't believe someone else has finally figured this out.
00:28:06 - Monarch Wadia
Yeah. You know, we're talking about all these different languages. It's actually a really nice segue because we have the context. We need to talk about this with C and C++.
You have this really hard problem, which is how do I manage ones and zeros that change in a deterministic way without losing my mind. Right? And that last bit is the important bit.
I also say this other thing, which is if the singularity ever happens, it's not going to need a statically typed language. That's because you don't need to manage code if you have enough processing power in your CPU to deal with the ones and zeros directly. It's because we, as limited meat-based processing units, only have limited memory. We only have limited processing time as human beings. And so we need to bring order out of the seeming chaos of binary.
Now, the first attempts at this were: let's just wire these zeros and ones together in some kind of assembly language with punch cards.
And that was like the first attempt at managing the complexity that comes with binary. Built on top of assembly is C, which said, hey, look, it's crazy to even use punch cards and it's crazy to even use raw CPU instructions.
00:29:26 - Anthony Campolo
Algol 68 or 60 would have been like in between those two.
00:29:29 - Monarch Wadia
Not familiar with Algol 60.
00:29:31 - Anthony Campolo
In terms of modern programming paradigms, subroutines and all that kind of stuff, you should look into Algol. So that was the same generation as Fortran and COBOL. Fortran, COBOL, and Algol all came out in the late 50s, early 60s. So that was the languages that came in between assembly and the C languages.
00:29:52 - Monarch Wadia
So goto statements is what I'm hearing.
00:29:54 - Anthony Campolo
Exactly. Yep.
00:29:56 - Monarch Wadia
Okay. Yeah, yeah. So let's go with that. So you have Algol and COBOL and Fortran, and you have C, C++ around the same time kind of emerging as competitors. On top of that, now you get Python and then Java.
00:30:11 - Anthony Campolo
Yeah. Then you get object oriented. Yeah.
00:30:13 - Monarch Wadia
Object-oriented. And they're building abstractions on top of abstractions. But the main driver over there is not processing power. The main driver, the main selection agent for this evolutionary process of languages, the main selection criteria, is not, hey, how fast can you reproduce as animals? Or how much food can you eat fast? Do you have a thick enough skin that you can withstand parasites or insects that are trying to get into your skin and eat you from the inside, and all that stuff.
The analog for that is how easy are you to use and how understandable is it.
00:30:50 - Monarch Wadia
Which means that the main selection criteria is understandability and ease of digestion. And the limiter for that historically has been processing time, or rather CPU power, I should say.
Because of Moore's Law, CPU power has been largely rendered irrelevant for most use cases for programmers. So we were floating in this utopia, this cornucopia of CPU processing power. And what becomes important now is how understandable is the language? How understandable is a framework? Is it easy to work with? Can you teach developers really quickly how to work with this language when they onboard onto your company, or they get into your school? How quickly can you teach them a framework, a language?
We had it really good up through Ruby on Rails, and then JavaScript came along and ruined it for ten years. I love JavaScript, but it ruined it for ten years.
For the last ten years in JavaScript, we've been reinventing the wheel all the way up from compiling with Webpack. Before that, Bower. Before that, Gulp, Grunt, compiling, recompiling the languages, building syntax sugar on top of languages.
We've evolved from there now to TypeScript, a statically typed language in the JavaScript world. And the next step now has to be let's make it easier to manage business logic complexity. And that's where FSJam comes in.
That was a long ramble. TL;DR, because FSJam frameworks are easy to understand, you can teach more developers programming faster in an easy language, which is JavaScript. It just completely blows my mind that people haven't seen this.
I think Ruby on Rails was the best thing since sliced bread for people breaking into the industry. I cut my teeth on Ruby on Rails in some of my first production projects, and it taught me everything from front-end CSS, front-end JavaScript, REST. It taught me how to migrate databases, how to manage my logic, gave me convention-based patterns that really just drilled into me the importance of managing your code, of having a sensible folder structure, of having sensible conventions.
And all of that disappeared when JavaScript came along. And I'm so happy that we're finally coming full circle, coming back to that convention-based philosophy with FSJam. That's why I think more bootcamps need to know about FSJam. More universities need to know about FSJam.
00:33:24 - Anthony Campolo
If you haven't tried to go through the process of trying to learn JavaScript, like modern JavaScript, and then go through the process of then learning a really nice framework, you have to do both of them. You have to both feel the pain and then get the solution.
Until you've done that, it's so hard to explain the feeling you get when you finally have something that you can use and that makes sense and that works and that you can build with. Once I got into it, I was just like, this is the thing. I've been super passionate about it. It's really cool that I'm finding other people who are on this wavelength.
00:33:57 - Monarch Wadia
The old Ruby on Rails guys, once FSJam starts to emerge in popularity and they get wind of it, all of those old Ruby on Rails developers who are now architects are going to jump on the bandwagon. It's bound to happen.
00:34:10 - Anthony Campolo
That's the main thing I hear when someone new comes into the community and they're like, man, Redwood, this thing is super awesome. It's just like Rails. I love it.
It's funny because the differences between it and Rails are far wider than the similarities, but the similarities are what you get first off when you're introduced to it and it's introduced to you in a way where it feels like Rails. I think this actually trips people up who know Rails too well, because then they start making assumptions about Redwood that don't necessarily hold.
00:34:39 - Monarch Wadia
Yeah, Redwood is, from what I understand, very much into JavaScript-style, functionally inspired programming, and it uses newer technology, GraphQL, etc. But at the same time, it's not built like Rails, but it's built from the same principles and values that inspired and informed Rails. It's not the what or the how. I think it's the why that matches between those two communities, between Rails and Redwood.
00:35:08 - Anthony Campolo
Yeah, it's really interesting how they holistically want to have a full, coherent project structure with good conventions, but they have different conventions. They're aligned in that sense.
It's the same thing with Redwood and Blitz. They're both going for the same thing. So people look at them and think they're basically the same thing, but they're going at it from totally different directions. So you end up with two things that are totally separate, are totally different, trying to occupy a similar niche almost, but then they actually find the niche. Redwood's more for if you want a crazy huge API with multi-client support, and Blitz is like, no, I want to get a project spun up fast, do something pragmatic.
It all ends up working out, I think, because if people are actually working on things they're passionate about or building things that are meaningful to them, everything just kind of goes in the right direction organically.
00:35:52 - Christopher Burns
I think one of the questions I have, and I have a controversial answer, is: do you think FSJam is ready for mass adoption yet?
00:36:01 - Monarch Wadia
What is mass adoption? Like 80% of the use cases out there can be solved by FSJam. Sure, the frameworks are new. They have kinks that need to be worked out. I don't even think Redwood is at version 1 yet. But then again, React reached mass adoption before it reached version 1. Has it reached version 1? I don't know what the version numbering is now.
00:36:24 - Christopher Burns
I think the biggest thing that's going to hold them back right now, and I've experienced this myself, is serverless. I personally don't think serverless is ready yet for critical applications like my own using payment processing. You want that to be done as fast as possible, and serverless was just not cutting it.
I actually managed to Frankenstein Redwood to work on PM2, the Node.js process manager. But to get to that point, you start getting off the beaten path. The question is how far down that unbeaten path must you get before it gets too hard?
Because I would say booting up Redwood in PM2 on a fresh Ubuntu droplet, Linux gets quite complex quite fast if you've never even touched Linux before. But when the abstractions work, i.e. serverless functions are fast, require no server to run, and have no cold starts, I think it will definitely fly.
00:37:38 - Monarch Wadia
I think whether FSJam is ready or not depends on how you define FSJam. In many ways, FSJam is already here with Next.js, if you define Next.js as being part of FSJam.
00:37:48 - Anthony Campolo
Do they have a database?
00:37:50 - Monarch Wadia
No. Well.
00:37:52 - Anthony Campolo
That's the problem. So it's like that's why this is a new thing, you know.
So what you're saying, Chris, about the reliability of serverless, I think that's a really interesting point because you can architect a serverless application that's highly unreliable. Or you could just have it shoot straight into a DynamoDB and have a super crazy resilient database.
So I think it's about how you architect your application. But you have to know the space. You have to spend time with the different services, the different tools, the different technologies, and which ones are actually reliable. And how do you put them together in a reliable way?
00:38:24 - Christopher Burns
I think this comes down to what kind of a developer you are. It's almost like, in my head, Myers-Briggs. You all fall into a different type of developer.
I would strongly class myself as a bootstrapper. I have a problem. I'll do anything to fix that problem. Don't care how crazy it is. Problem fix. Move on. But Anthony, you may fall into more theory and philosophy and this is how it was done in the past, this is how it will move forward. What about you? What do you think you fall into?
00:38:57 - Monarch Wadia
I think it depends on the project. If I'm working on a legacy project, you can't help but be a bootstrapper in that scenario because you just want to get the job done.
But when we start new projects from scratch, especially now that I'm mentoring developers a lot more, about six or seven hours of my day goes into mentoring developers, just directly sitting with them, talking to them. Each developer gets an hour of my time. We've already hired six people on the apprenticeship program without calling them apprentices. So each developer gets an hour of my time every day.
In that model, I try to stick as closely to the cathedral philosophy of build this forever as possible because I need to teach them. Hey, this is how you build it, right? Don't worry about the compromises. They'll come, and we can make compromises. So it really depends on the use case.
00:39:46 - Christopher Burns
My question back on that is, is time the ultimate factor to bootstrapping or cathedral building, as you say? Because I would say, oh yeah, I always start cathedral building, like it's always going to be there forever. And then the further you get into the project, the closer to 100% you get, the more bootstrapping you'll get as this just needs to be finished.
00:40:10 - Monarch Wadia
It's true, it's true. I had a boss who said, any project you work on, if it makes money, it stinks. Any project that makes money stinks. So, well, yeah. I don't think there's a contradiction there.
00:40:24 - Christopher Burns
I could believe that. Because at the end of the day, you tend to find, and this is also a really interesting question to ask, is what are you teaching your developers to be? The only developer, or a developer in a team with a very specific role?
Because if they go into a tiny company, they could be one developer that has to do everything and have to be very high level. Or they could go into a bigger organization where they're more low-level and then just focus on one area.
00:40:53 - Monarch Wadia
Have you heard of Conway's Law?
00:40:55 - Christopher Burns
No.
00:40:57 - Anthony Campolo
Maybe every communication structure eventually approximates the organizational structure.
Like, you look at Amazon. Amazon is the ultimate example of Conway's Law. Amazon talks about two-pizza teams. So a two-pizza team is a team of people you could feed with two pizzas. Every one of their services is a two-pizza team. That's why they have 300 random disconnected services.
00:41:22 - Monarch Wadia
Yeah, yeah, exactly. It's Conway's Law. The way I like to put it is, the creature is always created in the image of the creator, and it's basically everywhere. It works both ways. It's weird. It's really weird how that law shows up in different parts of life.
If you are of the mindset that you will always work in one-person teams, your career will also be shaped in that way and you will specialize just naturally into being a one-person army if you decide that.
Like for me, for example, that's how I specialized early on because I didn't see the need to, maybe through experience, work with others. So all my code was just written for me.
But then I worked in a company that didn't operate that way, and they taught me how to be the other type of developer, and they kind of shaped the creature that is me into their own image.
So I picked up skills, I picked up knowledge, and now wherever I go, I notice that I'm taking that company's patterns with me, and I'm shaping new code in the shape of that company.
Yeah. Coming back to your question, I think it was something along the lines of, what do you teach these people to be?
00:42:34 - Christopher Burns
Yeah. What do you teach people to be? Someone that could do everything, that you would say, I can do everything to 75%, or someone that can do a couple of things.
00:42:45 - Anthony Campolo
Specialist versus generalist.
00:42:47 - Monarch Wadia
Gotcha. I think the way I look at it is my goal is not to make that decision for the developer. My goal is to see where their natural inclinations are, where their personality is naturally guiding them, what their interests are, and unlock them along the way.
So I can take somebody who wants to be a solo developer and teach them everything they need to know about: don't use React and Express. Use something like an FSJam framework, or Rails, or Adonis, or something that'll let you work solo. Make choices that make sense for you.
In this case, I can take somebody who wants to be an enterprise developer and say, don't even go into JavaScript. It's a waste of your time. Go into Java or C# and I'll guide you along that way.
So it really depends on the natural progression that these people are aiming at. I know developers who only want to back end in enterprise, and they came from an academic background. They got hired by a company that does work with other universities, a lot of universities, and I helped guide that person along that path.
And I don't think it's my decision. I think it's the developer's decision at the end of the day.
00:43:56 - Anthony Campolo
I agree, people tend to seem to lean more towards one or the other. Some people really want to super duper specialize on something, and some people really want to learn a million different things. And I think you have to counterbalance it.
For me, I was someone who liked to learn a million different things, and I had to really pick something and force myself to not learn anything else. So once I went all in on React, it was like, all right, this is the only thing I'm going to be learning. You have to get that focus when you're starting, I think.
00:44:22 - Christopher Burns
It's funny. It's funny how you two were talking about all the languages and I'm just like, I just learned JavaScript. It does everything these days. Thanks, everyone. Don't care about all the benefits. JavaScript. It's the one for me. It's like the ugly car that never breaks down. It's reliable. Well.
00:44:42 - Monarch Wadia
JavaScript is a pidgin language. It's kind of like English. It just borrows stuff from all the other languages, turns into something that's actually very expressive and elegant, and you can write poetry in it.
It won't be as pretty as poetry written in, say, Hindi or Gujarati, which are languages that I also know, but it'll be good poetry.
00:45:01 - Anthony Campolo
It's the bazaar instead of the cathedral.
00:45:04 - Monarch Wadia
It's the bazaar. This is true. What do you guys think about TypeScript?
00:45:08 - Anthony Campolo
It's amazing if you are working on a big project with lots of people, and there's potential for introducing bugs into code.
00:45:15 - Monarch Wadia
Do you guys think it's a bazaar thing, a cathedral thing? Neither? Both?
00:45:20 - Anthony Campolo
That's such a fascinating question. I've never thought of it that way. Yeah, because this is the fight that's always been going on. This was Crockford versus Brendan Eich. Look up the history of JavaScript 5. JavaScript 5 was essentially fighting about who gets to decide what JavaScript is. This has been, I think, a tension that's existed throughout the course of the language.
Actually, I made a comment about this on our last episode. I think that JavaScript wants to be more like TypeScript right now because it needs more structure. It's so dynamic, but it's not going to go all the way into being C#. It'll eventually hit a point where it gets too close, and then people will rebel against it, and it'll go back to being more dynamic, I think.
It's like full stack versus the microservices thing. You keep going back and forth, bundling, unbundling. You know.
00:46:05 - Christopher Burns
I build everything I build in TypeScript. I really do like the IntelliSense. That's like the best part. But I do admit how much of the TypeScript fundamentals do I truly understand? Probably about 70%. There's still stuff that's like uncharted territory. I don't know.
You're basically paving a path before you know anyone's paved it. I don't know what's in front of me. So TypeScript is that kind of guide saying left a bit, right a bit, left a bit, and at the end of the day it's really good but bad at the same time.
And I'm going to say why it's bad, not in two words but in a few words: open Git issue. Can I have types for this, please? Close issue.
00:46:51 - Monarch Wadia
Uh-huh. I isolate all my anys. I just put all my anys into nice little boxes and all of my code is TypeScript other than that nice little box.
But it puts library creators in a bad situation. Like Brandon from Blitz. I've helped Brandon out on his TypeScript stuff before, and it taught me a thing or two that I didn't know about TypeScript. It's really advanced. It's complicated, and people are demanding it, and it's just a big time-waster. It's a time sink. It's not something that'll make your library better at the end of the day.
00:47:25 - Anthony Campolo
You don't think it can make your library more stable and help maintainability?
00:47:30 - Monarch Wadia
Well, it depends on the library. If it's just a simple util.
00:47:34 - Anthony Campolo
So I think for something like Vue, like Vue and Svelte both recently have moved over to TypeScript. Those to me seem like projects that would greatly benefit from it because they're so massive and so complicated.
00:47:44 - Christopher Burns
My thought is sometimes, I'm not going to say all the time, but types are better than documentation, especially with something like Stripe, right, where you're basically passing an object. You don't know what the object is or what all the different fields in the object are.
Yes, I could open the documentation and search for it, or I could just click the type, and then the type is going to tell me what's optional and what's not optional. In that use case, TypeScript is really good, but in terms of writing the types as the library creator, you tend to see two ways. Sorry, three ways.
Now you're the crazy guy that codes in Flow. Who does that these days? You adopt TypeScript in a major rewrite. It's now all in TypeScript. You say, I'm not doing anything in TypeScript. That's up to you. Or my favorite is you add types to a JavaScript library in the messiest way.
00:48:46 - Monarch Wadia
It's a crazy, crazy world. And I really hope we are saved by WebAssembly. WebAssembly is kind of like my Captain Marvel. I just really hope it's going to come in and save us all.
00:49:01 - Anthony Campolo
I'd love to talk WebAssembly. That'll be episode two. We'll talk WebAssembly. But yeah, to start closing it out here, was there anything more about the Mint Bean apprenticeship program that you wanted to talk about?
00:49:12 - Monarch Wadia
Yeah. It's like, look, I've basically built Mint Bean. I shouldn't say I. My partner and I have built Mint Bean to help younger developers, newer developers. And it's something that's super necessary. It's a system that we need help building and we can't build it in a vacuum.
I just wanted to maybe plug a little bit about the sponsorship and the apprenticeship and how that might benefit companies and individuals. When you're working with a senior developer like myself, the hourly rates are usually triple digits, and I've seen hourly rates in quad digits for short-term contracts. But when you're working with a newer developer who's being guided by a senior developer like myself, you get the best of both worlds.
That's the value prop, if you want to call it a value prop. That's the value prop that we're offering to our sponsors. You get guidance from people like me, but you get the work done by people like Anthony who are really smart.
This has been a wonderful conversation. I've learned a couple of really interesting things. I'm going to have to look into Algol and Crockford versus Brendan Eich, that whole conversation.
00:50:17 - Anthony Campolo
Yeah, I'm a history nerd, for sure.
00:50:19 - Monarch Wadia
I noticed. You should look up [unclear]; it's interesting, more on the hardware side.
But yeah, we hire developers like Anthony and we help them get their first paying work and we help them get the mentorship they need. I've taken people from three months right out of a crash course program. At the six month mark, they were at the intermediate level. There's no other way to put it. They were at the solid intermediate level, and only because they got the production experience they needed from sponsors.
If anybody would like to get in touch with me, I would love to have a conversation about how Mint Bean can help you, because the goal over here is not to help me, it's to help the developers that are in our community.
00:50:58 - Anthony Campolo
What's the best way for them to get ahold of you?
00:51:00 - Monarch Wadia
LinkedIn, Twitter. To make this memorable, my first name is Monarch, as in the queen or the butterfly, whichever you prefer. My last name is Wadia. That's kind of like the Republic of Wadiya from the Borat movie, so now you're not going to forget. I am the king of Wadiya, Monarch Wadia.
You can look me up on LinkedIn or Twitter, or you can look up Midtbyen. You'll find me out there on the interwebs, on LinkedIn and Twitter. Best way to get in touch with me.
00:51:26 - Anthony Campolo
Yeah, thanks a lot for being here, Monarch. This is an awesome conversation. I have so much respect for what you're doing.
00:51:32 - Monarch Wadia
Thank you, Anthony. Chris, you guys are doing really cool work over here. The FSJam thing, I'm so happy that they have somebody who's advocating for it, like you guys. And I hope you guys spread the word. Thank you so much for having me on board today.
00:51:45 - Christopher Burns
And talking about spreading the word, you can now find us on most podcast platforms. The easiest way to find if the podcast is on the platform is by searching for it on the platform, or by going to fsjam.org. Subscribe.
We are now on all the podcast players, from Apple Podcasts to Google Podcasts. You can join the Discord at the link on our website, which is where you'll also see the show notes for this episode. Thanks from me.
00:52:14 - Anthony Campolo
Thanks a lot.