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.

Recent spending in CA (Sep 1-now) looks like it's heavily landlord associations running ads against prop 33, which would allow for new rent controls.

https://adstransparency.google.com/political?region=21137&to...

As a CA voter I find it very awesome that I could look that up so easily.

EDIT: The sort order isn't part of the URL, so you have to sort by Amount spent: high to low -- blew that one Google!

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.

Years ago I was driving home and saw a Corona beer billboard and distinctly remember thinking that I would love a Pacifico. So it kinda worked on me.

If you can afford to and you have a team dynamic where "everyone makes mistakes" you can give them more responsibility -- like other people being stuck until they actually fix the build. But that can backfire if they're very junior or the culture is very negative around making mistakes.

Otherwise asking them questions can help. Come from the place that you must be missing something and ask them why you can't get XYZ to work as expected. Make them figure out what the problem is. Really get in the mindset that you're missing something though, or it can come off as patronizing.

I’ve had the same experience mostly writing web apps in Ruby, which locks similarly to Python. Multi-threading is always needed to saturate IO, network, etc, never CPU, so GIL isn’t an issue. I always wondered what people were doing that ran into issues.

With Python being the language of choice for ML workloads I guess it’s more common to have the CPU be a bottleneck. It seems cool they’re making an option to turn it off for those use cases.

It seems like Python could maintain a GIL compatibility option to preserve the current/old behavior for legacy code.

Hmm well if I understand you correctly that's what I was saying as well:

Things go wrong when the DB trusts the application layer (rather than doing its own validation) -- e.g. the DB should control what is valid data, not the application layer.

I think someone mentions this every time nuclear power comes up.

It seems to me nobody is completely sure what the future will hold yet, except that we need to decarbonize energy production. Nuclear still seems like it could be a reasonable/viable/necessary option for decarbonized energy production.

The realistic worst case is that we waste some money building nuclear power plants that operate at a loss and are potentially decommissioned early.

Assuming we collectively have enough money to also keep building wind/solar/etc (it seems like we do!), and the risk of failing to decarbonize remains catastrophic, it's probably a good idea to hedge our bets and try all the viable options.

My guess is that we build a few crappy nuclear power plants with poor economics, learn some really useful things in the process, and then build some better ones with much more favorable economics.

FWIW I think I agree with you if you consider "critical processing of data" data validations (IME via constraints, checks, triggers, etc...). I think where things can really go wrong is when the DB accepts anything the application layer thinks is valid.

My favorite ORM says the same thing: https://sequel.jeremyevans.net/rdoc/files/doc/validations_rd...

I wouldn't be surprised if more people agree with that as well, maybe just using different terms.

I've recently dealt with multiple companies who started using IBM Aspera (which as a vendor to them means we have to use it too) only for it to work miserably. I've also seen a couple tiny, perfectly functional MySQL databases replaced by expensive, slower Oracle databases with much higher maintenance costs.

I think once a customer with a big enough budget is recognized by sales at one of these big organizations they make the sale happen. They talk to the higher-ups and either make them happy, or feed them a lot of FUD (or both), and then they're in, regardless of what the people working with the products (many of whom might be external vendors or consultants!) think.

They're basically focused on more traditional sales & marketing instead of more grassroots sales & marketing (mindshare), but at least in my experience they definitely still get new customers.

That sounds like Virgin America 20 years ago and I think it worked out well for them and for consumers. They had really cheap, reasonable flights, and they forced everyone else to put entertainment in the seat backs. I really miss their silly purple lighting and lounge music when you boarded.

I had this experience after the Equifax hack a while ago when something like 100M+ people's info was stolen. Until I froze my credit I was getting phone calls every few days asking if I had _really_ tried to open some line of credit I had never heard of. The people calling me explained that ever since the Equifax hack they had to do a bunch more due diligence because all they were getting was fraud. No lines of credit were successfully opened in my name, and the issue stopped completely once I froze all my credit.

I think the lesson is when bad stuff happens you really don't want to be in the small minority of people who it is happening to. Once it's happening to everyone then the problem actually gets solved.

We have some tests like that. We're injecting a stub to generate the error condition and then testing the output. The test code runs in the same thread as the server so we can temporarily inject a stub into the server for some cases.

You're right we have to know something about the system to know where to inject the stub, and in fact it makes the test brittle in case that implementation detail changes (which has actually happened and failed these tests before), but it doesn't really matter where we inject the stub to cause the error response, so it's not as bad as it sounds. I think it might be pretty analogous to knowing where to mock the JSON API w/ a non-200 response code.

We very rarely stub anything and consider it a code smell, this is one case where we made an exception though because there is otherwise no way to generate an error message via the user interface.

We do browser based end-to-end testing which tests the frontend and backend at the same time using a single tool (Capybara in our case). We take snapshots at various points during the test runs which are then compared to previous runs for visual regression testing.

Nothing is isolated so it's probably slower. The tradeoff is that the tests are really simple for how much they cover, and they're entirely separate from the implementation details so refactoring/changing technologies becomes really easy. It's an old project and we've incrementally migrated from jQuery to Backbone to React to Stimulus with the same tests. Conceivably we could change the app to a SPA and keep the tests.

I have no way to really know if it's better than anything else (though I am interested in that question!), but I think it has worked out pretty well for us. One metric might be that our main app has been around for 10+ years, we're still delivering features daily, and nobody is complaining about a rewrite.

Same boat here. I'm doubtful that we could take on the additional maintenance work for less than the Heroku premium we pay.

I wouldn't be surprised if I'm wrong and newer tools bridge the gap for a lower price and/or time investment, but I also wouldn't be surprised if I'm right and many places using Docker could save time/money offloading the maintenance to something more like a managed PaaS.

Maybe I missed it in the article but it looks to me like they're hiring more junior candidates. For more experienced candidates (which it sounds like you are) I think years of experience doing similar things in a similar field/organization would be the most likely thing to lead to a phone call.

I inherited a project where all the validations were in the forms and it meant that you couldn't reliably use the model layer without the forms layer (you'd end up saving invalid data). We eventually moved the validations to the model layer and dropped the forms abstraction. It didn't feel like the right separation of concerns when we had to pretend data was moving through forms to reliably interact directly with the model layer.

The enforcement of allowed params (and type casting from strings) definitely seemed like it was in the right place per-action in the control layer though, so we kept that from the forms even though we implemented it in the controllers.

I wonder if we just didn't understand the idea though? Or maybe if the original implementers didn't implement it right?

Yes if the user must retain their state after the modal closes a full page refresh would not be the right thing. I probably wouldn’t build Figma in Rails, but I probably would build a CRM in Rails.