If I had one minute to evaluate a job interviewee, I’d put a piece of writing in front of them (either code for a developer or prose for a less technical person) and watch them type it into an editor in real-time. If they are able to do so quickly and with few errors (for some values of quick and few), they pass.
This is completely unfair, and heavily biased towards certain privileges; many otherwise excellent candidates would be missed. But as a first-order approximation, I’d be willing to wager it works more often than not.
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.
While targeted to traditional artists like writers and musicians, both have much to say about broader creative activity, within which technological workdefinitely 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!
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.
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.
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!
Steps I expected to take when creating an Amazon QuickSight instance and connecting it a PostgreSQL database in Amazon RDS:
Write terraform to create the QuickSight instance
Write terraform to create the RDS dataset
Open the QuickSight console and create a dashboard using that dataset
Steps I actually had to take:
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
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
Manually edit the resultant IAM policies to include permissions to use the customer-managed keys that encrypt all our resources
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
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
Grant permissions for this user to be able to read the schemas and tables that hold the data I want to visualize
Create the RDS dataset in QuickSight, manually entering the connection details
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.
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.
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!
For the first five years of my career, I worked for a defense contractor located on-site at an Air Force research facility. My job was to write software, but the lab had quite a bit of hardware as well. Over time, things could get pretty messy as we were regularly reconfiguring the setup, leaving random cables and parts strewn all over the place.
We must not have been unique in this, because about half-way through my tenure there the powers-that-be started a “tidying up” initiative that everyone was required to participate in, up and down the ranks, including uniformed military, civilian, and contractors. Being already something of a neat freak, I bought some split loom tubing (from Parts Express, my absolute favorite source for A/V parts) and used it to bundle all the cords at my desk. Apparently I’d done such a good job that word got around about my setup, and one afternoon the person at the top who’d launched the cleanup initiative stopped by and thanked me for my efforts, and said my desk was the example that others in the building should emulate.
Ever since I learned proper cable coiling technique I’ve enjoyed keeping areas with many of them as neat as possible, ideally with none of them visible. Today I was happy to do so in my wife’s classroom, including installing a light strip since the cubby where her desk lives is in a poorly-lit corner.
I didn’t need much nudging to do this; now the drive to tidy cables is a bit of a compulsion. If I ever see random ones laying about (such as on a conference room table), I’ll coil them out of habit. And if I ever see someone doing it wrong you can be sure I’ll have something to say about it. Yes, there is a right way, and it’s easy to learn with a bit of practice, so no excuses.
