1) Our Programs Are Fun To Use

I really enjoyed this one. As developers, we like to play with the ideas and test them out ourselves. Doing is almost always more engaging:

“But more than that, they taught me how much more fun it was to learn by playing with an interactive, dynamic program instead of passively reading about concepts in a book.”

The big takeaway for me is how this applies to READMEs. When I approach a README, usually I want an example, I’ll yank it out and play with it. Sometimes the code is old and rotted. Sometimes it takes effort to setup an environment to play with it. What if interactive playgrounds were as ubiquitous as READMEs?

2) My Answers for Microservices Awkward Questions

This is a nice, short Q&A about Jay’s experience with microservices. Some highlights of note:

“I find accidental coupling to be the largest productivity drain on projects with monolithic codebases.”

When questioned about how to coordinate a deploy of multiple microservices for a feature:

“We have a strict rule that no feature should require deploying separate services at the same time. If a new feature requires deploying new versions of two services, one of them must support old and new behavior - that one can be deployed first. After it’s run in production for a day the other service can be deployed. Once the second service has run in production for a day the backwards compatibility for the first service can be safely removed.”

I love the idea of constraining a feature in order to enforce a disciplined change process. The stability in the process is probably very comforting to their teams.

When questioned about whether or not to abstract out a microservice vs. a library:

“Something that’s strictly a library provides no business value on it’s own.”

This is an interesting heuristic. Most of the time, microservices are argued for in order to promote decoupling – it’s purely a high-level architectural decision. I’m not exactly sure how he defines “business value”, but I thought it was interesting that the heuristic didn’t have to do with an architectural question, so much as a “what type of behavior” question.

3) Patterns are for People

This blog is a rebuttal from Avdi about the idea that good languages have patterns built in as language features. Avdi argues that patterns are encapsulations of a developer’s experience and ideas. Ultimately, the pattern a developer uses is separate from the language they use. He writes:

“…patterns reflect how a particular team, or series of teams, managed to come to grips with a particular type of problem.”

And then talking about his study of patterns from software written for different industries:

“Very few of those patterns are foundational or even widely applicable.”

He finishes with the point:

“Patterns aren’t a language smell; rather, patterns are by definition, [optional] language features.”

I agree that patterns are a product of the industry the software is written in, and who writes it…but I think languages are, too.

Languages are abstractions to make it easy to move bits. Languages, by his definition, are patterns as well – formed from a specific environment and people. Whether we like a lispy syntax, or a object-oriented ruby approach, we are ultimately trying to do a similar thing, but in a different pattern. Patterns are inherent in languages.

So I’m not so sure that patterns are optional, since they are always present. The language itself is a set of patterns. And because of that, I think it’s fair to levy judgement upon a language based on the types of patterns it ships with.