> You don’t need to signal brilliance; you need to generate good-enough results quickly. As a previous academic now working in industry, this stuck out for me.

> You don’t need to signal brilliance; you need to generate good-enough results quickly. As a previous academic now working in industry, this stuck out for me. "good-enough", and "quickly". On the whole I understand where the article is coming from, but I think some of the things it brings up, while maybe true, are actually rather unhealthy trends. I don't know for sure, but I feel like things used to be a little less like this 10, 15 years ago. What I'm referring to is the refusal for companies to properly invest in knowledge. At least in my limited experience so far, I find that I've been asked multiple times now to start a project from scratch, or given a shoddily written codebase as a starting point, and told to add features / generate results as quickly as possible, take as many shortcuts as possible, just deliver some PoC or minimum viable solution so that we claim support for something or put it in our marketing material asap. Meanwhile there is zero effort to take time between projects and actually develop general knowledge and excellence in a particular field. Many times now I have felt that the company would really, really benefit from just giving the team 3 to 6 months to fully study a topic, not as part of a project, but as a general knowledge gathering exercise, to experiment with different methods and implementations and just explore and see what is possible with the data that we have. The idea being, that when we do start a project for a client, we really know what we're doing and know what are the best tools to reach for to solve the problem quickly and well. Instead what happens is that every now and then some idea comes down from on high, either from management or sales, that some "concept" must be proven immediately, like give me something in 2 weeks, don't worry about the code architecture for now (3 months later, still hacking on the poorly designed codebase that gets passed on to the next team..) and don't worry about studying the optimal solution, just jump right to implementing something. There is just no sense of, you know, let's invest some time to really properly study this and become proper experts so that we can be the best. Every single time it's just, let's solve this problem from scratch with barely any time to try more than 2 things, and then when we get mediocre results, we'll scratch our heads and have no idea what went wrong because we don't really know what we're doing. Compared to academia, where if you don't fully understand what you're doing, someone is going to catch you with a bad analysis, or invalid assumptions etc. Instead the "closed" way things work in industry lets one away with hiding poor methods and choices from your competitors, and show publicly a very "shiny" version of what you really have. Having said all that, there are many positives, like you can actually implement something that will be used, and you can work on interesting, applied problems, and get paid well for it, which is honestly really helpful for motivation. And, as the article says, it actually is less stressful not having to constantly defend your intelligence, or fight for publications and grant money, but just gaining trust in people by delivering good work in a timely manner. In that sense it is far simpler and, frankly, more lucrative, so the upsides do outweigh the downsides imho. But the lack of planning for the future and general long term thinking do rather bother me.