Google has a separate user-agent identifier in for robots.txt for AI products that can be blocked separately from the search crawler. Many sites block the AI crawler while allowing the google search crawler. AI content is controlled using googlebot-extended user-agent
GCF still suffers from JS lock-in, as they currently only support Node, thus you can't make a .NET comparison in the first place. That being said, of the various offers I really like the UI and the like.
If you're going to be handling http requests it's almost a given you'll be using AppEngine rather than Cloud Functions. Still "serverless" but more tools and languages to choose from.
Not the flexible environment iirc. Which is basically the reasonable env to expect, now. Standard env has some aging issues that keep getting worse. most notably jvm 7, if that’s your poison, but just all round crippled env lacking standard libs and with lock in substitutions.
> If you're going to be handling http requests it's almost a given you'll be using AppEngine rather than Cloud Functions
Why? Cloud Functions support HTTP.
I mean, if you can stay within AppEngine’s free tier quotas, there's a clear reason to use it, but otherwise it would seem to be a matter of weighing pros and cons, with HTTP alone not deciding that you should use AE over CF.
I think this problem derives from the nature of and incentives of people. What happens is that certain managers (and founders) have derived their success from pushing certain directions that have added a lot of value.
Usually long term initiative take a lot of domain knowledge and a specific set of connections. When something new becomes more important, they risk losing their personal position since they may not be the best person in terms of knowledge and connection to carry out the new direction. Instead they try to use their accumulated power to keep their direction supported even when it's not in the interest of the business for as long as they can.
To address this, perhaps there's merit in rewarding timely exits and somehow punishing people that have dragged things out. However the most that companies can do is usually just fire someone. And at that point they have probably sucked the company dry of the value they can personally extract.
The only line in Buffet's quote I disagreed with was "rationality frequently wilts when the institutional imperative comes into play", and this is why.
It would be awfully surprising if virtually all companies had the same problems due to smart people suddenly behaving irrationally in the same way. It's much less surprising that smart people behave rationally in their own interests, but that those interests regularly fail to align with overall company interests.
And I think the pattern you describe is even mirrored on an institutional level. People are quick to mock Kodak for ignoring the rise of digital cameras, but they tend to undervalue the amount of risk that pivot would involve. If you're a world leader in product X, and that gets replaced by product Y, pivoting destroys the value of your expertise and puts you at risk. It's unpopular but perhaps sensible to settle on winding down profitably (the institutional version of a timely exit) instead of pivoting.
I wonder if taking such a view can be short-sighted. While it is true that employee turn-over can be costly, perhaps that is also one of the ingredients that make tech successful. The valuable employees that you hire have gained their skills at a number of other companies and the employees that have left are contributing to other companies. While this isn't on your balance sheet, it is contributing to the tech community as well. I wonder how you would go about quantifying this.
From my experiences, those in tech for the most part have come from the tech community and stayed in the tech community. Employee mobility is creates a mixture of ideas and also lets individuals to be trained in certain disciplines by those that are most capable at it. In return, companies get employees that were well trained by other companies thus increasing the value of tech companies as a whole. I wonder if this becomes a trend and companies try to close their borders tighter (somewhat reminiscent of U.S. politics right now, huh?) that companies will see short term gains, while the entire industry would suffer in the long run.
Don't forget acquisitions though, you don't need to be public to be acquired and those deals also cash out vested employees.
We can talk about if that's favorable or not relative to an IPO, but public offering isn't the only way out. Actually, I expect acquisition is probably a more common exit for employees than IPOs.
Some larger private companies buy back shares as well to help employees with liquidity. It still sucks being relatively cash poor as an employee for multiple years when your company is valued at billions of dollars.
As you get experienced, I think it's beneficial to be able to learn to be both fast/sloppy and slow/meticulous given the circumstances. Having worked in both enterprise scenarios and startup environments, I've learned that it's really a result of larger environmental pressures.
If you're working in long-range software, it's by far more beneficial to be a bit slower and more meticulous in your approach. What you're really looking for is incremental improvements that have large impact because the scale or importance of the project is already established to be very big. While you feel like you're not getting much done, the impact multiplier in these situations is very large.
However, when you're in a startup environment, you don't have any value in the product yet, so you have to move fast. A few bugs here and there are not really a problem since you will probably redesign and revamp different features. Testing is a lower priority and you feel like you're moving a lot faster as a developer.
I think healthy teams have a healthy spread on these trade-offs, centered about around the maturity of the team/product/company. Tension between the two sides keeps things moving forward and allows adjustments to keep the machine moving forward as best it can.
The 10x developer that isn't actually a 10x developer, but continually gets to start projects! So they get to do that part where you can make 80% of the program in 20% of the time. They slap it together, and move on to the next big thing. Leaving everyone else to clean up their rushed mess that barely works.
That's probably the appropriate way to tackle new projects, you know. Most ideas suck. Therefore the first (few) versions of such software is perfectly reasonable if it's rushed.
I hate that I work at a big company and we get into new project discovery mode and then take 3-5 weeks to code up extremely over complicated prototype programs. But they have tests (usually more than code), they have "good design", they have code that's reviewed and sent back at least thrice, they're stable, they've got monitoring, ... And they take huge amounts of time.
The one quality all of that has is that everybody agrees it's a good idea. When trying to quantify what that means ... I completely fail.
The design always fails to account for something. I have had it happen once that the initial design actually lasted to "v1.0", in 3 years. So I'm becoming unsure what makes a design good, except everyone agreeing that it's good and a certain "clean" look there is no difference between a good and bad, clean and messy, thought through and ad-hoc. Good designs don't survive a few feature iterations any better than bad designs, but they impose lots of extra costs on feature iterations. And that's assuming people don't make the mistake that turns the best of good designs into horrible designs : sticking to it. Attempting to fit new features into a design that didn't account for them can make the most beautiful design an utter disaster.
Same thing about reviews. Reviews seem to make people make huge changes in one go, because that feels much better if people regularly argue about much of it, compared to having to redo a change that by the time it's reviewed 5 other things depend on, where you get to throw out the 5 other things. And of course fairly commenting on huge changes is not done because pretty soon you'll feel guilty about the amount of work you're causing. Which is exactly why people have a better experience making huge changes, of course.
Tests ... never prevent bugs. Now I'm not saying tests don't have value, but the current testing culture is utterly and completely broken. I've simply decided to hack the system : a cli to your methods that allow you to quickly do ad-hoc tests and record them into generated code. Why ? First, it allows you to test against real-world data, which means your idea of what your code does actually meets real world data instead of artificial cases that may miss the point in the same way your code does. Second it allows you to quickly regenerate the tests if there is some big change needed. And thirdly it completely hacks the system. Getting coverage is trivial. And your LOC stats will be through the roof. Double bonus if you do this for less-than-expressive languages like C and Go, it's less necessary for things like Java and C++.
But "best practices" seem to make everyone happy in big companies, make everything take very long, and because of that very often cause the failure they're trying to prevent. It's like in chess : people like "safe" moves once you've beaten them once or twice. And in 10 moves or so they get themselves into a situation where they have to give up that safety, and your "haphazard" moves turns out control 80% of the board and fighting from that situation is not going to go well. But it's the desire for safety, the fear of loss, that's exactly what's causing their loss. They don't see things this way, though. If only they'd moved this piece to cover that as well, then it would have been fine. It doesn't even seem to matter if you show them that no, it wouldn't have been fine. That the issue was their attempt at securing what they did resulted in a complete takeover by the other party.
And every attempt I make at changing this fails, often with people having emotional breakdowns and complaints. And then their projects fail, again and again. Multiple times people have been very angry at me for providing a solution to some problem they were doing a 2 year project, restarted from scratch 3 times, for by writing a 300 line script that utterly kills interest in their project because it works and solves the problem. Apparently that "violates trust".
I don't understand why businesses want this. It keeps the peace, yes, practices like this, at the cost of efficiency, at the cost of developer sanity (developers wash out after about 5 years despite the current employment conditions, and often become non-developers. Hell, several people I know became accountants and prefer it over software development. Seriously).
And despite this, people seem to further down the rabbit hole every time I seem to look at it. WTF ?
I actually think this is exactly the point. He is talking about how these people are highly intelligent but not successful because society isolates them and doesn't give them the opportunity and motivation to learn those skills in the appropriate window.
This is kind of the opposite of students that are underperforming that don't get the attention to help them keep up. Instead these are students that can overperform, but don't get the challenges, validation, and motivation - the general positive feedback - that will help them grow and succeed. Instead they are meet with disapproval and neglect since teachers both dislike them asking hard questions (thus challenging their authority among already hard to control kids) and don't have time to give them the attention they need (since they are most focused on the largest median group).
See https://developers.google.com/search/docs/crawling-indexing/...
In fact NYT does block google from using its content for GenAI products:
User-agent: Google-Extended Disallow: /
As well as chat gpt
User-agent: GPTBot Disallow: /
So idk why this would be unexpected.
See https://www.nytimes.com/robots.txt