Seattle Node and Swift Freelance Developer


I worked on several cool projects this summer, but also had some challenging tests of my skills as a freelancer.

The challenges of being a freelancer

Just a few of them…

  • Scrambling to find new clients when a long-term project ends unexpectedly.
  • Wanting to say yes to a position referred by a friend for fear that offers will stop coming if you say no.
  • Taking a short job to bridge to a longer-term job, then having the longer-term job come through too quickly.
  • Balancing expectations on availability with clients
    • “I’ll be available next month”  doesn’t mean “I’ll start next at the beginning month”
    • “I’m available for four weeks”  doesn’t mean “until the end of next month”

As a freelancer, it’s hard to be strict about exactly what work you want to do and can-do. A good goal is to charge enough so that you can say no to all but the best-fit clients.

There’s a fine line between no projects (or too little work) and too much work. In one case I was trying to work while sick to keep the client happy (not that they asked). I didn’t get better, and I barely ended the project on a positive note. It would’ve been much better to just take the time off up front that I needed to not get sick.

Haiku Deck

I worked at Haiku Deck on an awesome product with a fun team for 2 years. Even though I knew funds were tight, it came as a little bit of a surprise to learn that the budget for my time was used up. The ensuing restructuring made for a chaotic week. As a freelancer (unlike salaried employees), I actually like this dynamic change. It’s a challenge to find fresh problems to sole.

The main issue for me, was that I hadn’t been doing a lot of networking. I had gotten lazy about participating in community events. So when my job dried up, I didn’t have another one to jump to. Or, even a clear definition of what I wanted to the next. I did have a lot of side projects I to work on. So I started work on those and tried to get a quick job through Upwork (previously oDesk) to pay the bills.

Scality via Upwork

I’ve always been enticed by the prospect of finding small projects online that are paid hourly. I love the idea of working remote and on my own time. Someday, I’d like to do this while traveling. I had used oDesk as a client before – hiring writers and developers. But I never signed on as developer to get paid for a project.

I applied to about 10 projects. The application process was time-consuming. I tried to write enough and ask enough questions to distinguish myself from the other applicants. I had to explain why I charge 5 times as much as the other developers. I found a good project that was very clearly specified, the unit tests were even provided.

I landed the project and started work – albeit at 2/3rds my normal rate. Unfortunately, the unit tests did not cover a very important and complicated part of the new functionality. So there were a couple very late nights getting things done in a timely fashion for the client. The project was using node to transfer giant files. I wrote up some of my learnings about subclassing node streams.

I expected starting out with Upwork that I would have to discount my rate. What I didn’t account for was that every minute is logged. I don’t mind the invasion of privacy, my assumption is that as I gain trust with my clients – they will pay less attention to my hours. However, I didn’t account for the loss of “soft” billable time. I couldn’t charge for meetings. Every time I went to the bathroom,  took lunch, or researched something, I felt like I needed to clock out. This meant that 40 billable hours required about 50 hours of time. It was intense. Especially when trying to impress the client by meeting the deadline.

Of course, once I did a good job, client offered more work at a higher rate. Which is awesome. It was a great way to discover a new client that I wouldn’t have met through my Seattle network. However, At that point in the summer I wasn’t ready to “drink from the fire hose.”

I’m not sure I will return to Upwork because I think I would be more efficient pitching my skills in person (or on the phone), and finding more interesting projects through my network.


I wanted to work for Mark Barros because he’s an awesome CEO. But also I wanted to work for him because he pulled me up the half pipe during Tough Mudder. I got to help Moment for a few days with a product launch. Specifically, I worked on an order fulfillment system for cool new phone cases and camera lenses.

The interesting thing about working for moment is that it is primarily hardware company. Turns out that’s not a good fit for me. I’ve mostly worked for companies where software is the main product. For a business like Moment, hardware is the product. They rightfully use whatever software necessary to sell and deliver it. In this case it was WordPress with WooCommerce. A frustrating choice for me as a developer – but a logical one for Moment.


TA McCann wrote a great blog post about his experience killing this startup right before the seed round. It inspired me to write this post. I thought it would be fun to share my perspective.

