fzwang

In some ways, it's not better. I agree that the shift is now going towards more real-world experience rather than academics. Part of the motivation for me to create the program was to introduce more self-direction and real-world problems[1].

In addition, I think it's useful to separate education from schooling. What we often confound is the actual acquisition of useful knowledge (fundamental meaning of education) and our institutions (education systems). Learning on your own is very much education!

However, I think employment etc are more complex than just education. There are other factors, like social acceptability, political risk, etc. I've talked to managers who are just risk-averse when it comes to non-degreed students. They'll privately accept that this person has all the skills, maybe even more so than other candidates, but they can't accept them because if this candidate messes up, they will get blamed for hiring them. The political risk is too much, and would be much less if the candidate has more degrees. The systems of accountability is messed up but that's the reality young people have to navigate. They have to understand the markedness of not having a degree. It's sorta like the social version of "the market can stay irrational longer than you can stay solvent."

Depending on what they want to do, the degree won't matter. If you start your own company, obviously no one will care if you have a degree. Some investors see it as a plus. You can argue that putting a 4-yr university tuition as startup capital will teach more useful skills than a degree, even if they don't pursue entrepreneurship later. But most people are not willing or can't take those risks.

[1]https://www.divepod.to

Overall, I think it's still credible, but less credible than before, and heavily depends on your situation.

I run a program for students as a replacement for university, so I'm a bit biased when it comes to this discussion. It's useful to analyze both what a student want out of a degree and how a degree is "consumed" by another party (ex. an employer).

1. University degrees are still the "gold standard" in socially accepted proof-of-education. I think this is mostly due to social momentum. A few years of a "bad batch", ex. due to rampant cheating etc, will not change this. When I talk to other hiring managers, it's a bit of mixed bag. Some sorta understand where the students are coming from, as they also think that a lot of courses etc are arbitrary. Others are more concerned about the ethics of cheating, and the implications on a student's character, rather than the education outcomes ("I can work with inexperience, I can't tolerate lying").

2. If you're planning to pursue a heavily regulated profession, like medicine, you most likely need a degree.

3. As others pointed out, the university criteria now more closely resembles a toll someone must pay to access higher-paying jobs. Ie. it's less about education than gatekeeping. Having it doesn't make you qualified. Not having it disqualifies you in many people's eyes. I think this is partially driving a lot of the cheating. Students sense the disconnect from the university program (and schooling in general) vs real skills. It's just another hoop they have to jump through so they will choose the path of least resistance. For many parents, it's a sort of capstone project for a parenting job well-done. And that adds more to the complexity.

4. How you take advantage of your university experience matters. I wouldn't count on the university for a durable education, ie. actually teaching you things that will make you successful. You need to get that elsewhere (thus the emphasis on work experience). But the social momentum is important, as universities are social centers for young adults, so you may get socially isolated if you don't go. In this case, the value is in the network, not so much the programs etc.

The university experience, despite it's flaws, is still the status quo and definitely the safer "bet". Unless a person have clear understanding of why they shouldn't go, they should probably still go.

Some thoughts/comments below. I work with teenagers and young adults who are similar to you, ie. intelligent, passionate about CS, but a bit lost.

1) Think about what you want out of an internship. Money? experience? How does it fit with what you'd want to do/try next?

2) If you live in an area with a small/non-existent tech scene, then you need to expand your social circles. This usually means reaching out to other engineers etc, ask for a face-to-face call. Don't ask for a job (yet), just advice. It shows you're a real person, not just a Github handle, and you'll leave an impression on them. You will get a ton of rejection early on, but if you set your expectations low, you'll still come out ahead. If it's possible, travel to a bigger city to attend events for a weekend, etc. Maybe even give talks about your work/etc.

3) Part of the problem right now is that your so different that people don't know which box to put you in. So you'll have to work harder on signaling to alleviate their confusion. For example, some may think you're likely immature and hard to manage because you're 16. Others might think they can't retain you, so there's no point in investing in you. In some cases, they may even feel threatened by your successes and accomplishments. Try to leave your age out of discussions, and focus more on the objective elements to your experiences/interests.

