blakehaswell

  Imagine you've implemented a large program in a purely functional way. All the
  data is properly threaded in and out of functions, and there are no truly
  destructive updates to speak of. Now pick the two lowest-level and most
  isolated functions in the entire codebase. They're used all over the place,
  but are never called from the same modules. Now make these dependent on each
  other: function A behaves differently depending on the number of times
  function B has been called and vice-versa.

That sounds like a terrible design decision.

Having two functions which are used all over the place by different modules, and then linking their behaviour to some piece of state that wasn’t passed into either of them is a terrible idea. Suddenly that state becomes an implicit argument AND return value, and I have to know about that before I can call the function… Not only that, now I’ve lost my ability to reason about the behaviour of the function independently from the execution of the program. Further, functions A and B are now impossible to test in isolation. I need to actually call A multiple times before I can test B properly. Then once I’ve done that, well I’ve already called B a few times, so how do I test A? I’d have to have assertions for the behaviour of A and B tangled up in the same tests…

This is a mess, whatever programming language/paradigm you prefer.

Yeah, my experience has lead me to believe that planning the solution in relatively high detail before touching my keyboard leads to faster feedback, better designs, and fewer bugs.

I’ll generally take a pad and pen and write down my requirements and assumptions. This helps flesh out any further information I’ll need before I begin.

Once I’m satisfied that I understand the problem I’ll sketch out a planned architecture (dependency graphs, data structures, etc). If this uncovers more missing information then I’ll get that information and revisit the requirements and assumptions. Sometimes the missing information is that I don’t actually know how to do something in the particular environment I’m coding in. In that case I’ll prototype the minimum code I need to figure out how to do what I need to (I never use the prototype in production code).

Once I have a planned architecture that I’m happy with, writing the tests and code is relatively mechanical and straight-forward.

I’ll do this for pretty much any change to a codebase that is more complicated than changing a single function.

> We can understand our own unhappiness as workers not as a psychological problem that demands Prozac, but rather as a human response to domination.

As someone who has struggled to find enjoyment at a job working on products I didn’t believe in, I found this line particularly poignant.

Thanks for posting this, it’s the truth.

And it’s exactly why my wife and I are leaving our jobs to cycle around Europe for 10 months. I don’t know what will happen, but I’m diving in head first and I can’t wait to grab life by the horns and do something real.

Life is WAY too precious to waste it working for the man.

But those are the most important and interesting discussions to have, so I’m not convinced we should shy away from that sort of feedback.

That said, they’re also the sort of discussions which should often happen before code is written. Decisions can be changed much more quickly at that point, and people take it much less personally when you talk about how the design of something can be improved when they haven’t spent the time to implement it. :-)

Agreed. Generally I would argue against combining data and behaviour, for the very same reasons that the author wrote these abstractions.

However, I think there are better methods available. For example I would much prefer to organise related behaviour using Node modules (using Browserify if it’s a client app), which give you an extremely understandable way to group related behaviour AND hide private state.

Good article, but I wanted to point out that the looping and comprehensions stuff isn’t really much different with ES5’s array methods.

The first example can actually be written as the much more readable:

  myArray.forEach(function (item) {
    // do something with item
  });

While the second example can be written as:

  var myNewArray = myArray.map(modify);

That’s 64 billion messages sent through a single company. 64 billion messages sent using a single company’s proprietary application, communicating with their private servers using their proprietary communications protocol.

I find that kind of disturbing. What happened to that “decentralisation of the web” thing?

I’m sure there are better ways. But this is something we’re trying, and in the early stages it seems to be working well for us. YMMV.

As for the metrics… from the studies that I have seen, the effect pair programming has on these metrics is related to the complexity of the tasks.

For simple tasks, pairs don’t complete work significantly faster or with significantly fewer defects (so you’re essentially spending 2x effort for the same result). But for complex tasks, pairs tend to complete the work slightly more quickly and with significantly fewer defects (so you’re spending nearly 2x effort for a better result).

Given that our team was taking a long time going back-and-forth in this code review stage, we decided it would be worth expending the effort up-front to produce more correct code and (hopefully) reduce the time we were spending ensuring the code was correct after-the-fact.

I’m not sure that this will increase our teams velocity, but I think it might increase moral. Nothing sucks harder than finishing a task and then being told it’s not good enough.

I’ve been using a 11" Macbook Air (2011 model, 4GB of RAM) for the past 2 years as my primary dev machine and it hasn’t skipped a beat.

I’ve worked on everything from Spring projects to NodeJS projects, and I’ve used editors including Eclipse, WebStorm, and Sublime Text 2. I’m also a heavy Photoshop and Illustrator user.

Occasionally I have experienced problems where I’ve run out of physical memory while running Photoshop, Illustrator, WebStorm, and Chrome at the same time, but those problems have been very rare. Those problems have also been non-existent since switching from WebStorm to Sublime Text 2.

I would definitely recommend an Air as a dev machine, but get a memory upgrade if you can afford it.