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
  • Things BEING ON FIRE RIGHT NOW DROP EVERYTHING
  • 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
Stability
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.
Whoops!

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.
Clever.


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