4) I'd avoid getting your info from social media, as it tends to attract a certain type of users, and their opinions do not reflect real life. This is probably one of the most common problems I have to deal with, which is expanding students information diet and how to critically appraise what they're seeing/hearing.

5) Easier said than done, but don't get too discouraged by the feeling of being stuck. You're actually ahead and just dealing with problems that others will inevitably deal with as well, just a few years/decades ahead haha. The early rejections/setbacks will hurt, but you're actually building resilience in ways that you won't appreciate until you're much older.

Overall, the important thing to work on constantly is to connect with folks who will advocate on your behalf and open doors for you. Good luck and keep at it!

I'm a self-taught programmer, been coding since I was 12. Went to university for a science degree, but it was my programming skills that ended up being way more useful and lucrative. Worked in various technical roles since I was 18, from data engineering at major research hospital, technical due-diligence for venture capital, startups, ML research, etc. Basically, my degree didn't seem to matter.

At the moment, I'm running a program for self-directed CS education[1] and end up talking to a lot of people who were self-taught. Part of the motivation for the program was that we found that people we hired who had a lot of self-directed experiences were much better engineers. It wasn't that degrees were necessarily bad, but it seemed like the thing that made them good was not the degree.

From my experience talking to people who were also mostly self-taught, the outcomes are a mixed bag. In retrospect, I think I was quite lucky in that I had the right support structures (mentors, etc) in place throughout my life. Some I worked towards, others kinda fell in my lap. In addition, some of my earlier career/life decisions based on hunches have worked out so far (pivoting from medicine to ML in 2012). Not everyone I talked to had the same experience. Some really languished because they really had no support / positive influences. Others think it's one of the best decisions they've made, in both time/money saved and agency.

If I had to summarize, one of the major negatives is that self-directed education frontloads a lot of the problems early on. You're in total control, but also exposed to all your mistakes. If you don't have the right environment, you can flounder in the sense that you don't even know what you're missing. This is compounded by our terrible K-12 education system, which does not prepare you for self-direction. If you don't have other sources of support, it could lead you to a vicious cycle of failure begetting failure. You'll also be "marked" [2] and mistakes/setbacks will be attributed to your lack of degree, whether justified or not. From a career perspective, some hiring managers are not incentivized to take risks on non-degree holders. Ie. it could blow back on them if you don't work out. You'll have to work harder on signaling and networking, etc. You're not going "fit", esp in a degree-heavy culture, and that could lead to social isolation.

The positives is that, at the moment, there's never been a better time to self-direct your education. You end up learning things that interest you, at your pace at the right time, so the problems/work is always relevant. You can go really deep really fast. The people that you want to work for/with don't care about your degree. Self-directed education is inevitable, esp in tech. Every one of us eventually have to take control of our education. The problems you have to work through early on are also inevitable (ex. signaling to others that you are competent). The agency and sense of control is great for your mental well-being and developing accountability. Your team can count on you to take the initiative, figure things out, and learn the things you need to learn. Uncertainty is not paralyzing. You've dealt with it your whole life.

Overall, it's not an easy path. I think a lot of it depends on early support and the mental attitude/personality of the individual.

[1]https://www.divepod.to [2]https://en.wikipedia.org/wiki/Markedness

I used to work in VC. Although I've never deal with this situation myself, I've talked to other founders who've had similar experiences.

The general thinking is that the new team is essentially a new business. This new business needs cash, and taking that away is more or less a non-starter at this point. Fundamentally, founders are compensated for seeing things through, not for partial work. It's a really hard sell to either ask a cash-poor company for cash for non-productive purposes or to ask new investors to put up cash that's going towards an exit-package (ie. someone who's not going to be contributing). The only leverage you may have is how much pain you can cause by not being bought out, which puts you in an adversarial relationship with everyone else. I don't think that's good for you.

So I'd recommend you'd just hold on to your vested shares to build good will. Indicate your intent to exit, but you like the new idea and wouldn't put additional pressure on the business at this stage. If the business is successful in the future, you may get bought out by later stage investors to simplify the cap table and reduce governance complexity. But for that outcome, you'd need to be on good terms with current investors and the new team.

I used to work in VC and have seen a few teams in this type of situation. It sucks to be in the middle of it, but it's actually quite normal.

1) Your VC is not the main issue

