Interesting Shares

and why is it mandatory?

Some companies' C-suites have gotten their heads so far up their asses on AI that they've entirely forgotten about making money and the only metric they care about now is whether their company is using AI more than their competitors.

It's no longer about 'how do we use AI to make money?' -- it's about 'how can we spend money to increase AI usage?'

I was only saying I was worried it might become mandatory in the future.

But I'm pretty certain my employer will establish a corporate account with Microsoft for Copilot whereby my employer's employees get the premium Copilot "features" (I use the term loosely) by logging in to Copilot using their employee credentials through some SSO integration between the two companies. And then Microsoft will probably provide usage data on a per-employee basis to my employer.

My employer has a setup almost exactly like this with at least one other SaaS provider. The one I'm thinking of isn't an LLM provider like Copilot. But my employer has made it clear that a) they're monitoring usage by employees and b) usage (to the tune of a certain number of hours per week) is mandatory.

Honestly, hard disagree. It makes building a skeleton application really quick, but it's so magical. As the guy who people come to when they've been banging their head against a problem (because we bumped the version on one random serialization library and now the org.springframework.core.initializer.GenericSecurityPolicyContextFactoryConfigurationProviderServiceScannerImpl doesn't work, so we're faced with days more of Jar hell) for days, I'd much rather we just use Servlets directly without involving Spring at all. (And god help us if we ever attempt to upgrade our Java version.)

Servlets was supposed to make everything easier. It 100% has its warts. (Servlet containers are pretty heavy. JSPs are terrible in every way. One of the things I hate most about it is that there's no way to render a JSP to a string (for instance, for rendering email bodies) short of making a request back to a dummy endpoint on the same application that only does rendering.) But it's comparatively very clean and explicit, avoids 100 layers of magic, keeps your list of dependencies small, it's very obvious how you'd do any particular thing with it, etc.

But people decided it wasn't good enough and built Spring on top of Servlets to supposedly make things easier. I have to imagine it was built by the sort of people who would "fix" their cracked foundation by adding a new story to their house. If anything isn't acting right with Spring, you have to understand both Spring and Servlets to be able to fix it. And as I've probably mentioned a few times, Spring is suuuuuuper magical. And integrating other third-party things with Spring involves voodoo every time.

And then everything was good! Just kidding. Everybody agreed that wasn't good enough either. So did they fix Spring? No. They built another story on top of the failing foundation. Spring Boot. Which adds still more layers of magic on top. I'm no fan of XML, but I'd rather deal with a web.xml file than try to figure out what the hell any particular Spring annotation is actually doing (because it isn't working) any day.

Aside from that, you look for fixes online, and you get a Stack Overflow post with 8 completely different answers and just have to hope one is right. So I've learned not to even search for answers on places like Stack Overflow. Typically, I'll go straight to the Spring source code when people come to me with issues -- because they know I'm the only one brave enough to embark on such a spelunking mission. Spring isn't really intended to be understood. It's meant for people to throw... let's say spaghetti... at the wall until something happens to stick.

Bah! You got me on a rant. Lol. I'm not really familiar with any other Java frameworks. But last time I worked in Django, I loved it. It's not magic and it is intended to be understood deeply. (Hell. I've written ORMs in Java inspired by Django's ORM because it was so understandable and elegant.)

Anyway. In short, my experience with Spring has been exactly the opposite of yours, apparently. I think the context is one of the more innocuous parts of Spring, and I don't think it's that much of a concession to use that.

Maybe I hate Spring because I'm the person that people come to when it's broken, so every time I have to think about it, it's because there's some headache that it's causing. But then again, maybe everyone else on my team would hate Spring too if they didn't have me to externalize all the issues it causes onto. Lol.