Take advantage of Drupal upgrades

Drupal’s upgrade mantra has always been “we will break your code but we won’t break your data” and for that reason, Drupal core and contrib maintainers typically spend a lot of time and effort in providing upgrade paths for your data so you can theoretically just run the upgrade script and update your code and you’re good to go.

In practice, this is rarely the case. We all know that Drupal major version upgrades (like D6 to D7) are no picnic. Lots of contrib modules don’t have decent upgrade paths or do not exist at all for the newest Drupal version forcing you to find a replacement. Any code code you have that stores data will likely need to have custom update hooks written for it as well.

And even ignoring the data, there’s still the issue of code. Your custom modules and your theme will have to be rewritten since there are a heap of API changes between any major version.

In other words, Drupal major version upgrades are a big time suck. You’re rewriting code and massaging data and re-theming, all just to have a clone of your already-working site on the latest Drupal version.

Missed opportunities

According to Jeffrey Zeldman, “redesigning without fixing problems is a missed opportunity.” Along those lines, I think that upgrading your Drupal site without fixing problems is a missed opportunity.

Why upgrade your site to an exact clone of itself when you could just as easily improve and simplify the problematic parts? You’re already rewriting code and tweaking data, so you might as well use that to your advantage instead of just porting your existing site to a new version, warts and all.

However, upgrading your Drupal site via the upgrade script means that you have to keep everything as close to the old version of the site as possible so that the upgrade will work. You can’t change content types or fields or roles or modules because then the upgrade will obviously break. So what’s the best way to handle this?

The fresh start and migrate approach

My suggestion is a from-scratch build followed by a migration. The process goes like this:

  1. Identify problematic or messy or improvable areas of your current site.
  2. Sketch out a new, clean, improved site that fixes all of the problems of the current site. Pretend it’s a brand new site for a client and you aren’t constrained by any technical debt.
  3. Build that site. Build it like a new site, with a new theme and new content types and a new block setup and new field organization and new roles and new everything.
  4. Migrate the old site’s content into the new site using the Migrate module. Depending on your setup, you might even be able to use the Drupal to Drupal framework for the Migrate module which will simplify your migration.

Advantages of a clean build

The benefits should be clear here. With any second attempt at something, you go into it with the knowledge of where the first attempt failed, and this is especially true in the world of programming. You recognize gotchas or redundant content types or ugly IA and you know how to fix it.

Or maybe your old site didn’t even have any real issues (liar). Maybe you just want to use this opportunity for a redesign and IA overhaul. Either way, the end result here is that you get a better site and you don’t have to inherit the old site’s problems or legacy choices.

It’s worth pointing out that you can do this whenever you want, and you don’t have to do it during an upgrade. You’re always free to rebuild your site and make it better, but it’s costly and it’s time that you don’t directly get paid for, so it’s a tough sell. So the reason it works in this case is that you were already going to be spending a significant amount of time upgrading the site, so it’s not time you’re losing, it’s just time that you’re transferring from one objective (“upgrade”) to another (“upgrade and improve”), the latter being good for business and the former just being a necessary evil.

Also, doing it this way (with a migrate script rather than the upgrade script) means that you can continually migrate in new or updated content as you’re working. This is especially useful on sites where content is constantly added, whether it’s an active blog or a news site or a site with user comments or a forum, etc. If you upgrade with the upgrade script, then once the script is run, you basically have to lay down a content freeze since it’s difficult to pull in any content that was added or edited to the old site after that unless you do it by copying and pasting.

Disadvantages of a clean build

The only clear disadvantage here is time. It can be a little quicker to do the classic upgrade rather than doing a from scratch build and migration (though often not as much as you’d think). However, my rebuttal to this is that the time you spend now will be time saved later since you’re ridding yourself of technical debt and you’re fixing issues that need fixing rather than just cloning the site.

Did I miss anything? Tweet me if so.


AngularJS’s declarative markup

Every time a discussion of AngularJS pops up, someone inevitably brings up the fact that Angular wants you to add custom ng-* attributes to your markup. They say that we worked so hard to get away from stuff like:

<a onclick="whatever()" href="#">Click me</a>

…by replacing it with jQuery callbacks declared in a separate JS file, and now Angular is trying to bring back the old busted style by using stuff like:

<a ng-click="whatever()" href="#">Click me</a>

Here’s why I think this is not a big deal.

You can make it conform to the HTML5 spec

One of the most common problems people have with this is that ng-_ is not a valid HTML attribute. The quick and easy answer to that is that Angular also accepts data-ng-_ which is HTML5 conformant. It’s just not as widely used.

HTML is already behavior-oriented.

The argument that JS behavior for user actions should be separated from markup doesn’t make much logical sense to me, because HTML itself is built around the notion of behavior.