VC can cause a lot of harm. They often give bad advice and it's your job to decide when to ignore their advice. But if you're counting on your VC to drive your business, then I think you've gone into the relationship with the wrong assumptions. VCs provide capital. They sell cash for a stake in your company. Once they sign the cheque they've delivered 80%-90% of their value. They don't really have any significant insights into problems, simply because they're not really exposed to customers. VCs hear a lot of hypotheses from startups, but most of them are wrong/bullshit and difficult to interpret in context of what you're building. A VC's network may be useful if you already have something that works, have a sales/marketing strategy, and need warmer intros to potential customers/partners. But VCs are not there to discover problems for you ...

So I think it's important for you to readjust your expectations from VCs and investors in general. If they were good operators they'd be building their own companies ...

2) You are lost

I think it's good to have a candid conversation with your co-founder on not understanding any problems well enough to build a company. In this scenario, it's important to go into discovery mode, if you still want to build a company, and use your engineering skillsets to work on temporary measures for cashflow (like consulting, dev contracts, etc). You'll also need to manage your personal expenses to survival levels. Given your prior experiences at large tech companies, and the compensation associated with them, it'll be really hard to do mentally but not insurmountable.

3) Startups may not be your thing

I generally encourage people to try starting their own companies, but it's not for everyone. You really have to enjoy the "multi-hattedness" of being a founder and the early-stage experience. If you're not enjoying the company-building process, and would rather just build products, then you're likely better off going back to working at a more stable startup/company. You likely learned a lot of skills in trying to build a new company, and other startups will look favourably on that.

So I think you have to re-evaluate whether you'd want to keep going. The problems you're dealing with only gets worse as the startup grows. Pivoting at your current stage is the easiest it'll ever get. But the main question is whether you want to be in the game, so to speak, to begin with.

SEEKING WORK | US/Canada Remote | Toronto Hybrid

I'm experimenting with a new model for CS education using advisors who follow and adapt to students' interests. The core idea is that students should learn how to learn early and to self-direct their own education. However, they need support for when they get stuck.

At the moment, I'm looking to work with students who have deep interests in CS/tech, but want something more dynamic than a fixed curriculum program.

Experience: * Self-taught programmer. * Worked on data engineering at a large hospital. * Ex-VC - worked on technology due-diligence. * Started independent R&D lab (www.ithron.com). * Designed this model based on my experiences hiring engineers.

Engagement model: * Work with students 1 on 1 * ideal age range is 16-21, * 2-3 hours of meetings per week + 15-20 hours of self-directed time * 3 month batches, can be extended to a full-year. * More info at: https://www.divepod.to

Feel free to reach out at: frank [at] divepod [dot] to

I used to work in VC and second this. Nothing really preps you better than the real deal. Line up some practice rounds with low-stakes investors first.

The issue with using founders/friends is that they're too emotionally invested in you to ask the hard questions in ways the investors will. Founders also think differently than investors. For example, a friend who has built companies before would look at a potential issue and their "operator brain" would automatically come up with ideas on how to address it. As a result, they may downplay the problem. Whereas an investor may laser in on it to test your thinking/confidence.

If you had to practice, making the question submission anonymous (as you can) may help. I know I hate giving harsh feedback to friends directly, even if they ask for it. The sting still lingers around. Not knowing who asked the question could be helpful, but it's possible they would still be able to tell if they know you.

1) RE: Unintended consequences - It was usually some mix of willful or accidental misinterpretation of what we wanted. I can't go into details, but in many cases the annotators are really aiming for maximizing billable activities. In situations where there are some ambiguities, they would pick one interpretation and just go with it without really making the effort to verify. In some ways, I understand their perspective in the sense that they know their work is a commodity and would just do the minimally-viable job to get paid.

2) RE: Benefits of outsourcing - The primary benefit was usually speed to get to a certain dataset scale. These vendor had existing pools of workers, which we can access immediately. There were potential cost-savings but it was never as good as we had projected. The quality of labeling would be less than ideal, which would trigger interventions to verify or improve annotations, which then adds to cost and complexity.

