Just a Theory

Trans rights are human rights

Posts about Work

I’m a Postgres Extensions Tembonaut

Tembo Logo

New year, new job.

I’m pleased to announce that I started a new job on January 2 at Tembo, a fully-managed PostgreSQL developer platform. Tembo blogged the news, too.

I first heard from Tembo CTO Samay Sharma last summer, when he inquired about the status of PGXN, the PostgreSQL Extension Network, which I built in 2010–11. Tembo bundles extensions into Postgres stacks, which let developers quickly spin up Postgres clusters with tools and features optimized for specific use cases and workloads. The company therefore needs to provide a wide variety of easy-to-install and well-documented extensions to power those use cases. Could PGXN play a role?

I’ve tended to PGXN’s maintenance for the last fourteen years, and thanks in no small part to hosting provided by depesz. As of today’s stats it distributes 376 extensions on behalf of 419 developers. PGXN has been a moderate success, but Samay asked how we could collaborate to build on its precedent to improve the extensions ecosystem overall.

It quickly became apparent that we share a vision for what that ecosystem could become, including:

  • Establishing the canonical Postgres community index of extensions, something PGXN has yet to achieve
  • Improving metadata standards to enable new patterns, such as automated binary packaging
  • Working with the Postgres community to establish documentation standards that encourage developers to provide comprehensive extension docs
  • Designing and building developer tools that empower more developers to build, test, distribute, and maintain extensions

Over the the past decade I’ve have many ideas and discussion on these topics, but seldom had the bandwidth to work on them. In the last couple years I’ve enabled TLS and improved the site display, increased password security, and added a notification queue with hooks that post to both Twitter (RIP @pgxn) and Mastodon (@pgxn@botsin.space). Otherwise, aside from keeping the site going, periodically improving new accounts, and eyeing the latest releases, I’ve had little bandwidth for PGXN or the broader extension ecosystem.

Now, thanks to the vision and strategy of Samay and Tembo CEO Ry Walker, I will focus on these projects full time. The Tembo team have already helped me enumerate the extension ecosystem jobs to be done and the tools required to do them. This week I’ll submit it to collaborators from across the Postgres community1 to fill in the missing parts, make adjustments and improvements, and work up a project plan.

The work also entails determining the degree to which PGXN and other extension registries (e.g., dbdev, trunk, pgxman, pgpm (WIP), etc.) will play a role or provide inspiration, what bits should be adopted, rewritten, or discarded.2 Our goal is to build the foundations for a community-owned extensions ecosystem that people care about and will happily adopt and contribute to.

I’m thrilled to return to this problem space, re-up my participation in the PostgreSQL community, and work with great people to build out the extensions ecosystem for future.

Want to help out or just follow along? Join the #extensions channel on the Postgres Slack. See you there.


  1. Tembo was not the only company whose representatives have reached out in the past year to talk about PGXN and improving extensions. I’ve also had conversations with Supabase, Omnigres, Hydra, and others. ↩︎

  2. Never be afraid to kill your darlings↩︎

Times Up

December 22, 2023 was my last day at The New York Times. My tenure was just under two and a half years.

My first 19 months at the company were pretty much everything I had hoped, as I collaborated with Design and Product to design a distributed platform and conceived, designed, and implemented CipherDoc, a service for encrypted data management. I’m incredibly proud of that work!

But alas, plans change. After the company mothballed the project, I refocused my time on glue work: re-platforming services, upgrading runtimes and dependencies, improving logging and observability, and documenting code, architectures, and playbooks. It felt good to reduce the onboarding, maintenance, and on-call overhead for my teams; I hope it helps them to be more productive and fulfilled in their work.

I treasure the terrific people I met at The Times, just super thoughtful, empathetic, and creative co-workers, partners, and colleagues. It’s no wonder they had the energy to form a union, The Times Tech Guild, for which I’m gratified to have helped organize and steward members. The Guild connected me with a far broader range of talented and committed people than I would have otherwise. I will miss them all, and continue to cheer for and support the movement from the outside.

And now, as 2023 winds down, I’ve decided to try something new. More news in the new year!

Sign O’ The Times

The New York Times T Logo

Some news: I’m super happy to report that I started a new job last week at The New York Times.

