Putting it all out there

Here are my normal steps for starting a project:

  1. Have idea
  2. Buy Domain Name
  3. Start sketching idea out
  4. write some code, push it to github
  5. stop working on project
  6. goto 1;

Turns out, I’m not alone:

For example, I’ve got 30 domains and I’ve only done something awesome with 3 of them. Sometimes when I log into my DNS manager I just see 27 failures. I think to myself, there’s 27 potential businesses, 27 potential cool open source projects just languishing. If you knew anything you’d have made those happen. What a phony.

To break this cycle, I’m taking a page that’s often repeated in blog posts and on Hacker News (although when I’m looking for the references, I can’t find them). From now on, I’m putting it all out there.

If I’m working on something, it’s going public.  The way I see it, this accomplishes a few things:

1. The shame factor is much higher. When I have a domain name, you probably can’t see it (unless there’s something that let’s you search `whois` records by the name of the person that registered the domain? Is there?), but with my code out on github, you can see whether or not I’ve been working on those projects.

2. Feedback.  Last night I asked on twitter about a problem I’m having:

Almost immediately, Justin Niessner replied with:

I knew about State machines, I’ve even written a patch for Evan Plaice’s JQuery-CSV library that allows it to work on Macs (Todo: put that fix in my branch), currently it’s only in use on The Motley Fool‘s Scorecard (Portfolio) tool to import CSV files that I wrote. But what I didn’t know was that they were applicable to my situation. I’d never thought about them being used in gaming. Because I put my code out there, I was able to get an answer and do some research into how games implement the state pattern.

3. Blog posts. Putting my code out there gives me something to reference when I’m writing a blog post, and it helps me to remember the state that my code was in when I’m writing the blog post. In the old days of Subversion, the ‘end’ product would be all that showed up, not the numerous steps to getting to that end state.

4. Tracking Progress: Fear may be a good motivator, but actual progress is motivating too. It’s easy to forget progress when everything is private. In my own mind, I started programming yesterday, nevermind that it was 14 years ago. It’s easy to forget those little bumps along the way. I must have relearned trivial CSS knowledge half a dozen times over the past 14 years, and without writing it down and documenting it, I’ll probably relearn it half a dozen times more.

As of today, any non work-for-hire code I have on Github, I’ve turned public.

It’s scary, but isn’t that what learning is all about?

How to destroy Programmer Productivity

The following image about programmer productivity is making its rounds on the internet:

programmer productivity in a graph

As Homer Simpson might say, it’s funny because it’s true.

I haven’t figured out the secret to being productive yet, largely because I have never been consistently productive. Ever. Joel Spolsky talks about this in one of his blog posts:

Sometimes I just can’t get anything done.

Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn’t happen.

These bouts of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I’m not in flow. I’m not in the zone. I’m not anywhere.

I’ve read that blog post about half a dozen times now, and It still shocks me that someone who we see as an icon in the programmer community has a problem getting started.

I’m glad I’m not alone.

I’m not here to share any secret methods to being productive, but I can tell you what has kept me from being productive:

  • Open Floor plans
  • Developers arguing about Django vs. .NET
  • Developers arguing in general
  • A coworker coming up to me and asking, “Hey, did you get that email I sent?”
  • Chewing. Apparently I suffer from Misophonia
  • Not understanding the problem I’m working on
  • Not really believing in the project
  • Not understanding where to start
  • Facing more than one task that needs to be complete BECAUSE THINGS ARE ON FIRE RIGHT NOW
  • Twitter Notifications on my Phone
  • Email pop ups
  • Really, any pop-ups
  • IMs
  • My wife asking, “Hey, when you have a minute could you do X?”
  • Long build times
  • Noise
  • Constant parade of people going past my desk
  • MandoFun
  • Wikipedia (Seriously, don’t click on any links)
  • Hacker News
  • The Internet in General