3) RE: In-house ops - Essentially, moving things in-house doesn't magically solve the issues we had. It's a lot of work to recruit and organize data labeling teams. They are still subject to the same incentive-misalignment problems as outsourcing, but we obviously have a closer relationship with them and that seems to help. We try to communicate to them the importance of their work, especially early on, where their feedback and "feel" for the data is very valuable. And it's much much more expensive, but all things considered still the "right" approach in many cases. In some scenarios, we can amplify some of their work by using synthetic data generators etc.

We've experienced this scenario a few times, where someone used AI generated code which had significant bugs or mistakes.

- Telling them about the mistake is not as helpful as you think. It's the same as taking an exam, getting something wrong, and looking at the answer key immediately. You feel like you learned something, but it's not as strong, and you're more likely to make the same mistake in the future. Doing things by hand, although painful, is still a strong check on your understanding of the problem.

- It's very frustrating for the person reviewing the code. Reading someone else's code is not easy, esp when they can't articulate what they were aiming for, or there's a big discrepancy from what they think they wrote vs what's actually written. In many cases, the reviewer is thinking "Why did I even bother with this? I should've just vibe-coded this myself. At least I know what should've been done. This isn't even worth it for mentoring purposes, because they did't actually learn anything."

- Using threat/punishment based incentives create a lot of bad vibes and culture. People are less likely to talk about mistakes and spend more time thinking about how to hide their mistakes.

- Eventually, the consensus converges to the position that the best way to learn is to do things manually and it's better when junior folks didn't rely on these tools from the beginning. It's important to explain to them why or else it can seem hypocritical when more experienced people are allowed to use LLMs more freely.

I agree in part with what you're saying. I do think LLMs are here to stay and will be part of most programmer's toolkit. What my team and I are trying to figure out is where is it helpful, where does it break, and what are the long-term consequences. From an accountability perspective, we do allow senior folks to pick the tools they use, including LLMs. But they also need to be responsible for the outcomes. The consensus so far is that the fuzziness of understanding that LLM tools introduce causes harm in the long-run, in ways that are hard to trace back. It's like radiation and cancer. So if someone is using it, they better have a good rationale.

Your analogy with book reading is very interesting, although I interpret it differently. It seems like you enjoyed reading longform books, but the environment you moved to (US) is not reading-heavy (much more visual, like TV/phones). The skills you developed was not as valued in this new environment. The issue is the skillset-environment mismatch. If you had moved to a reading-rich culture/community, you'd have appreciated your past reading experiences.

In software engineering, I think the skillset is more like longform writing, where you have to build the mental model of the story and also be able to dig down to individual words. The more experience you have building these models from scratch and learning from other good builders, the better off you will be. People can certainly get by and "coast" on just using outputs from LLMs, the same way that there will be many LLM storywriters. But I'm concerned it'll put a ceiling on what they can accomplish. They are not developing the skillset needed at a higher level. They're stuck in-distribution, and never venture out. They may not even know what "out" is.

I guess some programmers are OK with that. And some orgs may be perfectly fine with LLM-based engineering (ie. Think of how many dysfunctional engineering teams there are. is adding LLMs that much worse?). They are willing to risk the tradeoffs. But they may later discover that it's a shrinking pool with a lot of newcomers, and to advance their craft and profession, they may have to write some code from scratch and read Kernighan and Ritchie.

We've explored using external vendors for data labeling and annotation work for a few projects (image and text data). I think overall the problem is more along of the lines of mis-aligned/drifting incentives. It's like Goodhart's law, where whatever metric you use for outcomes tend to be manipulated or have unintended consequences. And putting in the trusted systems to identify bad/shifting metrics is costly in a way that makes outsourcing not worth it.

In most cases, we've opted to build the data labeling operation in-house, so we have more control over the quality and can adjust on the fly. It's slower and more costly upfront, but better outcomes in the long run as we get higher quality data.

We've mostly banned the use of AI coding assistants, with exception of certain uses, for junior level devs/engineers. Essentially, they need to demonstrate that their use case fits with what LLMs are good at (ie. for in-distribution, tedious, verifiable tasks).

