[Themaintainers] an oldie but a goodie of an article

[Giovanni Tirloni]

Hello! It's my first post here!

This was a very interesting article and I found myself nodding all the way
through it. Thanks for sharing.

I don't know if innovation is becoming an outdated word but I certainly
hope so.

I have started my career as a system administrator, working with servers
and network infrastructure. We've recently been re-labeled DevOps Engineers
and lately, Site Reliability Engineers. There's a ton of work that's simply
maintenance, from keeping systems updated against bugs and security
vulnerabilities to making small changes to work around design imperfections
in the software we work with. We often create what's called "glue" code
because of that. All of the complex and difficult work we do gets
summarized as a percentage number for how much our systems stayed up.

However, looking at the progression of my career and the pervasiveness of
the Agile Movement, I'm now often asked to do my work in terms of
"releases". This works well for "maker" types, I suppose, but the work I do
often falls in the "not sexy" category. What kind of "release" is it when I
simply update a fleet of hundreds of servers to avoid us becoming the
victim of the latest security vulnerability? Nobody wants to hear about
that. So much so that in "iteration meetings" (done every 2 weeks), we only
discuss what we are "shipping", new features, a new product, something new
new new. It's often an uphill battle to get maintenance-type work included
in the task planning because, well, the business is not asking for it.

The same happens with creating and evangelizing infrastructure standards,
reviewing and improving existing backend processes, having demo sessions,
etc. None of that goes into bi-weekly presentations shown to CxO's. I don't
have a good solution for this situation except being the annoying person
that constantly reminds everybody in the room that certain maintenance
tasks can't be forgotten. I wish I didn't have to be that person. I
certainly wouldn't need to be if CxO's routinely enquired about the health
of things instead of the latest new feature.

I try to be more pragmatic, to surface the maintenance work that is done
routinely (which is harder in startup types, but I digress) but in the end,
I must admit there's more frustration than anything else. In my darkest
moments, I wish a hacker would exploit a vulnerability we should have fixed
but didn't prioritize. Or that systems will just crash, I'll be called in
to fix them and people will know there's value in this work. More often
than not, we'll instead have a "post-mortem" meeting to discuss what we're
doing right and wrong, with the focus on the wrong.

In my profession, it's to say that when everything is working, nobody knows
you exist. When things break, it's your fault. But I still love my work,
despite all of this. The feeling of having everything running smoothly is
very gratifying.

Regards,
Giovanni Tirloni

On Thu, Oct 10, 2019 at 11:12 PM Sierra Reed <sierra at newdayinvesting.com>
wrote:

>
> https://www.theatlantic.com/technology/archive/2015/01/why-i-am-not-a-maker/384767/
>
> Regarding the culture around the word "maker", attributed to DIY, hardware
> projects seen as a catalyst for innovation. The article explores how
> gendered this Maker Movement is, and how those who "make", often men, are
> prioritized above the care-takers and the repairers (read: the maintainers)
> for the economic potential of the thing that is made. Makes a fair case for
> how women are the original maintainers.
>
> I'm curious, as innovation becomes an outdated buzzword, how maintenance
> will be considered as a tactic in the making of new things, and how this
> might allow new opportunity for women to enter the field of tech if so.
>
>
> Best,
> --
> Sierra T. Reed | CONTENT STRATEGY
> NEWDAY IMPACT
> Address: 735 Montgomery Street, Suite 330
> Jackson Square, San Francisco CA 94111
> Direct: 415.272.9389 | Email: sierra at newdayinvesting.com
>
> This communication is intended only for the recipient to whom it is
> addressed. It may contain information that is privileged and confidential.
> Nothing contained in this email constitutes tax, legal, insurance or
> investment advice, nor does it constitute a solicitation or an offer to buy
> or sell any security or other financial instrument. Past performance is no
> guarantee of future results.
>
> If you are not the intended recipient of this message, any use,
> dissemination, distribution, or copying of this communication is strictly
> prohibited. If you have received this communication in error, please
> immediately notify the sender and permanently delete all copies that you
> may have.
>
>
> This communication is intended only for the recipient to whom it is
> addressed. It may contain information that is privileged and confidential.
> Nothing contained in this email constitutes tax, legal, insurance or
> investment advice, nor does it constitute a solicitation or an offer to buy
> or sell any security or other financial instrument. Past performance is no
> guarantee of future results.
>
> If you are not the intended recipient of this message, any use,
> dissemination, distribution, or copying of this communication is strictly
> prohibited. If you have received this communication in error, please
> immediately notify the sender and permanently delete all copies that you
> may have.
>
> _______________________________________________
> Themaintainers mailing list
> Themaintainers at lists.stevens.edu
> https://lists.stevens.edu/mailman/listinfo/themaintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stevens.edu/pipermail/themaintainers/attachments/20191011/8ed35e14/attachment.html>