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 For years, I’ve wanted to use social media to help draw attention to the blog entries I write. But manually posting to Twitter and LinkedIn about each blog entry was just too boring to contemplate. With this latest reboot, and the fact that I’m using a CI server to generate each post, I finally decided to break down and automate the process.
tl;dr In November of 2013, through a chance conversation with a casual acquaintance, I happened across what would turn out to be a pretty significant shift in my career path. After two years as the CTO of iTrellis, it’s time to move on.
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?
tl;dr With a static-site-generated blog, it was getting painful to do all the steps necessary to push a new post out the (virtual) door. So I did what any good DevOps-minded engineer would do—I put TeamCity on the job.
tl;dr Don’t hedge your answers when somebody is asking you for a commitment; “Do, or do not. There is no try.” (Yoda) Saying “maybe” is, at best, your way of preserving your ego, and at worst, your way of trying to avoid a commitment.
tl;dr I’ve found a new blog that I’m enjoying reading so far, and thought readers might want to browser-bookmark for future consumption.