Alex Heath:

During internal testing, his team realized that if you don’t recognize a single artist in a playlist, you might question if it’s actually geared for you. That’s why the playlist is intended to have a mix of mostly new tracks with a few songs you’ve heard before.

“There’s something compelling about this humans versus robots narrative: a lovingly curated playlist versus an algorithm screwing up your sexy time,” says Ogle. “That whole distinction no longer really describes how we work. Discover Weekly is humans all the way down. Every single track that appears in Discover Weekly is because other humans being have said, ‘Hey this is a good song, and here’s why.’”

My Discover Weekly playlist has been hitting the spot and it’s interesting to get an insight into how they are put together.

Although Spotify has had humans making playlists for years, its efforts got a major boost last year with the introduction of Truffle Pig, an internal tool from The Echo Nest that breaks music down into thousands of categories like “wonky,” “chillwave,” “stomp and holler,” or “downtempo."

What you hear from everyone at Spotify is that humans using data insights are key to curating music on a large scale. Naturally, they’re also using data to evaluate how well playlists are working.

An example of data-centric tools aiding human decision makers.

Asymco:

This implies that the problem with enterprises is not the stupidity of its buyers. They are no less smart than the average person–in fact, they are as smart with their personal choices for computing as anybody. The problem is that enterprises have a capital use and allocation model which is obsolete. This capital decision process assumes that capital goods are expensive, needing depreciation, and therefore should be regulated, governed and carefully chosen. The processes built for capital goods are extended to ephemera like devices, software and networking.

It does not help that these new capital goods are used to manage what became the most important asset of the company: information. We thus have a perfect storm of increasingly inappropriate allocation of resources to resolving firms’ increasingly important processes. The result is loss of productivity, increasingly bizarre regulation and prohibition of the most desirable tools.

Dan McKinley:

If you think about innovation as a scarce resource, it starts to make less sense to be on the front lines of innovating on databases. Or on programming paradigms.

The point isn’t really that these things can’t work. Of course they can work. But exciting new technology takes a great deal more attention to work than boring, proven technology does.

Some fantastic points about what your job is when building software and the trade-offs that are constantly in front of you.

Stuart Butterfield:

The best — maybe the only?— real, direct measure of “innovation” is change in human behaviour. In fact, it is useful to take this way of thinking as definitional: innovation is the sum of change across the whole system, not a thing which causes a change in how people behave. No small innovation ever caused a large shift in how people spend their time and no large one has ever failed to do so.

This is the best definition for an overused term I’ve heard in a while.

The whole piece is an enthralling call to arms to a group of people building a product.

Ville Immonen:

JavaScript is evolving and new ES2015 and ES2016 editions (previously known as ES6 and ES7, respectively) pack a bunch of new features and Babel makes it very easy to use of them today. These features make some previously essential functions from utility libraries obsolete.

Truth Labs:

“Dashboard”, “Big Data”, “Data visualization”, “Analytics” — there’s been an explosion of people and companies looking to do interesting things with their data. I’ve been lucky to work on dozens of data-heavy interfaces throughout my career and I wanted to share some thoughts on how to arrive at a distinct and meaningful product.

I’ve been doing a lot of data-driven interface work over the last few years and the advice in this article is spot on.

Michael Feathers:

It’s funny. I can’t count the number of times I’ve seen organizations with large monolithic software applications move toward SOA. It’s easy to think that we’ve learned a lesson in the industry and that services are just the new “best practice.” Surely we would’ve started with them if we were just starting development now. Actually, I think the truth is a bit more jarring. Different architectures work at different scales. Maybe we need to recognize that and understand when to leap from one to another.

The process space has similar issues. If we cargo-cult anything from the small team space into the large organization space, we’re falling prey to a blind spot. We’re missing an opportunity to re-think things and figure out what works best for small teams, interacting teams, and large-scale development. They may be quite different things.

I agree that the rules are different for different organisation sizes. I like Michael’s comparison of moving across organisation sizes to state transitions in physics.

Vsevolod Dyomkin:

At Grammarly, the foundation of our business, our core grammar engine, is written in Common Lisp. It currently processes more than a thousand sentences per second, is horizontally scalable, and has reliably served in production for almost 3 years.

Simon Marlow:

Haskell isn’t a common choice for large production systems like Sigma, and in this post, we’ll explain some of the thinking that led to that decision. We also wanted to share the experiences and lessons we learned along the way. We made several improvements to GHC (the Haskell compiler) and fed them back upstream, and we were able to achieve better performance from Haskell compared with the previous implementation.

Agile Tortoise:

Terminology for iOS is based on WordNet, a great semantic lexical reference. We do not offer a full Mac app for Terminology, but have prepared a dictionary using this same great data for use in the built-in OS X Dictionary app.

Brian Marick:

So, interesting: an enormous amount of effort is spent on apps that convert map/vector-structured data into map/vector-structured data.

However, because of the mindshare dominance of object-oriented programming that came because of Java - “Smalltalk for the masses” - it’s hard for most people to think of an approach other than a pipeline of structured data -> objects -> structured data. The tools and frameworks and languages push you toward that. So: a programming model tailored to objects with serious lifetimes has been used for data that lasts only for one HTTP request.

Dave Copeland:

We’ve given up on “fat models, skinny controllers” as a design style for our Rails apps—in fact we abandoned it before we started. Instead, we factor our code into special-purpose classes, commonly called service objects. We’ve thrashed on exactly how these classes should be written, so this post is going to outline what I think is the most successful way to create a service object.

Some good advice for building service objects in Rails.

Michael Snoyman:

As of today Front Row uses Haskell for anything that needs to run on a server machine that is more complex than a 20 line ruby script. This includes most web services, cron-driven mailers, command-line support tools, applications for processing and validating content created by our teachers and more. We’ve been using Haskell actively in production since 2014.

An experience report on using Haskell in production.

Tony Morris:

In this talk, I will explain to you how list folds work using an explanation that is very easy to understand, but most importantly, without sacrificing accuracy.

I particularly like the constructor replacement analogy for foldr.

Elisabeth Hendrickson:

I prefer:

• Recovery over Perfection
• Predictability over Commitment
• Safety Nets over Change Control
• Collaboration over Handoffs

Ultimately all these statements are about creating responsive systems.

When we design processes that attempt to corral reality into a neat little box, we set ourselves up for failure. Such systems are brittle. We may feel in control, but it’s an illusion. The real world is not constrained by our imagined boundaries. There are surprises just around the corner.