Annecdotally, what we've found was that those using AI assistants show superficial improvements in productivity early, but they learn at a much slower rate and their understanding of the systems is fuzzy. It leads to lots of problems down the road. Senior folks are also susceptible to these effects, but at a lower level. We think it's because most of their experiences are old fashioned "natty" coding.

In a way, I think programmers need to do natty coding to train their brains before augmenting/amputating it with AI.

I used to work in VC and have talked to a number of people regarding this. The classic pivot vs persevere problem.

1) My view is that you don't/can't really know in advance. Most of the examples you see/hear about are retrospective, and suffers from survivorship bias and/or positive reporting bias. Ex. Typically, you only hear about how people's decisions led to success. Or you only hear about earlier failures if the subject later succeeded. What you don't hear about are other people who made similar choices and still failed. Unless you're connected to these builders/founders networks and have insider-access/great rapport, it'll be difficult for you to get exposed to the hidden, unreported side.

2) What's worth analyzing are the material consequences of whatever outcome/decision path. One thing you do want to avoid is anything that could take you out of the game, so to speak. Like huge financial obligations, etc.

3) And most decisions aren't so black and white. There's a very large, gray area in between where you could get real creative. In this gray area are 3rd options where you could be positioning yourself for long-term sustainability to work on whatever it is on your mind. Sometimes I call it "pivot to persevere." Ex. creating another venture B to fund venture A.

I agree. Self-directed education definitely front loads a lot of the problems/decision making early on. I think one of the goals of a good advisor, if you can find one, is to smooth out these issues so they don't become overwhelming.

And to your point about curiosity-driven learning, I'm often shocked at how deep some students get with their learning, if/when they are interested. In some ways, I think we really underestimate how capable young people are. And it's very satisfying, as an educator, to see a student start to embrace continuous learning, as their default mode, and don't interpret learning as a chore or box to check.

This is something I had to deal with as well. It also surprized me in terms of how limited their information sources are, esp with younger students. One thing I found helpful is to actually introduce them to engineers in person (like a take your kid to work day), which I think grounds them a bit. But this box-checking influence is everywhere, including in the K-12 curriculum. In some ways I understand their perspective. Most schools/teachers do have a box-checking mentality, and I think students intuitively understand that what these "educators" are after is a metric. They don't actually care about real skills. But to your point, the rest of the world actually values competency and it's something students should strive towards for the long-term.

I run a comp sci education program to help students self direct their education[1]. We sometimes reference the OSSU curriculum.

Althought there are lots of benefits to the self-taught route, there are some caveats which students should be aware of. You will have to work harder on the "signaling" and networking. There are definitely social benefits in being associated with a university. And a lack of degree will mean you're "marked"[2], which you'll have to overcome. A setback or mistake will be attributed to your lack of degree, whether justified or not. And some hiring managers can't take the political risk of hiring a non-degreed candidate. Not insurmountable, but this means we work on it from day one. If you do decide to self-direct your education, the benefits are that you learn faster and don't waste time spining the hamster wheel, so to speak, to grind out courses. Everything you learn is in context and relevant. If you realize you miss some fundamentals, you'll just go back and learn those concepts/topics. It's a different way of learning, which imo, is inevitable for technical professions. But it's not for everyone, and some students just vibe with it more.

What's sad is that many students are sort of forced into the self-taught route, because they don't have the financial resources to go to college/university. And if they're not aware of the trade-offs, they could really struggle.

[1] https://www.divepod.to [2] https://en.wikipedia.org/wiki/Markedness

I understand the feeling. And sometimes you start to question your own judgement of people. I guess just keep in mind to not let the bad ruin the good.

In Canada, there's a higher level of baseline trust in society, so it's shocking to experience things like this. In other parts of the world, this is just normal everyday business.

I'm not a lawyer but have talked to a few founders who faced similar situations, ie. employee breaks the law or there's a substantial breach of ethics.

1) Document your case and speak to your lawyer. Pray they didn't do anything that would affect your customers/clients that could cause legal issues for you. I assume you're reviewing all their communications.

