Infinite Quack

Big software projects, at big software companies, are deeply collaborative affairs. The majority of the work isn't writing code; it's getting a shared vision into everybody's heads. That's not what this post is about, though. Since I decided to take a little break from my day job and decompress, I found an activity that relaxes me, and reminds me of my earliest days writing software. First I'd like to describe what my earliest paid software gig was like. Then I'll talk about a personal project I worked on back in 2012, and then another that I'm working on now. Memory Lane: QANIMATE Back in my High School days, I worked on a project called CUPS, "Consortium of Upper-level Physics Software". You can still find traces of it online . The piece I wrote is QANIMATE , although they did misspell my last name in the author attribution! I worked with Ron Stoner at BGSU  over the course of a summer. Essentially it was an internship, an educational opportunity...

A former Amazon teammate, Neil Macneale , posted on Dolt's blog about the project we worked on together in the 2010's: easing the company off of Perforce (and some lesser-used source control systems including Subversion and CVS) and onto Git. I recommend reading it if you haven't already: Enterprise Git - The Amazon Story I was unfamiliar with Git until Neil introduced me to it. He made me a believer, then encouraged me to join his team. I remember the excitement of building a newer, better source control system to power all the company's developers, and making it as sturdy as possible. And I can say we succeeded. These days at Amazon, pushing code changes just works. It's a utility that you don't even think about. I imagine a lot of Amazon developers wouldn't even know what you were referring to, if you said "GitFarm" to them. They know they use Git, but they have no need to know the details. That's true success: when the system works so well...

This post was inspired by a talk called Being Human , given by Jason Wodicka, someone I worked with at Amazon. This is a great talk, and you should watch it. Jason is a smart guy, and while he and I may not have arrived at exactly the same conclusions (or perhaps we "violently agree" and are just looking at similar ideas from different directions), I absolutely appreciate where he is coming from. What follows are my personal reactions and responses to the talk. Also I should note that this is hardly my first blog post on AI; if you'd like to read the others, see Never Is A Long Time and Buckle Up and... well, any of these . Yes, Jason: You're quite right about the boom-and-bust, summer-and-winter cycle of AI. It's looked promising before, and we've been disappointed before. I, too, have been around for a while, and I too used to read Wired magazine in print. 😄 We must approach reputed AI developments with a big ol' grain of salt. Turing's "imi...

Some are born leaders, some work hard to become leaders, and some have leadership thrust upon them. I don't see myself as a natural leader, at all. I'm most comfortable as an individual contributor. But sometimes I find myself in a position where leadership is called for, and nobody else fits the bill. Sometimes I must step up to ensure things don't fall apart. This happened to me today, but not in a work context. It happened here at home. Not many people know this about my home situation, but it's non-traditional. I share a house with nine other people: my domestic partner / long-time girlfriend, her disabled son, her mother (a retired medical worker), my girlfriend's sister, the sister's two young children, a friend of my girlfriend along with her spouse, and a friend of the sister. Four of these people receive disability income, and a couple of others deserve to (and one is working on getting approved). A number of these people ended up here because they had ...

I’ve been at Amazon as a software developer continuously for over 18 years now. That’s longer than most. Lately I’ve been reflecting on my time there. Here are 18 lessons I've learned -- most of which are applicable to any collaborative endeavor. Trust is your most important asset. It’s slow to build and easy to lose. This is true inside the company (with teammates, reports, and managers) and outside (with customers, partners, and investors). Error correction is at the heart of development. Humans make errors, and a lot of humans make a lot of errors. This is unavoidable, and one should never blame the person – always the process. Swift and honest error correction builds trust. This, too, is true inside the company (with teammates, reports, and managers) and outside (with customers, partners, and investors). Transparency is the best policy. If you don’t have enough informa...