The way of the substack

the-way-of-the-substack.md

The way of the substack

With over 200 modules in npm, and many such as browserify, dnode, optimist, etc. relied upon day-to-day by developers all around the world, substack is a pretty damn productive guy.

Plus, he's got an awesome philosophy on programming to boot (yes, there is a programming philosophy! ... no comprende? Let me explain later).

BTW, how do I know this? I got to talk to him at campjs as he wrote & published a module (lexical-scope to be exact). He was super friendly and shared alot of his thoughts on many topics.

All in all, it was really cool to meet someone that's completely congruent with what he says & lives out as a programmer. It almost felt Bret Victor-like.

Tools of the trade

Substack uses:

• a small-ish Lenovo laptop
• unix: not Mac
• node/npm: duh!
• vim
• xmonad: keyboard friendly window manager that tiles windows automatically with virtual workspaces
  • Why? Floating windows that overlap aren't generally useful, so you might as well tile them, use multiple workspaces and make it all accessible with the keyboard.

That's pretty much it. As you'd expect, he knows alot of node modules, far too many to mention here.

How substack creates modules

1. substack codes as usual:
   • Uses console.dir alot to inspect & debug
   • Didn't TDD - creates an example.js that requires the module and tests its functionality
   • Codes in vim & switches to a terminal every so often to run the example.js script
2. If he notices an opportunity to modularise, he immediately moves the function into a new file & changes the function declaration to module.exports = ... (When I say immediately, I really do mean immediately).
3. When he's happy with the module, npm install tape tap
4. Refactors the example.js file as a set of tests (see below).
5. Writes README.markdown from scratch with introduction, API documentation & license (API documentation is quick & easy to write when you have small modules).
6. Runs pkginit to create package.json.
7. Create GitHub repo and npm publish

Test example:

t.plan(numberOfTests)
// do stuff
t.same ... // asserts

Now... if you've already done a few modules, the above set of steps might seem like nothing special to you.

The secret sauce is that substack is fast - really fast! He thinks fast, he codes fast... he's fast!

As the adage goes, "practise makes perfect".

Philosophy

I have to admit something... in the past, I used to evaluate packages by looking at the Github page to see when it was last updated. If I see something that is more recent, it gets my tick of approval.

Bad Chris!

Now substack doesn't do that. He just wants the most dependable, easy to understand and smallest module he can find (or make) to fulfil his objective.

In other words, he subscribes to the UNIX philosophy. I thought I did as well, until I talked to him.

So as an example, everyone sees nodejs as quite progressive. Features like domains, streams, etc. are being improved upon at the moment.

However, substack wants to see nodejs as 100% complete and dependable one day.

That means no more work on it and zero issues, just like the UNIX tools we use - cat, grep, date, etc.

Hopefully what I said makes total sense to you. But for me, what he said sounded like crazy talk at first. I mean, can't we have nodejs v42.6.7 one day?

Over time, it eventually sunk in and made total sense.

Lean Mean Fighting Machine

This goes on to my next point - substack practises extreme modularity.

He tries to keep each module he writes under 200 lines of code, although he knows it's not easy in all cases.

But he doesn't say it's impossible. To him, it's about taking the time to understand the abstractions. And once you do, refactor to modules.

If this is done right, you have modules that are:

• Easier to add to projects without feeling guilty of bloat (e.g. jquery, ember, etc.)
• Easier to contribute to
• Easier to read & understand
• Has independent versioning

Wow, doesn't that sound awesome! Why doesn't everyone code like that?

The more astute among you might say, "That sounds great, but if you go crazy modular, you're going to have massive dependency graphs with replicated functionality everywhere."

Sure you might, but substack says he's never really encountered that. I haven't encountered that. Therefore, we're right!

No, jokes aside, a smart package manager (i.e. npm) with a whole bunch of micro-libraries is usually still a lot smaller... and more importantly, easier to understand than an all-purpose framework.

Modularity over convention

So what about all-purpose frameworks?

My heading was a play on the words "convention over configuration". When I queried substack about his thoughts on CoC, he was slightly perturbed. He then gently explained that how you glue modules together essentially is the "configuration".

To summarise, Dominic Tarr put it well when he came over at one stage and briefly quipped, "configuration is a smell".

All in all

There were other topics discussed, but this post is getting a bit past 100 lines :-). All in all, it was super interesting to talk to substack.

If you learnt something useful (or think I'm full of it), I'll happily receive your comments below!

Related sources

• 09-Mar-13: Nodeup podcast on module authoring
• 09-Mar-13: How substack writes modules
• 09-Mar-13: edgeCases = Math.pow(configurationOptions.length, 2)
• 22-Feb-13: Javascript Jabber - specialised vs. monolithic
• 22-Feb-13: substack's talk entitled code collage
• 22-Feb-13: substack on streams

History

• 09-Mar-13: Updated to be more correct in terms of how substack writes modules (e.g. test.js to example.js)
• 22-Feb-13: Wrote the article