2) In most cases for early-stage companies, it's probably not worth it financially to pursue the case. It'll end up eating a lot of time, energy, and money that could've gone elsewhere. In the very least, documenting your case and throwing out some low-cost tactics could be useful for defensive purposes.

3) The priority at this point, I assume, is to re-establish your sales op. I would reach out to your professional networks and let them know not to work with this individual. Recruit your investors' networks as well, if any. The goal is to find good ways to protect yourself and your friends/partners.

4) Use the crisis to rally the team! You've been debuffed all this time! Turn this into a gift.

5) This sort of stuff happens all the time in one form or another. And it'll happen again. Anecdotally, I've found that it's happening more now with remote work where it's just harder to vet people. And if you're working cross-cultures, it can be even more difficult. Don't beat yourself up too much and learn from it.

Good luck!

From my personal experiences, working with small engineering teams and running an comp sci education program[1].

TL;DR: There are some benefits, but mostly not worth it or actively harmful for students/junior engineers.

1) Students using LLMs to code or getting answers generally learn much slower than those who do it old fashioned way (we call it "natty coding"). A very important of the learning experience is the effort to grok the problem/concept in your own mind, and finding resources to support/challenge your own thinking. Certainly an answer from a chatbot can be one of those resources, but empirically students tend to just accept the "quickest" answer and move on (bad habbit from schooling). But eventually it hurts them down the road, since their "fuzzy" understanding compounds over time. It's similar to the old copy-from-StackOverflow phenomenon, but on steroids. If the students are using these new tools as the new search, then they still need to learn to read from primary sources (ie. the code or at least the docs).

2) I think one of the problems right now is that we're very used to measure learning via productivity. Ie. the ability of a student to produce a thing is a measurement of their learning. The new generation of LLM assistants breaks this model of assessment. And I think a lot of students feel the need to get on the bandwagon because they produce very immediate benefits (like doing better on homework) while incurring long-term costs. What we're trying to do is to actually teach them about learning and education first, so they at least understand the tradeoffs they are making using these new AI tools.

3) Where we've found better uses for these new tools are in situations where the student/engineer understand that it's an adversarial relationship. Ie. there's a 20% chance of bullshit. This positioning puts the accountability in the human operators (can't say the AI "told me so") and also helps them train their critical analysis skills. But it's not how most tools are positioned/designed from a product perspective.

Overall, we've mostly prohibited junior staff/students from using AI coding tools, and they need a sort of "permit" to use it in specific situations. They all have to disclose if they're using AI assistants. There are less restrictions on senior/more experienced engineers, but most of them are using LLMs less due to the uncertainties and complexities introduced. The "fuzzy understanding" problem seems to affect senior folks to a lesser degree, but it's still there and compounds over time.

Personally, I've seen myself be more mindful of the effects of automation from these experiences. So much so that I've turned off things like auto-correct, spellcheck, etc. And it seems like the passing of the torch from senior to junior folks is really strained. I'm not sure how it'll play out. A senior engineer who can properly architect things objectively have less use for junior folks, from a productivity perspective, because they can prompt LLMs to do the manual code generation. Meanwhile, junior folks all have high powered footgun which can slow down their learning. So one is pulling up the ladder behind them, while the other is shooting their feet.

[1] https://www.divepod.to

After seeing a ton of teams and failed companies, I think people fall into two categories. The first group don't care much about what they work on, as long as it grows quickly. The second group is emotionally invested in an idea/space. This is obviously a gross generalization, but you get the idea. There are good and bad manifestations for each group. The anything-that-pops group can over-pivot and never stick it out, but obviously rolls the dice more which improves chances of a good outcome. The my-life-calling group can get too ideological and be stuck on something that's just not working/isn't the right time, but the endurance is necessary for building great companies. There is no right way. I think the most important thing is for you and your co-founders to understand each other's stances and the types of sacrifices you're willing to make. Your stance could also change with experience, so you should check in regularly. Nobody's born with a "calling" and it's developed over time. But should your stances diverge in a significant way, a lot of conflict can result.

For a good breakup, I usually think about 3 perspectives:

