[thrdbndndn]

Something related to this article, but not related to AI:

As someone who loves coding pet projects but is not a software engineer by profession, I find the paradigm of maintaining all these config files and environment variables exhausting, and there seem to be more and more of them for any non-trivial projects.

Not only do I find it hard to remember which is which or to locate any specific setting, their mechanisms often feel mysterious too: I often have to manually test them to see if they actually work or how exactly. This is not the case for actual code, where I can understand the logic just by reading it, since it has a clearer flow.

And I just can’t make myself blindly copy other people's config/env files without knowing what each switch is doing. This makes building projects, and especially copying or imitating other people's projects, a frustrating experience.

How do you deal with this better, my fellow professionals?

[blauditore]

Software folks love over-engineering things. If you look at the web coding craze of a few years ago, people started piling up tooling on top of tooling (frameworks, build pipelines, linting, generators etc.) for something that could also be zero-config, and just a handful of files for simple projects.

I guess this happens when you're too deep in a topic and forget that eventually the overhead of maintaining the tooling outweights the benefits. It's a curse of our profession. We build and automate things, so we naturally want to build and automate tooling for doing the things we do.

[bonesss]

I don’t think those web tooling piles are over-engineered per se, they address huge challenges at Google and Facebook, but the profession is way too driven by hype and fashion and the result is a lot of cargo culting of stuff from Big Dogs unquestioningly. Wrong tooling for the job creates that bubble of over complicated app development.

Inventing GraphQL and React and making your own PHP compiler are absolutely insane and obviously wrong decisions — for everyone who isn’t Facebook. With Facebook revenue and Facebooks army of resume obsessed PHP monkeys they strike me as elegant technological solutions to otherwise intractable organizational issues. Insane, but highly profitable and fast moving. Outside of that context using React should be addressing clear pain points, not a dogmatic default.

We’re seeing some active pushback on it now online, but so much damage has been done. Embracing progressive complexity of web apps/sites should leave the majority as barebones with minimal if any JavaScript.

Facebook solutions for Facebook problems. Most of us can be deeply happy our 99 problems don’t include theirs, and live a simpler easier life.

[CuriouslyC]

Not sure why you lumped React in there. Hack is loopy, and GraphQL was overhyped but conditionally useful, but React was legitimately useful and a real improvement over other ways of doing things at the time. Compare React to contemporary stuff like jQuery, Backbone, Knockout, Angular 1.x, etc.

[rokob]

I agree with you very much, if what you are building actually benefits from that much client side interactivity. I think the counterpoint is that most products could be server rendered html templates with a tiny amount of plain js rather than complex frontend applications.

[dlt713705]

First of all, I read the documentation for the tools I'm trying to configure.

I know this is very 20th century, but it helps a lot to understand how everything fits together and to remember what each tool does in a complex stack.

Documentation is not always perfect or complete, but it makes it much easier to find parameters in config files and know which ones to tweak.

And when the documentation falls short, the old adage applies: "Use the source, Luke."

[nananana9]

Don't fall for the "JS ecosystem" trap and use sane tools. If a floobergloob requires you to add a floobergloob.config.js to your project root that's a very good indicator floobergloob is not worth your time.

The only boilerplate files you need in a JS repo root are gitignore, package.json, package-lock.json and optionally tsconfig if you're using TS.

A node.js project shouldn't require a build step, and most websites can get away with a single build.js that calls your bundler (esbuild) and copies some static files dist/.

[latexr]

> As someone who loves coding pet projects but is not a software engineer by profession, I find the paradigm of maintaining all these config files and environment variables exhausting

Then don’t.

> How do you deal with this better, my fellow professionals?

By not doing it.

Look, it’s your project. Why are you frustrating yourself? What you do is you set up your environment, your configuration, what you need/understand/prefer and that’s it. You’ll find out what those are as you go along. If you need, document each line as you add it. Don’t complicate it.

[tekacs]

Honestly... ask an AI agent to update them for you.

They do an excellent job of reading documentation and searching to pick and choose and filter config that you might care about.

After decades of maintaining them myself, this was a huge breath of fresh air for me.

[ehnto]

Simplify your tools and build processes to as few as possible, and pick tools with fewer (or no) config files.

It could depend on what you're doing, but if it's not for work the config hell is probably optional.

[syhol]

You start with the cleanest most minimal config you can get away with, but over the years you keep adding small additions and tweaks until it becomes a massive behemoth that only you will ever understand the reasoning behind.

[iainmerrick]

Right, and then when you don't work on it for 6 or 12 months, you come back and find that now you don't understand it either.

[latexr]

Part of doing it well is adding comments as you add options. When I used vim, every line or block in the config had an accompanying comment explaining what it did, except if the config’s name was so obvious that a comment would just repeat it.

[iainmerrick]

That's a good call. It's a big problem for JSON configs given pure JSON's strict no-comments policy. I like tools that let you use .js or better yet .ts files for config.

[dgacmu]

Or consider jsonc - json with comments - or jwcc - which is json with comments and trailing commas to make life a little easier.

https://jsonc.org/

https://nigeltao.github.io/blog/2021/json-with-commas-commen...

There are a lot of implementations of all of these, such as https://github.com/tailscale/hujson

[iainmerrick]

I like this idea a lot, and pushed for json5 at a previous job, but I think there are a few snags:

- it's weird and unfamiliar, most people prefer plain JSON

- there are too many competing standards to choose from

- most existing tools just use plain JSON (sometimes with support for non-standard features, like tsconfig allowing trailing commas, but usually poorly documented and unreliable)

Much easier just to make the leap to .ts files, which are ergonomically better in almost every way anyway.

[mikkupikku]

A lot of json parsers will permit comments even though it isn't meant to be valid. Worth trying it, see if a comment breaks the config, and if not then use comments and don't worry about it.

[maleldil]

For reference, jq and python don't allow comments.