[PaulHoule]

There's something to say for getting in the habit of delivering microprojects with minimal dependencies and tooling.

I do most of my Python work with PyCharm on a Windows machine, frequently with poetry as a dependency manager, but lately I was writing a script for burning DTS-audio CDs in a single step on my Linux server (has the optical drive) and made the decision to only use the Python standard library and do it all in a single file I edit with vim. The result is 150 lines of code that spin like a top.

I went through a phase of doing all the problems on HackerRank and learned to love "single-file Java" and discovered that you can do almost anything in a single file except declare a public class (if it is all in one package, default access is all you need.) It's not the usual way I do things but I like Java a lot more knowing I can write simple programs without maven, an IDE and all of that.

[samsquire]

Most of my code I write is small projects where all the code is in one or two files

I don't enjoy working on enterprise codebase where there's thousands of files that do very little and the code is refactored so hard that you need to jump between 20 classes to understand how it all works and fits together.

Leetcode solutions are usually single file solutions.

My programming language and interpreter are more than one file though. A parser that lexes and creates an AST and an interpreter class and a class for each kind of AST node that do codegen.

I could probably hast used a single file and inner classes.

[hu3]

After years of working with arguably ever-engineered projects where everything is an interface and the actual implementation is hidden so far up the callstack that half the time was spent searching for the file that needed to be changed, I came to like down-to-earth, YAGNI (You aren't gonna need it) mentality. This includes sometimes keeping things in a single file when sensible.

Sure your domains aren't so pure anymore because you've cut some layers of indirection and simplified things. But the cognitive load is so much smaller.

Such a pleasant delight to work on "dumb" code.

As always, it depends on the size of the project. But my threshold for keeping things simpler has certainly shifted towards trying to keep things simpler when possible.