Things that have contributed to making me productive in the past:

  • Quiet atmosphere
  • Quiet workspace (A private office works wonders)
  • Understanding the next step I need to take in a project
  • Knowing the problem space well
  • No interruptions
  • Seriously: No interruptions
  • Staying off Twitter
  • Staying off Hacker News
  • No hardware problems
  • Loving the project I’m working on
  • Short build and debug times
  • Not debating politics on the internet


It’s telling that half of the things that keep me from being productive are problems I’ve created; but some of them aren’t. Like Open Office floor plans.

Ultimately, each of us controls what makes us unproductive. I suck at peaceful confrontation. I either come of too strongly, or I sit there and let the other person walk all over me. I’m really not good at it at all. As such, I don’t have any good advice for handling the external forces that contribute to not being productive, but I do know this: Whatever I can control, I should control. That means:

  • Turning off notifications on my iPhone (this has the added benefit of increased battery life)
  • Giving myself a reward for 3 hours of continuous coding (usually in the form of “internet time” like checking Hacker News or twitter)
  • Working from home when I really, really, need to get something done
  • Investing in a good-for-the-price pair of noise canceling headphones
  • Scheduling ‘no meeting’ times on my calendar. These are times shown as busy to everyone else. It’s my work time.
  • Not getting into programmer arguments around the office; people have strong opinions, and the programmers who have arguments love to argue. If there’s an actual business problem that needs to be solved, let’s grab a conference room and come up with the advantages and disadvantages of each approach. Let’s get some data. Let’s not just argue.
  • Position my desk in such a way that passersby aren’t distracting.
  • Taking a first pass at the problem, and *then* asking another developer to walk me through the problem so that I can get a better understanding of what to do. This accomplishes two things: First, it allows me to get the ‘lay of the land’ so that I’ll at least have a basic understanding of the forces at work. Second, it allows me to ask more intelligent questions when I ask for help

What makes you unproductive, and what do you do to combat it?

Discuss this post on Hacker News or Reddit.

Edited on 9 July 2014 for typographical errors.

The very best Polyglot Developer Platform For the Money

My career has gone through many phases: Perl to PHP, PHP to VBA, VBA to C#, C# to Python, Python to JavaScript, and back to C# again. I’ve tried Dual booting, I’ve tried VMs, I’ve tried dedicated machines for each environment. I’ve tried corporate “certified” machines (Lenovo), I’ve tried building my own dev machines. Nothing is pain free, but after jumping through every hardware problem known to man, the least painful developer hardware I’ve found is

The MacBook Pro.

Just about every issue I’ve had with development revolves around three specific problems:

– Stability
– User Experience
– Developer Support Tools


The MacBook Pro (MBP) absolutely kills in the stability arena. The Operating system is stable, I don’t have to worry that patching my system will result in rebuilding the OS, and I don’t have to worry about Windows Updates.  For running VMs, ReSharper is amazingly stable, able to suspend and restart the VM quickly for when that’s needed.

User Experience

Have you ever had this happen to you? You’re in Windows, and you’ve hit “Postpone” on an update, only to walk away from your computer and find that the update installed and restarted your computer without your consent?  Or, if you’re using linux, and you make the mistake of using apt-get and it installing a new linux kernel, only to have your system hosed on reboot?  My personal best? That happened three times before

I wised up.

Apple’s user experience is top notch (iTunes notwithstanding). While there is some fussiness around setting up Python for a Mac, there are clear analogues for developers who want to develop for FOSS on a MBP. The OS comes back quickly from sleep; the keyboard and trackpad contain unobtrusive (yet useful) features.  The entire experience from opening the box to using it for actual development is insanely easy compared to other platforms, where sometimes sound drivers don’t work, or the installation fails for no particular reason.

One significant advantage to choosing a MacBook Pro is that Apple needs to only support a handful of hardware, instead of the thousands upon thousands of combinations of hardware choices that Linux and Windows need to support.

Developer Support Tools

