Tag: Invent And Simplify

Doomed To Repeat It

Doomed To Repeat It

By | | Comments 0 Comment

Technologists are particularly susceptible to recency bias. It’s one reason why I try to read older computer science literature from time to time (especially work from the 60s and 70s). The Mythical Man-Month is my canonical example; it should be required reading for everyone who works with technology. The Psychology of Computer Programming contains timeless truths of what it takes to lead a team of software engineers. Donald Knuth’s The Art of Computer Programming is a dense, three volume work, but much treasure lies within. I’ve only finished the first book, but I came away with tremendous respect for the geniuses that paved the way for us fortunate souls who have IDEs, fast compilers, and gigabytes of RAM.

Today I read On the Criteria To Be Used in Decomposing Systems into Modules, a research paper by D.L. Parnas of Carnegie-Mellon University, published in 1972. While the details of the middle section weren’t terribly interesting, it’s the bookends of introduction and conclusion that impressed me. The benefits of two-pizza teams were clearly understood fifty years ago, for example (“separate groups would work on each module with little need for communication”) and the paper lays out a novel approach to decomposition (to me, at least):

“We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.”

The above resonates with prior posts I’ve written on abstractions, especially Out of Sight, Out of Mind. If the goal of abstraction is to hide difficult detail, we ought to modularize with that goal front-and-center.

There’s Gold In Them Thar Hills

There’s Gold In Them Thar Hills

By | | Comments 0 Comment

In my conversations with fellow engineers, git comes up quite a bit. I find myself regularly giving advice both tactical and strategic on its effective use. Learning it in detail is a force multiplier, but few people do. Part of the problem is that training materials are all over the map.

Which is why I was so pleased to discover Git from the inside out. Without question the best introduction to git I’ve come across. It perfectly balances teaching basic commands while also explaining what’s actually happening. Despite having used git at a fairly advanced level for 10 years, I still learned some new things, for example that each git add creates an immutable blob object that is retained for a while even if you git add the same file again, and even if you never commit it. Also that it’s pretty easy to decode raw git objects should you ever need to; here’s a script I wrote to do just that, if you’re curious.

I’ve said before that abstractions are valuable, but they’re not excuses to avoid learning internals, because critical information lies beneath the surface. At the risk of pretentiously quoting myself:

When things go wrong, the engineer must descend into the particulars, and an inability to minimally reason about, if not fully grasp, what lies beneath an abstraction can prove fatal to the debugging process.

I didn’t write the above with version control in mind, but I surely could have. Engineering organizations are full of developers who run stuck the moment a git command fails. You don’t have to be that developer!

Turduckens Everywhere

Turduckens Everywhere

By | | Comments 0 Comment

Did you know you can implement a CPU in Minecraft or write arbitrary computer programs using Magic: the Gathering cards? Computing is powerfully weird, and hidden structures and capabilities can arise from all sorts of odd places.

I read a theory a while back that the Internet was, in some meaningful sense, intelligently conscious, though we may never be able to interact with such an intelligence. The analogy was to human consciousness arising from the cells of the brain in a way that no individual cell could ever comprehend it, but despite that it being no less real. The notion of Turing-complete computers being buried inside all manner of languages and tools has a similar vibe to it.

Can’t Unsee It

Can’t Unsee It

By | | Comments 0 Comment

On the plus side, she writes her people-searching algorithms in Python. But c’mon Wonder Woman, you need to work on your variable naming!

I’m pretty sure this function could be further simplified with some basic mathematics; it’s far too long and complicated. Reminds me of the film I captured it from.

Getting Warmer

Getting Warmer

By | | Comments 1 comment

This past summer my family and I took on a little project: we bought a house in Lake Arrowhead and listed it on Airbnb. Because it’s useful to both see and remotely control the temperature there, we had a dual-zone WiFi-enabled Honeywell thermostat installed. And because I’m a nerd, I wanted to track its settings, and the corresponding outdoor temperature, over time.

Behold the Temperature Collector. It runs in AWS Lambda and polls both the thermostats and a public weather API every 5 minutes, writing the results to CloudWatch metrics, where I can then graph them on a dashboard. Pretty nifty!

While I was at it, I added support for a Nest thermostat, which I have here in San Diego. And because I love writing automation, I have terraform code to deploy it all. If you need a simple example of how to create a Lambda that runs periodically, you’re welcome to steal it. That’s the beauty of learning in public.

Whatcha Been Up To?

Whatcha Been Up To?

By | | Comments 0 Comment

I’m naming this truism in honor of the co-inventor of the spreadsheet:

Bricklin’s Law

