bvirb

When we (the engineering team I work on) started using agents more seriously we were worried about this: that we'd speed up coding time but slow down review time and just end up increasing cycle time.

So far there's no obvious change one way or the other, but it hasn't been very long and everyone is in various states of figuring out their new workflows, so I don't think we have enough data for things to average out yet.

We're finding cases where fast coding really does seem to be super helpful though:

* Experimenting with ideas/refactors to see how they'll play out (often the agent can just tell you how it's going to play out)

* Complex tedious replacements (the kind of stuff you can't find/replace because it's contextual)

* Times where the path forward is simple but also a lot of work (tedious stuff)

* Dealing with edge cases after building the happy path

* EDIT: One more huge one I would add: anywhere where the thing you're adding is a complete analogy of another branch/PR the agent seems to do great at (which is like a "simple but tedious" case)

The single biggest potential productivity gain though I think is being able to do something else while the agent is coding, like you can go review a PR and then when you come back check out what the agent produced.

I would say we've gone from being extremely skeptical to cautiously excited. I think it's far fetched that we'll see any order of magnitude differences, we're hoping for 2x (which would be huge!).

Very much agree for the type of software I've worked on my whole career. I've seen way more time and energy wasted by people trying to predict the future than fixing bugs. In practice I think it's common to realize something didn't "possibly work" until after it's already deployed, but keeping things simple makes it easy to fix. So this advice also ends up basically being "move fast break things".

We attempt to address this problem at work with an extra caveat to never add code "in the wrong direction" -- so it's fine (usually preferable) to have a partial implementation, as long as it's heading in the direction we'd like the more complete implementation to go in. Basically "KISS, but no hacks".

Accurate, saw restroom use tick up 1

We've been using Elasticsearch + PG and it's pretty nice and fast, but it adds a whole layer of extra stuff to deal with when your data is in PG but then also needs to be indexed into an external server outside of those PG transactions. In our case I'm pretty convinced it hasn't been worth the effort. I think we could've optimized PG to be as fast as we needed with a lot less overhead than dealing with an external search index.

We moved our queues to PG and it cuts out the same kind of overhead to be able to wrap an update and start a job in a transaction. PG has been plenty fast to keep up with our queue demand.

Ultimately I think being able to do things transactionally just avoids a whole class of syncing issues, which are basically caching issues, and cache invalidation is one of the 2 hard things.

Is there some way to normalize the amount spent on education per student with the need per student? NYC is also the most expensive place to live in the US, so conceivably the amount spent per student doesn't go as far towards their educational outcome. Baltimore is very poor, so conceivably the gap between the amount spent per student and the need per student is still high. Wealthy suburbs in Washington DC might already have so much support per student that their education system would do fine spending even less per student.

Or I suppose in other words: do education spending numbers actually cover what it takes to provide good educational outcomes? And if not, and we wanted to specifically improve education outcomes, could increased education spending still do that by offsetting other deficits? In more concrete terms: if we did something like give schools way more money could they pay for more things like after school tutoring and recreational opportunities to improve educational outcomes that might be happening in places like wealthy suburbs of Washington DC but not as much in Baltimore?

I think it's possible that your numbers of amount spent per pupil don't take into account the total benefit to that pupil towards their education. If Norway say also helps comparatively more with housing, food, and medicine, then that might also factor into the educational outcome of their pupils, especially if it means parents can spend more time helping their children.

Anecdotally the smallish town I grew up in had good public schools, and many of my teachers lived in nice homes nearby the schools they taught at. The HCOL city I currently live in has (supposedly) poor public schools and one of the issues I hear is that teachers can't afford to live anywhere near them and don't want to commute hours to work, so they have high turnover. If housing weren't so expensive the public schools here might be better while appearing to spend the same amount on education.

I started out freelancing and eventually built a consulting firm w/ a partner, I left around 50 people because selling time for money just never got fun.

Took a business partner, a couple engineers, and one of the products we had built for an old customer from the consulting firm (on good terms!) and built an enterprise SaaS product out of it, much happier working working with a small team on a product.

For me the value of working on lots of things was meeting lots of people I'd like to continue working with and getting product ideas.

The argument would be that the marketing done by the label(s) she has signed with is a big part of why she has 7.5M monthly Spotify listeners (and the related fame is why so many people will pay to see her feet).

Not sure if that's a good argument, maybe she would've grown just as popular w/o help from a label, but that's why artists sign.

In a similar boat (small team, have to balance new stuff, maintenance, customer requests, bugs, etc).

We ended up with a system where we break work up into things that take about a day. If someone thinks something is going to take a long time then we try to break it down until some part of it can be done in about a day. So we kinda side-step the problem of having people able to focus on something for weeks by not letting anything take weeks. The same person will probably end up working on the smaller tasks, but they can more easily jump between things as priorities change, and pretty often after doing a few of the smaller tasks either more of us can jump in or we realize we don't actually need to do the rest of it.

It also helps keep PRs reasonably sized (if you do PRs).

> Going from 10 to 10,000 qualified candidates for a position allows a far more productive match

Yeah going from 10 to 10k qualified candidates means wages go down. As companies get better and better at WFH the pool gets bigger and bigger.

Personally I think some industries will go this way and others will go RTO, depending on how competitive they are (especially around R&D). Wages for relocation/RTO will end up rising.

On the flip side: I've heard people saying software is going to be offshored and has no future at least since the 90s dot-com bust, they were still saying it in the 2000s when I was in school, so I'm skeptical that the growth of WFH will overcome all the barriers to global hiring.

Ultimately I think WFH wages will go down/stagnate (of course w/ higher quality of life for many) and companies that want it will have to pay significantly more for someone willing to RTO.

I also think it only takes one unicorn to say "we did it by having everyone RTO!" to flip everything back around.

10yo+ B2B SaaS company we're still on Heroku. I think the value prop is particularly good for B2B SaaS and probably less so for consumer products. Our margin per customer is so much higher than the infra cost it just never makes sense to spend money on devops instead of building features.

That said it does feel a bit like a ghost town, I'm always happy to hear when someone is doing something over there.

We came up with a rule “no single use abstractions” so any abstraction with a single caller gets absorbed by its caller. We eventually had to say except across MVC boundaries (the project is MVC organized) or else we got some weird code organizations (controllers consume everything). It works pretty well though, in some cases we have some long methods, but really killed the premature abstraction “this will be useful in the future” discussions that eat a lot of time and energy. I think having a simple rule for everyone makes it easier to follow.

What a fun thread. I've always heard this as one of The Great Filters related to the Fermi paradox. FWIW the wikipedia for the Fermi paradox even mentions that:

> The most commonly agreed-upon low probability event is abiogenesis

...which I read as saying that the most commonly agreed-upon reason we haven't found life anywhere else yet is because we _are_ special and abiogenesis is the rare event (the great filter).

All the various great filter theories are pretty fun reading.