With a few extra hours during the summer, I joined TA with a couple other developers and designers at his home. We discussed and coded an initial prototype. My job was writing the Node API to send faxes requesting medical records from doctors. Few providers responded. As it turns out, providers have no incentive (despite the law) to share medical records with their patients.

T.A. and I have a great working relationship. I can show up, ask a few questions, and then implement an experiment. It was worth the investment of free time for the possibility of working together. Sadly, we decided not to pursue it and it’s back to being a side project for me.

Photo app

Another great project that I spent considerable time on over the summer was a viral photo app. It is sort of like a Photo booth with a twist. A friend of a friend and I had a similar idea and the three of us started working on it. As I got the prototype going, we narrowed in on an MVP feature set. A big part of this was negotiating ownership of the project. It will hopefully yet see the light of day.

The project was excellent experience with Swift development. I am impressed by how well documented the iOS APIs are. I was also relieved to be writing code that compiled after lots and lots of JavaScript.

Retirement Calculator and Portfolio Creator

To prove my credentials as an iOS developer, I wanted to get an iOS app in the app store. A close relative is a financial advisor. After seeing his website, I realized it would make a straightforward iOS app. I scoped it out and talked to him. Within about 10 days of work we had Retirement Calculator and Portfolio Creator in the App Store.

I was pleasantly surprised that there was zero pushback from Apple. The release process was smooth. As a marketer, the project reinforced the importance engagement for mobile apps. We have new users that have committed valuable megabytes of their phone. We want to keep them using our app. This is a small insight for me – more obvious in mobile than on the web. Orphaned registered users seem that much closer when your code is in for installed on their phone.


The project that I’m most excited to be working on is building tools for freelancers. We’re also matching freelancers to projects. I’m going to skip writing about this now because we’ve got some cool stuff in the works. But I did want to share this call I had with freelancers. We’ve been following up with everybody and I’ll have more on this by the end of the year.


I worked with Per Nilsson and Anna Luisa West from Formidable Labs at Haiku Deck. They were great. I wanted to work with Formidable again. Formidable offered a great project that I couldn’t refuse, helping Ookla launch a data portal.  You’ve probably used – we helped them report on all that great data. The result was a killer product for their clients.


Recovering from a dislocated shoulder


Bikers: If you get nothing else from this post, watch this video Showing Kocher’s method for putting your shoulder back in (I paid a very nice ER doc $800 for a live demonstration). Of course, you should see a doctor as soon as you can, but maybe it will spare you a scary hike.

One Sunday (July 25, 2015) when I was bored with riding on the road, I took off for a trail ride. It was an amazing 45 minutes before I got into trouble. I started on the beginner trails at Duthie Hill. Even though it was a damp morning, the trail was so nice I kicked myself for not going up there once a week all summer.

I started slowly and cautiously. I’ve had bad luck falling off my mountain bike – a couple times since I got it last year. After the beginner trail, I went to another nearby Grand Ridge trail which is more difficult (see photo above). I rode a ways out before turning around. Unfortunately on the way back I hit a loose patch of gravel on the outside of a narrow turn. My front wheel washed out to the right and I flew like superman into the ground – landing mostly on my chest. I landed with just the right forced to dislocate my left shoulder.

A nice young lady came along two minutes later. I asked her “This doesn’t look normal does it?” showing her my shoulder. “No,” she said. She graciously pushed both of our bikes out while I hiked. I carried the weight of my left arm in my right-hand. Surprisingly, it was not that painful. I didn’t relax until we hiked / jogged for about 20 minutes out to the road.

I’m writing this post to share some of the supplements I found trying to accelerate my recovery. Unfortunately, it’s been very slow. Over a hundred days now. I was able to get back on my bike after about 2 1/2 months, but I completely missed the last month of the race season. Luckily, it was only about two weeks that my arm was in a sling and I couldn’t type. It seems like my shoulder will be back to normal around the end of the year (5 months total).

Here are some of the supplements I that I tried.

  • Glucosamine
  • MSM
  • Gelatin (collagen) – (helps re-grow tissue)
  • Fish oil
  • Daily vitamin
  • Cissus quadrangularis (helps joint healing)
  • Magnesium (relaxes muscles)
  • Ginger tea (reduces inflammation)
  • Vinegar Apple cider  – forget why I started, but I drink this now to when my stomach is out-of-whack.