Each link has an href that says what happens when you click it. Each form has an action that says what happens when you submit it. Select dropdowns open when you click them. Radio buttons and checkboxes toggle when you select them. Saying that HTML and HTTP actions are kosher but JS actions are not seems arbitrary to me.

A document vs. an application

I think we can all agree that separating content from presentation and logic is nice and recommended in a document.

However, Angular applications are not documents, they are applications. They are dynamic and they live and breath and they respond to user input. This is a paradigm shift and as such it should be treated with different rules and different best practices.

(Yes, all HTML pages are technically documents, but you know what I mean).

It’s not global

One reason why onclick=”whatever()” is so frowned upon is that the whatever() function had to be global for it to be recognized.

With Angular’s ng-click=”whatever()” approach, whatever() is just a function on the $scope object for whatever controller that markup is using, which means you’re not throwing everything into the global scope. This has the added benefit of making it easily testable (testability is very highly valued in the Angular community).

It has to live somewhere

An event listener by definition requires at least some DOM and at least some JS so that it can tie the two together. In the world of jQuery callbacks you’re adding DOM to your JS (in the form of selectors). In the world of Angular you’re adding JS to your DOM. Either way you’re coupling them, which brings us to…

The alternative is no picnic

Doing it the jQuery callback way means matching behavior up to jQuery selectors, which means that your behavior depends on whichever class or ID or decided to assign to your markup. This means that a class change that might just be for CSS purposes could break your JS in non-obvious ways. This is a refactoring nightmare and will make scare you away from making any edits to your markup when making design changes.

Plus, when the behavior is defined in the markup, you can easily tell what is happening when you click this or hover that. If you see ng-click=”whatever” then you know you can grep your JS for whatever() to find the function’s definition.

On the other hand, if your jQuery callbacks are defined in one of 10 or 20 JS files and you have no idea which selector the JS is using to grep for it, finding the code you’re looking for can be tough. It usually involves setting an event breakpoint in the browser’s dev tools and stepping through the debugger until you see it, which is not my idea of a good time.

Did I miss anything?

Tweet me if so.


The Professional Coworker

I tried to keep this post as ranting-free and preaching-free as possible but it was difficult, so please try not to complain about that. I did my best.

In my line of work I’ve met a lot of great programmers, and I’ve met a lot of people who are a pleasure to work with, and interestingly enough the intersection between those two groups has been pretty small for me. In my experience, good programmers just don’t tend to be good coworkers. I’ve talked about this before.

If being a good coworker was very difficult or required some natural talent, this would be understandable, but most of the things that make someone easy to work with are dead simple. To understand, let’s talk about what makes someone a good coworker. In my mind, it comes down to a few things:

  • Organization. Good coworkers don’t lose things (notes, emails, deadlines, tasks, passwords).
  • Responsiveness. Good coworkers are easy to get a hold of and respond quickly.
  • Reliability. Good coworkers do what they say they will do, when they say they will do it.
  • Personality. Good coworkers are friendly, approachable, and positive.

The interesting thing about that list is that all of those 4 things are just a matter of effort. We’re not talking about “sense of humor” or “intelligence” or other inherited traits or lofty goals. Rather, it’s things that anyone can accomplish with a little work.


Stop losing crap. That’s it. If you lose crap and rely on your coworkers to find it for you or cover for you or feed you the same information more than twice, then you are bringing down your team. If you find this difficult, here are some (possibly common sense) things that might help:

  • Put passwords in a password manager like LastPass.
  • Keep all your miscellaneous notes in one searchable place like Evernote.
  • Keep a task list, and really keep up with it. People are keen on Trello nowadays. I just use Google Tasks since it’s built into Gmail so I see it a hundred times a day without meaning to.
  • Keep your inbox empty except for emails that you need to respond to ASAP. Use a service like FollowUpThen to archive things that you can’t respond to yet and have them pop back up at a later time so you don’t forget about them. This way you will never miss an email, because if it’s in your inbox, it needs your attention now, and if it’s not, then it doesn’t.
  • Put deadlines into Google Calendar and set email reminders for a day or two and a week ahead of time.
  • Save all history from all IMs so that they’re searchable (most chat apps support this) and don’t delete any emails.
  • When looking for information you think someone has given you before, make sure you search everywhere (email, IM history, notes, etc.) thoroughly before asking your coworker to tell you again.


This next part is important: respond to emails (and IMs and calls) in an hour or less. This is the biggest single point of frustration I have had with poor coworkers, they either ignore emails altogether or take a day or more to respond. Unless you’re getting 200+ emails a day (which is fairly rare for your average programmer) there is no reason for this.

