![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I am frustrated, on an ongoing basis, by the value we're asked to place on "hard work." It's a puritan virtue that seems to stick around with people a lot. Any time an employee is honored you hear speeches about them working late into the night or crunching all weekend to get a project done. When things go wrong, we remind ourselves that someone was working really hard, so we should have sympathy for the fact that the results still had problems.
The thing is, in my experience the majority of time I find myself working particularly hard it's a sign that I'm working *wrong.* The environments where I've personally had to work long hours have all either been the result of bad planning on my part or a destructive environment that required it. Certainly, with the exception of a few adrenalin-fueled rushes, there has always been an inverse relationship between the overall numbers of hours I've worked and my overall productivity during those hours. And every one of those stretches was the result of a bad system design.
The thing is, basically any engineering work is about system design. The goal is to optimize your resources (processor power, memory, bandwidth, disc space, number of complicated operations such as disc reads and writes or database access, etc.) You don't necessarily want to minimize your use of them all, but you need to use them in appropriate amounts such that if there is a sudden change your system can handle it (that link is to Maciej Cegłowski's account of how pinboard handled the day the "delicious is going away" slide leaked).
And people are part of any system. Developer time and energy is something that a good tech manager manages as much as they manage memory usage and runtime complexity. (I cannot *count* the number of times I have heard the chestnut about Ruby and Python development being about optimizing developer time at the price of computer time in a world of cheap computers.)
I was lucky, early in my career, to have a mentor who taught me the value of virtuous laziness in the form of an obsession with automating boring tasks in order not to have to do them. (My current coworkers are probably sick of hearing the sentence. "But... why is a *human* doing this?" from me.) Later mentors, and my own trial and error (soooo much error) and also my therapit, taught me the value of setting appropriate expectations for what I could accomplish, not promising to promise more than I could do in a given time period, efficient process management to keep myself working steadily rather than in a rush, etc. I have to admit, a lot of my own personal anguish in watching the first forty-eight hours after the last AO3 launch unfold was the bitter reminder of disasters of my own on that scale or larger.
Every time I hear "but I worked hard" my heart screams out that working hard is the WRONG THING TO DO. Communicating about what you're capable of is the right thing to do. Asking for help when you need it is the right thing to do. Offering help to someone who is overworking is the right thing to do. Re-setting launch dates around what is posible is the right thing to do. Making sure that time-sensitive updates are uncoupled from other updates is the right thing to do.
Preventing cultures where heroism is not only the norm but mandatory? Is the right thing to do.
Look. I know it's easy to backseat quarterback. But like. These are not new problems. People have worked out the answers before. (Oh yeah, that's another general vice/virtue thing I take issue with. A lot of the time copying someone else's answer is ABSOLUTELY the right thing to do. Of course, in that context it's called "following best practices"...) You can learn things the hard way if you want. (Some of us need to learn things the hard way in order for the lesson to stick.) But. Take the lesson when it is given to you, rather than defensively claiming that you worked hard and that the people criticizing you are doing so with unnecessary vitriol. (Yes, some of them are absolutely using unnecessary vitriol. But having worked in customer support as well as in software development, I'm a big believer in the right of customers to bitch unproductively and the right of engineers to be filtered from the bullshit while getting the productive stuff. That's what, wait for it, good tech managers are there for.)
And the pain of watching someone repeating your own past failures in ghastly slow motion in front of an audience of thousands? Is a pain like no other.
ETA: when I use the word "failure" I am not referring to launching some code with a few bugs in it. Everyone does that shit. I'm talking about the communication and process management failure around it and the fact that it cost their project a developer who, according to the AO3's impact chart has been responsible for a MINIMUM of 10% of the code in the archive. (Because of whatever emergency push process juggle led to last week's mess, for instance, none of the skins code is credited to lim in that report. I don't know what other code Naomi's committed on lim's behalf because the practice in question makes that impossible to determine.)
The thing is, in my experience the majority of time I find myself working particularly hard it's a sign that I'm working *wrong.* The environments where I've personally had to work long hours have all either been the result of bad planning on my part or a destructive environment that required it. Certainly, with the exception of a few adrenalin-fueled rushes, there has always been an inverse relationship between the overall numbers of hours I've worked and my overall productivity during those hours. And every one of those stretches was the result of a bad system design.
The thing is, basically any engineering work is about system design. The goal is to optimize your resources (processor power, memory, bandwidth, disc space, number of complicated operations such as disc reads and writes or database access, etc.) You don't necessarily want to minimize your use of them all, but you need to use them in appropriate amounts such that if there is a sudden change your system can handle it (that link is to Maciej Cegłowski's account of how pinboard handled the day the "delicious is going away" slide leaked).
And people are part of any system. Developer time and energy is something that a good tech manager manages as much as they manage memory usage and runtime complexity. (I cannot *count* the number of times I have heard the chestnut about Ruby and Python development being about optimizing developer time at the price of computer time in a world of cheap computers.)
I was lucky, early in my career, to have a mentor who taught me the value of virtuous laziness in the form of an obsession with automating boring tasks in order not to have to do them. (My current coworkers are probably sick of hearing the sentence. "But... why is a *human* doing this?" from me.) Later mentors, and my own trial and error (soooo much error) and also my therapit, taught me the value of setting appropriate expectations for what I could accomplish, not promising to promise more than I could do in a given time period, efficient process management to keep myself working steadily rather than in a rush, etc. I have to admit, a lot of my own personal anguish in watching the first forty-eight hours after the last AO3 launch unfold was the bitter reminder of disasters of my own on that scale or larger.
Every time I hear "but I worked hard" my heart screams out that working hard is the WRONG THING TO DO. Communicating about what you're capable of is the right thing to do. Asking for help when you need it is the right thing to do. Offering help to someone who is overworking is the right thing to do. Re-setting launch dates around what is posible is the right thing to do. Making sure that time-sensitive updates are uncoupled from other updates is the right thing to do.
Preventing cultures where heroism is not only the norm but mandatory? Is the right thing to do.
Look. I know it's easy to backseat quarterback. But like. These are not new problems. People have worked out the answers before. (Oh yeah, that's another general vice/virtue thing I take issue with. A lot of the time copying someone else's answer is ABSOLUTELY the right thing to do. Of course, in that context it's called "following best practices"...) You can learn things the hard way if you want. (Some of us need to learn things the hard way in order for the lesson to stick.) But. Take the lesson when it is given to you, rather than defensively claiming that you worked hard and that the people criticizing you are doing so with unnecessary vitriol. (Yes, some of them are absolutely using unnecessary vitriol. But having worked in customer support as well as in software development, I'm a big believer in the right of customers to bitch unproductively and the right of engineers to be filtered from the bullshit while getting the productive stuff. That's what, wait for it, good tech managers are there for.)
And the pain of watching someone repeating your own past failures in ghastly slow motion in front of an audience of thousands? Is a pain like no other.
ETA: when I use the word "failure" I am not referring to launching some code with a few bugs in it. Everyone does that shit. I'm talking about the communication and process management failure around it and the fact that it cost their project a developer who, according to the AO3's impact chart has been responsible for a MINIMUM of 10% of the code in the archive. (Because of whatever emergency push process juggle led to last week's mess, for instance, none of the skins code is credited to lim in that report. I don't know what other code Naomi's committed on lim's behalf because the practice in question makes that impossible to determine.)
