Month: August 2023

If You Can’t Beat ‘Em

If You Can’t Beat ‘Em

By | | Comments 0 Comment

I don’t have a ton of tech writers that I read regularly, but one that I do is Gergely Orosz. His newsletter, The Pragmatic Engineer, is incredible, full of insights and advice for folks at any point in their technical career journey.

A recent two-part installment discussed in detail the plusses and pitfalls of trying to measure developer productivity, a notoriously difficult problem in software engineering. It’s one I’ve been thinking quite a bit about recently, in an attempt to balance the business need to understand how much value we can deliver per dollar spent, without devolving into a joyless culture of mediocrity that treats its team like coding robots (which, it must be said, they’re not).

If you’re in the same position as me, I’d encourage you to subscribe to the newsletter and give the articles a read-through, but if you’re short on time, I absolutely love this simply-summarized single objective measure:

Weekly delivery of customer-appreciated value is the best accountability, the most aligned, the least distorting.

Yup, that sums it up. Other measures matter, but nothing beats screamingly happy stakeholders.

True Grit

True Grit

By | | Comments 0 Comment

Speaking of persisting, there’s two books I’d recommend on the topic:

While targeted to traditional artists like writers and musicians, both have much to say about broader creative activity, within which technological work definitely falls.

P.S. If you’re short on time, you can find a selection of extracts from the latter book in this article: How to Fall in Love with Hard Work.

P.P.S. I almost didn’t write this post because both these books have considerably mixed reviews on Goodreads. But I decided to take their advice, post anyways, and let the reader decide. How meta!

Persist Until Something Happens

Persist Until Something Happens

By | | Comments 0 Comment

Yesterday we held the inaugural 4S Tech meetup. In my book it was a success, with 8 attendees (including myself), and a nice mix of founders, CTOs from both small and large companies, engineers, and even a person from a venture capital firm. The conversation ranged across a number of topics: how to start a company, dealing with founder fallout, mid-sized opportunities that often go unnoticed, dealing with tech FOMO, and of course, generative AI. I know I had a good time and learned a few things, and given that everyone stayed the entire 2 hour allotted time and beyond, I’m guessing the others did too.

I’m already looking forward to doing it again next week. Can we keep the momentum going? I certainly hope so; if you’re in the area, consider joining us: Thursdays 2-4pm at Mostra Coffee in 4S Ranch.

Withertos And Whyfors

Withertos And Whyfors

By | | Comments 0 Comment

If I’ve said it once, I’ve said it a thousand times: there’s more to being a software engineer than coding. In fact, coding isn’t even the hardest part.

The point of that latter article is that AI won’t replace programmers any time soon, but not because it can’t code. Rather because it needs to know what it’s coding for, and specifying that well is what matters, whether it be a carefully constructed prompt to GPT or a detailed requirements document.

One of my favorite sayings is “It’s only software!” And I mean it, in that with enough time and money, computers can do just about anything (which is itself pretty darn cool). But no amount of software can determine what ought to be built. To do that we must apply a broader set of tools.

Just Do It

Just Do It

By | | Comments 0 Comment

Don’t mean for this blog to turn into an endless stream of “gripe about all things AWS” posts, but once again today I ran into an issue that I feel the system ought to be able to figure out on my behalf.

I’m trying to deploy a CloudFormation template (which, not my favorite) in us-west-2. There’s a small bit of configuration (the WAF rules) that are globally applicable, and when not deployed in us-east-1, this causes the whole template deployment to fail (with an utter non-sequitur of an error message):

I mean, obviously that means I’m trying to deploy in an unsupported region, am I right? (eye roll)

Oh CloudFormation, why aren’t you smart enough to just apply the parts that must be global in any region? Right now you’re forcing me to either 1) deploy the whole thing in us-east-1, which I don’t want to do for locality reasons, or 2) split the template into two pieces, which adds complexity. Boo!

Amongst The Silos

Amongst The Silos

By | | Comments 0 Comment

Steps I expected to take when creating an Amazon QuickSight instance and connecting it a PostgreSQL database in Amazon RDS:

  1. Write terraform to create the QuickSight instance
  2. Write terraform to create the RDS dataset
  3. Open the QuickSight console and create a dashboard using that dataset

Steps I actually had to take:

  1. Write terraform to create the QuickSight instance only to discover that creation via API is not supported in my region of choice, so had to throw it away
  2. Create the QuickSight instance manually in the console, during which I had to explicitly select that I wanted to give permissions to talk to RDS
  3. Manually edit the resultant IAM policies to include permissions to use the customer-managed keys that encrypt all our resources
  4. Apply a security group to the RDS instance that allows TCP access on port 5432 to the QuickSight public IP addresses in my chosen region
  5. Add a user to PostgreSQL specifically for QuickSight to use, one with a password hashed using an older algorithm, since the QuickSight driver uses a version that lacks support for modern (read: most secure) algorithms
  6. Grant permissions for this user to be able to read the schemas and tables that hold the data I want to visualize
  7. Create the RDS dataset in QuickSight, manually entering the connection details
  8. Create a dashboard using the above dataset

Figuring out a number of the above steps required decoding unhelpful errors, searching through pages of documentation, and other non-trivial efforts. For shame, Amazon, for shame. Y’all should talk to each other more.

Leave No Trace

Leave No Trace

By | | Comments 0 Comment

Pro Tip: When creating a piece of code or infrastructure that you only need for a short period of time, mark it as temporary, and ideally include a date after which it’s safe to delete. That way in the future, if you forget to delete it yourself, when some person comes across it, they know it can be cleaned up without risk.

This is doubly important if the temporary thing you’ve made opens up a potential attack vector. The canonical example is adding remote IP addresses to a security group, which I had to do just today:

I view the above as a corollary to the Shopping Cart Theory. The world thanks you for your service.

Avengers Assemble

Avengers Assemble

By | | Comments 0 Comment

Back in June, I reflected on the importance of professional friendships, and teased that I’d have more to say “soon” about it. Well, the day has come (and yes, I realize to some, a six week delay might not feel like soon, but in programmer terms, I think I delivered pretty quickly).

I’m excited to announce the launch of 4S Tech. It’s mission is to cultivate a community of technical leaders who live in 4S Ranch though encouraging them to get to know one another, discover each other’s work, and share ideas for collaboration.

Our meetings will begin on August 24 and every Thursday after that from 2-4pm. If you’re anywhere near the area, I’d love to have you stop by for casual conversation, networking, and co-working at the terrace outside Mostra Coffee. They also sell beer if that’s your thing, and there’s a number of other food and drink options nearby if you want to hang longer.

If you’ve got any questions or ideas, please let me know. Here’s to establishing connections!