After ten years at iovation, the last four working remotely from New York City and the last three under the ownership of TransUnion, I felt it was time to find something new. At The Times, I’ve taken the role of Staff Engineer on a new team, User Systems. I’m particularly stoked for this gig, as it falls right into areas of abiding interest, including privacy-by design, personal data protection, encryption, authentication, credential management, and scaling a vital app for the whole business. Add that to the straightforward commute once the office reopens, and it’s hard to find something more ideal.

I truly appreciate the extraordinary experience of my ten years at iovation. I originally thought I’d stay a couple years, but was so engaged by the people and the great work we did that I kept at it. I learned a ton about product engineering, product design, and scalable architectures, but especially about working with terrific colleagues who made me a better person even as I tried to be of service to them. I will especially miss working with Scott, Kurk, Clara, Travis, John, and Eric — and countless others. I wish them all the best, and would enjoy working with any and all of them again anytime.

Now I’m excited to make new connections working with my amazing new colleagues at The Times. I expect we’ll collaborate on fulfilling work building super useful tools that advance The Times mission to inform and empower its readers. I’m delighted to be jumping on this ride with them.

Compassionate Sacking

Jennifer Kim, in a Medium post based on her Twitter thread:

#1 rule: No one should ever be surprised with a “you’re fired.” That’s how you create disgruntled employees, embarrassing Glassdoor reviews, dip in team morale, etc. An out-of-the-blue firing is a failing on the manager’s part, not the employees.

So how do you do that? The most important bit:

  1. Give them a fair shot to improve. As a leader, it’s your job to try to make it work, each employee is owed that.

Practice listening skills. Demonstrate that you believe in them, and you want to see them improve. Commit to giving a LOT more feedback (specific & documented).

If you have little faith that the employee will be able to improve, taking these and the other steps Jennifer recommends might feel like a waste of time. But unless the employee’s actions involve violence, harassment, fraud, etc., you need to give them every chance possible for not only their benefit, but the benefit of their coworkers. Of course you don’t mention it to your other employees, but people talk, they know what’s going on, and they all need to know that if they step out of line, you’ll support them as much as you can.

In other words, a firing should never come as a surprise to either the employee getting the sack nor their coworkers. Because worse than negative Glassdoor reviews is the erosion of trust among the people you continue to work with after the event.

Flex Your BICEPS

I’ve been thinking a lot about what creative professionals want and expect out of their jobs. We require certain base features of a job, the absolute minimum for even considering employment:

  • Fair, livable compensation for the work
  • Comprehensive, low maintenance, effective benefits (especially health care)
  • Equitable work hours and conditions (vacation time, work/life balance)
  • Safe work environment

Employers attempting to skimp on any of these items devalue the people they employ and the work they do. Don’t do that.

Assuming an organization meets these fundamentals, what else gets people excited to go to work? What makes employees happy, committed, and productive members of the team? Fortunately, I’m far from the first to explore this topic. Paloma Medina reduces the literature to the muscular acronym BICEPS:

There are six core needs researchers find are most important for humans at work. Not all are equally important to everyone. You might find that equity and belonging are most important to you, but choice and status are most important to your employee. Getting to know them and coaching to them is a shortcut to making others feel understood and valued (aka inclusivity).

The BICEPS core needs:

  1. Belonging
  2. Improvement/Progress
  3. Choice
  4. Equality/Fairness
  5. Predictability
  6. Significance

Beyond the utility of having these needs enumerated to think about collectively — with obvious implications — I find it useful to examine them from varying frames of references. To that end, consider each from the perspective not of rewards and perks, certificates and foosball tables. Ponder them with the goal of creating a virtuous cycle, where the work improves the company, engendering greater satisfaction in the work, and encouraging more of the same.

Belonging

Organizations serious about encouraging friendships and closeness often highlight social gatherings, team-building exercises, and outings. But don’t underestimate the motivation of the work. Small teams given the space to collaborate and accomplish their goals might be the best structure to create a sense of belonging to a tight-knit group — and for employees to find joy in their accomplishments.

Then reward those accomplishments. Not just with compensation or perks. No. Put the full force of the business behind them. If a team finished work on a feature or shipped a product, don’t limit recognition to a cocktail hour and a raised toast. Promote the hell out of it through all available channels: marketing, sales, blogging, support, community forums, whatever. The surest road to satisfaction and a sense of belonging is to turn that work into a palpable success for the organization.

Improvement/Progress

