Feed Readers have been around a long time, some of the earliest ones doubled as Usenet readers, and just like email they have persisted through various technology innovations and shakeups.
The problem typically solved by a Feed Reader is aggregation. More specifically, it's aggregation of medium to long form articles.
Even casual usage of a Feed Reader leads to information processing and triage issues. Feed Readers are not a place where you see only the articles you want to read, you add feeds that you're mostly or even casually interested in. For me, the information a Feed Reader can tell you (publishing site, title, author, picture) isn't always enough information to triage what I'm willing to take the time to read.
A few years ago I stopped using a Feed Reader when I noticed that nearly every article I wanted to read I'd already read after being linked to it on Twitter. Twitter is a great news aggregator. There are tons of people I have some kind of trust relationship with filtering content for me and when they post it it comes with their endorsement of the article. Another great part of Twitter is that there isn't an unread count. I slip in to the stream whenever I like and I'm fine with what I don't see when I'm not engaged.
I've also been using Flipboard for well over a year. Flipboard is a much better aggregator than a Feed Reader ever could be but is not always a great reader.
Feed Readers double as an optimized "reader" applications. This was somewhat frustrating to me because I'd have to context switch too often from triaging what to read and taking the time to actually read long form articles. But when I dumped the Feed Reader I was left with lots and lots of open tabs waiting to be read -- a system I don't recommend and is known to cause anxiety.
Enter Pocket. Pocket is fucking awesome. Anywhere I find an article I want to read (Twitter, Flipboard, Firefox, Chrome) I just send it to Pocket and forget about it until some time in the future when I context switch in to reading mode. I even use the Desktop app for when I feel like taking a break and reading but I'm not on my iPad or iPhone.
Separating aggregation from the reader is my favorite accidental innovation in this whole process. It limits context switching and allows me to accomplish both tasks much faster. A big thanks to Daniel Erickson for telling me about Pocket and their Desktop app which got me started on this.
The system still had one problem. There are a few feeds, about 6, that I genuinely want to read every article. These fell through the cracks the last few years until I found IFTTT. IFTTT is an express train to mashup town so it can be a little confusing to figure out what the hell you're suppose to do with it. One thing it does, very well, is send every new article in a feed to your Pocket account.
There it is, my life is complete :)
These are the feeds IFTTT posts to Pocket: David Simon, Charlie LeDuff's articles on Fox Detroit, Paul Carr @ Pando (I also read his NSFWCorp but with less frequency so I let them come in from Twitter), Clay Shirky's Blog (and god damn do I wish he had an aggregated feed like David Simon does), Asymco, and Tim Ferris.
My first task in my new role has been hiring. I've been involved in hiring for a long time but now that its the most important thing for me to get right it's a good time to write about it.
Don't build a team, build a culture. Teams expand, contract, change process and leadership at a decent pace in any startup and the culture is what can hold it together through all that change. Culture is the expression of shared values and interests between people. Culture is the heartbeat of a community. So the central question must be: what are the values and interests of your culture? Hiring is a selection process and you have to identify what you want the culture to be to do it right.
Open Source communities form around projects and technology, a common and shared goal is almost a given, and the more focused a community is on accomplishing their shared goal the more diverse the people that make up that community tend to be provided the leadership doesn't do anything stupid and exclusionary. It's pretty simple when you think about it, a node.js bug might be worked on and tested by a half dozen people from different parts of the world. You can find issues where a mormon, a jew, a bi-sexual and a Canadian all collaborated together without a single interpersonal squabble. That's because focusing on a shared goal makes us temporarily blind to unrelated differences.
If you're creating a culture, and hiring is how you'll build it, you must decide what the shared goals are.
We all get some amount of fulfillment from our work, intellectually and emotionally. A person's temperament and history have a lot to do with what part of their work they derive that fulfillment from. For instance, people who come from a long history of being removed from the product learn to derive fulfillment from the part of their job they control, their code, rather than from anything related to finished product. People who seem abrasive excel at their individual work but that's because they prefer doing things themselves rather than interacting with people which makes them poor collaborators.
Lot's of people like to tackle "hard problems." These people are dangerous. The problem with enjoying hard problems is that you rarely find simple solutions. People who want the word "architect" or "scientist" in their engineering title should be avoided unless you're building a bridge or an artificial limb. "Smart People" are overrated, I once sat in a room with people 10x smarter than me, original Macintosh team smart, and all we did was write a lot more code in our failure to make a usable product than a dumber team could have, a failure so spectacular they wrote a book about it.
Products are built to solve a problem for users. The scope and method of problem solving changes as the product evolves, what can sustain that development process and help keep the product consistent is a culture that values solving the problems of users. People that like finishing, people that like shipping, and people who feel a sense of pride about the product they put in someone's hand more than the lines of code they wrote to get there.
There are plenty of startups where culture means ping pong and free beer and most of the time it's because they share less interest in the product than beer. If you lock people up together to build stuff they'll find a way to identify with each other, if they don't actually share a common interest in making a product they'll find unrelated and personal interests to identify with and your group will grow homogenous as people look to hire more people that seem like them personally. At the same time people will get emotional about changes to their code, solve problems you don't even have, and read Reddit instead of work together to build something great.
A little over a year ago Max Ogden and I started a company. With some seed funding from Atlas Ventures we went about creating an application that would "bring people together." Our initial release was a little rocky but around the end of the year we got the product to where we had envisioned it.
Its been a great experience. We stayed focused on making a simple product and ended up building and cutting several ideas that distracted from our core value of bringing people together for real life interactions. During this time Atlas Ventures has been nothing short of amazing, they supported us when we needed it and have continued to believe in us even now.
With the money in the bank starting to run out we have some hard decisions. At this time the product hasn't gotten enough users to justify a new round of investment. We still believe in the product and want to see it live on. The current hosting costs are minimal and the money we have can keep it up more than a year if we stop paying ourselves.
Gather will stay up at least through the end of the year and I'm looking at ways to cut the costs even further if we need to. Max and I will seek out new opportunities. I'm already excited about a few and, in case you didn't notice, Max has rocked the world of voxel gaming with less than a month's effort.
I realized today that while I've talked a lot about how I curate content for NodeConf I've never actually written about it. Some of my influences have written what they think and what I'll be covering is an iteration on their thoughts bent toward achieving my own goals. If you have a moment you should read Chris Williams and Malte Ubl.
I have very little aversion to risk. This should be taken in to account because a lot of what I'll say won't be followed by most conference organizers and nobody should think ill of them because of it. Most people have to worry about selling all their tickets and not going broke. I'm lucky, I ran my first NodeConf with Chris Williams helping and it rode on the coat tails of JSConf so I didn't have to worry about making any huge mistakes or not selling all my tickets. By the time I did the second NodeConf I was confident that with node's popularity I'd have no problems selling the tickets and that emboldened to make the it the best conference anyone had ever been to.
In planning the third NodeConf I've had to identify some guiding principals for what NodeConf needs to be.
The first principal is that NodeConf is what I think the community needs, not what the community is asking for. Last year, hardly anyone was asking for talks about hardware but all my closing talks were hardware and they killed. I'm in a unique position for NodeConf because I'm deeply invested in the community and spend a lot of time travelling and talking to people about what they are doing with node. This access allows me to find content I wouldn't be able to find otherwise.
NodeConf is selected. I might do a reverse CFP to get an idea of what people are excited about but it's not my primary guide in developing and selecting content. I settle on the subjects I want to cover (realtime, hardware, debugging) and then I seek out people who can best fill it in.
The second principal is that everything should be new. The format should be new, the talks should be new, and hopefully the food should be new. So far the venue has always been new but I reserve the right to change that. Changing the format means that when I solicit talks from speakers they have to write something new. This trick only works once which means I can't recycle a format year over year. For the second NodeConf I did acts of 4 talks that covered a subject with each talk only lasting 20 minutes. Having such a short amount of time meant that nobody could use a previous talk and nobody could cover foundational information before their subject which forced the speakers in an act to work with each other so that each talk lead in to the next. An important part of this was that I didn't post a schedule publicly, which insured that nearly every attendee was in every talk. If you aren't able to insure that everyone is in all the talks in an act you're limiting how much the talks can lead in to each other and the speakers might get poor feedback about their talk because they didn't cover what was in the talk before them.
As connected as I am to the community I can't know everyone but I can and do know enough people that I can get connected with who I need. I didn't know who was doing the most interesting realtime development so I asked Guillermo Rauch and Daniel Shaw who I should talk to and they referred me to Mikito Takada and after a good conversation he understood what I was looking for and created a great talk. People seem to think that process like CFPs and voting will produce a higher quality but I've found that having real conversations with people is the best way to get new and creative content.
The third principal is that the surface of content should be as interesting as the information. I stole this from high end culinary culture where dishes must look as appetizing as they taste. Hardware talks get this almost by default because they have physical interaction which is interesting even if you don't care about the code or the process. A talk that tells a story in order to convey information will hold attention and interest much better than a talk that does not. The best example is Stuart Memo's "JavaScript is the new Punk Rock" from JSConf.eu 2012 which incorporates physical manipulation and demonstration in to a story and technical explanation of audio APIs available in the browser.
The parties must also follow this principal. JSConf does this wonderfully where all the parties re-enforce the "theme" of the year and are fun. In the second year of NodeConf I had a party at a karaoke bar with an API written in node.js and a party where all the music was created by node developers including the newly formed "Stream or die()". A portion of the attendees are looking for an excuse not to go to the party and having a hook like a theme or a fun activity like karaoke or bull riding will help get them there instead of relaxing in their hotel after a long day of conferencing.
My final principal is that the conference must be a true experience, which I've taken and adapted from Funconf. I care about building community which means that I need to find ways of getting the attendees to connect with each other. Talks don't do this at all, talks convey information one direction and enforce a separation between the speaker and the audience and sometimes between the audience members. If the conference becomes an experience, if it's like a ride that you get on with everyone else, when you're off the ride to eat or relax at one of the parties everyone shares that experience and feels connected.
These are pretty simple principals but they effect every decision. Last year the format I created was adapted and used by several other conferences which was a great compliment and a testament to how effective it must have been but the fact that its become popular means I'll need to create something entirely new this year. Most conferences build and iterate on their format rather than destroy them entirely to start from scratch each year. I do this because I'm more excited about NodeConf being a leader than I am in running a conference just to have it. Running a conference each year can be a burden but forcing myself to be creative lends me the energy I need to keep it happening.
In our latest version of Gather we added a new feature called discussions. This feature allows you to comment on gatherings and when the app is open this is a realtime chat with other live users about the gathering.
Our backend is all node.js, no big surprise there, and for discussions we decided to use socket.io for all the well tested fallback logic. Many people have talked about how they scaled socket.io but none of those approaches felt right to me. By default socket.io runs in one process and a message to all users in a "room", which for us would be a gathering, is relatively simple. Once you go to multiple processes people find ways to scale out those rooms. The most common solution I've seen is using Redis as a message bus but there's plenty of people using other databases and message queues to accomplish the same task.
We don't like adding black boxes to our application which means we're weary of most traditional infrastructure. The cost of managing more services and complexity of our application would grow immensely if we add a message queue or another database.
We've done a very good job of keeping our backend simple and horizontally scalable. We can add application servers at will, it's honest-to-god horizontal scalability. If we make something a message bus for all our realtime messages it'll inevitably become a bottleneck and will be difficult and costly to grow with the application. In other words it won't be horizontally scalable.
I tried to think of a way we could scale out the messages without adding a message bus or anything that couldn't scale horizontally and this is what I came up with.
Each gathering is a key in a Redis database. When a user hits an application process that application processes' internal IP and Port are added to the Redis set. If more users hit that application process and subscribe to that room it won't continue adding itself to the set and it won't remove itself from the set until all the connected users have left the room.
When a new message is sent to a room (by PUT or socket.io) the application process will query the Redis set for the internal application processes the message needs to be sent and then will dispatch an HTTP message to each of those processes including itself if it's in the set. When the application processes get the HTTP message they will send it to all the users subscribed to that room in their process.
The size of the Redis database grows with the size of active users and does not need to grow with the number of messages or the number of subscribers. The only thing that needs to grow with the number of messages are the application processes, which we already have a strategy for horizontally scaling.
Rather than trying to scale out the feature in isolation we decided to leverage what we already had a good scaling strategy for and limit the amount of potential new infrastructure we'll ever have to add. This was a decision I don't think most people would come to when they hire new people to scale their application.
Until recently application processes sucked at concurrency and scaling applications required infrastructure, which is traditionally not terrible at concurrency. With node.js (or erlang or clojure or scala) the application processes are responsible for concurrency and have some strategy for scaling which should be leveraged rather than competed with and complicated by infrastructure. The end result is simpler and can be managed by less people.
After marriage, a honeymoon in Portugal, and a surprise eviction I settled into a new home after a long move and stood on a scale in my new bathroom. Both feet planted shoulder length apart, naked and ready for bed, I felt powerless, the way an alcoholic feels ordering a 5th drink. I had no idea how the skinniest and shortest kid in his 6th grade class was clocking in at just over 200 pounds.
This was the end of 2011. I'd just started a company with one of my best friends and finished a year of travel where I saw more of the world than my parents had seen their entire life. The road before me for the next year would be even more work, more travel, and a lot of reflection with my wife about where our life would be taking us in our new marriage. Six months earlier my doctor had told me I was obese. He said it very technically and displayed that for my height I was just over the line from "overweight" into the "obese" red section of the graph but that didn't hit me the way 200 pounds did seeing it on that scale a half-year later.
A few days later my good friend Marco Rogers told me that his fiancé Aniyia had decided to go on the Paleo Diet, which meant Marco was on the Paleo Diet. I'd heard about this diet years before from a friend that lost over a hundred pounds, so I was familiar but hadn't been considering it, or any other diet. Instead I was trying to accept a new self-image of fatness and dying younger than I had anticipated. Then Marco said something that piqued my interest more than dropping weight or living a longer healthier life; that he no longer had energy crashes around meals and had a more even and sustained energy throughout the day and could get more work done.
Nothing is a better motivator to someone who just founded their own startup than the promise of getting more work done in a day. I was already working most hours of the day but found it difficult before and after meals. I would later read about how high carbohydrate diets train your body to produce insulin when you get hungry, leading to a crash in energy before meals and a lethargic feeling after meals due to the dramatic shifts in blood sugar. At the time, I knew nothing of the science but after 3 days on the Paleo diet I could work all day without a crash.
That was the first thing that influenced me, and has influenced others since, that you can get more work done if you don't eat grains and sugar. That's easy to remember, no grains, no sugar, no legumes and no potatoes. With most diets it's just way too hard to remember what to eat and what not to eat or how much of something to eat or not eat. It's maddening to try and count calories or trade a few semi-prohibited items around each day. I found it much easier to just say: "I don't eat these things" so that I could focus on what I can eat. I frequent dishes I love at local restaurants and create new ones following a few simple rules rather than compile each meal from a set of variations and rules.
Everyone eats things they aren't suppose to at some point during the week. Any rule you're following all week you'll want to break every so often, it's human nature. If the rules of a diet say you can have something in moderation then you aren't avoiding it most of the time, you're moderating, and "breaking" the rule becomes eating far more of it than you should have. It's not that I don't ever eat sugar, that I never have a little crust of bread, it's that 99% of the time I don't and when I do I can actually notice the effect it has.
In the last year many friends have gone on and off this and a few other similar diets, like the suggested dietary rules of the 4 Hour Body. There were some key things that allowed me and others I've known to stick with it the first week: simple rules, no restriction on amount of food, and no required exercise.
Me, and most of my friends, are busy people. We can't keep up with a mental activity like counting calories, we can't be hungry for half a day when we're trying to work, and we definitely don't have a surplus of time to devote to exercise. Leaving all that out most of us can keep up with a diet like this.
After the first week, which is always the hardest, I'd lost 10 pounds. That's the second thing that kept me hooked, the Paleo diet was demonstrably working--and faster than I had ever thought possible. I went from feeling utterly powerless over my own body to feeling like I had almost complete control. This inspired me to read, a lot, about the effects of food and diet on the body which I never would have done without that experience the first week.
The first 3 months I followed a fairly standard Paleo Diet and lost about 35 pounds. I felt great, I was never hungry, and I was down not just a few belt sizes but had to get an entirely new belt. But my weight loss had started to lose momentum and I was looking for ways to increase it.
I took a lot of great information from 4 Hour Body. I've seen a lot of people criticize it and I do think that if I wasn't already 3 months into the Paleo Diet it wouldn't have helped me much but it does have some great insights and is well written which is more than I can say for the other dietary books I've read. The most important piece of knowledge I took from 4HB and haven't seen anywhere else is to eat a protein rich breakfast (I do 4 fried eggs) within 30 minutes of waking up. This was very hard for me to keep up with so I have sample data from weeks where I was very consistent and weeks where I didn't even make it out of the shower in 30 minutes. For me, eating that breakfast within 30 minutes of first waking up more than doubles my weekly weight loss. I still don't fully understand why this works, but it does, at least for me. It's one of those things you read and don't believe until you actually do it to yourself and measure often.
Another thing I did for a few months was cut fruit. This sucked, but it worked. This was the first time I did something I actually disliked on my diet. Cutting out bread and rice was no big deal once I realized I could double my steak intake but after cutting sugar fruit was the only thing that could satisfy a very identifiable craving you still get for calories at odd times. Many more things from the 4HB I found didn't work at all. The "cheat day" I found useless on a physical level and a source of anxiety on a mental level. The exercises I actually like, and still do, but have little to no measurable impact on my weight loss. Everyone is a little different but my weight seems to respond dramatically to diet and very little else. I still feel better in weeks where I ride my bike a few times or do some kettle bell swings but there's no measurable difference in fat loss.
After 6 months I was down to 150 and noticed a problem, I'd lost weight too fast. I had a lot of hanging skin around my stomach and back, nothing too bad, I wouldn't need surgery, but I did need to calm it down. In the second half of the year I was less picky about desserts and more lax during travel. I happily added fruit back into my diet and in November was down to 140 for the first time since High School. Then I went to Kauai for a week and gained 10 pounds but I'm nearly back to where I was before the trip :).
Most importantly, I'm in control, I don't feel powerless (at least about my body) and I'm healthy. I'm turning 30 in a few days and that might make me feel old if I didn't feel younger than I have in almost 8 years. And before you ask, my cholesterol is great. Prior to this diet my triglycerides were nearly 300, now they're 120, and my LDL/HDL are almost exactly where I want them to be (coconut oil to the rescue).
Most dietary advice is pretty poor and very little of it seems to be truly influential so I leave you with only this: you don't have to starve or be unhappy with what you eat in order to have control over what is happening to your body, you just have to stop eating bread.
I didn't take any before and after pictures but RealtimeConf did a good job of filming me near my largest and smallest.
Keeping It Realtime Conference 2011 - Beyond Realtime (Mikeal Rogers).
RealtimeConf 2012 - Mikeal Rogers.
Tell me if you've heard this one.
The problem with [technology/startups/Silicon Valley] is that they create [popular app] and don't even know about [really important thing].
I've heard it several times and it completely misses the reality of politics, culture, and the orientation of change that is created by technology.
While we'd like to categorize a technology or product into buckets labeled "good" and "bad" it ignores the reality of an irreversibly changing world. The changes created by technology are not universally positive or negative.
Software that can help people talk to one another anonymously can be used by Alcoholics Anonymous just as easily as it can be used by terrorists or teenagers plotting a group suicide. The technology itself has no moral code and it would be a mistake to try and enforce one because once something is possible it will be done, sooner or later.
Since we can't name a technology as being positive or negative it's our second instinct to trivialize it or hail it as revolutionary which is always the case with social tools that give a voice to the previously voiceless. While we all agree with the principle of free speech we easily forget that most people do little of interest and have little of interest to say. We can either focus on the triviality of the majority of speech in a social tool or exhaustively praise what we feel is important. Both approaches are wrong and miss the real impact the tool will eventually have.
One of the biggest problems we have in our culture is that people lack understanding of one another. People who disagree have very little empathy for those they disagree with and when we exchange only opinion with each other it's easy to dehumanize one another. This is why social tools that share more than opinions and political beliefs are important. If we can share our humanity and our culture with each other we might regain civility in our discourse. This is why sharing brief thoughts of family and moments captured in photos are important.
My last bit of criticism is that it's as easy as it is hypocritical to compare something popular to something important. Something popular, something that has caught the attention of millions of people, can always be made trivial next to something your readers and followers believe to be important. The fact that it exists, and that people care, appears to be evidence enough that the whole world has terrible values and motives.
People rarely devote themselves to the things they find to be most important in the world, they devote themselves to what they are good at and what makes them happy. I once left my job in technology to work for a book publisher because they were doing work that I admired. After a few days the reality set in that I was objectively terrible at packing boxes and could never be happy with that job no matter how great I felt about the output.
To degrade other's work because they have specialized around what they are good at and what makes them happy because it's not contributing to what you feel is important is incredibly hypocritical since you are most likely talking about what you think is important and working on what you're good at just like they are. People admire those doing what they can't, people who have the talent and ability to take on the important work that we find ourselves to be inadequate at. We should all be happy about what we do, support and admire those doing what we cannot, and keep our mouths shut about those who are lucky and successful in what we simply don't care about.
I own a series of beautiful books from the Post Secret project. The books are large and include full color pages of post cards sent to the project which asked people from all over the world to send anonymous secrets to an address in Germantown, Maryland.
As I followed the project through its blog and eventually twitter I became quite obsessed with the project and bought the books almost as soon as they were published. When I was forced to move out of my house in Oakland I purged 90% of the paper books I owned but the Post Secret books survived and have a place on the shelf in our new townhouse.
The books are a near perfect representation of the project, they reproduce not just the words but the impression you get about a person by their handwriting and choice of card. It's the kind of thing I'm naturally drawn to, finding the perfect form to represent and express an idea.
I have opened these books maybe twice each and haven't actually read any of them for more than 10 pages.
The problem with finding the purest form of expression is that you disconnect from all other practical concerns. As much as I love this project, and the books themselves, I've consumed far more of this content through their blog and twitter and all of my book reading has been dominated by books that are easier to read.
In technology we are obsessed with finding the most correct and technically superior form of expression. This constantly blinds us to the real needs and addressable market of our technology. In the past I've celebrated technical superiority over simplicity and, with time, always found myself on the losing side between competing technologies.
Lately there has been a rush of technologies, some being very well funded, that are seeking to create a better platform. They tend to share a distaste for things that are already built and prefer to build new and incompatible systems. This stems from a need to "do things right" and what they leave behind is more than just prior technology but the entire communities built around them that are growing rapidly. Somehow these platforms, and presumably their investors, believe that by ignoring the communities that contain nearly all their potential future customers they will create something more appealing than the platforms those communities are already a part of and have a hand in shaping.
There is a balance to be found between correctness and accessibility and node.js seems to be finding it. Living with JavaScript, and all its faults, seems to have built an understanding in the community that nothing will ever be perfect. By embracing the warts of the language and of various operating systems node.js lives in a harsh reality. It must be as correct as possible but embrace its constraints rather than fight them or form complex abstractions around them.
I find myself incredibly dismissive of new technologies that tout their "correctness" but lack community. It creates cultures that don't celebrate simplicity and adoption. I don't think node.js will be the last platform to gain adoption and popularity, nor do I think node.js is finished growing, but much of its success is cultural. I won't take any new platform seriously unless it demonstrates a similarly positive culture and community. I had celebrated pure technical achievement for most of my career and was shown too often that it's just not that important.
Node.js will not be the last community I'm involved in. There's always a next thing, but I won't be looking for a technology, I'll be looking for a culture that can balance strong technology with simplicity and a healthy hunger for adoption.
3fE in Dublin has two large trophies from the World Barista Championships, but these barista skills in espresso are of no interest to us and we order a Chemex of their recently roasted Kenyan coffee. I'm sharing this Chemex with Max Ogden and Isaac Schlueter for a few minutes before Isaac says, "I have good coffee so often now that it doesn't seem like good coffee to me, it just seems correct."
A few years back I can remember dragging Isaac past about 10 coffee shops to arrive at the one I had deemed acceptable. Isaac was along for the ride but considered my quest ridiculous and remarked, "The great thing about not drinking good coffee is that you're fine with regular coffee, or even shitty coffee." Isaac clearly had no foresight into the impact our friendship would have on him in this regard, and I've always felt that he probably harbors some mild resentment because as much as I might be able to claim responsibility for his coffee enlightenment, I also must then claim the same level of responsibility for "ruining" his enjoyment of bad and mediocre coffee which is available in far greater abundance.
Isaac's apartment now includes an electric Bona Vita kettle and a Hario v60 for pour-overs, exiled forever from the guild of bad coffee lovers.
When Isaac used the word "correct" to describe our coffee he was using it the same way he had a day before and I couldn't help but relate the two incidents. At dinner we had gotten to talking about what I call the "substack pattern" -- node modules that export a single function -- and how it influences a module's aesthetic and keeps things simple. Isaac said that this was not a matter of opinion, it was simply the correct way to build node programs and modules.
I agreed with Isaac, but a few years ago I doubt I could have made such a bold statement. In my experience with so many other platforms and years of big projects, big modules, and grab bag utility libraries, I had never experienced the joy of working in an ecosystem built out of so many simple and small components that I now take for granted with node.js.
Theoretical exercises and methodologies get volleyed back and forth in regards to just about everything in programming. It's easier to read a book or write a blog post than it is to relate an experience but it's going through an experience that can change your perception forever. Rather than forming opinions about what is "the right way" you develop a more binary response: "This is the correct way, I have experienced its greatness, unless you have also experienced this and can relate to me you will not be able to dissuade me from my belief."
This makes it hard for those of us in certain communities to have civil discourse with people from other communities. If we've solved a problem well, and lived in the world where that problem no longer exists, there can no longer be an exchange of differing opinions. At the end of the day, we live in different worlds, and they just "don't get it." You can't have an argument about how to best solve a problem you no longer have especially if the other party is unwilling to admit that you have succeeded.
What doesn't help is to pretend these differences in perspective do not come from experience and to bend over backwards to give everyone a platform for "their opinion" about a problem that has been solved. We can either attempt to relate our experiences to each other and move toward a shared understanding or become content with the constant and embittered exchange of strongly held opinion we have now.