[HN Gopher] DevTools Leverage
       ___________________________________________________________________
        
       DevTools Leverage
        
       Author : kiyanwang
       Score  : 20 points
       Date   : 2021-08-20 20:26 UTC (2 hours ago)
        
 (HTM) web link (explog.in)
 (TXT) w3m dump (explog.in)
        
       | dbt00 wrote:
       | > Finally, if you have senior anywhere in your title or job
       | description: an implicit part of your job is to make the people
       | around you more effective. Diving into - and fixing - tools
       | should be a meaningful use of your time.
       | 
       | This, 100x. The internal tools function is often forgotten by
       | other teams when dealing with things like ongoing education,
       | professional development, code quality initiatives and even
       | hiring practices. (Ironically, because a lot of those things end
       | up leveraging tools that the tools teams own!) The tools team
       | should be a rotation or an area for open contribution, not a
       | permanent destination or specialty.
       | 
       | > There are downsides, of course. Toolsmiths are at least one
       | step removed from the actual work that's going on - it can be
       | hard to explain what we built to anyone without context (or
       | violating NDAs). Depending on how enlightened your management is,
       | your team might also be severely underfunded for what it needs to
       | accomplish, mainly because the effect of good tools isn't
       | generally easy to measure.
       | 
       | The other downside to tool building is that when you build
       | something, you're competing against "there's no tool for this
       | that fits our need", but when you're maintaining and evangelizing
       | the tool your competition is often "open source software on the
       | internet", which can outdevelop you by sheer weight. So you
       | should always bias heavily for buy/download over build, and you
       | should always minimize how much you fork and customize those
       | tools let you get left behind by the broader community.
        
       | lazyant wrote:
       | Not the argument of the article but I'm tired of this meme about
       | automation and speed of execution ("worked one week to automate
       | this task that takes two seconds").
       | 
       | Automation is not about completing tasks faster, it's about
       | correctness, predictability, consistency, reproducibility,
       | developer workflow, processes as code, code reviews, audit
       | trails, knowledge sharing etc.
       | 
       | It's about being paged for an issue in production and not having
       | to wonder if John entered a typo in his laptop and deployed by
       | mistake in the wrong environment.
        
         | mnahkies wrote:
         | I've encountered a few manual processes for producing data
         | recently that amount to query this thing from here, export this
         | CSV from here then plug it into this sheet and write down the
         | number.
         | 
         | It works, it produces the right number and probably only takes
         | a few minutes of one person's time each month.
         | 
         | I'm still for automating this end to end, because it makes it
         | auditable and tamper proof.
         | 
         | If the data is produced by some ETL job then any problems are
         | bugs in the job, not because someone made a typo (or in the
         | worst case falsified figures, etc - basically it's good to
         | remove humans from the process)
        
       ___________________________________________________________________
       (page generated 2021-08-20 23:00 UTC)