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.
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.
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.
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.
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.
Today my kids had to choose between virtual and socially-distanced on-campus learning for this fall semester (thanks COVID-19). The selection process involved picking their high school from a drop-down on the district website. Oddly we couldn’t initially find their school (Del Norte) in the list.
Why not? Well, it turns out that Google Chrome’s auto-translate feature was attempting to be helpful, and transformed it into “From North”. Which made me realize three things:
I’m really thankful to be techie and able to debug such issues, because I imagine this will cause confusion for those less clued-in to potential browser oddities.
It’s really hard for computers to do be “smartly” helpful in a transparent way; if an algorithm isn’t darn near perfect it’s likely to do more harm than good.
The implementor should have added translate=no to their <html> tag to avoid this problem altogether.
I feel like I say “_______ is hard” a lot, so forgive the repetition, but today’s article illustrates that service design is hard. The “micro” in microservices leads many (including myself at times) to believe each service should be as small as possible. It’s an unfortunate name, because that’s not the truth (naming things is hard too, but I digress).
What’s the right size for a Microservice dispels the above myth and several others, on its way to presenting a few helpful criteria to size a service. For anyone who designs systems, or builds systems, it’s worth your time.
Are you using the AWS Cloud Development Kit yet? If your job ever involves creating or maintaining infrastructure (on AWS, natch), you absolutely should be. Take the power of CloudFormation (minus the annoying parts) and mix it with the familiarity of your favorite programming language (Python, am I right? Yes I am. But TypeScript, Java, and .NET are also choices), and you get a killer option in the burgeoning Infrastructure as Code toolbox.
Instead of spending a bunch of time telling you why the CDK is so great, here’s some resources to help you to discover so for yourself:
Have you ever looked at a heavily object-oriented codebase (Java, I’m looking at you) and immediately felt dumber? Did the design patterns touted as the ultimate in software craftsmanship sound amazing when you studied them in school, but now every time you see them in real projects they result in layer upon layer of confusion?
There is no one approach to rule them all when it comes to software development, and while I wouldn’t be quite as hard on object-oriented programming as the articles linked above (yes, there are multiple ones), it’s not the only, best, or even appropriate pattern to use in all circumstances.
