These days, it seems that almost everybody wants to learn to code — and if you believe all the boot camps and book titles that have surfaced over the past two decades, you might think it's also easy to do. It seems to me that the latest generation
As a longtime Ruby programmer who has just recently begun to focus more on Clojure, I find myself continually surprised by all the little treasures that Clojure offers. One of those treasures is Clojure's sophisticated support for destructuring -
Lately, I've been working on Satellite, an open-source monitoring solution for Mesos clusters. It has become clear that Satellite needs to be easier to install and configure, and that we may need to change the very nature of its configuration files.
As developers we're tasked to take a problem specified in the fuzzy language of human interaction and translate it into a representation that can be understood by a machine. To do that we have to simulate the machine in our heads, and manually trace
Who's afraid of big bad technical debt? Every conscientious software engineer knows about technical debt. Lots of us learned the hard and painful way that deferred refactors and sloppy code can and will come back to bite you eventually. Since we
As a developer you will always encounter situations where there are multiple ways to accomplish the same task. Evaluating your options can be done by acting as if you are reviewing the resulting code. The 4Cs are a useful tool for doing this and
MojoTech Developer David Leal continues his series on Living Documentation. Be sure to check out The Why and The How. In my previous article, we discussed how we should write living documentation. In this article, we’ll explore how we can write the
David Leal (@ior3k) shares some thoughts on the documentation process. Update: Part 2 of the Series: How to Write Living Documentation If you are a software developer, I hope by now you have realized that you're much more than a "code monkey". If
Whenever you write code, you hold certain assumptions in your mind. You expect some conditions to be met, and you promise that, if those conditions are valid, you’ll do something in return. But sometimes your code fails to convey those assumptions.