For Mac, Parallels is one of the best pieces of virtualization software out there. I can run a Windows VM and a Linux VM in Parallels and have everything just work, including each VM communicating with the others and the outside world over HTTP. I tried to get Hypervisor to do that over the course of two days and was met with failure.

There are some issues with Mavericks, however. If you click on a dialog that wants your attention (the bouncing icon in the Mac OS X Icon Bar) and the icon belongs to a VM on a different desktop (multiple monitors), you get… weirdness.

One area where Mac has been deficient before Mac OSX Mavericks was multiple monitor support, in that it didn’t really support multiple monitors. Now with Mavericks there is first class support for multiple monitors, but it’s not perfect yet.

Have you ever tried to get support for a Dell? It’s terrible. Hours spent on the phone to have a customer service representative tell you to wait for them to ship you a box so you can ship your Dell back for replacement. Contrast that with the Apple Store experience. I’ve taken my MBP to the Apple Store three times, and all three times I was in and out within 30 minutes, and *every single time* it was free. That’s incredible.

With the advantages the Macbook has over other development experiences, it’s hard to imagine reasons *not* to use it for development.


Three common project failures

I’ve worked on six greenfield projects as a programmer1. Do you know how many of those projects succeeded? Three.

That’s my shipping percentage for greenfield projects: 50%. When I think about the projects that failed, they had one or more of the following themes:

Not shipping early enough: It’s really easy to add fluff to a project. For one project we made a wrapper for the E*Trade API along with the architecture to securely handle OAuth tokens. It was quite an elaborate architecture for something that ultimately didn’t ship.

How to address it: Ship the most minimalistic thing you can. Lean startup talks about this as a Minimum Viable Product. Even more basic than this is to start with an experiment.

What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

If we had set up a button and a landing page for the product (Without actually building the product), we would have known how many people actually wanted it. It would have taken us about a week to have our idea validated. Instead, we squandered four months building something that we ended up not shipping.

Biting off more than we could chew: Years ago, Joel Spolsky wrote about Things you should never do, Part I (there never was a Part II). In it, he talked about the action that singlehandedly torpedoed Netscape:

Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

It’s a bit smarmy of me to criticize them for waiting so long between releases. They didn’t do it on purpose, now, did they?

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

It’s one of those blog posts that you read, laugh at, and say, “We’re not that stupid. We won’t make that mistake.” and then you proceed to make that mistake. We did. The project was essentially a rewrite of the application that made all of the money. It was an attempt to unify different parts of the application and to be able to cross-sell and up-sell other products.

It was shut down one week before its beta launch; 5 months after the project began development work.

One of the major issues from a rewrite is getting executive level buy-in (and keeping it). A rewrite is a way of making programmers feel better about crappy code. Just rewrite it! The problem is that if you’re rewriting something, you’re not (by definition) making it better for the people who pay for it. At most you’re making it better for future features, and at worst you’re just making different mistakes.

Technical debt is real, and it has a disastrous effect on programmers’ psyche; but a rewrite isn’t a sustainable way of addressing technical debt.

How to address it: Ask the people who pay the bills frequently about their expectations, but frame it in such a way that they can’t weasel out of an answer. If you ask a business executive, “How long do we have?” They’ll say, “as long as it takes to finish.” They don’t really mean that. It’s not their fault — they have great intentions, but they don’t really mean that. They really mean, “As soon as conceivably possible.” One way to see what the threshold is is to ask, “If it takes us three months, how would that sound to you?” Watch their body language for the answer. If that number seems high to them, they’ll flinch, or stumble, or otherwise show that they think three months is too long. You may also get a response to that effect. If they seem fine with that, extend the length until you get past their comfort level. This also works really well on individual features.

Team dynamics: It’s weird how certain combinations of people just don’t work well together. Bob and Steve work well together. Steve and Emily work well together, and Bob and Emily work well together. Put them all in a group, and suddenly you have a dysfunctional team on your hands. In a company where developers often move to different projects, every so often those combinations crop up. It’s not a reflection on anyone in particular, but it’s bad when it happens. Sometimes a team just doesn’t gel, and from personal experience that can doom a project.

