Friday was my last day at LivingSocial. I’m moving on to a small team at a small startup that I hope will eventually be big. My tenure at LivingSocial was short - it would’ve certainly been longer had this opportunity not come along - but I learned a lot in the 14 months I worked there.

Sure, I learned stuff about Rails, Ruby, service-oriented architectures, asynchronous processing, and credit card payments. But that’s not what I’m talking about. Those skills are great experience and will look just fine on my resume, but I learned two things that made me a better developer:

• Deliver results, not promises
• Assume everyone knows what they’re doing

So, someone shared some code on Github and some classic developer snark rolled in. And then there were some apologies about it. I saw those snarky tweets when they came through, clicked to the Github project, didn’t understand what the issue was, and went back to work.

Now, I’m all for bad projects and bad code being called out. Our industry produces some shitty code, and a general lack of repsect for craft can kill business, or even people. So bad code needs to be pointed out. The question is, is this bad code? I think we can all agree that if it is bad code, we should try to point it out in a more constructive way (and I know it’s easier said than done), but let’s forget the tone and focus on the message. Is replace a silly project, or implemented in a stupid way?

No, it’s not.

Saw a blog post this morning titled Why Functional Programming in Java is Dangerous. Author Elliotte Rusty Harold sets up the world’s worst straw man I’ve seen. He talks about Uncle Bob’s post on the advantages of functional programming. Elliotte’s thesis is that Java and JVM just can’t handle this sort of thing, and then sets out to prove this with some terrible code that, unsurprisingly, is terrible. He takes this bit of Clojure

(take 25 (squares-of (integers)))

And “re-implements” it in Java. He does this by implementing integers to just allocate an array of all the integers.

Yeah.

Both DHH and Tim Bray make great points about “dependency injection” and its issues regarding Ruby and testing. My colleague Adam Keys makes a similar point, though doesn’t call his anti-pattern “dependency injection”.

The scare quotes are because neither DHH nor Tim are accurately representing the purpose of dependency injection. Dependency Injection is not about a framework, XML, factories, or testing. It’s about simplifying code. Let’s see how.

There’s been lots of talk about DCI in the Ruby community lately. As I mentioned, I am only partway through Jim Gay’s unfinished book on the subject, but I ran across a blog post that had a more substantial example in it.

Titled Why DCI Contexts?, someone named rebo, shows a starting point of “normal” code, then “DCIzes” it, then walks through adding new features to the system. It’s a bit long, but his explanation is great, and it shows a lot more than just calling .extend on an object - he clearly demonstrates how roles and contexts are used to implement specific use cases.

Despite the deftness of his explalnation, I find the result code entirely too complex, thanks to confusing abstractions, a needless DSL and leaky abstractions. It would all have been a lot simpler if he Just Used Classes®

Let’s see why.

Over the past several months, the Rails community, at least to my eyes, has become increasingly concerned with managing the complexity that appears when following the “fat model, skinny controller” advice prescribed by many Rails experts. The real issue, however, is reusability. How can logic be easily used in two places? In your average object-oriented language, there are four primary ways to accomplish this:

• Copy and Paste
• Inheritance
• Composition
• Mixins

None are so superior to the other as to always be applicable, so how can we know when to use one over the others?

Was having a discussion with Mike Gehard, Jeff Simpson, and Dan Hopkins about Dan Mayer’s excellent post, and we go on the topic of refactoring test code. My assertion is that you cannot, technically speaking, refactor test code, because you have no tests of the test code. Refactoring cannot be done without tests that assert that the changes you’ve made haven’t introduced problems.

The discussion put forth a few such tests of tests code, such as running it on prod, having the tests continue to pass, or measuring coverage. Unfortunately, none of these are sufficient to call changes in test code a refactoring. I would call it a rewrite or redesign, and I think that the distinction is important.

We were recently having a discussion at work about “doing it right” and “technical debt”. The discussion revolved around the optionality of “doing it right” - when is it OK to not “do it right”?

I would say it’s almost never OK to write code incorrectly. If your understanding of what “doing it right” means includes an “optional” clause, you have the wrong definition. As professionals, we should always do it right. We should always do our work correctly. I don’t mean we should over-engineer, nor do I mean that we should solve an abstract problem instead of the one in front of us for “flexibility”, but we should have a basic standard that we inflexibly hold ourselves to.

Writing code that does not adhere to our personal standards of correctness isn’t technical debt - it’s slop.

GLI 2.0 is out! GLI is the best way to make a “command-suite” command line interface. If you need to make a complex command line app that takes subcommands, like git or gem, GLI is the most powerful and easy-to-use way to do that.