Funds for conferences, training, and formal education clearly help employees make progress in their careers, or to sipmly improve themselves. But people also get satisfaction from work that helps the company to execute its strategies and meet its goals. Assuming the vision aligns with an employee’s values,1 contributing to the material achievement of that vision becomes the employee’s achievement, too.

So be sure to create opportunities for all employees to grow, both in their careers and contributions to the company mission. Avoid artificial divides between those who make the execute and those who support them. Not everyone will participate; still, encourage ideas and suggestions from all quarters and, where possible, adopt them. Beyond the old canard to “act like an owner”, clearly link organizational success to the ideas and work that created it, and give everyone the chance to make a difference. They improve as the business improves, and that’s progress.

Choice

Typically, “choice” means different healthcare plans, Mac or PC, sitting or standing desk. Such perks are nice, but not materially meaningful.2 The choices that warm the creative worker’s heart have much more to do with autonomy and decision-making than fringe benefits. Let teams choose their projects, decide on technologies, self-organize, make the plans to execute. People empowered to take initiative and make decisions without micromanagement or post-hoc undermining find motivation and reward in the work itself. Let them do it!

Equality/Fairness

Yes, grant employees equal access to resources, to management, to the decision-making process, and any other information necessary for their work, benefits, etc. That only stands to reason. But give them equal access to interesting work, too. Where possible, avoid unilaterally appointing people to teams or projects: let them organically organize and pick their collaborators and projects. Such decisions mustn’t be made in isolation; it wouldn’t be fair. Rather, you’ll need to hold regular get-togethers of all relevant teams to make such decisions collectively, PI Planning-style. Give everyone a voice, leave no one out, and they will mostly work out the optimal distribution of tasks.

Predictability

In addition to paying employees on time, every two weeks, make the work cycle predictable, too. Everyone should have a good idea when things happen, what the iteration cycle looks like, what the steps are and when they get slotted into the schedule, when projects complete and products ship. Just as importantly, make it clear what will they be working on next – or at least what’s in the pipeline for the teams to choose and plan for in the next iteration of the development process. A predictable cadence for the work lets people understand where they are at any given time, what’s next, and what successful execution looks like.

Significance

Titles and industry recognition, obviously, but this item brings my commentary full circle. Make sure that the work employees do gets seen not only by immediate managers, not simply lauded at the weekly dessert social. Make it a part of the success of the company. Promote the hell out of it, let customers and users know that it exists and solves their problems — no, show them — and shout it from the rooftops so the entire world know about all the stuff made by your super valuable team of humans.

They’ll be happier, more satisfied, and ready to make the next success.


  1. A very big assumption indeed. I expect to write a bit about company strategies and alignment to employee values soon. ↩︎

  2. Okay, sometimes a choice is no choice at all. Mac or nothing for me! ↩︎

iovationeering

Since June, as part of my work for PGX, I’ve been doing on-site full-time consulting for iovation here in Portland. iovation is in the business of deterring online fraud via device identification and reputation. Given the nature of that business, a whole lot of data arrives every day, and I’ve been developing PostgreSQL-based solutions to help get a handle on it. The work has been truly engaging, and a whole hell of a lot of fun. And there are some really great, very smart people at iovation, whom I very much like and respect.

iovation

So much so, in fact, that I decided to accept their offer of a full time position as “Senior Data Architect.” I started on Monday.

I know, crazy, right? They’ve actually been talking me up about it for a long time. In our initial contact close to two years ago, as I sought to land them as a PGX client, they told me they wanted to hire someone, and was I interested. I said “no.” I said “no” through four months of contracting this summer and fall, until one day last month I said to myself, “wait, why don’t I want this job?” I had been on automatic, habitually insisting I wasn’t interested in a W2 position. And with good reason. Aside from 15 months as CTO at values of n (during which time I worked relatively independently anyway), I’ve been an independent consultant since I founded Kineticode in November of 2001. Yeah. Ten Years.

Don’t get me wrong, those ten years have been great! Not only have I been able to support myself doing the things I love—and learned a ton in the process—but I’ve managed to write a lot of great code. Hell, I will be continuing as an associate with PGX, though with greatly reduced responsibilities. And someday I may go indy again. But in the meantime, the challenges, opportunities, and culture at iovation are just too good to pass up. I’m loving the work I’m doing there, and expect to learn a lot over the next few years.

Kineticode