It’s really only Advil that I can definitively point to as helping my recovery. I should’ve taken more sooner in order to sleep better and heal faster, but I didn’t like the idea of numbing the pain. I think the nice snugness of my newly reformed shoulder capsule is due to many of the supplements that I took (primarily the Gelatin).

I also used a heating pad, stability ball, foam roller, and tennis ball in a sock to release tight back muscles.

I did a number of exercises recommended by a physical therapist. Other than slowly strengthening and stretching my shoulder, it’s hard to say which helped the most. So I won’t list them here.

The big lesson from this is that I need to keep working on my skills. The Total cost of the accident: a $2,000 trip to the ER, and a $1,000 chipped tooth.

Update: day 87 (12.5 weeks)

Motion continues to increase slightly every day. I’ve started doing Tony Horton’s Shoulder rehab workout.

Update: day 102 (14.5 weeks, 5 November 2015).

I was still having trouble sleeping last week. I can’t get used to sleeping on my back. A cold I got earlier in the summer came back. I’m pretty sure it’s because I wasn’t getting enough sleep (5 hrs a night). On a doctor’s recommendation, I’m back doing three Advil an hour before bed. It’s made a big improvement in my sleep.


Should I write unit tests for node code?

A friend (learning node development) just asked:

Hey, another developer is encouraging me to do some unit testing using a testing framework called Mocha and Chai. What are your thoughts: must do, nice to have, or good hygiene (like pushing to GitHub and production every day)? Thanks in advance for your advice!

My answer: Must do, but it’s Level 2. In other words, as soon as you’ve grasped the basics (shipped your first app or site) – you should learn to write tests.

It’s more than just good hygiene. As your code base gets more complicated, automated testing will catch bugs that hand-testing won’t catch. You don’t have to go crazy, I’d suggest just starting with tests for the parts of your code that are hard to test by hand.
I like mocha. Chai is a little over-complicated. You can also just use “assert.” Other npm libraries I use for code testing:
  • Istanbul (coverage)
  • Sinon
  • Nock
  • Supertest

Longer answer: Automated testing is often required to know that your code is working. Once you’ve got a good suite of tests, you can change things with confidence and quickly verify that you haven’t broken something unexpectedly. However, It won’t guarantee that your code has no bugs (after all, tests can contain bugs too). Lastly, writing tests first (AKA “test driven development”) will help you organize your code better and write better interfaces.

How to win a bike race

Screen Shot 2015-11-25 at 12.10.14 PM

I finally won a Cat 4/5 criterium – in a race I’ve been doing off and on since the mid-1990’s. It’s 4 days later as I write this, and I’m still reveling in it. As I wrote in my 4 hour bike racer post, I set this goal because I previously upgraded my cycling license without ever winning. There’s a million reasons why winning this particular race was no big deal, but I made it the cornerstone of my mid-life crisis. I didn’t want to go to my grave without ever having won. It feels a little boastful to write this, but it’s my blog dammit. I write it for me, and I’m pretty satisfied with myself.

This was the actual race, Seattle’s weekly Seward Park Criterium. It’s open to young and old, male and female racers.

A few keys to winning:

  • Showing up week after week (a couple of the people that usually win weren’t there the night I won)
  • Counting lapsto get in position at the right time. Hint: 2 laps to go is too soon
  • Locking down the inside lane. I learned this from another guy in the race. If you keep near the curb, there’s only one direction people can attack you from.

Two weeks ago, after being aced out in the sprint yet again, I wrote down these tips for myself:

  • You have to come-around sometime in order to win. If the lead-out is not there, just go.
  • Carry momentum. If you’ve got it, just go.
  • Attack when it hurts. Don’t take your foot off the gas when others are hurting also.

Another thing that helped was analyzing the lap times and taking a few timed practice loops around the course. In practice, I could get around in maybe 1:50, but in the race our lap times are between 1:30-1:45, so I knew there was no chance of a solo breakaway.

As it happened, there were only slow wheels to be had – so I went from the middle of the hill 300m or so from the finish. Normally, I would’ve thought that was too soon – but I managed to hold everyone off. I remember thinking – “you may never get this chance again.”

Of course, acquiring the best bike money can buy was a big part of my success.

2015 Pinarello Dogma F8 Naked Red with Shimano Dura Ace C-50 wheels