You can take this one of two ways. You can go the super-obsessive route (like I do) and tell your email client to alert you right as emails come in at which point you stop whatever you’re doing and reply that very second (this becomes difficult when you get an email every few minutes). Or you can set up a recurring reminder to tell you to check and respond to all of the emails in your inbox every 30 minutes or hour. Either way, the goal here is to make sure that no email sits in your inbox for more than an hour. If you can accomplish this, then your coworkers will absolutely adore you.

Now is the part where you say “but Mike, you don’t understand, I power code for hours at a time and checking my email kills my concentration and productivity” and to that I say if responding to your coworkers quickly means losing 5 minutes of productivity then that sounds like an excellent sacrifice to me. “But Mark Clark the productivity expert writes that checking emails that often is bad! He says you should have 1 or 2 set times you check it each day!” Same answer. Yes, that is more productive, but an insane level of productivity isn’t the holy grail. It’s more important to be responsive to the people you work with than it is to squeeze every last ounce of coding productivity out of your day.

The 2nd, less crucial part of being responsive means making yourself available in as many ways as possible. Along with email and phone, stay logged in to whatever chat apps each of your coworkers prefers using. It’s nice to make sure no one has to open up an app they didn’t already have open just to chat with you.


This is fairly close to organization (i.e., just plain losing tasks or deadlines) but not the same thing. In this case, you miss tasks or deadlines not because they were lost in the shuffle but just because the you didn’t plan your time well or just didn’t care enough to make it happen.

An attitude of “if I miss this deadline then I have failed my team” is dangerous but also powerful. If your deadlines are completely unreasonable then obviously you should try to fix the root cause of that rather than just giving up sleep and killing yourself, but if you’re missing reasonable deadlines then do whatever you need to do at a personal level to stop it, because that is not OK. You are breaking promises to your team.

Doing a better job prioritizing your task list and setting daily goals for yourself tends to help, but in general an “I cannot miss this deadline” attitude is the best motivator, even if it means you work some nights. Stop telling yourself that if you are a day or two late on this or that deadline then it’s not really a big deal.


If you’re grumpy, then your coworkers will be grumpy to have to work with you (even if you’re otherwise 100% awesome) and grumpy coworkers don’t do good work. So even if you don’t personally care about making people happy or sad (you monster!) then try and force yourself to be friendly during working hours just for the sake of the project that you’re working so hard on.

Why does it matter?

If you write good code, why does all the other stuff matter? You were hired to write code, right? Doubtful. You were hired to help the company accomplish its goals, and your role in these goals is probably far more complex than just “write beautiful code that works well.” It probably involves things like supporting your coworkers, managing scope, hitting deadlines, explaining things to PMs, communicating with clients, writing documentation, managing other developers, keeping track of your hours, etc. All things that even the best coder can easily fail at.

So please, for the sake of your coworkers, try and make sure you’re making their lives easier instead of harder.


Marking Gmail read with Apps Script

Recent versions of Android give you the ability to Archive an email right from the notification bar. I use this like 30 times a day, for emails that I can tell from the subject that I don’t need to read. It’s awesome.

The only issue is that these message stay unread, and seeing a bunch of unread messages in my archive or labels annoys me, so every morning I search “label:unread” and mark all as read. It’s a total first world problem, but annoying nonetheless.

I’ve been looking for some sort of app or something to auto-mark-as-read any messages not in the inbox for months now. Then someone recently pointed me to Google Apps Script and 10 minutes later I had a script running which automatically marks all archived messages as read every minute. I was blown away at how easy this was.

Here’s how it’s done:

  • Head to to start a script.
  • Choose to create a script for Gmail in the little popup.
  • Delete all the sample code it gives you.
  • Replace it with this (written using the API reference):
function markArchivedAsRead() {
  var threads ='label:unread -label:inbox');
  • Save the project with File > Save.
  • Add a new version using File > Manage Versions and enter “initial version” then submit that.
  • Do a test run using Run > markArchivedAsRead and be sure and authorize the app when it asks you to.
  • Add a new trigger using Resource > Current Project’s Triggers and choose to run the above function every minute (or hour or day or whatever if you want to be nice to Google’s servers).
  • Save the script again and exit. Don’t worry, it will keep running.

And you’re done. It will continue to run every minute until you stop it. How awesome is that?

Update: Some people are reporting an error which says “This operation can only be applied to at most 100 threads. (line 3, file “Code”)”. To fix this, you have to manually do a search for “is:unread” and mark all of them as read before running the script, so that it starts with a clean slate. The script can only process 100 threads per run, so if you give it more than 100 on the first run, that’ll obviously bust it.

Hey, maybe you should follow me on Twitter!


Drupal’s Golden Handcuffs