How to address it: Talk about it early, as soon as it becomes apparent. Team retrospectives (with beer) are a great way to loosen lips and to hear what people think. Don’t schedule it as a retrospective, schedule it as a time for the team to ‘talk about how we think we’re doing’. The first ten minutes will be positive, the next twenty will be a little deeper; but by the 35 minute mark you should start to hear how people really feel.

Any project I’ve worked on that has succeeded has either had these problems and worked through them quickly, or not had them at all. These are not insurmountable issues, but unchecked, they will torpedo projects.

“Watson, when I say you are instructive, I mean I learn from your mistakes.” — Sherlock Holmes to Dr. Watson

[1]: I’ve worked on a lot of different projects, but only 6 greenfield projects. Every other project had already shipped, and we were either developing new features, or we were just maintaining the project. I feel lucky in that I was able to work on 6 greenfield projects in a three year span.

Why is it called Heartbleed?

Yesterday I posted about the Heartbleed bug, but didn’t address why it’s called “Heartbleed”. I err’d in the writing of that blog post on (at least one point):

It’s called “Heartbleed” because programmers love cute names. I haven’t actually found a credible source for its naming, so I default to the ‘cute’ reasoning. It’s accurate in general, if nothing else.

That was partially right. Programmers do love cute names. But that’s not the full story. After doing some more research, I found out why it’s called the Heartbleed bug, courtesy of this Security.SE answer:

In short, Heartbeat allows one endpoint to go “I’m sending you some data, echo it back to me”. You send both a length figure and the data itself. The length figure can be up to 64 KiB. Unfortunately, if you use the length figure to claim “I’m sending 64 KiB of data” (for example) and then only really send, say, one byte, OpenSSL would send you back your one byte — and 64 KiB (minus one) of other data from RAM.


So the function that has the bug is called “Heartbeat”, and the bug allows for the server to ‘bleed’ information it should otherwise not send back. HeartBeat + bleed = HeartBleed.


Authors [foot]note: A shorter form of this answer made it into my inaugural Higher Logic blog post, as well.

Why isn’t your Angular Application Open Source?

I love Angular. It’s a great client-side MVC framework. One of its major issues is a lack of understanding of how to put together an Angular Application, and the documentation is no help there.

They tried to improve by including a reference application (app), but… Well…

App Structure level: 2legit
App Structure level: 2legit


The problem with reference apps is that they’re not actually being used. Here’s the difference between the two:

Reference App
A real world application

It doesn’t have to be this way.

You can open source your Angular project.

There are traditional arguments against Open sourcing proprietary applications; but I argue that none of those apply here.

It’s our proprietary code: It was, before you released it as an Angular application. Now anyone can see the entire source code of your project. Even if you minify it, they can still see it.
It’s got our secret sauce in it: It probably shouldn’t. You should move any proprietary algorithms or methods to the server side, and expose the result through the API.
It’s not very good!: That’s ok. Any app that has real world usage is useful to see.
Someone may find a vulnerability: That’s good! They’ll let you know there’s something wrong
What if our competitor sees it?: Since (by their nature) JavaScript applications are available to the client; it’s likely if they cared about it, they’d already have copied it. You don’t have a source problem, you have a legal problem.
The source code is a mess! It’ll take us weeks to get it ready: Every company has a period of downtime. Business rarely goes full tilt 24/7. Use one of those periods between product launches to schedule this work. It’ll let your developers relax and recoup after a hard push.
I don’t want to accept patches: That’s your right. It’s not exactly the smartest move, but putting the source code on Github doesn’t mean you have to accept other people’s patches.

With those aside, let’s look at the positive reasons for open sourcing your Angular Application:

