Most of us in software (and probably in other fields) know about hero culture. It’s a concept everybody loves to hate. The term refers to an environment where individuals work in isolation and thrive on receiving sole credit for their work. This is generally perceived as leading to inflated egos and poor cooperation among developers. It’s the same phenomenon you see in professional sports, when star athletes are sometimes accused of not being good “team players” and getting greedy with the ball, wanting to be the center of attention.

So there are social reasons to dislike hero culture. There are plenty of practical reasons, too. One involves a principle known as the bus factor: the more you rely on a hero, the more vulnerable you are in the event of losing him or her—e.g., if he or she is hit by a bus, or leaves for another company.

But you guys know me. If everybody else is going left, I’m going to go right (a highly predictable trait that my friend Sameer frequently reminds me of).

If you turn away from hero culture and sprint in the opposite direction, you’ll eventually start getting into what I’ll call Borg culture.

Borg culture is the antithesis of hero culture, where every individual is functionally equivalent. In a Borg culture, there is no place for glory or arrogance. There’s also no pride and no personal ownership. I would argue that this isn’t really better.

A while back I wrote about software engineering versus software craftsmanship. In general, I think most of us would associate my description of “engineering” with what is typically done at larger corporations—less personal, more mechanical. That sounds like Borg culture. Actually, I think it’s just the opposite. Big companies are notoriously conducive to hero culture, ... (read the full post)

I recently started a JavaScript project called Lazy.js that’s been getting quite a lot of attention. Essentially the project is a utility library in a similar vein to Underscore or Lo-Dash, but with lazy evaluation (hence the name).

The reason I think the project has been piquing the interest of so many JavaScript developers is that it offers the promise of some truly solid performance, even compared to Lo-Dash (which is itself highly optimized in comparison to Underscore). This chart shows the performance of Lazy.js compared to both of those libraries for several common operations on arrays of 10 elements each on Chrome:

You can read more about what Lazy.js does on the project website or in the README on its GitHub page. In this blog post, I want to write a little bit about how it works, and what makes it different.

A different paradigm

Fundamentally, Lazy.js represents a paradigm shift from the model of Underscore and Lo-Dash (starting now I’m just going to say “Underscore” for brevity), which provide a host of useful functions for what I’ll call array transformation: each function accepts an array as input, does something with it, and then gives back a new array:

This isn’t how Lazy.js works. Instead, what is essentially happening at the core of Lazy.js is function composition: each function accepts a function as input, stores it, and gives back an object that can do the same. Then ultimately when each(fn) is called on the last object in the chain, it composes all of those functions together, effectively changing the behavior of fn.

Let’s take map as an example. The idea of mapping is simple and something we do all the time; it basically means translating or converting.

Here’s some ... (read the full post)

Looking back on some of my recent posts on this blog, I’m a bit annoyed at myself for being too hand-wavy and not saying anything all that original.

I’d like to make an effort, at least in my next few posts, to get more concrete and challenge some of the conventions I’ve observed in the software world. I’ll start with an idea that I think is not all that radical, though it would mark a sigificant departure for most teams I’ve worked on.

How we think about priority

The way most teams prioritize work seems totally sensible on the surface. Essentially, tasks are assigned some priority ranking such as “high”, “medium” or “low”; and then the highest-ranked tasks actually get assigned to people. In a perfect world this would mean that the most important things always get done, and then when there’s a surplus of time a team can “catch up” on issues that aren’t quite as urgent. In practice I think a different reality tends to emerge.

On projects I’ve been a part of, inevitably it turns out that the “high-priority” work is the only work that gets done. We never seem to run out of high-priority things to do; and so there ends up being this giant mountain of “low-priority” issues that, if we’re honest with ourselves, will never be tackled. Which would imply that more and more important things keep always coming up.

But either this isn’t true, or it shouldn’t be.

Other than the fact that it just doesn’t seem reasonable that such a curve could actually represent reality, I see two problems here. First, the accumulation of many small bugs over the life of a project brings the quality of the software down, which is a sad state of affairs. Have you ever encountered a ... (read the full post)

I bet you weren’t expecting any sane developer to make this argument!

Well, to be fair, the title of this post is somewhat intentionally provocative. But anyway, you’re here now; so it served its purpose. And make no mistake: I am going to defend global state—just possibly not in quite the way you might be expecting.

What we mean by global state

First, some background. If you’re reading this, there’s a good chance you’re a developer so I probably don’t have to explain this; but I think there are at least two forms of global state that come to mind in software. One form is global variables–values that are accessible and can be changed, globally, anywhere, by all of the code in a project. The other is constants–values that may be accessible to potentially every part of a program, but cannot be changed.

These aren’t the only kinds of global state, though. I would argue that globality–apparently that’s actually a word–is a continuous (as opposed to discrete or binary) property. Meaning: it isn’t just variables and constants; there are things in between as well. There are some values that will definitely change (e.g., a global cache), there are some that might (e.g., a feature flag), others that probably won’t (static configuration values), and so on. There is also the question of a variable’s impact, which is not the same as its scope, or how widely it happens to be accessible. One bit of state might define the language or dialect in which an entire UI is presented, for example, while another may simply indicate whether or not to display a certain dialog when an application loads.

So there’s some sort of spectrum here (you know how I like spectrums), or ... (read the full post)

I never actually worked in an environment like this, but I’ve read enough articles on The Daily WTF to have an image in my head of the old dusty, temperamental servers that companies used to have back in the 90s and early 2000s.

Those were dark days, from what I hear—when your business was victimized at the whim of an unpredictable piece of hardware. If the power went out, or the CPU overheated, or the hard drive failed, your site went down. It was as simple as that.

We live in a different era now, with PaaS and IaaS and all that cloudy good stuff. Your average tech-savvy business owner is going to know there’s no particularly good reason to run your own server anymore if you’re a small company. And if you’re one of the large companies providing these services like Amazon or Google, you have been on top of the hardware problem for a long time, with data centers distributed around the country (or the world) connected in a controllable and reliable way. It’s not an issue anymore.

This is a dream come true for everyone at the top of the food chain. The last thing you want in a high-up role is to be embarrassed by a problem at the bottom, far below eye level. The infrastructures that exist now for tech companies abstract servers into basically a sea of computing potential, which can be drawn from, predictably, as needed. (And on those rare occasions when outages do occur, it’s still nothing to lose sleep over. It’s Amazon’s problem; they’ll deal with it and apologize profusely in the morning.)

Dreaming of sliders

Essentially hardware is now a slider system, where increased scalability demands call for nudging a slider up, at which point additional hardware is ... (read the full post)