I used to work at Pivotal Labs, and it was an incredible gig. I loved it and learned a lot. Pivotal is known mainly for two things: their highly-effective agile development methodology, and creating Pivotal Tracker, the agile project management tool. (N.B. The AP Style Guide insists that you always refer to the product as “Pivotal Tracker,” or “Tracker,” but never “Pivotal.” Pivotal is a company. Pivotal Labs is a consulting agency within that company.)

I’ve written and spoken a lot about how Pivotal does agile. Unsurprisingly, so has Pivotal. Pivotal was founded in 1989, and after years of working this way, they created Pivotal Tracker as a tool for managing this particular kind of agile software development workflow.

As such, Tracker enforces that process with a degree of rigidity. This is a good thing, I think. So many of Pivotal clients, and so many startups in general, have one of several problems that Tracker tries to solve by offering strong suggestions about how to work.

  1. No technical/product-focused cofounder, and hence no guidance on product development process
  2. A technical cofounder with no product experience, and hence no guidance on product development process
  3. A technical cofounder or employee who has only ever hacked alone, and hence has little notion of how to create a product development process as the company grows
  4. A bad product development process

If you follow the rules of using Tracker, you will always write specs. You will always break those specs into smaller chunks that still deliver value, called “stories.” You will estimate the stories as a team. You will work on them independently, in the order of their priority, and only one at a time. You will deliver them to QA, or “acceptance” before they can make it to production.

So Tracker is usually a breath of fresh air to these companies. A smart person can pick up the basics of how to do agile the Pivotal Way in a day or two, and really internalize and become highly effective within it by a couple weeks. Even if it’s not perfect for them, it’s a great place to start. Some people have called Tracker’s process “training wheels”. I’d say it’s a little more like a damn good starter bicycle. But I don’t bike, so my analogy might be off.

So what’s the problem then?

The problem is that efficiency and effectiveness is only part of what a startup’s product team needs in order to succeed. The other part is innovation, and that part is much more difficult to describe using a prescriptive process like this one. Tracker gives you no insight into how a story got into Tracker. All of that happens offline and Tracker doesn’t care about it. But as a company, you have to care about it, because you can’t build a company on bad ideas executed quickly.

We’ve tried a number of things to try to fill this space at SideTour. Some have worked, some haven’t. We’ve done several Pivotal-style brainstorming sessions called “inceptions.” We’ve tried several incarnations of kanban. We’ve done some of this in our iteration planning meetings (IPMs, also known to some as sprint planning meetings). We’ve tried various levels of strictness in adherence to Lean Startup. We’ve spent time ignoring Tracker and focusing on more free-form development process, somewhat like programmer anarchy, which we called an “internal hackathon.” We did a company-wide brainstorming session during an offsite. And we’ve had a lot of ad hoc conversations and emails to define our product ideas. eEach of these has had various levels of success worthy of their own blog posts.

But the important takeaway for the purpose of this article is that you can’t use Tracker for any of this. Don’t even try. And Pivotal wouldn’t even disagree with me; it’s simply not what the tool is for. It’s an agile development tool, not an ideation tool.

For that, you need something more flexible. I used to recommend card walls for this (to replace people’s natural tendancy to do something horrible like store important collaborative information in Word or a moleskine), but lately, I’ve been recommending Trello.

With Trello, you can define your own process. Some people would say this makes it a great replacement for Tracker, and you can certainly do that. See, for example, this Trello board I made that implements Pivotal Tracker that could serve as a starting point for modifying the Pivotal process into your own agile development process. Another option is to use Trello to track your ideas in various stages before they enter Tracker.

I don’t have a formula for how to manage the process you use to fill the backlog with successful features. If such a process existed, and I knew it, I would be on a beach in Ibiza drinking away my millions one margarita at a time instead of writing this blog post. But here is what SideTour tried during our Hackathon Week, and it both produced great ideas and raised the level of energy and engagement across the entire office by noticeable amounts.

  1. Allow the team to add their own ideas to the Ideas column.
  2. Encourage team-wide discussion on the ideas (turn on voting if you wish)
  3. Allow the developers to pick the next thing they want to work on, based on their own opinions of the discussion and voting.1. Enter some form of agile development cycle. The phases used by Tracker are a reasonable default.
  4. Measure success to help improve company intuition.

This process is not optimized for efficiency. Time developers spent discussing various product ideas could be more efficiently allocated to coding. But coders are people, not inputs to a code production engine. And the most valuable ones have product sense. They also know your product better than almost anyone else in the company. Keeping them out of the idea generation phase increases the chance that your startup is going to miss that next important idea.

It’s easy to be lulled into a false sense of security by finding success within your Tracker velocity or “Done” column. But it’s easy to see how too much focus on getting things done, without an equal or greater focus on what things need to get done, could kill your startup. For that, you need to look outside of Tracker, and inside your team.

I stayed in a bed & breakfast at Harvard Square this weekend and found the most amazing hotel computer setup I’ve ever seen. I just have to share this.


Here is the whole iMac in all of its glory, adorned with detailed instructions for the novice computer user.


