DevTools Leverage | Hacker News Reader

DevTools Leverage

explog.in

39 pointskiyanwang9 comments

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.

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)

I made a code challenge which consisted basically on some simple ETL stuff, get data, parse geoJSON into a State, return data in json format in an api endpoint including pinging some random example api, which casually the day I sent the assignment and was testing it, would be crashing and giving nulls for the positions. It was because some CDN/DNS provider du jour (can't remember exactly which was down. So whatever was auto-generating random gps locations wasn't working it this small time window and would make my otherwise correct code and tests fail, I explained all this and got hired, but I could haven't had the luck to read about the down issue on HN and just be f***

no one brings up the lack of friction as a feature for small personal projects either. I have made some things that are just for me and took a few min to code up but are a quality of life thing and spark joy when you use it. You don't feel bad for not remembering how to run some command that you should know or just get that "It Just Works®" satisfaction.

There's also the ikea effect of building something for just yourself but that's just a bonus if you aren't on a team.

> 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.

> you should always bias heavily for buy/download over build, That's a good point; I haven't spent much time thinking through this based on the work I've done so far (heavily leaning towards build over buy, with an existing complex internal tool ecosystem).

I think I might still push for build (or maintain the ability to heavily customize) for things that are particularly important for areas the company aims to have a strong advantage in/are business critical.

Really love this style of thinking. Tool building done well can have such a huge impact on everyone around you; especially if it’s easy to build good tools.

We’ve been building something with this in mind; to try to make it way easier to focus on the important parts of tooling, and abstract away all the annoying boilerplate. You might be interested in checking it out at https://ab.bot. We’re in the current YC batch and had a Launch HN a few weeks ago.

I wrote about our love of toolmaking here: https://blog.ab.bot/archive/2021/07/15/tools-for-inside-the-... :)

That was a really fun post to read: I really like the approach you're taking with abbot -- making it easy to write new tools quickly by only adding the business logic while having fun. Not needing to worry about UIs is also excellent, and I suspect one of the biggest time sinks otherwise.

Reply on news.ycombinator.com