Posts tagged programming


For me, npm is the heart of node.js. It’s the secret to node’s success: a package manager that learned from its predecessors and got an enormous number of things right. Using it was easy: edit a json file, type npm install, and boom! You’re cooking with jet fuel, jet fuel provided in little modular canisters by hundreds of strangers who like to share their codefuel with everybody else.

NPM is what got me into open source. Publishing a package was as easy as writing one. My hands were shaking when I first typed npm publish (which npm itself tells me was Fri Jan 6 2012, at 10:26). I was terrified that I’d published crap code (I had). I was terrified that I’d published bugs (I had). I was terrified that somebody would tell me I was doing it wrong. Nobody did, because I was doing it right. I was participating with the node community through npm! Nobody found the bugs I’d just published, except me, and getting a fixed package out was just as easy as typing npm publish again.

NPM lets me give back in some small way in response to all the code other node users have given me.

NPM is the secret advantage of node that I touted to my most recent employer, when I sold them on the wisdom of writing web services with node instead of the JVM. Look at the way it handles versions! Look how active the ecosystem is!

So I’m thrilled when I tell you that I’m joining isaacs, seldo, and rockbot at npm, Inc.

The only sad part is leaving the team at LyveMinds. The people are great people who have been joy to work with over the last year. I’m going to miss Kit Cambridge and Sean Zawicki terribly. The Valley’s small; we’ll see each other again, friends.

But thanks to Lyve, I’ve been out in the real world of node in the enterprise. I know where npm’s pain points are. I’ve lived them and pondered ways to fix them for my small team. Now I get to help fix them for everybody who uses node. It’s like sharing a little node module times a million. I’m stoked.

Come work with me. We need an ops person right now.

6career, work, programming, node.js,

Interesting bits from "Characterizing people as non-linear, first-order components in software development" f


Characterizing people as non-linear, first-order components in software development (1999), by Alistair Cockburn, is one of my all-time favourite documents regarding software methodologies.

The reblogged post is a fantastic summary of what appears to be a great paper that I must read immediately.

Source: mononcqc

6programming, culture,

Why I’m suspicious of the VC-promoted culture of youth

(This was threatening to turn into more work as a serious essay than I am up for right now, so I’m shipping it as is, in draft form.)

the youth thing— why I’m suspicious

I’m always suspicious of people in my industry who prefer to fund or hire younger software engineers. I’m extra-suspicious of the ones who suggest people drop out of college to found startups.1 People like that go on my “do not trust” list, because I think they’re choosing to target young people because they’re easier marks.

VCs have always treated engineers as marks. We as a group have been ripe for exploitation by them for a number of reasons; generally we learn what to expect after watching a startup or two. Inexperienced people are particularly sweet victims because they don’t have the experience, and haven’t been hanging out near experienced programmers long enough to hear the war stories.

Stay away from VCs who want them young.


Let’s step back and talk about VCs.

VCs want returns on their investments. They invest their money in a number of startups in the hopes that a few of them will pay off. They make their money back when a company goes public (rarely post-90s-boom) or gets sold. This is the “exit” they all talk about. They do not make their money back from a small company that stays small & sustainable, that is, a company that doesn’t exit. A company like Pinboard, which makes a nice comfortable income for its single programmer, would not be a success from a VC’s point of view. They’re short-term thinkers. They care about their return on investment. They do not care about your business or about you.

This is capitalism; nothing wrong with it when well-regulated. You merely have to be aware of their goals and how they affect VC decision-making: what they fund, how they fund, and what it means they demand from the people who take their money. They will want growth. If the product is the usual insane given-away-for-free iPhone app, they’ll want massive growth so the product is attractive acquisition bait for advertising broker companies like Facebook & Google.

Do not mistake their values for yours. They want a home run; they don’t win if you hit a nice solid single to left. They want their money back tenfold. Everything they do and everything they demand from you is aimed at that goal. If it’s beneficial for you, that’s entirely by accident.

sustainable pace

Let’s talk some more about that giving your life up thing. Think it’s an exaggeration? Here’s Michael Arrington on the topic:

If you work at a startup and you think you’re working too hard and sacrificing too much, find a job somewhere else that will cater to your needs.

He quotes extensively from jwz’s Netscape diary. Here’s what jwz says about Arrington:

He’s telling you the story of, “If you bust your ass and don’t sleep, you’ll get rich” because the only way that people in his line of work get richer is if young, poorly-socialized, naive geniuses believe that story! Without those coat-tails to ride, VCs might have to work for a living. Once that kid burns out, they’ll just slot a new one in.

Consider a startup accelerator that considers women involved in a startup to be “a distraction”, and silently refuses to fund startups with women founders. Look at the assumptions there. Women are a “distraction” to the young, male, presumably heterosexual founders. A normal life activity— dating, having relationships, maybe even starting a family— is a “distraction”.

That startup accelerator does not want a healthy work/life balance from its candidates. It wants as much work from them as it can get away with, for as long as it can get away with it. It hopes the founder lasts long enough for that exit moment, but if not, it doesn’t care. Discard the burnout case as a failed investment; maybe one of the other 800 will pay off.

Wanna be a burnout case? That’s the price of that startup accelerator lottery ticket.

further reading

Some other blog posts on the differences between what VCs want and what you want:

