As an administrator of a few small online forums, I've tried hard to minimize the burden of running the forums. Running even a single small online forum can take a considerable amount of time.
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.
This article raises some good points, but I disagree with the solution. Writing an official list of responsibilities will likely lead to hand-wringing tradeoffs any time a new ask comes in. This is not an efficient way to manage ones time. There are many reasons why I don't think it's efficient (overhead, accuracy, etc), but fundamentally I don't want to be in a "default no" stance when someone asks me for help. Letting past work be an albatross around my neck that accumulates a base maintenance cost prevents seizing future opportunity is soul crushing.
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.
When our office manager quit to pursue better and more lofty opportunities (all the power to them!!), I gave her one final task for her last week or so — list every single thing that you are responsible for.
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.
Not necessarily too much here to help avoid it or mitigate the situation of being 'over capacity', but I did like the list example. Shows that this "know a bit of everything" is probably more common than we think.
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.
I do wish I knew of a better solution/mitigation. I feel like there might not be anything an individual really can do. It depends on coworkers picking up the slack or leadership/customers just demanding less (hah).
I quit my last job over this, which kinda inspired this post. I tried to formally shed some of my responsibilities, but the only people who volunteered were other over-capacity people! So really nothing changed haha
In my case I have regularly found myself deep inside the bus factor zone because I had a lot of knowledge acquired through working on so many things. Raising the issue "I'm a roadblock" or "I'm overburdened" doesnt seem to work as you pointed out. It seems this is just a sign to a manager to do more managing to you.
The real fix, in my opinion, is to actually hire people. Tech has gotten into this fetish of "dev ops as a culture" or "admin as a culture" or whatever nonsense. These are just excuses to not hire teams to take this work on. Overburdening developers is exactly what they want by design. I suspect this is because developers are paid so much they want to "feel like they're getting their moneys worth" out of them.
Tech culture is toxic and full of abuse parroted gleefully by a lot of these startups HN tends to adore. Leaving companies doesn't even help because its a problem in the culture of tech. Until developers just outright refuse to do nonsense like maintain kubernetes clusters, perform SRE tasks, etc the pain will continue. I look forward to the day I can retire from this awful industry. I unfortunately have many years left of 60 hours weeks to go.
That’s easy: If there are competing priorities then there are also competing interests and stakeholders.
If these are internal, then nicely and professionally relay that some of these will need to take a backseat and then let the stakeholders argue and decide what needs to happen.
Also drop hints that a larger technical team would help. If you’re doing things that matter, then sooner or later you’ll find yourself with a team because it’s the stakeholders pushing for it.
The worst outcome is that you burn yourself out trying to do it all, which is expected in startups but very counterproductive when the organization matures a bit.
If you work for a medium sized company (maybe even a small company) you can easily get trapped into maintaining some system just because you once volunteered to 'look at it' when it needed attention a few years ago. You fix an email problem the CEO ran into, and suddenly you are the 'email expert' that everyone runs to when they have an email problem. Fix someone in sales' computer and now everyone wants you to look at their laptop to see what is wrong with it.
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.
I have become the resident "hardware guy" in roughly this fashion. When I got the job, my only computer hardware experience was building my own janky PC and having watched 100s of hours of Linus Tech Tips, but when my boss suggested I build a 10,000 dollar workstation for use in our lab, I said yes because it sounded exciting. Fast forward 8 months to the present day and I've been managing CUDA versions on GPUs across workstations, installing and troubleshooting hard drives, moving servers between different locations, and other odd jobs related to our on-premise compute. It doesn't make up a huge part of my day-to-day work, but it's also funny looking back at how I somehow became the "hardware guy" when one my coworkers has background in mechatronics! (this is not a complaint, btw, I quite like being in charge of expensive PC components)
It is not always bad to become the 'resident expert' on some technology that was not part of your original job description. Sometimes it can help you expand your horizons in something that is really interesting to you. Sometimes it can be great for job security when you are the only one who truly understands some critical piece of the infrastructure. But for every one of those tasks, there are probably two where you can get roped into maintaining some legacy system that is nothing but pain.
This is extremely similar to my DevOps role. Company about 250 ppl, 4 DevOps engineers.
As a ex-product lead (full stack dev) and head of engineering, the “we developers want only to code” winds me up so much.
Just because your code worked once and now another dev has (badly) applied a framework upgrade, doesn’t mean it’s DevOps’ job to find out “why the build is broken” and fix the incompatibility between your old code and the new framework.
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.
Readit News
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.
I quit my last job over this, which kinda inspired this post. I tried to formally shed some of my responsibilities, but the only people who volunteered were other over-capacity people! So really nothing changed haha
The real fix, in my opinion, is to actually hire people. Tech has gotten into this fetish of "dev ops as a culture" or "admin as a culture" or whatever nonsense. These are just excuses to not hire teams to take this work on. Overburdening developers is exactly what they want by design. I suspect this is because developers are paid so much they want to "feel like they're getting their moneys worth" out of them.
Tech culture is toxic and full of abuse parroted gleefully by a lot of these startups HN tends to adore. Leaving companies doesn't even help because its a problem in the culture of tech. Until developers just outright refuse to do nonsense like maintain kubernetes clusters, perform SRE tasks, etc the pain will continue. I look forward to the day I can retire from this awful industry. I unfortunately have many years left of 60 hours weeks to go.
If these are internal, then nicely and professionally relay that some of these will need to take a backseat and then let the stakeholders argue and decide what needs to happen.
Also drop hints that a larger technical team would help. If you’re doing things that matter, then sooner or later you’ll find yourself with a team because it’s the stakeholders pushing for it.
The worst outcome is that you burn yourself out trying to do it all, which is expected in startups but very counterproductive when the organization matures a bit.
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.
As a ex-product lead (full stack dev) and head of engineering, the “we developers want only to code” winds me up so much.
Just because your code worked once and now another dev has (badly) applied a framework upgrade, doesn’t mean it’s DevOps’ job to find out “why the build is broken” and fix the incompatibility between your old code and the new framework.
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.)