We Are Storming

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?

Why Google Source has high uptime

Google Source has tremendous uptime. They manage it by having a super-flexible schema, and code that takes advantage of it.

Reading "The Power of Two Choices," by Michael David Mitzenmacher

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.

Notes on Development Sequence in Small Groups by Bruce W. Tuckman

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.

Microsoft WinWord Post-Mortem

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.

Starting a Project with Top-down Agreement

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 blog now has diagrams!

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.

My new project: Satellite

Things I was definitely wrong about

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.

Things I was always right about

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.

Heisenbugs – tldr: just run it again

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

Can we measure how much more complicated computing is?

25 years ago, a simple question was asked about storage, access times, and economics, and the result was a simple paper. Every ten-ish years since then, an updated paper was written to answer the same question. It's not a terribly good measure of complexity, but it is enlightening.

Niklaus Wirth proves that better software is possible, in "A Plea for Lean Software"

This paper reads like an old man yelling at clouds, but then, half way through, he simply writes a better cloud. (This metaphor is pretty awkward given cloud computing.)

History and lessons of Algol 68

Algol 68 is the Cronus of programming languages. Cronus is the titan who fathered Zeus, an important character in the myth, but vastly overshadowed by his own progeny. Algol 68 was an important language, and had a fascinating history. This post is a combination history, lesson, and filled with quotes from people who were there.

The Biggest Post-Mortem

When there are failures at a small level, like a deployment goes wrong, there's a meeting, and a blameless post-mortem written is shared publicly. Normally this happens quickly, while everyone's memories are still fresh. When entires projects and movements fail, the opposite happens. There are no public post-mortems, and no meetings. A couple people leave the company, some blame is privately assigned, and the rumor mill goes into overdrive. At this level, a failure can mean a derailed career.

Inside the (1984) Japanese Software Industry

I went to dig into some of the sources cited in Peopleware (see my previous two blog posts), and I fell in love with this 1984 article on Japan's software industry and Hitachi Software Engineering. It's a look into a company that feels like peak-era IBM: much bureaucracy and even more success.

Peopleware Bibilography

Timothy Lister and Tom DeMarco didn't include a bibliography in Peopleware, so I swept through the book and produced one for curious readers.

Scattered notes on Peopleware by Tim Lister and Tom DeMarco

I just finished reading that old software classic, Peopleware. The first chapter is "Somewhere Today, a Project Is Failing," and hooked me immediately.

Soft Skills for Software Architects, a video series by Mark Richards

Mark Richards runs the Developer to Architect website, and puts out a video every Monday. He has helpfully categorized them. I watched all the videos in the "Soft Skills" category and took notes.

Learning about Faults, Errors, and Failures.

I've been reading about failures in distributed computing. A lot of it is thanks to Vaidehi Joshii's Year of Distributed Computing at https://medium.com/@vaidehijoshi . Here's small summary of what I've learned.

Product Management - Week 2 - Goals and Metrics

Here are my notes for week 2 of my product management education. This week is all about metrics, goals, and strategy, with a dive into Pirate and Heart metrics,

Product Management - Week 1 - What is it?

I've started an online Product Management class because, I dunno, I like learning new, non-coding things related to my job. I'll be posting all my notes here.

Bad communication can be a win-win scenario

In the aftermath of GE's price fixing scandal, we learned that GE executives had a culture of winking while they told subordinates not to break the law. Sometimes. Each salesperson had to interpret the word and the wink, and the occasional lack thereof, according to their own internal rules. Effective communication was, effectively, absent.

North East Database Day

NEDD is a one day conference in Cambridge. It's an inexpensive way to learn about the cutting edge of database research. These are my notes on each speaker.

Horizontal and Vertical Motivators, and Hygiene

I'm not in management, but damned if I don't love a good management paper. Today it's Frederick Herzberg's "One More Time: How Do You Motivate Employees," where I learn to not kick an employee.

Witness The Most Productive Team in Cinema

There is one scene that gets referenced several times in Rapid Development by Steve McConnell as an example of a hugely productive team.

Reading: The Best of Software Writing by Joel Spolsky

Joel Spolsky's writing and opinions are evergreen, and his 2004 book The Best of Software Writing shows it.

Reading: Software Engineering Under Deadline Pressure, by Scott H. Costello

An 1984 paper that models the time it takes to complete a project, and show what happens when you pull are up against bad deadlines. The answer will not surprise you!

Reading Martin Fowler's Recommended Reading on Microservices

Why trying to make accidents rarer can actually make them more common

excerpt from How Complex Systems Fail

Notes on Site Reliability Engineering, by Google

For my own reference, here are notes I took while reading Google's book on SRE.

Just delete those failing tests

If you're responsible for a large, legacy code base, here's my hint to you: delete your failing tests.

Using Moose's "before" method modifier to modify parameters

A small trick to make "before" a bit more powerful, a bit more useful, and a bit more dangerous.

The Post-CAP Reading List

Eric Brewer and Daniel Abadi expand our notions of what the real trade-offs are in the CAP theorem.

The 7000 page Harry Potter book that never was

An scientist's idea of literary criticism is different from most people's. It involves math.

GUI: Taking Lessons from Hand-Drawn Animation

Chuck Jones inspires UI designers in this classic paper from Ungar and Change.

Early example of Duck Typing in 1991's SELF

In 1991 Ungar and Smith wrote about the experimental programming language SELF, and in it described duck typing, callng it behaviorism

One-liner to analyze Python programs

The great benefit of knowing the command-line is being able to write scripts to analyze scripts, all in ~1 minute.

One Parent CSS

How I write CSS.

HTML5 Semantic Markup is for HTML, not CSS

I hand crafted the CSS for site. It's still a work in progress. I learned that while semantic tags are good for HTML, they're not that great for CSS.

Catches for traditional programmers when learning Python

After a lifetime of programming and compsci education, I've had some issues learning with Python. It screws me up in small ways. It's a wonderful language, but dear god I wish these things were different.

It's easy to dismiss the GoF Design Patterns

font-feature-settings should not be used in code blocks

The problem of learning Object Oriented Design

The greatest problem in learning object oriented design is in the toy problems. The object oriented solution never looks better than the regular solution.

How to write a program, the wrong way

Learn the right way to write a program the wrong way

David Parnas and the roots of good programming design

This paper is considered seminal in Object Oriented Design, but Parnas never mentions objects, and his example program is described in procedural programming terms. The lessons in this paper are applicable to *all* programming methodologies. It's just about smart design decisions.

Reflections on Trusting Trust by Ken Thompson

You can't trust Ken Thompson. He'll prove it.

It shouldn't be surprising to anyone that...