The way of the
Plus, he's got an awesome philosophy on programming to boot (yes, there is a programming philosophy! ... no comprende? Let me explain later).
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
- a small-ish Lenovo laptop
- unix: not Mac
- node/npm: duh!
- 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
- substack codes as usual:
console.diralot to inspect & debug
- Didn't TDD - creates an
example.jsthat requires the module and tests its functionality
- Codes in vim & switches to a terminal every so often to run the
- 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).
- When he's happy with the module,
npm install tape tap
- Refactors the
example.jsfile as a set of tests (see below).
README.markdownfrom scratch with introduction, API documentation & license (API documentation is quick & easy to write when you have small modules).
- Runs pkginit to create package.json.
- Create GitHub repo and
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".
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.
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!
- 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: substack's talk entitled code collage
- 22-Feb-13: substack on streams
- 09-Mar-13: Updated to be more correct in terms of how substack writes modules (e.g.
- 22-Feb-13: Wrote the article