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 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 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 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.