Drupal’s main draw is that it gives you the power to do an insane amount of work with zero coding. This is both its blessing and its curse.

The blessing

Drupal is great for developers for exactly one reason: it’s really, really productive.

Here’s a short list of example things that can be accomplished in Drupal with no custom code:

  • A listing of arbitrary content written by user X and published within the last Y months (where X and Y are arguments in the URL in the form blog/user/X/recent/Y), grouped by month and formatted as an ordered list with custom wrapper elements and classes per-field and per-row.
  • A full featured RESTful API which exposes your sites entities (whether it be products, users, categories, blog posts, videos, whatever) as resources with niceties like YouTube video links formatted as embed code and referenced images converted to grayscale.
  • Completely custom types of content with arbitrary fields such as link inputs with custom validation, photo uploaders with unlimited values and drag/drop ordering, custom tabs acting as field containers, multiple WYSIWYGs per textarea depending on which input format you choose (markdown, raw HTML/PHP, filtered HTML with custom allowed tags, blah blah).
  • Routinely parse and import content from external data sources (XML, CSV, and JSON to name a few) as Drupal content with source fields mapped to Drupal’s custom content fields in the GUI
  • Robust and fast site search powered by a Solr backend and index with support for facets/filters, sorting, weighted results, multiple search sections/pages each with their own set up default filters (by content type, category, arbitrary field value), etc.
  • A global store locator with geocoding and proximity searching, locations displayed as custom icons on a map, and the ability to customize the output of the results list (show a thumbnail of the store if you want to, output results as a table with sortable columns if you want to, I could go on).

Seriously, it’s freaking ridiculous. The benefits of having all this available in a ready-made GUI without custom code should be obvious, but I’m going to list them out here so that I can waste your precious time.

  • No debugging your custom code
  • No digging through the docs trying to find the API function you need for an odd task
  • A discoverable UI–click around until you find what you’re looking for, rather than digging through code
  • A team of thousands of users and contributors testing the code in ways you never would have imagined and fixing the bugs
  • A much much smaller risk of security breaches due to that team
  • Holy crap, so much faster

That last one sums it up. Creating advanced functionality by clicking around is so much faster than writing it by hand, even if you’re using an opinionated framework that cuts down significantly on the custom code you’d have to write. The minimal debugging and bug fixing and security auditing and API reading are all just more time saved.

In essence, Drupal is extremely productive once you know your way around core and the popular contrib modules, so much so that it’s very hard to leave it for something else for general purpose site building.

The curse

So Drupal lets you get crap done really quickly and sends you laughing all the way to the bank…what’s the problem? Here’s the problem. Here’s the typical day for a Drupal developer:

  • I’m bored
  • I’m bored
  • WTF?????
  • I’m bored
  • Lunch!
  • I’m bored
  • I’m bored
  • I’m bored
  • I’m bored

The particularly astute readers will have noticed that a Drupal developer is usually either 1) being bored clicking around or 2) screaming at Drupal for failing them in extremely hard to debug ways.

When stuff breaks, it shatters

Let’s start with #2. The issue with building complex functionality on top of code that you didn’t write is that when something breaks, you cry. Debugging through layers and layers of code on top of code written by other people is much more likely to cause you to light socks on fire than debugging your own code.

Say that you’re using the Media: YouTube module to display YouTube links attached to content as embedded videos, and the options to adjust the video size aren’t actually doing anything (note that this bug is entirely hypothetical–Media: YouTube is great as far as I know). Where do you go? You probably first search the issue queue for that module, and maybe you’ll see an issue about it and a fix which might involve upgrading to a dev release and possibly breaking compatibility with the version of the Media module you’re using. Or, more likely, you can’t find anything in the issue queue so you dig through the Media: YouTube code which contains lots of calls to custom formatter hooks (in Drupal core) and to hooks in the Media module, all of which have their own nasty call stack to worry about. So basically, you’re going to have a bad time. However, at least you’re doing something that requires brain power.

The click monkey

That brings us to #1. Most of the time everything works alright more or less so you’re just clicking around plugging away with building the site. This is almost worse, because you are now a click monkey (the type of monkey that code monkeys make fun of).

Everything that you were excited about as a programmer–working through interesting solutions to complex issues, writing sweet algorithms, refactoring crappy functions into beautiful snowflake functions–all that stuff is just a pipe dream, and you’re nothing more than a well paid mouse button operator.

Can custom code cure cancer cornflake?

