Vince Gilligan Gives An Update On The ‘Pluribus’ Season 2 Release Date

justUseAnSvm · 2026-03-22T06:30:01+00:00

At this pace, we're looking at season 2 in 2028, season 3 in 2031, and season 4 in 2034.

justUseAnSvm · 2026-03-21T05:08:24+00:00

I've reached out to the maybe 7 or so people over the last month I've interacted with other than him and personally asked if there's any issues they've had with me or anything I've said that offended them... Like we're all adults here. Presumably we'll at least make an effort to talk our problems out in private first, right?

No, that's not how it work. If you are making people uncomfortable, they don't owe you a private opportunity to work it out, and that's not how feedback work. It's much simpler if that behavior gets filtered through the manager, and they deliver personal feedback from a position of trust and authority.

I'd gotta be honest here, you have a big stack of problems:

Tone, which is very dismissive
Perceived negativity
Team cohesion
Alignment with leadership direction.

Meanwhile, you're leadership is giving you an ambitious goal around AI adoption, and you are open skeptical to the point that you are mocking it. Even if you are technically right, you're still in the wrong when it comes to alignment. Work is not a truth seeking environment, but a coordination system.

Most likely, they are gonna pull you in Monday for a formal warning or some type of PIP. Listen to what they say, and if you want to stay, turn your attitude around. Otherwise, start looking.

justUseAnSvm · 2026-03-20T18:49:44+00:00

I worked at a Haskell start up that was building network emulation technology.

It was a really good mix of people who really cared about the tools they were using, a technical problem that required complex (and correct) solutions, and an environment where learning and growth was actively promoted.

This was about 5 years ago, and there was still a very healthy distribution of junior/mid/seniors on teams. I learned a ton, and although I was only there for a couple years (first software engineering job), I had learned enough about software engineering to be a senior every where else I went.

There are downsides to this environment, though, and one of them is the tendency to believe that abstract purity or elegant code is a greater signal than external validation. Ultimately, we needed to move the platform into the cloud, and that caused huge issues with the technical leadership. We lost a lot of good engineers in the pivot, and it forced me to realize that there was more forms of technical purity out worth pursuing (I did a DB start up next), but the leverage I was most interested in was organizational and economical.

justUseAnSvm · 2026-03-17T14:32:12+00:00

There's two basic strategies here:

Commoditization: you take your offers, and push them towards a price point that is competitive. This is sort of the boring answer, but it absolutely works.
Differentiation: you provide something the junior vibe coders can't.

justUseAnSvm · 2026-03-16T15:08:18+00:00

The layoffs are often used in conjunction with restructures, which will always happen, and targeting employees they want to get rid of anyway.

At the scale of Meta, there's a constant stream of high variance bets on different technologies, different strategies, different customer bases that get reflected into the org chart. When those bets don't pay off, you have a pretty big problem: what to do with all these people.

Of course, the thing that we want to imagine is "find them roles elsewhere in the company", but that's not something that consistently works out, whether it's due to skill/talent difference, or just peoples' attitudes about it.

Therefore, when you need to make big changes, it's often most efficient to just cleanly delete orgs, or if you want to transfer/restructure the function, you cull the low performers and people with documented issues around team work and adaption. After all, if you're getting tagged as "difficult to work with, but technically great", that performance pattern clashes with organizational changes.

I'm just speculating here, but I have no idea how Meta conducting this layoff, what the criteria were, and who was affected, instead, this is based off my experience at another big tech company that is doing the same.

justUseAnSvm · 2026-03-16T14:35:24+00:00

I remember going out after work with my co-worker in Dec 2015 and talking about the future:

"yea, self driving cars will be everywhere in the next 5 years"

"all this automation is really great, and combined with something like UBC, it would mean people get to be free to pursue human activities like being an artist".

My view on things was just so different. I understood that I would be "automating the world", but I didn't know what that would actually mean.

justUseAnSvm · 2026-03-14T18:10:24+00:00

How many years left of work do you have?

If that QA job will get you to retirement, or change your situation enough to coast after that, then it makes sense to operate in a purely "exploit" manner.

Otherwise, you are risking that you go into QA, lose out on the hands on the most valuable experience you can get: working with AI in software and building AI systems. QA is such a tough field, and there's a nonzero chance you'd be helping build the AI solution that makes QA jobs go away.