The daddy of all such articles: jwz’s Watch a VC use my name to sell a con.

What is true is that for a VC’s business model to work, it’s necessary for you to give up your life in order for him to become richer.

Follow the fucking money. When a VC tells you what’s good for you, check your wallet, then count your fingers.

99 problems but money ain’t one

A balanced look at when to take money & when not to: Entrepreneurs: Go as Long as Possible Without Taking Venture Capital

Here’s a good survey of articles about what the VC model is: Does the VC model suck?


As usual, publishing something jars loose more thoughts on the topic. This obsession with naive youth also explains Paul Graham’s obsession with people who start hacking at age 13. He needs those 20-year-old founders to be capable of writing software that works well enough to look acquirable. The only way they can do that is with a years-long head start; hence they have to get going in their early teens.


  1. Although I think most CS degree programs are total crap, I think degrees in related fields like mathematics or electrical engineering or linguistics are worthwhile. The thing you’re getting is experience in teaching yourself difficult topics. You’re learning how to think. 

6startup culture, vcs, silicon valley, programming, medium,


Back when PHP had less than 100 functions, the function hashing mechanism was strlen(). In order to get a nice hash distribution of function names across the various function name lengths, names were picked specifically to make them fit into a specific length bucket.


Redis critiques f

In the course of a great discussion of the flaws of the Redis clustering design, this great comment:

It’s really important that a transaction tell the truth of what happened and that the expectations are intuitive to the users. If that is not the case then users will struggle reasoning about the system and their application code will have incorrect expectations and potentially lacking compensations. This can all lead to applications causing incorrect state.

The scary thing is that the author of Redis doesn’t seem to understand what he doesn’t understand. He wrote a great in-memory cache. He’s in the middle of writing a bad clustered db.

6redis, programming, CAP, distributed algorithms, medium,

I like this version better.

6programming, culture,

Why Developers Never Use State Machines f

A foundation in computer science allows you to take a problem X that you don’t know how to solve and reason, “I don’t know how to solve X, but I do know how to solve Y and I know how to convert a solution for Y into a solution for X. Therefore I now known how to solve X.”

I was hopping around reading about state machines this morning when I encountered this nugget. It’s not only useful advice, it reminds me very much of the most useful problem-solving advice ever, from Pólya’s How to Solve it:

If you cannot solve the proposed problem, try to solve first some related problem. Could you imagine a more accessible related problem?

The wikipedia article, surprisingly, contains a great summary of the book’s advice. (I can only assume a wikipedia editor hasn’t discovered it to ruin it yet.)

6problem-solving, polya, programming,

A Strongly Named Language f

Taking the Objective C/Smalltalk method naming convention a couple of steps further. I sort of like this.

6programming, languages,

The Cost of Features f

How code bases grow over time. Builds to an analogy calculated to appeal to me:

It’s not a car for everyone, but it’s spectacular in its niche.


How To Make Your Open Source Project Really Awesome f

Specifically written for the Clojure community, but these points apply generally:

If you plan on releasing a library as open source, please make sure it has

  • Clear dependency/installation instructions
  • At least one brief documentation guide
  • A change log and tags in the repo
  • Some information about supported language/runtime/tool versions and project maturity
  • A mailing list where users can ask questions and help each other

The mailing list seems more appropriate to very large or complex projects, but documentation is always a good idea. I like to see automated testing reports right there at the top of the README, too. It’s a huge confidence builder.

6programming, open source, medium,

"What's going on" f

[T]here are cultural and technical sources of performance issues [in scripting/dynamic languages], and they are related. In his talk, Alex criticizes the naïveté of both tools and programmers. He bemoans the lack of sophistication in tools that make implicit hash addiction and allocation problems unavoidable, but he also complains about the commonality of poorly performing idioms in scripting language code. The tools, or in some cases lack of tools, encourage these poorly performing idioms in this code.

There is a change coming in the languages we use for common tasks. The tradeoffs we made when we all chose dynamic languages a decade ago (perl, python, ruby, etc) are starting to irk us because they’re not longer tradeoffs we have to make. The next generation of languages (Go is the topic of the linked-to post, but I suspect Rust will be on the list) is allowing us the rapid development without the performance tradeoffs.

6programming, languages from a practical perspective, medium,

Building the Adobe Photoshop 1.0 source f

An amazing exercise in software archaeology, as the writer digs up the compilers and libraries needed to turn the Object Pascal source into working software.

A blast from the past for me: MPW! I still change the shortcuts of every editor I use into a replica of MPW, because it was the best. (And only BBEdit truly preserves its search-n-replace goodness.)

6macintosh, programming,

Why Do Computers Stop and What Can Be Done About It? f


Earlier this week I was lucky enough to see Joe Armstrong talk about the principles behind Erlang. During the talk he mentioned one of my favourite technical reports—Why do Computers stop? by Jim Gray for Tandem Computers.

[…] For a little more analysis and a summary, I’d recommend reading @mononcqc’s excellent summary, especially to those who want to skip straight to the good bits of the report.

Source: programmingisterrible

6programming, fault tolerance, craft, medium,

The game of distributed systems programming f

Stashing this link here, because I am once again thinking about this blog post and how I can advance my own understanding of the problem space. Uh. Erk.

6distributed systems, programming,

Everything fails all the time f

My current reading is this post on distributed systems & the CAP theorem.