1) Relationship with your co-founder(s) - Unless there's some major violation of my values, I'd like to be on good terms even if the team fell apart. That means you might still grab dinner/beer with them and even help them out in their next venture. You all may end up co-founders in the future when you're all wiser and the opportunity presents itself.

2) Reputation with your investors - The VC space is smaller than you think, and you need to maintain goodwill. These investors did make a bet on you, and I think you'd want to demonstrate you tried your best. You might even return some of the money left (it's mostly symbolic, but w/e counts). Most VCs understand failures are inevitable, but you don't want to leave the impression that you were the problem.

3) Self-image/self-esteem - I think many founders underestimate the benefits of a good closure emotionally. A good breakup means you sleep well at night and are content with how you handled things. You don't want bad vibes to fester and ruin your motivation and focus for whatever you do next. Building a company is already hard enough, you don't need the debuff. Doing rash things you'd end up regretting will likely cost you more time and opportunities later.

Some additional personal observations that OP might find useful:

- Building a company is really emotional, as you already know. Most founders are under-skilled when they start, and are forced to learn quickly. As a result, you get a lot of scars along the way and the experience will test all of your insecurities. Learning how to resolve existential crises again and again is part of the package. And it gets worse. Wait until you have whole teams of smart opinionated people that you have to lead.

- It'll be good to revisit why you and your co-founder decided to start a company. You've both spent 2 years of your lives living in the trenches, so to speak. Someone decided you two were worth the risk. Why didn't your co-founder quit after the first idea failed? Why does she keep trying? I obviously don't have enough info to make any judgement calls, but I've seen situations where people make the wrong call because they've failed to truly appreciate the emotional baggage. For example, sometimes the first failure hits really hard and triggers all sorts of insecurities in a co-founder about not being good enough. And if their team starts questioning their judgement over and over without diffusing the insecurities, it just makes things worse.

- There are good and bad breakups. Good breakups are worth it for the emotional closure and the reputational upside. Bad breakups can create all sorts of fallout that will affect you in unexpected way (sometimes without you even knowing, ex. if the drama resurfaces during due-diligence). All the legal mechanics are also much smoother and drama-free when the breakup is on good terms.

- I am probably biased because these types of co-founder blowups are what keep investors up at night. Losing a technical co-founder is not only emotionally draining, but usually lethal for the investment. People problems are gnarly and take a lot of skill and precision to diffuse. If anything, use the crisis as a personal challenge to figure out how to resolve it on good terms.

Working through a really difficult situation like this could actually make their working relationship much stronger. To your point, even if they fail they'll learn from the experience, which will be useful for their next venture (either together or going separate ways).

I used to work in VC and have seen a few examples of this. Every case is a little different, but from what you've described I'd focus on salvaging the co-founder relationship. Conflict like this is totally normal. IMO, a pivot is when you change directions based on new information. It sounds like you're not pivoting, but lost. If you haven't already, addressing this head-on and having a candid conversation about being lost would be beneficial. Think of it as an exercise to possibly strengthen your relationship via conflict. Few other thoughts:

1. At this early stage of the business, the core asset is really the co-founding team and their relationship. Conflict is very much normal, but how you resolve it is important. You should be able to articulate your co-founder's concerns. For ex. she might feel the pressure to show "progress" to your investors.

2. It takes a lot of time and energy to build a good working relationship. Moving onto something else might seem like a good idea at the moment, but you could be right back with the same issue with another co-founder.

3. If you do decide to move on, end the relationship as amicably as you can. Note that this is not necessarily the "quickest" route, but it'll help keep your reputation intact.

Edit: spelling.

Divepod - comp sci education program based on advisory model[1]. Instead of a fixed curriculum, each student is paired with an advisor who follows their interests and adapt the learning plan as they go. Something I wished I had as a teenager.

[1]https://www.divepod.to

Thank you! In some ways, I feel like we are re-inventing the apprenticeship type of model.

And to your point regarding history/ethics/philosophy, these topics come up inevitably. In the earlier experiments we've done, the discussions can turn very philosophical. A part of me wants to include these topics in the website, but another part says it might scare off some students who may not recognize the relevance yet.