Still, you’ll likely need to write some custom code, whether it’s for a unique feature that there isn’t a module for or you’re just doing some theming overrides. It seems like this should be the escape from the monotony of clicking but really it generally just ends up being frustrating. Drupal just isn’t a great system to code for.

  • It’s complex. Try wrapping your head around the render array in 7 or figuring out WTF to do with stream wrappers.
  • Content and display are not well separated. Modules build markup directly, hopefully with theme_whatever functions that you can override in your theme, but often not. Doing this in custom code just feels sad, even after years of doing it.
  • The Drupal 7 database abstraction layer is nothing more than a PITA. I don’t know anyone who prefers that to raw SQL, and IMO the added benefit of having a tiny bit more database agnosticism isn’t worth the decreased DX.
  • Drupal 8 will “hopefully” bring with it Views in core, a GUI layout builder in core, edit-in-place in core, all of which are things which will have their own complexities to learn and understand and override and debug.
  • Many changes require flushing the Drupal cache to appear. If I had a jellybean for everytime I flushed Drupal’s cache in the last few years, I would be too busy eating jellybeans to write this.
  • Documentation is still a mess, despite a huge community-wide effort to improve.
    • Individual contrib modules may or may not have docs, and if you’re lucky they may be a page on or a README.txt in the module. However, the chances that there are docs specifically for developers rather than site builders are slim to none, so you’re often stuck digging through contrib module code looking for hooks and functions to do what you need.
    • Drupal core documentation is scattered across various book pages throughout the site and many things just don’t have documentation at all (at least that that I’ve found).
    • Many docs pages are outdated but don’t tell you that, so you find yourself hoping that someone in the comments has said what Drupal version that page applies to, and maybe even linked to an updated page for the newest release.
    • It’s always a battle to find the API function you’re looking for if you don’t know what it’s named. What’s the function to select all nodes assigned to a taxonomy term? Here, let’s search the API for taxonomy. Hmm, 10 pages of results. How about for “taxonomy nodes”? Zero results. Resort to Google, hope that someone has asked this on Stack Overflow, finally find it, and repeat the process 10 minutes later with another function.

So no, custom code cannot cure cancer cornflake. Custom code is either also boring if you’ve done that thing times before or frustrating if you haven’t.

Note that I understand that there are many reasons why most of the above list of grievances can’t be changed (for example, if modules didn’t build markup directly then you’d be stuck doing it all yourself in the theme ala Expression Engine which would greatly increase your development time), but it doesn’t mean that I have to enjoy it.

The future

Will Drupal become more fun in the future? Possibly, but likely not. Possibly because things like API cleanup and docs and miscellaneous DX niceties can add up to a difference, but likely not because Drupal has always been and always will be about being productive over being fun to code on. Drupal 8 is adding more functionality (see Spark) rather than subtracting it.

It’s a vicious cycle–Drupal attracts people who want to get crap done and don’t care as much about getting it done in the most enjoyable or most elegant way possible, because that’s what Drupal’s good at. These people in turn become contributors and push Drupal further along that road.

The Golden Handcuffs

So your work isn’t quite as interesting or challenging as it might be if you’re working with Django or Rails or whatever, but you’re able to do stuff a lot faster than you’d be able to do it using anything else so you can’t leave without dealing with the frustration of knowing that. Try spending 150 hours building proximity search with mapping in Django and knowing that it would take a day in Drupal. It’s the Drupal Tradeoff ™ and unfortunately it’s not something that any version of Drupal can really improve upon.

So what to do? Well I know what I’ll do, I’ll keep using Drupal and getting crap done, and I’ll just use other technologies on side projects to stay sane and feel challenged and interested. Tis the power of the golden handcuffs.

Discuss on Hacker News or reply to me on Twitter.


Nerf guns don’t matter

I’m seeing it more and more–job descriptions with perks about nerf guns and happy hour, or new grads who joined a startup and are bragging about ping pong tablesand free coke. This is apparently something that people see as a fun culture, a sign that this is a place you’d enjoy working at and has people you’d enjoy working with.

This stuff doesn’t matter.

A fun distraction is still a distraction

This stuff is all stuff you do when you’re not working. When you have a few minutes to spare here and there and are bored and want to have fun. It’s recreation. It’s a distraction from work. It’s not going to make you more productive, or make you happier with the work you have to do, or the people you have to work with.

In fact, it might make you less happy with those things. Suddenly the work you have to do, which could and should be fun and challenging if you’re in the right field, is just a necessary evil to spend a few hours on before the next game of ping pong. You’re not at work to play around, you’re at work to get crap done, but if you spend long enough in an environment like this, then the work becomes the distraction and the nerf guns and happy hour become the thing you look forward to and are excited about.

This will not help your productivity and certainly won’t make doing actual work any more enjoyable.

Keeping work and play separate

Lots of people seem to love bragging about working hard and playing hard, and it’s a pretty common attitude that working with people you can go play laser tag with and be friends with is a big win. I’m going to disagree.