So what, you might ask, does this mean for Kineticode, the company I founded to offer support, consulting, and training services for Bricolage CMS? The truth is that Kineticode has only a few technical support customers left; virtually all of my work for the last two years has been through PGX. So I’ve decided to shut Kineticode down. I’m shifting the Bricolage tech support offerings over to PGX and having Kineticode’s customers move there as their contacts come up for renewal. They can expect the same great service as always. Better even, as there are 10 associates in PGX, and, lately, only me at Kineticode. Since Kineticode itself is losing its Raison d’être, it’s going away.

PGX

I intend to remain involved in the various open-source projects I work on. I still function as the benevolent dictator of Bricolage CMS, though other folks have stepped up their involvement quite a lot in the last few years. And I expect to keep improving [PGXN] and DesignScene as time allows (I’ve actually been putting some effort into both in the last few weeks; watch for PGXN and Lunar/Theory announcements in the coming weeks and months!). And, in fact, I expect that a fair amount of the work I do at iovation will lead to blog posts, conference presentations, and more open-source code.

This is going to be a blast. Interested in a front-row seat? Follow me on Twitter.

Looking for the comments? Try the old layout.

New Gig: PostgreSQL Experts, Inc.

A bit of good news: In addition to my ongoing Kineticode work doing Bricolage consulting services, training, and support, I have a new gig! I, along with Josh Berkus, David Fetter, Andrew Dunstan, and a team of other PostgreSQL experts, have started a new company: PostgreSQL Experts, Inc. I’m really excited about PGX, a cooperative of solid and experienced–dare I say expert?–people dedicated to providing exceptional PostgreSQL professional services, including consulting, training, and support.

Moreover, we have a solid group of experienced application developers, who are ready and willing to build your PostgreSQL-backed applications on Rails, Catalyst, PHP, or whatever environment you prefer. If it’s related to PostgreSQL, it’s what we do.

So get in touch or meet us at PGCon (we’re sponsoring!) or at OSCON 2009. I’m really excited about our company, and looking forward to growing it as PostgreSQL adoption grows.

Looking for the comments? Try the old layout.

I’m Ba-aack!

Sandy - your free personal email assistant

Yes indeed, I am back. Was I ever gone? Well, yes, I’ve been rather busy for the last 15 months.

But December 31 was my last day at Values of n. I’m really pleased with the work I did there. Sandy in particular, was a pleasure to work with. I really think that the work that Rael and I did with Sandy has been important work. Dare I say potentially paradigm-shifting? At any rate, I’m convinced that Sandy is really going to go places. If you haven’t signed on to become her client, do try. Though I will no longer be as intimate with her as I have in the past, we’re still going to keep in touch—I’m still her client. And Rael will do a great job pushing forward with her.

So why did I leave? Well, the truth is that, after Julie’s dad died in July, I found that I no longer had the resources to commit to the 80-100 hours/week required to work in a startup. It was just no longer that important to me. Don’t get me wrong, it was rewarding work, but my priorities completely realigned. It was vital that I continue helping Rael to get Sandy’s career launched, but once that was done, it was time for me to move on.

And what am I doing now? Well, first and foremost, I’m taking a few months off. I’m going to spend a lot more time re-acquainting myself with the two terrific women with whom I share a house, and just generally reset myself. Take a few deep breaths. Relax and enjoy life a bit. Sleep in now and then. That sort of thing.

That’s not to say that I’ll be sitting on my ass all the time. I have a very long list of things I want to do during this time, including catch up on my blogging (hence the title of this post), fix some bugs in Bricolage and help get 2.0 out the door, update my Perl libraries (I’ve got some great ideas for improving SVN::Notify), finally get all my digital photos organized, etc. I already spent much of last week revamping our mail system (I outsourced it to FuseMail). And all that’s leaving aside all the things Julie and I want to get done around the house. That’s the really important stuff.

But do watch for more blog posts in the coming months, too. There are a few interesting things I want to write about, and I’ve got some serious catching-up to do. Interested in following along on my adventures? Follow me via Twitter.

Looking for the comments? Try the old layout.

How to Extend Bricolage 2.0

Going through the latest version of the Bricolage 2.0 technical specification, I can see at least six ways that developers will easily be able to extend Bricolage:

