tl;dr As part of preparing for a workshop next week in Poland, I’ve been diving back into the CLR source code—which takes me back to my old friend, Rotor.
More than a decade ago, I published Effective Enterprise Java, and in the opening chapter I talked about the Ten Fallacies of Enterprise Computing, essentially an extension/add-on to Peter Deutsch’s Fallacies of Distributed Computing. But in the ten-plus years since, I’ve had time to think about it, and now I’m convinced that Enterprise Fallacies are a different list. Now, with the rise of cloud computing stepping in to complement, supplment or replace entirely the on-premise enterprise data center, it seemed reasonable to get back to it.
At first, it was called “DLL Hell”. Then “JAR Hell”. “Assembly Hell”. Now, it’s fallen under the label of “NPM-Gate”, but it always comes back to the same basic thing: software developers need to think about their software build and runtime dependencies as a form of Supply Chain Management. Failure to do so—on both the part of the supplier and the consumer—leads to the breakdown of civilization and everything we hold dear.
tl;dr Once again I find myself in the position of needing to call BS on a blog post and deconstruct it: Yes, it is possible to be a good .NET developer, and here’s why.
tl;dr Hadi Hariri has made a few observations regarding the churn we’re seeing in the Microsoft open-source space (around .NET Core and ASP.NET Core, among other things). But I don’t think this is a permanent state of affairs; what I think is going on is that Microsoft is finding that managing an open-source project is more than just owning the GitHub repo and just reviewing pull requests.
tl;dr Peter Verhas asks a seemingly innocent question during a technical interview, and gets an answer that is not wrong, but doesn’t really fit. He then claims that “Sometimes I also meet candidates who not only simply do not know the answer but give the wrong answer. To know something wrong is worse than not knowing. Out of these very few even insists and tries to explain how I should have interpreted their answer. That is already a personality problem and definitely a no-go in an interview.” I claim that Peter is not only wrong, but that in addition to doing his company a complete disservice with this kind of interview, I personally would never want to work for a company that takes this attitude.
tl;dr By now, everybody in the tech industry has heard that Microsoft and Xamarin have come to terms and Microsoft will acquire the cross-compiling mobile development tools vendor. This is a good thing for both parties, and aside from watching Miguel de Icaza pop the cork on some very expensive champagne and celebreate with his people, there’s a number of things to think about. Here’s my thoughts around the next steps for Microsoft (and the Xamarin division within Microsoft, however that looks), as well as for people using Xamarin.
tl;dr I’ve been asked a number of times over the years how, exactly, I approach learning new stuff, whether that be a new programming language, a new platform, whatever. This is obviously a highly personal (meaning specific to the individual offering the answer) subject, so my approach may or may not work for you; regardless, I’d suggest to anyone that they give it a shot and if it works, coolness.
tl;dr My first (!) course is up at Pluralsight: “On Polyglot Programming”.
tl;dr It’s been a few years since I did this particular routine for the NFJS shows, but I found a sequence of demos/explanations that really demonstrated clearly why Java (and other classic O-O) developers should learn a little functional programming style, even if they never pick up an actual functional language. And the key to that sequence of demos? “Collections are the gateway drug to functional programming.”
tl;dr A recent post on medium.com addresses the topic of technical debt; I had an intuitive disagreement with the thrust of the post, and wrote this as a way of clarifying my own thoughts on the matter. It raises some interesting questions about what technical debt actually is—and if we can’t define it, how can we possibly understand how to avoid it or remove it, as opposed to our current practice of using it as a “get-out-of-this-codebase-by-blowing-it-all-up” card?
It’s really starting to appear like the “technical monoculture” that so pervaded the 90’s and 00’s is finally starting to die the long-deserved ugly death it was supposed to. And I couldn’t be happier.