[HN Gopher] Know Your Carrying Capacity
___________________________________________________________________
Know Your Carrying Capacity
Author : todsacerdoti
Score : 88 points
Date : 2022-10-09 12:13 UTC (10 hours ago)
(HTM) web link (www.macchaffee.com)
(TXT) w3m dump (www.macchaffee.com)
| didgetmaster wrote:
| 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.
| mkaic wrote:
| 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)
| didgetmaster wrote:
| 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.
| mgkimsal wrote:
| 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.
| mac-chaffee wrote:
| 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
| Test0129 wrote:
| 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.
| nobodyandproud wrote:
| 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.
| Test0129 wrote:
| > 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.
| nine_k wrote:
| Just a wonderful (and terrifying) quote:
|
| > _explode like a pinata filled with responsibilities_
|
| (The idea is to not be that pinata.)
| pfoof wrote:
| Me, a DevOps Engineer, company less than 40 people:
|
| - 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.
| closewith wrote:
| This just seems like Ops?
| megak1d wrote:
| 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.
| disadvantage wrote:
| 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.
| elric wrote:
| 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 ...
| btrettel wrote:
| 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.
| ozim wrote:
| I basically have the same way when dealing with any software -
| add ons or modifications are nice until you have to update
| stuff.
| dkarl wrote:
| 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.
| Teckla wrote:
| 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).
| whateveracct wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-09 23:00 UTC)