Write a new task by subclassing Bricolage::Biz::Task
A task can be designed to do just about anything to a single Bricolage object. Hell, you’d be able to look up other objects, too, so anything’s possible. Tasks are run by scheduled jobs, event-triggered actions, or by distribution jobs.
Create a new data type by subclassing Bricolage::Biz::Value and Bricolage::Biz::Type::Value
We’ll support quite a few different value types to start with, but we couldn’t anticipate everything, so this’ll be your chance!
Create a new UI widget by subclassing Bricolage::Widget and Bricolage::Biz::Type::Widget
Maybe your new value requires its own special widget. Or maybe you don’t like the way the existing widgets handle other types of values. So write your own!
Write a new distribution mover by subclassing Bricolage::Biz::Dist::Mover
We’ll start out with file system copy, SFTP, SFTP, and WebDAV distribution movers just as we have in Bricolage 1.8, but there’s always room for more!
Write a new authentication plugin by subclassing Bricolage::Util::Auth
The built-in and LDAP-based authentication systems aren’t doing it for you? You want to authenticate against a different database? Make it so!
Write a new storage back-end by subclassing Bricolage::Store
We’ll have a PostgreSQL back-end from the start, and perhaps SQLite and/or MySQL. But here’s your chance to get Bricolage running on FileMaker Pro just as you’ve always secretly desired!

So have fun with it! When it gets here. Want to help get get here? Subscribe to Bricolage-Devel and chip in!

Looking for the comments? Try the old layout.

Bricolage Tasks, Jobs, Actions, and Alerts

I’ve been working on the design for what are called distribution jobs and alerts in Bricolage 1.x. There were some good ideas there. Distribution jobs enable users to set up a list of tasks to execute against the files being distributed, such as validating them against a DTD or distributing them via email. It also allowed developers to create fairly simple plugin modules that could be added as new jobs. Alerts are great ways of letting users know that some even has happened, and their rules-based evaluation of event attributes is a powerful way of configuring alerts to be sent only for certain events logged for certain objects.

The problem is that they’re specific solutions to general problems. Distribution job s are an example of scheduling arbitrary tasks to be executed, while alerts are an example of triggering the execution of arbitrary tasks upon the logging of an event. So what I’ve been working on is trying to generalize these ideas into a simpler yet more powerful and flexible architecture. What I’ve come with is this:

Tasks

Very simply, a task is an object of a class designed to perform a simple, um task. Examples include publishing a document, expiring a document, sending an alert, or validating a file against a DTD. An abstract base class, Bricolage::Biz::Task, will establish the the interface for tasks, although its subclasses may add their own attributes (such as the subject and message of an alert). Each will implement an execute() method that will simply carry out the task on the object passed to it. Some task classes may operate on only one type of object (such as Task::Publish), while others may operate on many or even all Bricolage business classes (such as Task::SendAlert). There is no connection between task classes and events or jobs, except that the object that called the task object’s execute() method will be passed to execute() as a second argument.

Actions

An action is an event-triggered series of tasks. New action types can be created that have rules set to be evaluated against the event, just as is currently the case for alert types in Bricolage 1.x. The difference is that rather than being limited to sending alerts, actions types will be associated with one or more task objects, and each of those tasks will be executed in sequence when an action of that type is triggered. This will enable users to, for example, configure an action to republish an index document whenever a story document is published.

Jobs

A job is a scheduled series of tasks. Users will be able to create new jobs for any single object in Bricolage, associate any number of task objects, and then schedule the job to be run at some specific date and time in the future. This approach will enable users to, for example, schedule a job to send an alert about a given document one year in the future, as a reminder to update the document.

Destinations

Destinations will be similar to what’s currently in Bricolage 1.x. However, rather than having “job” classes specific to distribution, they’ll be able to specify a list of any tasks that are designed to be executed against an output file. This keeps the interface for tasks identical across all three uses.

Alerts

Alerts are no longer closely tied to events, since they can sent as part of a scheduled job or as part of a distribution to a destination in addition to when an event is logged. Rather, they will only be created by Bricolage::Biz::Task::SendAlert. So a Bricolage business object can have any number of associated alerts, just as it can have any number of associated events.

Upshot

The upshot of this redesign, which took me several days of thinking to tease out to be general enough to satisfy me, is that more users will have more of what they need from Bricolage, and developers can more easily add new functionality that’s immediately available to event actions, scheduled jobs, and distribution destinations.

Looking for the comments? Try the old layout.