Closing applications is the Mac's turbo button.


Sad and confusing that the arrows don't line up with the icons. Good to know that I can use Skype for Skype though. I was also confused as to what "viruses" referred to, until I read the much more common terminology,
"virii."


Easily the worst UI paradigm of OS X, explained succinctly.


No idea why this one was put on the back. Maybe they got sick of people using the shared computer for porn.


Oh, in the USB port? Right.


I have to believe this was all constructed after the 100th parent dropping their kid off at Harvard for Freshman Week asked the manager how to use a Mac. It’s so ridiculous, but part of me kind of loves it.

I went through my old blog, and sadly, the only post I think is worth saving, is my famous sangria recipe. Whatever that says about me, I am willing to accept.

WARNING: This sangria is incredibly alcoholic and will knock you on your ass after two or three glasses. Makes about 3.5L of sangria plus a bunch of alcoholic fruit that contain more alcohol than you think. You’ll need at least a 5L jug for this. Serves around 20 people 2-3 glasses each.

Ingredients

  • 1.75L dry red wine (Yellowtail Merlot is fine)
  • 1 cup Gosling’s spiced rum
  • 1 cup Mr. Boston Blackberry-flavored brandy
  • ½ cup Peachtree Schnapps
  • ½ cup Cointreau (or Triple Sec if you’re cheap or want to reduce the alcohol content)
  • 1 cup orange juice (the only time in life that no pulp is acceptable)
  • 4 Tsp sugar
  • 4 cans ginger ale
  • 2 lemons
  • 2 limes
  • 2 apples
  • 4 oranges
  • 1 cup strawberries
  • 1 cup raspberries
  • 1 can diced pineapples in juice

Directions

  1. Pour all the alcohol, mixers, and fruit juice in a big freaking pitcher
  2. Pour in the sugar and stir it for awhile
  3. Cut all the fruit into half-slices and throw all the fruit slices (and any juice) in the pitcher
  4. Holy crap, don’t drink it yet. Let it sit for 48 hours, 24 hours minimum. Seriously. Stop that. Don’t drink it.
  5. When it’s time to serve, add the cans of ginger ale.
  6. Slice the remaining oranges and slot them. Serve with a lot of ice in red wine glasses with the slotted orange slices as garnish.

Why I love this recipe:

Goslings and ginger ale make it a bit spicy, which takes most people by surprise. There is a ridiculous amount of alcohol in here, even moreso if you eat the fruit. Like seriously, watch out. If you don’t believe me about the 48 hour wait, try sampling the sangria as soon as you pour it and every 12 hours. The nasty acidic taste in the cheap wine decreases over time and will completely disappear within 48 hours.

Some people have claimed that this is not true sangria, but is in fact a cocktail, owing to the unusally large amount of liquor in the recipe. To that, I say have two or three glasses, and let’s settle this with a fist fight.

Enjoy!

originally posted on 2011-08-16

If you’re a programmer early in your career, you’ve probably heard a lot of people talk about the importance of having a strong network. It’s true. For things like finding a job, a co-founder, or just someone to get advice from, having a strong professional network is invaluable. But the hard part is actually building one, or even knowing how to begin.

The easiest way seems to be to go to networking events. There’s a big problem with this approach though, and that is that 87% of networking event attendees are doing it completely wrong. Ok, so I made that number up, but hear me out anyway.

If you go to any kind of tech meetup, you will see all sorts of people trying to “build their networks.” They seem to be doing this by walking around, engaging in varying degrees of shameless self-promotion, and trading business cards with as many people as possible. As far as I can tell, the meetup-goer who employs this strategy is expecting that one day, they will have a specific need to use their network for something. They will go directly to their stack of business cards, each one a legally binding contract to call in one favor, and solve their problem with a single email or phone call.

The problem is, of course, that if you have to go to a stack of business cards (or to LinkedIn) to figure out who’s in your network, you’ve already failed. This kind of networking is completely wrong twice. It’s wrong because it’s not going to work, and it’s wrong because it’s a soulless form of quid pro quo that is unbefitting of human beings.

The most helpful people in your network are going to help you not because they expect something in return, but because – get this – they actually like you. So stop trying to make “connections” and “business contacts,” and start trying to make friends. You know, like people do. In life.

Here’s how I suggest approaching meetups and professional networking events. Go with a friend or two. Introduce them to each other and anyone you know at the event. Have them introduce you to some people they know that you don’t. Afterward, grab drinks, or dinner with the friends you’ve brought, and their friends. Have a fun evening.

You can even make a game out of this method. Take the number of business cards you’ve collected (business cards with QR codes count double) and subtract the number of new friends you’ve made. Score it like golf. Par is 2.

I scored a 1 at the last Out In Tech event. I score under par fairly consistently at CTO School, owing mainly to the wine bar after the event. I stopped going to the meetups where I was consistently scoring triple-bogeys, and I’ve been much happier for it. Try this out, and I think you will be too.

How would you feel, years later, about a college that issued a statement in support of Loving v. Virginia and then retracted it due to pressure from its alumns?