But more importantly, I think there was a philosophical reason for winning. In the past 4 years, I’ve changed the way I think about fitness. I’m no longer a weekend warrior like I was in my 30s. I can’t coast on decent DNA any longer – I have to workout to survive. The best I can hope for is to cause my own pain (or “steady discomfort” as they say).

The thing is, when you do 30 minutes of exercise per day (OK, some days it’s 5 minutes) – you can do a half marathon without training for it. I workout less now. I don’t ride massive miles, but do try to make my short workouts intense.

Remember that startup I mentioned in my earlier post about habit formation? One of the best quotes I’ve hung on to is:

“You want to know how to paint a perfect painting? It’s easy. Make yourself perfect and then just paint naturally.” Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance


Or, as I read this morning…

“Winning is not a moment of triumph – it is a habit of discipline and a process of becoming” – Métier

Turns out, if you want to win a bike race, you make yourself into a bike racer then ride naturally.

But I digress. Here are some hacks that worked for me. They’re important too.

  • Caffeine: correlates with better performance, what can I say?
  • Creatine: also seems to increase my work threshold, especially when coupled with caffeine
  • A good night’s sleep, or a nap if you can afford it, before the race has helped me too.
  • Soylent: great recovery and every meal drink. Rice protein not whey (though version 1.5 is giving me reflux and gas despite taking stomach enzymes with it).

New goals for 2016

  • Get to know more riders and get on a team
  • Help support racing however I can – heard a youngster speculating about how he could be win this race – and that’s what it’s all about (motivation and experimentation, not winning).
  • Do more mountain biking

Updates from Four Hour Cyclist 

  • It took 4+ years, not 6 months like I hoped.
  • Interval training (and high intensity intervals) did work, including for training for a marathon with minimal running.
  • I never did the track class, I’d still like to.
  • I acquired an olympic size deadlift bar, and about 2x my weight. I only ever made it to 1x my weight due to my lack of persistence (The 4HR body suggested 3x as the goal). This may be simply because I had it in the wrong room of my house – the garage and basement where it is hard to move around without hitting my head.
  • I never got a power meter, though prices are getting down a lot closer to $500. I traded my rollers for a Wahoo Kickr trainer (with power meter) and took a CycleU class – both helped me establish my Functional Threshold Power which was critical to doing effective computer-guided workouts during the winter.
  • For some reason, sprint workouts on the road require a lot of discipline. you have to head to a patch of road without too many cars, and you have to have the discipline to go back and forth putting yourself in a world of hurt. Doing this with others would definitely help.
  • My 2006 Dogma was stolen from my garage, but luckily my insurance covered the replacement cost of the 2015 version (pictured above) – a freakin superbike.
  • I drank so much whey protein I became lactose intolerant. Now I drink rice protein (primarily in Soylent).
  • I save Magnesium for the evening after a workout – helps relax the legs. During a hard  workout or race, I put creatine in my water – a recommendation from the 4HB.
  • Of course, to be an old-guy bike racer like me, you need full body fitness. Just 2 months prior I was not riding outside due to neck and back pain. I’d fallen off my mountain bike (at 0 miles per hour) knocking a rib was out of place. It was made worse by years of computer work. It took several weeks of chiropractic care and acupuncture to get everything loosened up so the ribs would stay in place. I immediately started strengthening. I used the exercises in my 4 Hour Body Cheat Sheet, and an old (fairly basic) Carmichael core training for triathletes video.



Pre-incorporation founder’s agreements

startup founders

I’m currently working on a couple of speculative projects where a non-trivial (more than a weekend) amount of unpaid work is necessary up-front to prove out the business. It’s important – especially when you’re working with new people – to flesh out everyone’s expectations in the beginning (and way easier than down the road). However, too much discussion is a waste of time before you’ve created a product that’s worth something.

Here are a few key questions to be answered.

  1. How much time and money will be invested by each founder?
  2. What are the specific roles and responsibilities of each founder?
  3. What is the scope of the Version 1 product we’re working towards, or hypotheses we’re testing?
  4. What is the definition of success? What outcome would keep each team member working on this project at the same or greater level of effort?