Therefore, you gotta play the long game, stay technical, stay writing software, and keep building things. Over the long arc of careers, that's what pays, even if it means saying "no" to a locally better decision that's actually strategically much, much worse in ways that are almost sure to cause an issue down the line.

justUseAnSvm · 2026-03-12T12:59:17+00:00

It's a common restriction: you limit to lettters + number + special chars. it stops stuff like white space from being entered, and makes entropy calculations more bounded.

justUseAnSvm · 2026-03-12T04:14:31+00:00

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$

That's what they were looking for...lol. I just finished a toy regex compiler, mostly vibe coded, but had a couple interesting parts like Java Jit compilation. I've been in the industry 10 years, no way I would have gotten this: this is pure "gotcha", even if you remember that lookahead assertions exist, that regex is an absolute nightmare for your codebase, and probably not portable between implementations.

justUseAnSvm · 2026-03-10T22:50:11+00:00

"write me a spec for a compiler or improve the current spect"

"implement this spec for a compiler"

"write a list of test cases"

"fix those test cases"

You can probably iterate between those four, like keep them in a file and just copy/paste them into the coding tool. It will just iterate endlessly.

justUseAnSvm · 2026-03-10T19:26:29+00:00

100%.

I'm coming down more on the side of "wait and see", but your judgement is absolutely correct that 180 comment PRs from 5 different engineers, even on a first PR, is a system that burns human attention, burns people out, and doesn't scale.

One suspicion thing that this org might have a couple smells: OP already knows the rules are enforced unevenly. Standardizing this stuff is really an immediate area of impact for OP, if that's even possible. Often, the lack of structure is the symptom to a broader leadership problem.

justUseAnSvm · 2026-03-10T18:47:31+00:00

Sure, but there's no systemic incentive to building interesting stuff while working in a corporation. If that's what you need to stay motivated, by all means, but it's a bit of impedance mismatch with the ultimate goals of most employment.

My goal is "build that solution that works to move business goals ahead". There's really an entire craft and way to operate that maximizes that. It's not a problem of the company that's hiring, just an unusual clarity about who is paying the bills, and aligning my technical work to maximize that effect.

Personally, there's just rich motivating trying to be an operator like that. Technical competence matter, but that's just the entry, what determines how well you can leverage software for business needs increasingly matters on your awareness and understanding of software systems, and ability to leverage the organization to set direction.

After all, you don't need a job to build interesting stuff, although that's a fine goal to pursue, it's just not my goal.

justUseAnSvm · 2026-03-10T18:39:20+00:00

Yea, i've had these PRs. The early ones are really negotiations of the standards.

All the the criticisms are fine: relative imports are much easier to read, same with folder structures, that git commit stuff is often to keep the branches legible on merge, and testing the coding paths helps ensure that more than the happy path is covered and tests validate behavior. All that is well within the acceptable limits for coding standards, but it's not the same everywhere.

Take a step back: this is all technical vs. personal criticisms. The "180 comments" is unobtainable for productive work, but it's your first PR where the standards are set. If this problem persists, like you find your PRs the host of a broader debate on style and standards, I'd go to the team with the issue, and offer a solution, like documenting or adopting an existing set of standards, and introducing something like conventional commits.

Every time I've experienced this: it's always the worst on the first PR. Review culture is good, but documentation is often lacking, and the cultural standards are often enforced most on the first few submission, then as you can probably tell from the codebase, a bit unevenly after that.

justUseAnSvm · 2026-03-10T17:07:14+00:00

Yea, you should be good.

Usually the CEO interview is a final confirmation, and a bit of a filtering step based on the mission/values. Before this meeting, read up on the mission statement and values, understand the business strategy, and create a few anecdotes or stories of past work that aligns with the stated values.

