Node or Not

Front-end web technologies are maturing at a break-neck pace.  It’s hard to keep up, to manage versions and dependencies, and stay abreast of the latest best-practices.  Heck, it’s hard just getting stuff to work correctly without having to go off-roading through someone else’s github repository.  But luckily, there’s a back-end framework that manages all that front-end stuff effortlessly. The other day I mocked up an administrative web dashboard using the rdash framework.  It was quick and easy- I slapped some dummy charts on it, filled in some Lorem Ipsum and showed it off.  It took only a few minutes to get all the frameworks in place; Angular.js, D3.js, Bootstrap, and a whole host of others to glue it together. Then the cool part started.  As I was showing the mockup to a coworker, I made a change to the code- and the web page automatically refreshed with the changes in place.  I had served up the web app using gulp.js, which watched the local file system for changes, rebuilt the entire app, and sent a message to the browser to refresh itself.  My coworker exclaimed that it must save a lot of time, not having to save, build, and then refresh for every change.  Yes it does. All made possible by node.js. If you’ve paid any attention to the web and software development world in the last couple years, you’ve heard about node.js.  You’ve probably even seen the blog posts about what it’s good for and what it’s bad for (video).  The whole conversation has become stale, so let’s ask a better question: should you use node? If you’re a developer, Absolutely.  But maybe not...

The Smartest Man in the Room

I’m a big fan of the BBC show Sherlock, in part because of writing and acting, but largely because the whole thing is driven by his singular genius and the friction he creates between himself and every other character.  In the tech world, we work with a lot of very smart, yet oh-so-prickly people.  It seems to come with the territory. But I was reading a post a few weeks ago titled, “Why I’m Kind Of Tired Of The ‘Smartest Man In The Room’” and it got me thinking.  Sometimes I fancy myself the smartest person on the team, but experience has demonstrated that “smart” and “successful” aren’t the same thing, and even if it were true (it rarely is), I’m not the sort of save-the-day genius portrayed in Sherlock. The truth is, no one is that smart. One of the big take-aways of reading that article was that most of the protagonists are really smart, and really awful to work with.  They’re jerks.  And somehow it’s okay to be a jerk if you’re really smart.  But in the real world, it’s never okay to be a jerk. I know that New Year Eve is a week behind us, and Thankgiving is soooo last year, but I’m thankful that my software development team is nice as well as smart.  That makes a difference not just in our personal interactions, but our interactions with our clients, and even our success rate.  Moreover, we cherish good process rather than save-the-day fixes. Watch an episode of Sherlock and you’ll see everything going down hill all episode, things in peril, and all the interpersonal...