From there, you can negotiate.

  1. The percentage ownership split. What percentage will each founder get if the project is sold?
  2. The percentage profit split. What percentage of earnings will each founder get?
  3. How will decisions be made? Is there one CEO, or is a majority vote sufficient? Can a majority of founders kick out another founder?
  4. What happens if the project fails, there is a disagreement, or interest fizzles out? Who keeps the IP (code) and branding (name) – subject to the others buying it from them?

After the Version 1 milestone is reached, if your project is a success – congrats (this is rare)! You should actually incorporate. Hopefully all founders will be on good terms based on the expectations set at the beginning (and reasonable with the most-likely changed requirements and direction of the business). If you haven’t hit it out of the park, re-evaluate, re-negotiate, and take another shot (or move on).

Here are a few templates for putting your pre-incorporation founder agreement in writing.

Please leave a comment below if I’ve forgotten anything, or if you have another resource I should add.

Aside: when researching this, I thought Startup Weekend surely must have a FAQ about this, and they do (in particular about IP and ownership). This is a great answer for a project where the initial investment is just a weekend.

Startup Weekend: How do teams address the issue of IP/ownership? While it doesn’t hurt to be clear about your individual expectations from the start, we’ve found that teams who don’t spend time addressing this issue until it actually matters (i.e., there is a tangible product to have ownership of) are much more productive and successful than those who do.

Related: Ideas are inevitable, why I don’t sign NDAs and laugh at stealth mode




Image courtesy of


How to inherit from node stream

Node streams

I recently had a project where I wanted my node javascript class to support pipe to and from (in other words, to be a duplex stream). I couldn’t find sufficient examples of implementing streams (probably because the node API has changed so many times). The current node stream docs are pretty clear, but miss a couple points.

After solving the problem, I created this Node Stream Inheritance sample project with code to share. The project contains sample code showing how to subclass node’s Readable, Writeable, Transform, and Duplex streams as they exist in node v0.12.2.

The node streaming API has a long history. For the purposes of this project, I wanted to make my class support streaming in the simplest way possible without any external dependencies.

Specific node stream inheritance questions

I implemented this project to demonstrate the following:

  1. What event should I wait for to know stream is complete? This depends on the stream you are piping to (the sink). In the case of a FileStream, handle the 'close' event.
  2. What events should I implement (emit) to indicate my writable stream has received everything it can handle? In this case I opted to implement my own 'full' event – indicating that my custom stream had no room for further input.
  3. How do I handle errors? _write and _transform provide callbacks. If you pass your error out, the underlying implementation will automatically emit an ‘error’ event. In the case of _read, you need to use this.emit('error', err);

Sample code

Here is some sample code from the project.

Duplex stream subclass test

Duplex stream subclass example


If you do want to use a library for a simpler API (that is more consistent across node versions), look into through2 and event-stream. Thanks @collinwat for the code review and recommendations!

Related: Top 6 problems with node.js

Modeling the brain. What does the fox eat?

Comparing 2 SDRs

Recently, Numenta Founder Jeff Hawkins made a claim that we’d have the technology necessary for “intelligent machines” in just five years. Numenta is working to model the neocortex in the hopes of combining machine learning with self directed action. Wow. I’d love that. But I think most normal people are terrified.

For background, please see these two videos.

In his talks, Hawkins cites an impressive example of generalization. During a recent hackathon, Subutai Ahmad ran a program training a Nupic Word Client (I’m just starting to grasp the terms, this may include a Cortical Learning Algorithm (CLA) and/or Online Prediction Framework (OPF)) on a short list of words. The sets of words were for example “cow,eats,grain.” With each input, the algorithm predicts the output, then adjusts based on what you teach it (load into it).

The impressive part was that the algorithm predicted “fox eats rodent” – without having seen the word “fox” before in the input.

The code actually does sort of “know” what a fox is, though. It queries (formerly CEPT) for a Sparse Distributed Representation (SDR) of each word it sees. The SDR is a numerical representation of the word, derived from “reading” wikipedia. Still, this is an impressive generalization – it is effectively understanding that foxes is like other animals, and it knows that those other animals eat rodents, so it appears to guess that foxes must eat rodents.

Comparing 2 SDRs

Comparing the SDR for “fox” (left) with “fish” (right)

There is a ton of interesting stuff going on here, including real-time learning that I won’t even attempt to explain. In the videos above, Hawkins explains how this is different from a traditional neural network.

