[HN Gopher] The Reinforcing Nature of Toil
___________________________________________________________________
The Reinforcing Nature of Toil
Author : kqr
Score : 26 points
Date : 2023-01-25 19:23 UTC (3 hours ago)
(HTM) web link (two-wrongs.com)
(TXT) w3m dump (two-wrongs.com)
| Centigonal wrote:
| It is is true that toil erodes development velocity and code
| quality if you have a team of utility players, or if your toil
| takes up a critical mass of work. However, there are situations
| where automating toil doesn't increase development velocity:
|
| - You have a developer who is good at manual, repetitive work but
| has trouble with more creative tasks (toil can keep this person
| productive as you work to develop their creative potential)
|
| - You have a new developer who needs to learn the system, or your
| team is inheriting a new project (toil can be a great way to
| understand the system, its strengths and weaknesses, and possible
| Chesterton's Fence situations - this is similar to the "don't
| renovate your house until you've lived in it all four seasons"
| advice)
|
| - Some toil is unavoidable - our team ingests data from hundreds
| of websites we don't control. Website operators can change their
| site content to literally anything, and it's impossible to
| account for all the issues this can create - even though the
| fixes can often feel simple and repetitive.
|
| That said, toil is usually unpleasant and feels less impactful,
| and automating unpleasant work usually has good knock-on effects
| (happier team members who feel like they're doing impactful work
| tend to be more productive, stay together longer, and refer their
| friends).
| passterby wrote:
| what's with the assumption that evolution does not include a kind
| of "code review" meaning some sort of "error" correcting scheme
| or something??
___________________________________________________________________
(page generated 2023-01-25 23:01 UTC)