I’d like for people at work to judge me based on my work, not on how good I am at pool or how well I can handle my alcohol. I’d rather they didn’t know any of those things, because it just distracts from what you’re there to do. I don’t want to have to deal with the drunken argument last Friday night at the bar when I’m working Monday morning. I don’t want someone I work with to be bummed out with me because I didn’t want to hang out on Saturday since I have a family.

Trying to enforce a culture where people are all friends with each other and go out drinking together and watch movies together does not make anyone any happier when they’re working, it just creates more opportunities for drama and biases.

What really matters

It’s easy to throw some toys into the office and call it your culture. Actually creating a good, positive, productive culture is much, much harder than that.

Do your employees feel heard when they have suggestions or questions? Do your managers do a good job of keeping track of budgets and focus without micromanaging and getting on everyone’s nerves? Do people have a solid method of critiquing each others work and providing helpful feedback without hurting any feelings? Does everyone feel challenged and interested in the work they’re doing?

These are the things that produce a good culture, and these are the things to strive for, and these are things that you can’t buy at Target or brag about on job descriptions, but they’re the things that keep people around and working hard and happy.

Discuss on Hacker News.


Coding skill vs. employee skill

At the extremely basic level, there are basically two good qualities that each programmer should strive for: programming skill and employee skill.

Programming skill is basically the ability to write good, solid, performant, maintainable, and all-the-other-desireable-code-adjectives code. This is what coders tend to spend their time harping on and debating about and reading about.

Employee skill is the ability to be a good employee and coworker. This means being responsive, being able to communicate well, hitting deadlines, being open to feedback, being able to explain complex things clearly, stuff like that.

An extreme example

Picture two people:

Rodrigo is an MIT graduate who writes compilers in his spare time. He is a core contributor to Haskell and wrote a few very well known Python packages. He can generally write very solid code that’s readable and handles edge cases beautifully. However, he takes days to answer emails, he rarely picks up his phone, he doesn’t seem to have much of an understanding of the importance of deadlines, he does things his own way, and you can’t get a clear thought out of him without rambling incoherence surrounding it.

Gabriella isn’t a very good coder. Her code is obviously written by an amateur. She takes 30 lines to write what should be written in 15 or 20, she introduces bugs that QA has to spend their time on, and she doesn’t really grasp the concept of writing code that performs well–“if it works, it works!”. However, she’s incredibly responsive–she answers emails within minutes and never misses a call, she is a great communicator and is able to explain complex technical issues quite clearly to clients, she has never missed a deadline, she is constantly looking for feedback to improve her work, and she’s an easy person to talk to.

So really think about it. Which would you really rather work with on a day to day basis?

What really matters?

In my experience, a programmer would rather work with Rodrigo, and a manager would rather work with Gabriella.

This makes some sense–after all, programmers are the ones who would have to deal with crappy code, and managers are the ones who would have to deal with missed deadlines and crappy team communication, so we all want the person who causes us the least amount of pain.

However, the point is that managers are the people you need to impress to get jobs and promotions and raises and pats on the back, so in this scenario, Gabriella comes out way ahead. And I’ve seen it happen many times–programmers who are great employees but not great coders move to the top while the great coders but poor communicators stay on the bottom.

Despite what we as programmers like to think, coding skill is not what really matters if you want to find success in a job, or at least in many jobs. Being a good employee is at least as important, sometimes more.

Discuss on Hacker News.


Taco Bell Programming

If you haven’t read Ted Dziuba‘s post on Taco Bell programming, go do that now. It’s really a great post.

The gist is basically that we can and should be writing programs using the stuff that’s been available for tens of years, stuff like bash and xargs and find, and that using the latest and greatest tool or language simply adds complexity and bugs. He compares it to Taco Bell, which uses “roughly eight ingredients” in random combinations to make the entire menu.

This was like a smack in the face to me, a person who always gets excited about trying the new hotness. One thing about it concerned me though – a lot of that stuff just isn’t fun. Nobody wants to write stuff in bash, and there’s a reason people use modern tools: they’re often more fun and less annoying.

So I emailed him to ask him how he balances that. Here’s my email:

Hey Ted,

Feel free to ignore this question if you’d like. I’m sure you get a lot of emails from random devs, especially lately.

Straight to the point, just read your taco bell programming post and was intrigued by it, but it didn’t mention anything about dev preferences or the dev experience. For example, writing something in bash (like Hubot for example) might take less code to do it in Python or CoffeeScript or whatever and it might be the more solid solution but most devs will go way out of their way to avoid having to write something non-trivial in bash.

So the question is, how do you find a balance between simplicity/tried-and-tested-tools (taco bell ingredients) and ease or enjoyment of development (using a more modern language/tool just because it’s less annoying)?

Thanks. Big fan of your posts.