But, in some ways this demo is misleading. It is not showing how the neocortex works (or how the brain reads, interprets, and generalizes between words), it is only showing how the building blocks we’ve got so far can be hacked to do interesting things.

The experiment only shows how an upper layer of the brain might work.  This demo (unless I’m misunderstanding) is showing how one layer CLA/OPF magic behaves when fed a sequence of richly derived word meanings (which in a multi-layer model would be learned and stored by a different level of the brain).

What I wanted to test was how robust this prediction is. Did Ahmad just get lucky with his 38 lines of input?

After a couple hours twidling my laptop to get things to run, I did reproduce the result with the same input file.  Aside: it is wonderful that Numenta and the hackers have open sourced their code and examples so the rest of us can play with it!

However, I also gave it a bunch more input, and got different – sometimes less or more logical results. With this data set, I get:

Input 1 Input 2 Prediction
fox eat grain

I also got “leaves” or “mice” with other variations of the input (I didn’t change much related to animals). It seemed kind of random.

But, I also get these great results (starting with grandma the first time it sees any of these terms in the input file)…

grandma likes music
grandma eats water
cousin likes sun
nephew likes music
niece likes water
brother likes iphone
raccoon likes release
horse likes sun
musician likes artists
runner likes beach

“Release” and “artists” don’t exist anywhere in the input. WTF? To be sure, I’m not training it on the best data set, and it is coming up with reasonable predictions. Here’s the full input and output.

I tried a bunch of much more abstract terms to see if we could use this at Haiku Deck, where we’ve got some interesting ways of guessing the best background image for a slide in your presentation. While the algorithm is clearly learning, it leaves a lot of mental jumping to decide if its predictions are correct.

I have no idea how Numenta is regarded by other AI or neuroscience researchers. But Numenta’s advances in modeling the brain have definitely re-awakened my dormant interest in Artificial Intelligence. Next, I want to try simpler input like images or even X/Y data (bitcoin prices, anyone?).



Adopting Node.js

Screen Shot 2014-12-11 at 11.26.30 AM

Scott Nonnenberg wrote a great post about how Node.js is not magical.

I totally agree that Javascript is “a bit tricky.” A lot of times
people that I work with think they know javascript better than they actually do. However, I’m also noticing that it is becoming a lingua franca – more people know it.

Another good point that Scott makes: Taking the time to do tests right is hard. In my opinion writing automated tests is necessary for shipping good node code. As a developer, I try to include it in my estimate whenever possible. It’s been hard figuring out how to test all the asynchronous code, but worth it to make sure code works fully before shipping it.

If you’re just getting started with Node, see Scott’s post for some helpful links.

For me, Scott’s #3 (async by default) is the big gotcha. I just don’t think 80% of server code needs to be asynchronous. It’s not worth the complexity it adds to writing and testing your code. I always think code should be simple, not clever, and written for non-geniuses to understand. Computers are cheap, and brain power is expensive (at least for now) – so if you have a server-side function that retrieves data from a database, does a few other things, and then returns it to the client – it doesn’t need to be asynchronous to have sub 100ms response times.

Many web data services do enough I/O to benefit from the concurrency.  But, I don’t think node is the right choice for human-facing websites. I still prefer Ruby on Rails (unless your team only knows javascript).


Top 6 Gotchas with Node.JS

Screen Shot 2014-12-04 at 10.55.39 AM

Node.js has many advantages. Many developers know Javascript at least a little bit. Node offers great performance for applications that wait on I/O (like web services). There’s a vibrant open source community creating reusable node modules for almost every task (and a handy package manager to bundle them together). Node is cross platform – the same code runs on Windows, OSX and Linux. And of course, there’s the promise of re-using Javascript patterns on both the client side and the server side.

I love node, but I’ve run into several gotchas with node in production the last few years. Here are the top 6.

1. The website (server process) is fragile. With node, the process restarts on every unhandled exception. This is different from Ruby on Rails, where you have a separate server process like Unicorn, or PHP where it runs as an Apache module.

With one client that was transitioning from PHP to node, our first deployments felt like we were “plugging the dike” – there were so many server crashes. Until we stabilized things, this sort of gave node a bad name (the perception was that PHP was more stable – but in fact the exceptions were just hidden).