Today my alma mater “officially” retracted apologized for a Facebook post celebrating the repeal of DOMA, which allowed the many LGBT Olin College community members – faculty, staff, students, and alumns – who are married or will be married in the state of Massachusetts – to enjoy equal protection under federal law.

As a matter of policy, Olin College does not endorse any political candidate or political cause, or any religious point of view.

Where is the controversy? Marriage equality is now the law in your state and in your country. Does Olin College hold no official position on marriage between heterosexual couples?

Shame on you, whoever made that call. Ordering an employee to remove disown that post was a statement. It was a statement that you would rather disown the LGBT Olin community than risk offending the tender sensibilities of a few bigots. You’ve helped create a piece of our collective memory around this historic decision, and it’s not one that any of us can be proud of.

EDIT 7/12/2013: It was called to my attention that Olin didn’t actually delete the Facebook post, they only issued an apology for it. My mistake.

It’s also worth mentioning that the original post had 120 likes and only 2 detractors. The Olin community is still a very open and accepting one.

My good friend James Somers wrote this article for Aeon Magazine. It’s a great article, well-written as I’ve come to expect from James, and there’s a lot to unpack – the idea that programming is basically plumbing, that venture-backed startups are essentially time-wasting factories of frivolity, and that our economic system’s basis in supply and demand massively undervalues creative workers like writers – but there is one idea I want to focus on in particular, because I think I have some insight into the argument that James doesn’t have.

I have a friend who’s a mechanical engineer. He used to build airplane engines for General Electric, and now he’s trying to develop a smarter pill bottle to improve compliance for AIDS and cancer patients. He works out of a start-up ‘incubator’, in an office space shared with dozens of web companies. He doesn’t have a lot of patience for them. ‘I’m fucking sick of it,’ he told me, ‘all they talk about is colours.’

I think it’s abundantly clear that this is a false contrast – rhetorically effective perhaps, but misleading. By contrasting the social good of curing terminal illness with the inanity of arguing over colors, James trivializes software engineering and elevates more traditional forms of engineering.

But he just as easily could have contrasted a mechanical engineer who makes Happy Meal toys to a software engineer who writes child welfare software. A huge number of plastics manufacturing jobs are dedicated to cheap toys that end their lives in landfills, but that doesn’t take away from medicine bottles any more than Facebook for dogs takes away from crowdfunding female entrepreneurs in third world countries.

Colors can be important. They can also be inane. I can tell you from experience that mechanical engineering is not free of mundane details – draft angles, radii, and of course – color. Nor is it free of what James earlier in the article calls knowing the “instruction manual.” In fact, for MEs, this is tenfold. I can still recite for you the names and compositions of commonly used alloys, rules of thumb for designing machined parts – depths of cut, recommended spindle speeds, and common design features of injection molded parts like bosses and living hinges – all rote knowledge accidentally commited to permanent memory through a few years of practice. And the ultimate instruction manual for traditional engineers? The $100k four-year instruction manual called a B.S. Engineering.

My friends and I who are building websites — we’re kids! We’re kids playing around with tools given to us by adults. In decreasing order of adultness, and leaving out an awful lot, I’m talking about things such as: the Von Neumann stored program computing architecture; the transistor; high-throughput fibre-optic cables; the Unix operating system; the sci-fi-ish cloud computing platform; the web browser; the iPhone; the open source movement; Ruby on Rails; the Stack Overflow Q&A site for programmers; on and on, all the way down to the code that my slightly-more-adult co-workers write for my benefit.

When James speaks of abstractions as though they’re a bad thing – something for dull people to be able to wrap their heads around instead of bothering themselves with the intellectual challenges of Djikstra and Turing, he ignores the existance of abstractions in every other creative discipline. Mechanical engineers learn physics in the same way that computer scientists learn linear algebra. One day they may use it a few times, but mostly, they’re using reference tables to calculate moments of inertia in that same way that Ruby developers might use Math.rand() instead of writing their own pesudeorandom number generator.

303 Stainless Steel Machinability Table

But that isn’t to say this article is all bad. Quite the contrary. I really appreciate raising the issue of how society values its workforce. We all know that it’s a great injustice how little teachers are paid, and how much better off society would be if we could attract more and higher quality educators to the profession. But singling out software engineers who make $100k a year, while ignoring bankers who make five times as much, and giving a free pass to makers of other disciplines with similar problems, seems disingenuous. Especially when software engineering is such a force for economic betterment, with its highly results-oriented, meritocratic culture. I know a programmer who was homeless on the streets in New York for years. He taught himself how to program, and now he’s self-sufficient. Software engineers are free of the expensive artificial certifications that create massive barriers to entry for people entering law, finance, and yes – mechanical engineering. This is why I’m excited about companies like Flatiron School and Thinkful.

Given all of that, it seems James is attacking the wrong target. The question may not be why are software engineers valued so highly, but why are the artists and writers he mentions valued so poorly? The answer to that, I think is much more elusive, one that maybe someday James will tackle with his incomparable wit and candor, but perhaps this time without the straw man.