[HN Gopher] Let maintainers be maintainers
___________________________________________________________________
Let maintainers be maintainers
Author : chalst
Score : 140 points
Date : 2023-08-26 13:52 UTC (9 hours ago)
(HTM) web link (graydon2.dreamwidth.org)
(TXT) w3m dump (graydon2.dreamwidth.org)
| brennvin wrote:
| I suppose it varies a lot from one organization and industry to
| another. My experience is that managers don't like it when people
| rock the boat, they prefer their subordinates to just quietly
| execute the tasks given to them. Growth-oriented people like
| myself are sometimes seen as a problem because they cause things
| to happen that are not in the road map.
|
| In my field (fin tech) managers often do not have the background
| to be able to assess the value of spontaneous technical
| contributions. So they assume that if something was not planned
| and requested by management it did not need to be solved.
| Aurornis wrote:
| > Growth-oriented people like myself are sometimes seen as a
| problem because they cause things to happen that are not in the
| road map.
|
| Creating new work that wasn't in the roadmap (excluding tech
| debt and other necessities to get roadmap work done) is a
| problem.
|
| The right way to grow is to learn how to work with the company
| to get important work into the roadmap.
|
| I've worked with some peers who had good ideas and good
| intentions, but they'd unintentionally try to blow up the
| roadmap and reset planning by prioritizing their work over the
| things we needed to get done.
|
| Working with the business to get things prioritized is a
| necessary skill. A lot of engineers just want to work on
| whatever they want to work on most, but that's a problem in the
| context of an organization trying to coordinate.
| vbezhenar wrote:
| > A lot of engineers just want to work on whatever they want
| to work on most, but that's a problem in the context of an
| organization trying to coordinate.
|
| May be it's actually a management challenge to turn this
| enthusiasm into money?
|
| What's a problem for one person makes an opportunity for
| another person.
| Spooky23 wrote:
| It depends on the business. Many places have no idea wtf they
| want, and presented with something interesting they'll ditch
| what they are doing to do it, because they don't know why
| they are doing whatever they planned anyway.
|
| The existence of this thread belies this. Running everything
| like a product is the fad today. It's a fad because running a
| "product" means understanding its lifecycle and resourcing it
| as appropriate. But the mandate in BigCorp is to run printer
| ink fulfillment with the same methodology as an actual
| product, so lots of leadership time is spent thinking about
| toner or whatever.
|
| It's inefficiency created in the pursuit of efficiency via
| control.
| gochi wrote:
| You can't get important work into the roadmap while also
| complaining that people are trying to blow up the roadmap
| when they try to get important work into the roadmap.
|
| Kind of a big problem here, as you're defining the right way
| as also the way that frustrates you (and assumingly others)
| the most.
| ResearchCode wrote:
| It's not a problem, that's how you create software. You can
| put some of those initiatives on a "road map" if you want,
| but there must be space for them. 50% "slack time" is a good
| standard for software engineering. Your software engineers
| likely know better than your middle-managers how to spend
| that time.
| brennvin wrote:
| > Creating new work
|
| I am not talking about creating additional work, I am talking
| about solving problems not on management's radar screen. Some
| problems are only visible from the floor.
|
| > The right way to grow is to learn how to work with the
| company to get important work into the roadmap.
|
| That is not always possible because valuable things sometimes
| have to be demonstrated to be understood. Not all things can
| be explained in the abstract, sometimes you have to build the
| thing first before people understand how useful it is.
| natpalmer1776 wrote:
| I agree with this sentiment. A good (software) engineer
| needs to have the discernment to know when to ask for
| permission, and when to ask for forgiveness.
| bombolo wrote:
| Sounds to me like you're getting micromanaged.
| natpalmer1776 wrote:
| I fail to understand how you manage to extrapolate my
| working conditions from a generalization of what soft
| skills are required to be a good engineer.
| tremon wrote:
| A software engineer only needs to make those judgement
| calls in a bad environment. In a good environment, such
| situations can be discussed in the open.
| hallarempt wrote:
| "managers" -- if there are managers on top of the maintainers,
| then, yes, it won't work.
| sndjdn wrote:
| [flagged]
| brennvin wrote:
| > but it's one you made up.
|
| You just made a bunch of things up.
| gloryjulio wrote:
| You need to discuss with ur manager about the priority of the
| tasks. This also help u with the bookeekping.
|
| When things break u can say that u have already had this
| discussion and it was not ur responsibility to fix it at the
| time
| gabereiser wrote:
| The problem is they can't justify your cost if you go outside
| the planned work load. They could probably still quantify it
| but it's difficult to assess your impact when your effort
| doesn't count towards velocity and delivery of business
| outcomes. If you work does impact those things, it should be a
| ticket/story/task so that the impact of work can be measured
| (seen...). I would suggest, in the future, adding these things
| to the backlog as you come up with them and bring them up
| during planning.
| ResearchCode wrote:
| The measure is called an accepted pull request. You don't
| need a ticket to submit a patch to the Linux kernel. If
| you're in a dysfunctional agile micro-management environment
| with "stories" and "backlogs" then look for a real job.
| brennvin wrote:
| > The problem is they can't justify your cost if you go
| outside the planned work load
|
| Cost? It's a freebie. I'm still doing my tasks, in addition
| to saving them tons of money with better tools.
| moomoo11 wrote:
| "just let AI do it bro"
| breadwinner wrote:
| > _companies often have an incentive structure that rewards
| novelty, especially in the form of features if not entire
| products._
|
| Unfortunately, this is true. Every developer has to fit into the
| everyone-does-everything mold, and if you don't you will not get
| good rewards. In reality developers are diverse: some are highly
| creative, some are very good at tracking down hard bugs, some are
| very good at devops, and so on. Not allowing for this diversity,
| and not having different tracks for developers to grow is tragic
| along multiple dimensions: People who are good at devops and
| enjoy doing devops don't see a growth path, so they leave. People
| who are creative and would prefer to spend most of their time
| doing creative work, can't because they are expected to do devops
| as well. Allowing for diversity of talent, and having growth
| paths for everyone would make for a stronger team.
| surajrmal wrote:
| I've always worked on teams where managers try to allow folks
| to play to their strengths, but ultimately folks can't entirely
| focus on just doing what they like to do. Otherwise you end up
| with unfair division of effort or some important things no one
| wants to do not getting done. Diversity of experience also
| allows you to better understand things which may make you more
| efficient overall. For instance, being forced to do some
| performance work will help you make better tradeoffs when doing
| design later.
|
| I think the most important things are to voice your preferences
| to your management and try to pick projects that are in a stage
| of their lifecycle that have needs for your strengths. If you
| prefer creative work, find a project early in its lifecycle
| with less baggage to way you down. If you love hardcore
| debugging, find something which is growing aggressively. If you
| like maintenance, find a mature product to help steward.
| breadwinner wrote:
| > _ultimately folks can 't entirely focus on just doing what
| they like to do_
|
| True, but companies can allow that when there is enough
| diversity in the team, instead of insisting that everyone fit
| into the exact same mold.
| stiglitz wrote:
| Unfortunately missing in the article is any plan for this to
| actually happen: for stability and quality to be valued by the
| CEMBI when their boss demands proof of "impact".
| surajrmal wrote:
| It's often important to help management define what impact is
| rather than to let them define it for you. If you want quality
| and stability to be included in impact, define a way to measure
| it and then get management to sign off on it being impact
| worthy. Our infra team has dash boards for keeping CI times
| low, false positive and false negative rates low, etc. Simply
| not regressing on those metrics is a daunting task and they
| have managed to convince management of that fact. As a result,
| their impact is measured by those dashboards which they
| defined. You can do this on any team by defining quality KPI
| such as the rate of customer reported bugs, customer sentiment,
| number and length of outages over some time period, etc.
| jeremyjh wrote:
| All those metrics can be gamed to death and none of them
| sound impressive to the C-suite. Even if they accept that
| those are your KPIs, they will not think of you as an "A"
| player if all you want to do is maintain a number.
| charles_f wrote:
| The word impact has become a trigger to me. It is both
| sufficiently abstract and seemingly concrete, and allows
| managers to do pretty much what they want from it.
|
| I remember one telling me "I'm all about impact", and then
| praise people who built arguably impressive but totally useless
| and uncalled for shit, while others who sacrificed their souls
| preventing entire rotten stacks to fall got a "meh, they had a
| huge opportunity and didn't seize it".
|
| An impact is what's happening when something hits something
| else. I prefer not to have impacts.
| Izkata wrote:
| A step further: The most spectacular impacts are when
| something crashes and burns.
| vvanders wrote:
| A good counter to this is having a strong technical IC
| leadership roles(I.E. Staff IC or similar) that leadership
| regularly gets input on in terms what is impactful in areas
| like this. The key piece is the work is low-visibility when
| successful and _high_ visibility when it goes all wrong. A
| strong technical organization will recognize that and leverage
| high-judgement individuals close to the technical work so that
| they it can be accounted for properly.
|
| Mekka talks about this in terms of underrepresented groups[1]
| but the same principals apply as well to any low-vis when
| successful / high-vis when it goes wrong(I.E IT, Ops, etc)
| roles. It's really up to technical leadership in an
| organization to make sure that they're noting high-impact/low-
| viz work and surfacing that in a way that the "new shiny"
| doesn't drown it out. I've been in both domains(high-vis
| graphics/shiny!, low-vis tooling/devx that had huge impact) and
| you really do need to account for it properly otherwise you'll
| have exactly the situation described in the article. Your
| company/org will falter and stumble as those infrastructure
| pieces slow _everything_ down if you don 't retain/reward the
| people doing that work.
|
| [1] https://mekka-tech.com/posts/2018-08-09-the-difficulty-
| ancho...
| moomin wrote:
| This reminds me of the episode of Last Week Tonight where John
| Oliver points out the problems America has on infrastructure
| maintenance:
| https://youtube.com/watch?v=Wpzvaqypav8&si=W1TxMMu26rQNM6PC
| neilv wrote:
| I wanted to like this, but:
|
| 1. it didn't make a great case for infrastructure working (they
| were on one angle with disasters, but ended up with one middle-
| aged bicyclist killed by a pothole, and some UCLA partier
| students enjoying a little wading pool water);
|
| 2. didn't suggest a plan of action;
|
| 3. was mostly poorly-executed gags, and a few potshots at
| politicians, diverting from any kind of critical thinking or
| action beyond impotent tweeting.
|
| I strongly suspect that Daily Show style news-tainment has
| unintentionally been dumbing down what should be a very active
| left (while Rupert Murdoch and talk radio cynically did
| something analogous to what would become the right). Now people
| intuitively feel powerless, except to Tweet zingers at the
| imagined enemy.
|
| How about: infrastructure is important because (off top of
| head)... disaster threats (cite some real-world examples, which
| exist), safety (e.g., drinking water), economic benefits from
| functioning infra (e.g., transportation efficiency), quality of
| life, social justice (cite real-world examples of poor areas,
| and how that marginalizes them), national sustainability (tie
| it into restoring can-do know-how, and manufacturing
| capability), with side benefit of creating worthwhile jobs that
| should already exist.
|
| And don't drop the ball just complaining "oh, those politicans
| being politicians" and leaving it at that, when a politician
| says they haven't yet found money for it. Nor try to use the
| kind of people who'd call in to a TV news program (and get
| selected to be put on air) as representative of anything other
| than people who'd call in to a TV news program. The citizen is
| left with a muddle-headed idea that same-ol'-same-ol', and not
| informed to do anythign about it, other than make bitter jokes
| about the perceived adversary.
|
| Graydon referenced West Wing, so I'll try: (context: backstage
| of Presidential election debate, incumbent meeting opponent GWB
| character): https://www.youtube.com/watch?v=wvr1T1sFvEg
| chalst wrote:
| Also titled "Curse of the CEMBI", where the acronym is for
| 'Corporate-Employed Maintainers with Bad Incentives'.
| softwaredoug wrote:
| Fundamental problem of management is you would _like_ to have an
| incentive structure for the impact of an individual BUT the most
| impactful people usually aren't out highlighting their
| accomplishments, they're in the background helping everyone else
| be successful.
| sanderjd wrote:
| But if they're helping everyone else be successful, surely a
| managers who cares about that will know that's what they are
| doing and be able to incentivize them to continue?
| softwaredoug wrote:
| Even the good managers have to build cases for promotion,
| raises, and recognition...
| sanderjd wrote:
| Totally. If managers really believe this "glue" role is
| valuable, they should be able to advocate for that belief.
| But it's definitely true that they may well fail, if the
| broader culture doesn't agree.
| neilv wrote:
| Excellent thoughts by Graydon here.
|
| One concern I have is that, every time he talks about the
| maintenance roles, I'm automatically thinking it's unglamorous,
| and marking a career plateau (perhaps decline).
|
| I also instantly visualized a suited executive reluctantly
| deciding it's a necessary role they have to staff, and the exec
| will feed the trolls in the mine, but the focus (and rewards)
| will consciously be on the stars who are making new things
| happen.
|
| Even though Graydon just explained that kind of thinking is a
| problem, I'm still thinking it.
|
| If I'm still thinking that (with background that includes very
| serious software engineering, as well as FOSS), then my guess is
| that a lot of other people will be thinking that, as well.
|
| BTW, I'm not saying that I'd personally devalue maintenance
| roles. If I was managing something important that needed to be
| maintained, and I lucked upon a stellar maintainer, I'd do
| everything I could to retain them and keep them happy, including
| making a case for why their comp should track with some of the
| new-product-star people.
|
| I'd also try to make sure that, if their position
| declines/disappears (e.g., they no longer have someone advocating
| successfully for the role) that they'll be marketable elsewhere.
| (I don't want them ever walking into an interview and hearing, "I
| see from your resume that you're more of a maintenance
| programmer, but we really need people who can hit the ground
| running, banging out new huge kernel modules. Maybe you could
| assist them, by writing unit tests, and fetching their coffee, so
| they can focus on the challenging new stuff?")
|
| One sign of hope is that the best-known worst-offender, at
| rewarding only new things, at least takes _some_ aspects of
| reliability seriously.
| SamoyedFurFluff wrote:
| Imo number 1 thing that helps a maintainer on the resume is to
| say they brought in some number of revenue, and all their bug
| fixes (especially taking out the fires of the other engineers
| doing features) saves the company a dollar amount or guaranteed
| a dollar amount of ARR.
| chriskrycho wrote:
| The trick is that in many cases the value delivered is
| invisible and unmeasurable. How do you quantify "time saved
| by not having bugs"? But that is what great maintenance does.
| Or, the same for "time saved by a really well-designed API
| that makes it easy to do the right thing and harder
| impossible to do the wrong thing"? Again: not measurable!
| "Just put a number on it" is the kind of facile response I
| consistently get from too many folks in management when
| trying to have these kinds of discussions, and the annoying-
| but-inescapable reality is that it is not always possible to
| provide a monetary number on the value of this sort of work.
| Despite that value often very likely netting out in the
| millions or more every year!
| Archelaos wrote:
| > ... it is not always possible to provide a monetary
| number on the value of this sort of work. Despite that
| value often very likely netting out in the millions or more
| every year!
|
| Hm. You fist state, that it is not possible to provide a
| monetary number, then you state it is very likely netting
| out in the millions -- which is providing a monetary
| estimate.
| tomjakubowski wrote:
| If the value of one thing is somewhere in the range of
| $1-$100, then its value is hard to quantify.
|
| But if you have one million of those things, you can
| still say "it's very likely I have value in the millions
| of dollars or more here".
|
| The same logic applies here. All that has to be true for
| "we have millions here" to be plausible is that (1) the
| value of each individual, unquantified contribution is
| positive and probably >$1 (2) there are probably millions
| of such contributions. You don't have to be able to
| quantify with any precision any individual contribution.
| erikerikson wrote:
| > I'm automatically thinking it's unglamorous, and marking a
| career plateau (perhaps decline).
|
| This may be a bug in your thinking, although the lack of
| organizational glamor checks out. The new shiny often gets the
| most attention. Often because it's trying to cross the gap from
| non-existence and out of mind to mind share and adoption, so
| marketing budget (literal but also emotional and attentional).
| However, the start of a project is usually far simpler, less
| constrained, and easier. Most of the truly hard trade-offs and
| the impacts from decisions don't come due until later. Not only
| this but the deep learning comes from observing these outcomes
| and starting to understand how the decisions in the beginning
| come together.
| lamontcg wrote:
| Biggest problem I think is really staffing the infrastructure
| tasks sufficiently.
|
| You will get bled down to practically no headcount being
| allocated to infrastructure, with all the headcount assigned to
| "big bets" on the non open-source products and the "skunkworks"
| projects trying to pivot the company into something new.
|
| Even when we had a team come in and get assigned to pick up a
| neglected piece of old technology instead of focusing on getting
| the maintenance solid and fixing all the shit in the backlog, it
| was all "big bet" features and when those fizzled the team got
| slowly cut down until the project failed.
| ricardobeat wrote:
| Isn't this somehow a modern, self-inflicted disease? FOSS used
| to be developed to very high standards by individuals, without
| relying on expensive CI pipelines.
| lamontcg wrote:
| I'm using "infrastructure" in the same sense that the author
| described:
|
| > ... as infrastructure -- triage and fix bugs from the
| backlog, optimize performance, increase security and
| reliability, pay down tech debt, simplify and automate
| ongoing maintenance
|
| And CI pipelines don't need to be particularly expensive, and
| they're pretty critical really if you're building
| "infrastructure" in that sense. Otherwise you're just
| shipping code off to your customers to be the CI pipeline.
___________________________________________________________________
(page generated 2023-08-26 23:00 UTC)