The probability of a project’s success is inversely proportional to the number of status tracking tools used by its team members.

Also, I think this is the first time I’ve used “pull quote” formatting on this blog. Neat!

Joined At The Hip

Joined At The Hip

By | | Comments 0 Comment

Anyone remember this commercial (and the lead-in to it)?

If the kid is me, the doll is Python. Anywhere I go, it goes too. If I have a problem to solve, it’s the tool I reach for nine times out of ten. We’re like peas in a pod, Python and me.

In all seriousness, though, the comparison is apt. I’m a generalist at heart, and I don’t know of a better general-purpose programming language than Guido van Rossem’s masterpiece. Only recently did I make this association, but it fits.

As a team leader, I aim to be adequate or better with any part of the tech stack, so I can plug myself in wherever I’m needed. But it’s unlikely I’m the best one on my team at any of the tech either (in fact, if I am, the team probably doesn’t have an ideal mix of talent). That’s an awful lot like Python, which is the second-best language at everything:

  • Need a quick one-off script? Bash is a bit faster to write, but Python is pretty easy also.
  • Building microservices? Sure, Go is the new hotness, especially if performance is king. But most of the time Python will do the job just fine.
  • Serverless? Oh yeah, Python is money, even if Node.js might be more popular.
  • Doing data science? The nerds use R, but Python’s a great choice too.
  • Putting together a giant enterprise application in all its OOP glory? Most would reach for Java, but object support in Python is great.
  • Functional programming purist? Haskell is your language. But if you want to dabble, Python will get it done, and provide you more flexibility if you need to violate the paradigm for expediency.

Besides us both being generalists, Python and I are both minimalists. It eschews superfluous bits like delimiters, and you needn’t bother declaring types if you’re in a hurry and the situation doesn’t demand it. I also don’t like clutter, e.g. consider my primary workspace:

I stand about 80% of the time, and the kneeling chair takes care of the rest.

Did I mention Python is really easy to learn? And the community is great? And it’s just plain fun? As far as I’m concerned, Python is the Holy Grail.

P.S. It also has a great name. And that’s not nothing.

It’s The Little Things

It’s The Little Things

By | | Comments 0 Comment

We talk all the time about customer obsession, it’s the first amongst equals of our Leadership Principles. The general idea is that you always imagine the customer is in the room with you when making decisions, and consider their preferences when implementing a feature.

As email got more prevalent (and with it, junk emails), one feature that came along in the spirit of customer obsession was one-click unsubscribe. Me being a person who strives for inbox zero, stopping email subscriptions easily was a welcomed capability. But who knew it could be done even better. Behold, zero-click unsubscribe:

How cool is that? Recognizing that I haven’t interacted with any of their emails or visited their site, they automatically unsubscribed me from their lists. That’s customer obsession in a nutshell.

The really surprising thing about this capability is that it’s surely dirt simple to implement. I bet I could pseudo-code it off the top of my head in one minute. Ready, go!

all_emails = database.get_mailing_list()
for email_address in all_emails:
last_contact = database.get_last_contact(email_address)
if datetime.today() - last_contact > ONE_YEAR:
database.remove(email_address)

See how easy that was? Any marketing email system worth its salt already knows when you click on a link in any of their mailings, so the data is there. Just takes a company thinking more about their customers than the size of their distro.

Ketchup

Ketchup

By | | Comments 1 comment

I’ve written a couple of posts in the past that provide an outline of my career progression. Today’s update is in that vein, as I’ve taken on a new role as a technical manager, getting back into people management after a few years off from it.

I was chatting yesterday with one of my new team members, and he asked me a pointed question. Paraphrased, “Given your technical background, why would you choose to be a manager?”

On my résumé, I describe myself as having

a keen interest in architecting systems that are secure, scaleable, and cost-effective, and then building the organizations best suited to implement them

And therein I think lies the reason. I’m a builder at heart, to which this blog’s domain name testifies. And building great solutions requires building great organizations, and it’s that latter team construction which is a manager’s primary responsibility. So I think it makes sense that the builder mentality can carry over to people, even if the technologies involved differ.

Here’s a great upcoming year!

No Silver Bullets

No Silver Bullets

By | | Comments 0 Comment

I thoroughly enjoyed the advice given in Scaling with common sense, probably because I’ve violated each of those principles at various times in my career, and are (hopefully) wiser for doing so.

But the real gem was a link to the following sketch:

I’ve been in that meeting, both as the speaker, and as the listener. Whenever I hear someone say “just move to microservices” like it’s some kind of magic spell that instantly fixes all problems, I want to go full-on Andy Bernard and punch a hole in the wall.