I disagree with the analysis, although I liked the opening paragraph. Why separate the economics of interest rates from the economics of AI productivity?
The just-say-no engineer was a ZIRP phenomenon
31–40 of 140 posts
Re: The just-say-no engineer was a ZIRP phenomenon
#32I agree with this take for experienced and capable engineering teams. Three times over the last three years, I have told my senior engineers to skip code review, and nothing catastrophic happened, and recovery from bugs was rapid. Three times I have been told by engineering management to reimplement code review. Now that management is either gone or about to be gone.
Few times bugs causes unrecoverable data - and code review are needed again.
Re: The just-say-no engineer was a ZIRP phenomenon
#33I agree with this take for experienced and capable engineering teams. Three times over the last three years, I have told my senior engineers to skip code review, and nothing catastrophic happened, and recovery from bugs was rapid. Three times I have been told by engineering management to reimplement code review. Now that management is either gone or about to be gone.
It is a bit frustrating when you want to do risk based approach but then it is much more work to explain it to people who don’t know better but they want a checkbox or read on the internet “that’s proper way of doing things”.
Another example is password complexity rules, we try to use latest recommendations with no forcing of PW change, no requirements beside length - but then there will be customer that will make fuss that we don’t have it as as it is compliance check box to have complex PW.
Re: The just-say-no engineer was a ZIRP phenomenon
#34There’s this trend that tries to sell the idea that, if LLMs and agents have any shortcomings, instead of them getting better we should lower the standards. Focus on the “MTTR”. Is the code bad? Don’t read it. Don’t review it. Remove the bottleneck (the human in the loop). This narrative is all over the place.
This tech is quite useful, and I wish we focused on how to work with the tool better and improved our processes around it instead of treating the symptoms.
Re: The just-say-no engineer was a ZIRP phenomenon
#35[deleted]
Re: The just-say-no engineer was a ZIRP phenomenon
#36I agree with this take for experienced and capable engineering teams. Three times over the last three years, I have told my senior engineers to skip code review, and nothing catastrophic happened, and recovery from bugs was rapid. Three times I have been told by engineering management to reimplement code review. Now that management is either gone or about to be gone.
Few times bugs causes unrecoverable data - and code review are needed again.
You have engineers that can say “hey this DB change might be risky let’s take second person to review it”.
No one is forbidding reviews.
But if you have a junior pushing code that can cause unrecoverable data loss his code should be reviewed.
Re: The just-say-no engineer was a ZIRP phenomenon
#37I low key disagree with the majority of this.
First, i dont think the low interest rates did that much for “tech companies” who were already cash cows which is usually the bench most people speak about. Small companies already operated in a no free money era as they never had the capital access to begin with.
Covid had a big hiring spike in tech and then it sloft off once rates went up. More of an excuse than real market conditions although startup, for sure impacted. Lets not even start with the political “org building” that still drives the “no” mindset today.
Second, ai has now been in the mix for at least a year now where it is objectively useful. I have not seen a single project complete faster than it would have pre ai. Stability is a wash trending to worse than pre AI.
The rigor is what is see draining slowly. You can be fast, say yes, and use ai all while maintaining some kind of quality bar.
Re: The just-say-no engineer was a ZIRP phenomenon
#38Just-say-no is a Quality Control mechanism.
You need someone to say: this shit is not going to prod, unless its value is obvious to everyone
Re: The just-say-no engineer was a ZIRP phenomenon
#39There’s this trend that tries to sell the idea that, if LLMs and agents have any shortcomings, instead of them getting better we should lower the standards. Focus on the “MTTR”. Is the code bad? Don’t read it. Don’t review it. Remove the bottleneck (the human in the loop). This narrative is all over the place. This tech is quite useful, and I wish we focused on how to work with the tool better and improved our proces…
Aren't people working on both? I'm sure the AI labs are working on their end of it. People are building better agents. You can work on skills or tweaking your AGENTS.md.
There no end to what you can do, but the question is how much time you devote to that versus your actual project.
Re: The just-say-no engineer was a ZIRP phenomenon
#40> Having half of the company’s engineers enmeshed in an endless loop of proposing changes and being told no was totally fine - they didn’t need to be productive anyway, and this way they weren’t impacting business-critical systems. Well, it's a take. This is pretty cynical.
There are many stories of FAANG hiring during that era for the purpose of denying talent to competitors. But now that you hired them, what will they do? And how will you keep them from creating problems?
It sounds cynical in retrospect; at the time the same set of facts were explained differently, in a way that didn’t hurt people feelings.