Community respect: People are more likely to trust someone they perceive as honest and open. Open sourcing your Angular app (That’s already ‘open’ anyway) gives you a net positive with little to no downside
More eyeballs: It’s more likely someone will uncover a bug, and in the spirit of community, they may even issue a pull-request with a fix.
Learning: Everyone learns when they open source something. The people who do it, and the developers who will see the code. Putting the code out there ensures that there are better examples of how a real world Angular application is structured.
Recruiting tool: You may have unlimited vacation and free lunches, but one of the things that developers really care about is being on the cutting edge and have the ability for everyone to see what they do.

Open source your angular app. There are lots of reasons to do it and very few reasons not to.

The Heartbleed Bug, for the rest of us

This morning while getting reading for work I heard Fox 5 news talk about the Heartbleed Bug. Fox business correspondent Lauren Simonetti referred to it as the “Heartbleed bug virus.” Since it’s a live segment, I figured it was just a verbal gaffe, so I double checked against the recorded segment she does daily for Fox Business:

“Today is the day to refrain from online banking and plugging other sensitive information into the web. That’s because security experts have found a virus called the “Heartbleed bug.” It attacks the software used to provide encryption of 2/3rds of all servers on the Public Internet.” (emphasis mine)

It’s easy to make light of non-techie explanations of software problems, but the blame really is on us. We don’t do a great job of non-technical explanations. If you’re looking for a technical explanation of Heartbleed, here’s one.

For the non-techies among us (especially news anchors), I’ll try to provide a good non-technical metaphor for what the Heartbleed bug is.

The Heartbleed bug is a software bug, *just like any other software bug*. The term ‘bug’ may be confusing here, but we mean a bug to mean a defect in a line of code somewhere, causing the software to behave in a manner that wasn’t intended by its author. They’re named ‘bugs’ because the first computer software error *was literally caused by a bug in the computer*.

It’s called “Heartbleed” because programmers love cute names. I haven’t actually found a credible source for its naming, so I default to the ‘cute’ reasoning. It’s accurate in general, if nothing else.

In human terms, viruses are referred to as ‘bugs’. They’re often used interchangeably, as in “Thanks for giving me that bug that’s going around.”

In software terms, they mean completely different things.

A virus is a piece of software *intentionally* written to infect computers. They can do many different things, from turning on your web cam without you knowing to just being really annoying.

Bugs are *unintentional* defects in software.

In the case of the Heartbleed bug, the defect is the digital equivalent of you leaving your house unlocked for two years in plain view of everyone in the world, and them able to get into your house, listen to your conversations, watch everything you do and record absolutely everything you’ve looked at on the internet for the past two years, while you were looking at it2. Any website, any financial transaction, anything. All without you knowing.

Normally you’d just change your locks, but that wouldn’t help you here. They have the digital equivalent of a skeleton key to 2/3rds of the locks in the world1. Until the company that makes the lock revoke the skeleton key and issues a new one, there’s nothing you can do. Changing your locks won’t help until then.

That’s how serious this software bug is. In your daily travels on the internet, I can guarantee at least one site you use is affected by it.

So what can you do?

– Don’t log into your bank or any sensitive site until they’ve confirmed that they’re not affected by this bug, or they’ve issued new SSL certificates for their site.
– Change your password for each site *after* it has revoked its security certificate.
– Never use the same password on two sites. If you do, at least make sure your bank and other sensitive sites have their own passwords that aren’t used by any other site (or used on each other).
– Follow these helpful instructions to make sure Chrome looks for certificate revocations:

To leave you with a bit of levity and to put this gaffe in context,
It’s not as if this is the first time a news anchor has made a technical gaffe. It’s even pretty low on the scale: The king of all tech gaffes would have to be Katie Couric and Bryant Gumbel’s hilarious description of what an email address and the internet is.


1: Techies will note that I’m conflating terms here between the skeleton key (SSL certificates) and your house lock (your password). Sometimes there just aren’t non-digital equivalents, so we make do.

2: Heartbleed allows the attacker to see 64K of what’s in memory at the given moment of attack. This is trivial to automate.