Use two choices. It’s easy to get hugely better performance by moving from one choice to two choices. It’s very hard to do better.

Forming. Storming. Norming. Performing. Every writer who writes about teams all reference this one (and only this one) article, and those four stages. It’s foundational, and it rhymes.

In 1984 Microsoft decided to port MacWord to Windows. They expected it would take about one year. It did not. It took five. In one of the many, many great documents unearthed by the Comes v. Microsoft antitrust lawsuit is this great postmortem of what went wrong.

I’m doing this project from the top-down. It’s totally unlike how I normally work. But it’s also my first time leading a team, which is also unlike how I normally work, and has different needs.

I’ve always wanted to be able to put simple diagrams in this blog without going through the trouble of graphically creating them in LucidChart or Balsamiq. I just want to type in text, and have it convert to a chart.

Three months ago I started a new job with a huge jump in responsibilities. I went from a comfortable Programmer and Occasional Scrum Master, to a panic-inducing Architect, Team Lead, and Manager. These are roles I’ve wanted for a while, so I’m happy to be here, but it’s a weird new world for me.

• I have a few things going for me: My boss believes in me, I’m working with a great devops guy, and my last job showed me what a sane development process looks like.
• I have a few things going against me: The company is just coming out of the chaos of a buy out and reorg, and my wholesale lack of experience.

I was given a small project to manage, Satellite. It should take less than six months, with a team of four developers, one QA, and two UI/UX people. Unfortunately I only get them part time.

Here’s the inevitable followup to my last post about things I was right about. This is a list of things that I was convinced about when I was younger, but I now I realize I was quite wrong.

Some bloggers have strong opinions and are just right all the damn time. Like Joel Spolskey, and Jason Fried. I admire them, but I’ve never been that guy, or been that confident in my opinions. But damnit, some of my oldest opinions hold up. After nearly two decades of professional programming, I’ve looked back and thought about the opinions I originally had. Here are the ones that I’m convinced I was always right about.

The TLDR is simple: if you have a disappearing/reappearing bug, just run it again.

Programming languages can be categorized in a number of ways: imperative, applicative, logic-based, problem-oriented, etc. But they all seem to be either an “agglutination of features” or a “crystallization of style.” COBOL, PL/1, Ada, etc., belong to the first kind; LISP, APL– and Smalltalk–are the second kind. It is probably not an accident that the agglutinative languages all seem to have been instigated by committees, and the crystallization languages by a single person