C.A.R. Hoare thinks programming languages should primarily support design and documentation, with programming being a distant third. Two papers by Turing Award winner C.A.R. Hoare, both on programming language design. I like to write up interesting tidbits and copy fun quotes, this isn’t a full summary If you don’t have time to read it all, here’s the tldr: C.A.R. Hoarse invented switch statements, warned us about buffer overflows, and loves Algol 60. (Not Algol 68, which I wrote about.) ...

It took me too long to realize that the paper I just read was directly relevant to me. It was about teams. I was on a team. Why didn’t I get that? Last month I read and wrote about The Development Sequence of Small Groups, by Bruce Tuckman, who discovered the classic Forming → Storming → Norming → Performing sequence. After I read it, and in great arrogance, I thought, “Well now that I know about the perils of storming, I’ll be sure to look out for it and guide the team I lead through it.” What I didn’t consider is the storm that was going to hit me the hardest wasn’t going to be the team I was leading, but the informal team between me and my peers. ...

Google Source has tremendous uptime. They manage it by having a super-flexible schema, and code that takes advantage of it. How googlesource.com manages database upgrades with no downtime, by Shawn Pearce I love this old post from Shawn Pearce on how Google Source has no planned downtime. They take advantage of protobuf and BigTable having a flexible schema. The application is coded to ignore columns it doesn’t understand, but still save and persist them. ...

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. The full title is The Power of Two Choices in Randomized Load Balancing, by Michael David Mitzenmacher. I love the simple theory of this: use two choices. Two choices is exponentially better than one choice, and having three or more choices doesn’t offer much more improvement. Need to hash? Hash it twice, then choose the bucket with fewer items. Need to load balance? Choose two servers at random, then pick the one with less traffic. Need to cache? TWO CHOICES. The math of this thesis is beyond me, but that’s true of most compsci theses now. (Can anyone retain their math knowledge if they’re not actively teaching or publishing?) ...

Forming. Storming. Norming. Performing. Every writer who writes about teams references this one (and only this one) article, and those four stages. It’s foundational, and it rhymes. Development Sequence in Small Groups, by Bruce W. Tuckman In 1965 Bruce Tuckman wrote a literature review and synthesis of how small groups come together, and how well they do their job. He looked at three types of groups: therapeutic groups, task groups (e.g. teams for a job), and groups who only exist in a lab setting. In all three types of groups, he identified 4 rough stages, and he brilliantly made them rhyme: forming, storming, norming, and performing. ...

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. The Opus Development Postmortem is 47 pages long, and should be mandatory reading for all project managers. The timeline WinWord dreamed up in August 1984 Prototype demoed in September 1985 Real work begins in November 1985 Windows 1.0 ships in November 1985 Windows 2.0 ships in November 1987 WinWord ships November 1989 Small Notes and Select Quotes Management of the development team, from within and from above has been one of the major failures of this project. ...

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. This job is my first time as a manager and a (formal) team lead. I finally understand what it means to get everyone moving in the same direction. I have very little idea how to do this. I’m just trying to get everyone to believe that this can get done from the top-down. Meaning, first they agree that the vision is possible, then the roadmap is a good ordering, then the epics are nice and contained, etc. ...

2022 Note: Now that I’m on Hugo blogging system, this post is out of date. 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. graph TD A[Blog with no diagrams] --> B B(Download mermaid.js) --> C{Do you like it?} C -->|Yes| D C -->|No| E D[Me too.] E[Troublesome.] How I did this First I added these two lines to my footer. (All my JS is in the footer. It was the “best practice” back when I made this theme.) ...

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 buyout 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 now I realize I was quite wrong. Tabs v spaces doesn’t matter “Tabs are for tabular indentation!” I screamed. But it doesn’t matter. I now believe you are allowed to argue about it passionately just once. Then you’re done. Just do what your team does. It doesn’t matter. ...