Here’s his response. I wasn’t planning on posting his response (if he even ended up responding) but it’s such a great answer, I’d feel like a chump if I didn’t share it.

Hey Mike.

I know a lot of devs will go out of their way to avoid shell scripting, and generally using the tools already available to them by their operating system. I know, I used to be one of them.

I got into letting Unix do as much as it can for me by the advice of a systems administrator I hired, who really swayed me toward that culture, and after the first project I wrote on Unix principles, I immediately saw the value of it (this one piece of functionality was the most rock solid thing I have ever written, it’s been running for 2 years now with zero maintenance).

On to your question. I guess it depends on what’s easy for you to do as a developer. Learning a new language like Bash isn’t something to take lightly. I still don’t know enough of it to be dangerous, but I hack things together. Once you understand the Unix Way, the process becomes much easier. I’d recommend reading “The Art of Unix Programming” for some great insights.

Generally, you’re never writing nontrivial code in Bash. You use a bash script to string together smaller utilities into something useful. All the real meat of execution happens in the programs your shell script calls. Nothing precludes you from writing bits of functionality in any language you want. One of the Unix Way principles is that “a program should do one thing, and do it well”.

When I try to find the balance between Unix tools and custom tools, I ask 3 questions:

What parts of this problem does the operating system solve for me?

Of the parts that the OS can’t solve, am I simply not aware of something my OS does that can solve the problem? (This happens a lot.)

What’s likely to be the most brittle part of the system?

I find that a lot of developers have gross misconceptions about how operating systems work, and will try to excuse themselves behind a veil of “scalability” or somesuch. For example, I had a good argument with a developer last week who was convinced that “starting processes was slow”, so he was cooking up some threaded catastrophe.

Fact was, it’s simply not true. Modern Linuxes can spawn processes very quickly, and actually use the same syscall to spawn a process that they do to spawn a thread (clone()).

At the end of the day, it’s really something that comes with experience. With any system you write, V2 is always way better, because you’re more aware of the things you don’t know 🙂


Why would anyone use vim?

(Note: this is a post for vim newbies. If you’re an experienced user, you won’t find anything new here)

I recently switched to vim full time after years of asking myself that question. It seemed like a huge percentage of the better hackers I came across used vim, but all I could see was “no mouse, no IDE goodies, no deal.” Why would anyone subject themselves to that? Well, turns out, here’s why:

Vim is ubiquitous

For web developers who do a decent amount of SSH’ing and editing on a server somewhere, this is huge. Pretty much any Linux box you can find yourself in will have vim installed, and it’s a huge plus when that editor just happens to be the editor you use day in and day out and are comfortable with.

To take it a step further, you can even use vim key binding in Firefox, Chrome, bash, Thunderbird, etc. Here’s a nice list. It has a decades-long history and tons of fans, so you start to find that almost anything you do on a computer can be done in a vim-like fashion.

Vim is lightweight

Vim starts up immediately and leaves a teeny tiny footprint. Maybe this isn’t important to some, but it really makes me happy.

Contrast this with the beastly modern IDEs or even the “lighter weight” text editors (Atom and VS Code especially, which are Electron-based) that take seconds to launch and gobble RAM. It’s very refreshing.

Vim has everything I wanted in an IDE

One of the main things that stopped me from giving vim a serious look for so long is the false belief that it was just a simple editor with some crazy key bindings. Turns out, I couldn’t be further from the truth. After just a couple days of using vim, I had set up an environment with:

  • Tab autocomplete (for both project functions and language functions) complete with a function definition popup
  • The ability to jump from function call to function declaration and back easily
  • A sidebar function outline, automatic syntax checking (even including JS using JSLint and HTML using Tidy)
  • Spell check (for typing up blog posts like this one)
  • Tabs for switching files (although it seems basic, I was worried about using multiple files in vim, but it’s really great)
  • Project search (including replace and regex support)
  • Smart indenting and auto-indent support
  • Just about any other IDE goodie that I wanted.

I really can’t think of anything I’m missing now that I would have with a different setup.

Vim has some really great plugins

I’ve found the plugin selection for vim to be a cut above that of most other editors. Some of my favorites are:

  • Fugitive – A vim-based Git wrapper that lets you do most git things without leaving vim.
  • Syntastic – Automatic syntax checking for many languages. Opens errors up in a split window, highlights problematic lines, lets you jump from error to error, etc.
  • Ctrl-P – Quickly open project files by typing any part of the filename/path. Much faster than using tree-based sidebar project file lists for me.
  • Gist – Create a GitHub Gist out of the document or selection. This is really, really awesome for me as I tend to send code a lot in IRC.
  • Tagbar – Displays a toggle-able sidebar of project or current file functions/variables for easy jumping.
  • NERDCommenter – Comment out lines/chunks/selections of code in many languages, with your choice of comment types.
  • Emmet – Vim support for the amazing HTML/CSS shorthand expander.