Handling all potential errors, as well as unplanned exceptions is impossible. Most deployments have another process to restart the primary node server process when it bombs. If you’re using a PAAS provider, this will be provided for you, but if you want fine grain control of your server (most web application companies will), hosting and scaling (keeping processes up and enough process around) is a challenge.

Common server-restarting libraries for node are: Upstart, Forever, or God.

2. Writing and maintaining asynchronous code. Callbacks are a simple mechanism starting out, but as your server code grows in complexity, they become a hairball. Crazy callback chains (AKA “callback hell”) make code unreadable. Even simple code that could’ve been procedural is forced to use callbacks due to the libraries you’re using.

Mixing synchronous and asynchronous code makes it difficult to handle every error. Furthermore, you have to understand the event loop to know when execution actually switches contexts. As you’re running your code – if you forget to call a callback, you’ll be left waiting to find out what happened. And, asynchronicity makes even your tests become more complicated.

The Async library exists to handle common asynchronous patterns. Personally, I prefer the “promise” (or “deferred”) pattern. It seems like a hack to send a function as a parameter, instead the promise pattern returns an object representing the state of the asynchronous call instead. jQuery has a promise library for the client side. When is the promise library we selected for a recent node-based web site (comprehensive API and more standards based).

3. Too much choice.  The flip side of all those great NPM packages is that there is no clear winning web framework (think Ruby on Rails) for node – in fact, there are several competing server side frameworks (express, hapi, sails, kraken). Each with their own conventions for:

a) File structure
b) Deploying code
c) Building assets
d) Automated testing
e) ORM

And of course, the best choices for each of these changes monthly. This, combined with #2 is why Node is not yet a great choice for simple human facing web sites.

Of course, it’s not necessary to use node on the server.  On one team we used it to great success for building thousands of lines of Javascript and templates to be hosted inside a Python Django website. The problem of too much choice exists for client side frameworks (and build tools) as for the server side (you’ve heard of Backbone, Angular, Ember). Node (with the help of tools like grunt or gulp) is essential to building a modern front-end, just prepared for the evaluation time and conflicting opinions on frameworks.

Screen Shot 2014-12-04 at 10.55.39 AM

Visualization of NPM Packages


4. Javascript the language. Many developers think they “know” javascript from having used it in client side code. In fact, they haven’t learned about things like prototypal inheritance, function binding (what is this pointing to?), or variable scoping that are unique to Javascript. Even once you’ve chosen Javascript, there are still a lot of decisions to be hammered out amongst your team. Code conventions (4 spaces or two?) Camelcase or snake case? Jshint is a huge help with this. But, be ready for…

5. Functional versus object oriented programming. There are two very distinct paths any Javascript project can take. Functional style favors dependency injection for testability and clear interfaces (that are theoretically more re-usable). Object oriented favors composition and inheritance for more readable code. The best choice is probably a mixture, as both are silly at the extremes. My current team is finding compromises, but please let me know if you’ve got any guidelines for when to be functional and when to be OO.

6. What about Coffeescript? I hate semicolons. Compared to other languages that give white space meaning (Python and Ruby), Javascript feels heavy and hard to read. I love Coffeescript because it lets you write clear (information dense) code while avoiding common Javascript pitfalls (see #4 above). Node supports Coffeescript natively, but unfortunately, transpiling from Coffeescript means you lose a debugger (and sometimes line numbers).

You also lose the benefit of going with a “lowest common denominator” language (everyone knows Javascript, C, or Java). And, you still need to know javascript deeply (#4). Worse, it can create division on your team. Make sure if you switch to coffeescript, you switch all the way.

Thanks to Scott Nonnenberg, author of thehelp-cluster (a solution to #1) for feedback on this post.

Please leave a comment and tell me: what problems are you having with Node.js?



javascript compare strings

For reference, this is all you need to know.

“0” < “A” < “a” < “aa”

In other words, first numbers, then capitalized words, then lower case words.

Here’s how you javascript compare strings

If you are sorting an array of strings, simply use the Array.prototype.sort() function as above.

If you want to write your own function to compare strings, use something like …

function(a, b) {
if (a < b) {
return -1;

if (a > b) {
return 1;

// a must be equal to b
return 0;