The autocomplete is fucking fantastic for writing unit tests, especially when there’s a bunch of tedious boilerplate that you frequently need SOME OF. I’m also really impressed by its ability to generate real code from comments or pseudocode.

Generally, though, I find it pretty awful for writing non-test code. It too often hallucinates an amazing API and I kick myself for not knowing it existed. Then I realize it’s because the API doesn’t actually exist, and the dumb fucker is clearly borrowing from a library from a completely different stack.

It’s a little worrisome, actually. Professionally written software still needs a human to verify things are correct, consistent, and safe, but the tasks we used to foist off on more junior developers are being increasingly done by AI.

Part of that is fine - offloading minor documentation updates and “trivial” tasks to AI is easy to do and review while remaining productive. But it comes at the expense of the next generation of junior developers being deprived of tasks that are valuable for them to gain experience to work towards a more senior level.

If companies lean too hard into that, we’re going to have serious problems when this generation of developers starts retiring and the next generation is understaffed, underpopulated, and probably underpaid.

Or vulnerable relatives and friends of those same republicans.

Sort of like Warhammer 40K, or perhaps Weekend At Bernie’s.

I fucking love that this sentence now exists.

You’re picking a weird hill.

My org has issues with e2e, but we keep them because they usually inform that something, somewhere isn’t quite right.

Our CI/CD pipeline is configured to automatically re-run a build if a test in the e2e suite fails. If it fails a second time, then it sends up the usual alerts and a human has to get involved.

In addition to that, we track transient failures on the main branch and have stats on which ones are the noisiest. Someone is always peeling the noisiest one off the stack to address why it’s failing (usually time zones or browser async issues that are easy to fix).

It’s imperfect, and still results in a lot of developers just spam retrying builds to “get stuff done”, but we’ve decided the signal to noise ratio is good enough that we want to keep things the way they are.

It works for us to some extent, but there are ultimately people who specialize in various areas. Nobody can be a true master of absolutely every area in a large system with enough knowledge queued up to be able to be an independent power player. And I think that’s reasonable to anybody who works in or near the trenches.

It should be expected that any member of a full stack team can figure out how to do any particular task, but it’s a waste of resources not to have people lean on teammates who have more recent deep experience in a particular area.

This goes for both technical areas as well as domains. If my teammate just spent a couple of weeks adding a feature that makes heavy use of, I dunno, database callbacks in the user authentication area, and I just picked up a task to fix a bug in that same area, I have two choices. I can consult with my teammate and get their take on what I’m doing and have them preemptively point out any areas of risk/hidden complexity. Or, I can just blunder into that area and spend my own couple of weeks getting properly ramped up so I can be confident I made the right change and didn’t introduce a subtle regression or performance issue.

As the number of tech and domain concerns increases, it becomes more and more important for people to collaborate intelligently.

My team oscillates between 4 and 6 developers and this has been our practice with pretty high success. Quality is high (when measuring our ability to deliver within our initial estimates and our bug count), morale is good, and everyone is still learning with minimal frustration.

I think the issue of team cohesion comes into play if people are all independent and also stop talking. If I take the couple of weeks in my previous example instead of talking to my teammate for some knowledge transfer, I’m disincentivized from leaving my personal bubble at all. I’m also less likely to stay within overall software patterns if I think I’m always trailblazing. The first time you write new code, you’ve established a pattern. The first time someone repeats what you did, they’ve cemented that pattern. That’s often a nasty double edged sword, but I generally lean toward consistency rather than one-off “brilliant” code.

Where this can start to break down is when people become pigeonholed in a certain role. “Oh, you’re the CSS guy, so why don’t you take this styling ticket?” and “Kevin, you do all the database migrations so here’s another one” are great ways to damage morale and increase risk if someone leaves.

Tl;dr: everyone should be able to pick up any task, and they should endeavor to keep their axe sharp in every conceivable area, but it needs to be carefully offset against wasting time by refusing to lean on other people.

As with most things, it’s usually a matter of personalities and not policies.

My secret weapon is “what questions do you think I should have asked?”.

Not as a cop out, but something to follow your other questions with. A good interviewer will point you toward some of the company workings you wouldn’t have thought to ask about. And if they’re evasive it’s a red flag you can use to consider their offer.