Vim’s modal editing really opens doors for amazing things

This is the main thing that keeps vim users happy. Vim has a “keep your hands on the home row” philosophy, and the only way that’s really possible is by making the main keyboard keys do more than just type letters. So, because of that, you have your regular old insert mode (same as other editors), but you also have a “command mode” that lets typing things execute commands rather than inserting text. Here are a few examples:

  • Type d$ to delete everything from the cursor position to the end of the line (d = delete and $ = end of line)
  • Type o to create a new line below the current line and enter insert mode on that line.
  • Type ci" to delete everything inside double quotes and enter insert mode (c = change, i = inside, and “ = what you want to change inside of)
  • Type gg=G to autoindent the entire file (gg = top of file, ”=“ = autoindent, and G = end of file).

This is crazy for awhile, but then it starts to not seem so crazy, then it starts to actually seem pretty sane, then it becomes amazing. For a quick intro to vim’s commands, type the vimtutor command at a terminal and go through that – it only takes about 10-15 minutes.

Vim is fun to use

All of this adds up to a really enjoyable experience. You have a lightweight, free, feature-rich, customizable editor that’s everywhere and lets you get crap done more quickly. I’m glad I gave it a shot.


On Google Wave

Google finally threw in the towel with Wave, saying that adoption rates just weren’t as they hoped. Many have said that Wave’s fail was that it launched as an invitation based service, which meant that you couldn’t really use it because Wave can only be used with other Wave users, and none of your friends had been invited yet. However, that’s not the reason; Wave still could have succeeded once everyone had access to it.

Here’s my take on it. The trouble with Wave is inherent in what it is: it’s an all-in-one communication tool. It’s part email, part chat, part word processor, part task manager, part twitter, part whatever the crap you want it to be. So where is the problem? Well, that’s not really a graspable and definable goal, so people had trouble understanding what it was really useful for in the real world.

Wave tried to do too much, which in turn made it seem like it didn’t do enough. It wanted to replace email, but it couldn’t contact people who weren’t already using it. It wanted to replace IM, but you had to use a browser for it to work, not an IM client. It wanted to replace collaboration apps, but lacked many of the task-specific features of such apps. Any app that attempts to be an end-all solution like Wave will constantly be plagued by people wanting it to do more to replace the individual tools they’re already using. It’s the age-old problem of doing many things, but doing none of them well

When it comes to successful apps, there are only two varieties: simple apps and onion apps.

Simple apps like Twitter (post your status, read others’ statuses), eBay (buy stuff auction style), Wikipedia (encyclopedia edited by everyone) are all deliberately simple. They are all easily understood at first glance because there’s nothing to not understand. They solve a problem that is easily defined and, as such, are instantly graspable.

“Onion apps” are just as easily understood, but their feature sets go a little deeper. Look at Google search, for example. At first glance, it’s an uber-simple search engine; the UI reinforces that. Then you see that you can also search for products and even buy products. And then you find out that you can search local businesses. You can even get maps and directions of those businesses. There are tons of really cool features that you slowly come across. This is what makes it an onion app – it seems simple until you peel (get it?) away at it a bit.

Facebook is the same way. At first, it seems like Twitter without the word restriction (i.e., a way to say what you’re doing and find out what others are doing), and people get that. Once that makes sense, then they notice that they can post photos and photo albums, and they can follow famous people and businesses, and they can even play games. All of this comes after the initial “oh, so that’s what this is used for”, or, once they are ready to peel away at it a bit.

And this peeling is why onion apps don’t suffer from the “it does too much” syndrome. Facebook, for example, could easily be ridiculed by saying that it’s for communication but it can’t replace email since you can only communicate with friends. However, nobody says this because we all understand that communicating with friends is the whole point of Facebook. It’s not a general purpose communication tool. This understanding may be false, since it’s used for much, much more now, but because of that initial impression and how Facebook presents itself, that’s all we really expect of it, so we don’t complain when we don’t get more.

This is Wave’s failure. Instead of being simple and graspable or even giving the initial impression of that, Wave gave you everything up front. It was an onslaught of “WTF is all this and what do I use it for” upon first loading wave, and that is a question that can’t really easily be answered, because it is “useful” for so many things. For Wave to have succeeded, it would have needed an actual problem to solve first and foremost, and focused on that problem, adding the rest of the features as layers.

So the point here is that for any app to be successful, it has to be understandable and it must solve a real, definable problem. You would think this is old news, but Wave obviously couldn’t do this, and sadly it had to die. RIP.