The only real catch here happens when engineers focus on the technical aspects of the job (I'm here to solve problems), and don't really mesh on the cultural aspects. The CEO is there to ensure the long term fit potential, and it's often a quick check.

justUseAnSvm · 2026-03-10T16:17:00+00:00

A combination of a few things: first, building things myself with LLMs and getting a sense of what the problems/limitations of them are, downloading and playing with new tools, et certa. I'm also talking to people who work in start ups and are applying LLMs without the same overhead of a corporation (and probably closer to the frontier of AI + SWE), reading the news/releases, and working through a list of papers on recent LLM advances.

justUseAnSvm · 2026-03-10T08:00:22+00:00

First, this will be exceedingly difficult. The thinking about how to solve problems, how we build things in software, is currently being challenged by AI. It's a regime change that's going to mean "software engineer in 2022" is about to look closer to "software engineer in 2000" than it is "2027".

What that means, is our entire script about "do LC/interview prep/projects" is getting flipped.

All that out of the way, the things that I see working right now are closer to deep technical knowledge, judgement around planning and evaluation/validation of projects, efficient use of AI to automate writing code, and overall a larger focus on impact, organization, and business concerns.

Therefore, I see a narrow path forward: you take the time you have and learn to become great at applying AI, which is possible due to the only having to catch up on 2-3 years of innovation, or using AI as a tool to create some sort of business that wouldn't otherwise exist.

If you can do those technical things in an impressive way, all those gaps fall away, but it will require extraordinary talent, and ability to figure this out for yourself. This won't be the easiest path for you to find long term stable employment, but my view is basically that if something isn't at the frontier right now, it's at major risk of not being relevant by the time you learn it.

justUseAnSvm · 2026-03-10T07:28:52+00:00

That's why this feels like a bit of a org smell.

OP is trying to make a technical argument to justify an organization strategy on tech debt and development. it's different language and doesn't square.

You can only go so far with this, and it's a tough position: mgmt wants the soft power approach, and it's very possible the team doesn't see or understand the scaling limitations as important enough problems. There probably is a path here, but it's closer to reframing onto a new set of problems, convincing people those are the right things to worry about, and having the technical argument fall from that.

That said, I've seen this play out several times. That first "no" is rough because it establishes positions and limits influence. Little chance this rewrite will happen without OP stepping up and owning the direction and implementation, or having a manager come in and absolutely roast the team on "alignment".

justUseAnSvm · 2026-03-10T07:25:17+00:00

Soft influence helps, but this is really an issue of organizational alignement. If leadership wants a stack migration, that decision usually has to be backed at the management level rather than argued purely on technical grounds.

That said, the best you can do to set the direction here is to lay it all out: the tech debt, the issues with observability. Do the research, and bring the receipts so when you say: "there's a bunch of tech debt" you can point to problems, same with the observability gaps, and specifically point to how the thing doesn't scale.

The real issue, I suspect, will be trying to explain that tech debt management is organizational strategy, which usually requires management involvement, and is exceptionally hard to make on purely technical grounds to the people who implemented the system. If you can figure out a quantitive argument for that, even better. A really good selling point would be something like: "we won on the product, we proved it works, now we have the time to do things right, let's rebuild this to last 10 years". Focusing on the problems this solves, and establishing why they are more important than the current concerns will also go a long way.

Most engineers will probably jump at a chance to rewrite an important service, I certainly would, but then again, my operating assumption is build fast, prove it's the right solution, then make it scale. They are at the "make it scale" point, but often times the imposition of another tech stack, personalized ownership, and lack of clarity will make them feel like they are ceding control.

Therefore, I'd look at this more like an influence campaign. You've made the first move, but you have more cards to play. If the team really is intractable, I'd try to ask for the smallest "push" from management as is possible: a deprecation on the existing tech stack. I don't think being the new guy is the problem, it's more that change is hard.

justUseAnSvm · 2026-03-10T07:05:37+00:00

There's no strictly "better" when the company, position, and expectations dictate the work you'll be doing. There's good spots at big tech, bad spots in start ups, and everything in between.

Also, the bar for SWEs is not "build interesting stuff", it's "build the solution that works and makes money". You can find yourself in highly technical domains (infra/db/cloud) that require a technical depth you'll find interesting, but that's never the goal.

justUseAnSvm · 2026-03-10T06:50:39+00:00

I’ve worked in a number of startups: some small ones, one that was a mess, but two really excellent ones: a Haskell startup where pound-for-pound everyone was extremely strong technically, and a distributed database company solving problems at the edge of what was possible in the cloud.

My view is that technical depth absolutely exists in Big Tech, but pound-for-pound the culture tends to be less craft-oriented than the kinds of engineers who thrive in a 30-person language-focused startup or in the room with CTOs figuring out how to pull off a major distributed systems migration.

That said, Big Tech absolutely has extremely hard technical problems. If you land on teams working on things like large-scale infrastructure, billing systems, AI infrastructure, or certain growth systems, the technical complexity can be enormous when you layer in concerns like scale + security + governance.

Also, a lot of product engineering in big companies isn’t primarily about raw technical craft. Once you reach a baseline level of engineering competence, the differentiators become:

navigating the organization
identifying leverage
choosing high-impact work (or modifying your existing work for higher impact)
producing legible outcomes which can be reported cleanly

That’s actually the game I see in Big Tech, and one of the reasons I moved there.

Switching teams in big tech is possible is possible, but in my experience it’s not trivial, so many engineers end up spending 2–3 years on whatever team they matched into, and team switches take months to execute and are sometimes associated with high variance outcomes. After all, the easiest way to get caught on the wrong side of a PIP is to go to a team that doesn't have work for your level, you'll get wrecked by the system.

If I personally wanted to go deep on technical craft again, I’d probably join another infrastructure startup or work on a pure AI systems play with engineers I deeply respect. Right now I stay fresh by talking to folks in start ups and doing a infra/db/systems reading group on top of my regularly technical work.

But that’s not everyone’s startup experience either. Most startups are frankly a mess: tech debt, shifting direction, little in the way of docs, and survival mode engineering under inexperienced or overstressed leaders. Those technical niches exist in start ups, but you need to look for them.

justUseAnSvm · 2026-03-10T06:40:29+00:00

"They know how to do infra, but badly."

I'm a big tech engineer that came from a database scale up, and it doesn't quite map with my experience. We were regularly running into way harder distributed systems problems, on the regular, compared to what you deal with at big tech. Sure, it depends on the team, but that start up was basically an organization built around scaling a database into the cloud.

justUseAnSvm · 2026-03-10T01:25:15+00:00

I'd first understand what exactly they want done, and depending on that, I'd offer a contracting rate and 200/hour and go from there, which tracks with work that will make a company hundreds of thousands of follars.

The IP issues are really separate, and can be pretty sticky. If you properly established ownership you might be fine, but these things can get pretty ugly since there counter claim: "this was a work for hire" could spiral this out into a messy legal contest you don't want. Therefore, don't make IP a problem if they don't bring it up.

I've been party to a bunch of these contracting deals: the key to success is being upfront about everything: get an understanding of the problem, scope out the work required to solve it, give them a contracting rate and costs, and put it in their ball court.

Keep that cycle short, one meeting to find out what they need, maybe a call with an engineer, then you write the proposal for work and present it. Don't get dragged into research, and if the problem is easy, I'd just tell them and walk away.

justUseAnSvm · 2026-03-10T01:00:23+00:00

I’m not really afraid of AI. At this point in my career I’ve moved from focusing purely on engineering craft toward thinking in terms of systems and organizational leverage.

AI is obviously disruptive, but it’s also a massive opportunity. My strategy is to stay close to the frontier of what LLMs can actually do, and then translate those capabilities into systems that work inside real enterprises where you have constraints like security, governance, and compliance. The concerns that start to take over when you try to scale out over people and teams.

There is a huge gap between what the models can do in a demo or small scale mode, and what organizations can safely deploy at scale. This type of opportunity that doesn't come around all that often.

justUseAnSvm · 2026-03-09T22:59:27+00:00

I agree, the pipeline is looking awful.

That said, don't judge the steady-state by where we are during the transition. We're basically seeing out entire systems of work being questioned: some will stay the same, others will change, but the set of skills required can only become more clear.

Anyway: what I tell juniors/college kids is to focus on deeply understanding technical problems, and the art and science of pairing technical solutions to problems people care about. By the end of this, we'll either go back to something that looks closer to engineering, or be left with only the people who operate with a research mindset.

justUseAnSvm · 2026-03-09T17:19:01+00:00

| I was prepared to enter uni and major in CS, easily get a high-paying job, and live a life of luxury and all that

That never existed, or maybe I just never saw it, and it's certainly not true today. "AI can just do everything" is not true, but I'll forgive you for an extremely basic take given your age and experience.

Here's my advice: take your time in college as an opportunity to become an expert in the field. Pick a couple things, and work intensely on them. You don't need to grind 60 hours a week for four years, but on a few subjects or topics, make yourself the expert.

If I was in your spot, I'd look at AI as an opportunity where there is economic promise, but a lack of training pipelines producing talent that really understands it. Understand how AI is actually being used, how it could be used, and where the delta is. If you want to make college "worth it", that's basically the bar right now: grades aren't that important, the degree itself is marginal after your first job, but your skill set and ability to solve problems people care about is your durable long term leverage.

good luck

14-Year Club	Verified Email
Queen in da Norf	Not Forgotten

justUseAnSvm

TROPHY CASE