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.
> 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.
Never works. If there's one thing the PHBs and their MBA goons hate it's paying people. That sounds like sarcasm but it's not. I've yet to hear some high-flying MBA tell me that the solution is to give me more money and hire more people. My favorite is that sales, a field probably just as important as developers, is not minimized and sales doesnt have to deal with "two pizza" non-sense, ping pong tables as a benefit, and long hours working literally for free because of the magic of salary. Sales gets to go home on the weekend and suckers like me are stuck doing pagerduty. Of course, when review time comes around there's never enough money in the pot to pay me more...
To these idiots, developers are a cost center to be minimized. Hence why as a developer you regularly wear the hats of 3 different subfields. For example, as a backend/systems engineer there are days I spend more time maintaining terraform/k8/whatever than actually writing code. Or even worse these days - maintaining code written by foreign contractors because labor arbitrage is the new hotness.
The industry needs an entire upheaval and software engineers need to stand up for themselves. Until that happens, the suffering will continue even if you're tied to the wall with golden handcuffs.
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.
Seems like a good thing for managers to understand as well, because different employees handle it differently.
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.
Unfortunately, if scrum (and story points and sprint commitments and the whole works) is mandated from above--as it usually is--even the best manager won't be able to prevent many or most software engineers from working in a constant state of stress and anxiety, regardless of how many hats the software engineers are wearing (or not wearing).
Having a big list like this also stops growth and integrating entire new tool-chains. I sometimes start with a blank slate when developing a new system, because in the beginner's mind, there are many possibilities, and in the expert's mind there are few.
This one hits close to home, I'm very much guilty of this. It's hard to delegate some of this stuff when your company is small. There's no budget for full time (.*)Ops when you're starting out as a software shop. Once a bit of money starts to roll in, there are other priorities to spend it on. And if you're anything like me, you enjoy the variety that this hodgepodge of responsibilities brings. Of course, this is a massive business risk in disguise.
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 ...
> Frequently re-visit that "list of things you have to personally maintain" in order to avoid blind spots. When you do this, you might be forced to jog your own memory by re-reading those docs or investigating that old VM.
I hate all analogies like this (complexity budget is another one) because they are wrong and assume that these pseudo-scientific values are static.
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.
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.