Know Your Carrying Capacity

The forum software is best kept as standard as possible, aside from perhaps simple things like custom themes. Addons and modifications could go unmaintained, have security issues, or not be rewritten when the forum software deprecates features the addon/modification relies on. These addons become additional pieces to maintain. Keeping up with forum security updates alone can be irritating. The security updates rarely come at convenient times. I always have something else I'd rather be doing.

For example, recently someone requested that I install an addon so their Discord server could automatically be notified when someone posts. I looked at the addon, saw that it already was dropped by the original maintainer before being picked up by someone else. Installing it looked convoluted. I told the Discord administrator to use the built-in Atom feed with the right Discord bot, and recommended a particular bot. They now have the feed on their Discord server working. No changes to the forum were needed, which kept the burden on me to a minimum.

And when a forum is dead and basically an archive, the forum software can have issues (incompatibility with later standards, slowness, security problems if the software can not be updated). So making a long-term archive seems prudent. Some people seem to want the archive to be particularly fancy. I once had someone ask me to make an archive of a forum I'm an administrator on. They wanted it to be a "modern" React app with a powerful internal search feature, etc. As I recall, I said that I'm not going to develop that and prefer simple static HTML. No maintenance needed. Want to search? Try Google's site: operator. (In response to this request, I downloaded the entire forum with wget, which took a while and required some iteration to get the settings right as there were many duplicate and unnecessary pages saved. I haven't uploaded the archive yet as I need to fix some broken links and the forum isn't entirely dead yet.)

Given all of this, I can understand why someone would choose to make a subreddit over running a forum on their own server.

That doesn't mean I don't have baseline responsibilities—I have many—but my goal is to make those things as efficient as possible. When I write code I work hard to make it as robust and self-documenting as possible and include test coverage. When I set up a new process at work (whether as an employee or founder), I make sure it's documented and bring others along. It's not possible for every conceivable maintenance task or call for assistance to be fully supported, but one thing I will never give up is my agency to prioritize my own time and decide what is most important. That way lies burnout.

In essence, I asked her to note down everything that made up her carrying capacity on a day-to-day basis.

At the same time, I realised that if I tasked myself with this very same exercise, I would simultaneously be horrified by the amount that I am (at least partially) responsible for, and terrified that I'd forgotten something in that list.

To this day I have not done this exercise.

I've been 'over capacity' in a some situations over the years, and telling people "I'm doing too much" doesn't really seem to help. The few times I've done this in the corporate world, someone assigns me another non-technical manager. Yay. Totally helpful.

I recognize this 'over capacity' in some colleagues too, often to larger extremes than I've personally hit.

I like the term 'carrying capacity' but unsure it would help communicate the idea any better.

EDIT: the 'potential consequences' list is useful too.

Any wonder why everyone claims 'I know nothing about that!' when a problem pops up in some peripheral system that no one is in charge of.

- physical servers and VMs

- some microservices

- CI/CD pipelines for every project

- helper scripts

- licenses

- security

- e-mail accounts

- setting up everyone's computers

- wiki and documentation

Moreover:

- understanding compilers and frameworks because "we developers want only to code"

- printer, routers, switches, TV

This is not a rant, just proof for this article.

It's not "problem solved" once you accept a patch to add a feature - it's something you need to keep in mind for the rest of the project's lifespan, and will prevent you from focusing on other (perhaps more important) things.

> explode like a piñata filled with responsibilities

(The idea is to not be that piñata.)

Some employees hide their stress and do everything until they break down. Some employees don't stress, still do everything, but do a rushed and shitty job of it. Some employees do what they can and silently drop everything else on the floor.

Managers tend to think that if they're chill and don't pressure people, then the people under them won't have the freak out stress breakdowns. Then they're surprised. Like, where did that come from? Everybody else is fine. Managers think the whole team will follow their vibe and their example, but that's not how people work. This is especially easy to miss with remote work. You can have two people on the same team, one calmly working exactly forty hour weeks, fully aware that things are going to shit, and the other working 80 hour weeks and laying awake at night worrying that they're going to be fired. Managers have to be aware of that and proactively find out how people are handling the workload.

For my part, I do my best to understand what I should let die. Wiki pages (or Notion docs)? Give me a break. Nobody reads them. Ten months from now somebody is going to need that info, and I (or whoever has the up-to-date info) will write it up for them and even give them a personal walk-through, in a fraction of the time it would have taken to maintain those docs through the months when nobody was reading them. Obviously there are exceptions to this rule, but it works for 95% of the docs I've ever been asked to maintain, and the exceptions are things that obviously should not be in a wiki or Notion (release notes, dashboard-y type stuff that you can get from a database query, etc.)

And I consistently let my manager know what parts of my "job" aren't getting done. I used to be afraid of telling them, but they understand, and they're grateful that I keep them in the loop, so they're aware and so they can correct me when they don't agree with my decisions. Not just the best managers are cool with this, but even the not-so-great managers. I've only had maybe one manager who was so shitty he couldn't deal with it. Everybody is happy that they're hearing it now and not getting taken by surprise later. It serves as a reminder for them, too, because they're fallible and often forget that certain things don't happen unless somebody has time to do them. They're also often unaware of the productivity cost of missing helper scripts, minor build and CI issues, and things like that, and if they're reminded they sometimes know of a person who needs a task and is good at figuring that stuff out.

And you know what's funny? This is the one part of the job that super arrogant rock star programmers are actually good at. They love to tell you about the stuff they don't have time for because of the super important work they're doing. So, in this one case, act like a rock star and tell your manager exactly what stuff you ignored this week because it didn't seem important enough to be worth your time.

I will try to mend my ways. But I doubt mgmt will be wanting to hire a team of 6 FTEs to manage the stuff that I've been managing on the side ...

Amen to that - checklists.

Your carrying capacity, complexity budget, novelty budget, maintenance budget, etc etc all go up over time. And the cost of things against them tends to shrink as well (see: using a novel PL as an example of this).

We aren't static creatures with static stats. We learn and grow. This is hidden dehumanizing management talk imo - a big part of the "fungible resource" philosophy is to not count on humans being human because it isn't a sure thing. But growth & learning is the most human thing you do every day in your career.