[cletus]

I live by this principle: If it takes you more than 30 seconds to test a change, you're going to have a huge productivity drain.

That means writing a test should be easy and running it should be fast (including any compilation steps). As soon as something takes more than 30 seconds, you've lost a lot of people. They've switched tabs. They're on HN or reddit or they've pulled out their phone.

You've broken the flow.

Some people can work effectively in an environment where it takes 1-10+ minutes to build something and then you run enough code to test a bunch of changes at once. You might even have multiple clients open at once and you switch between. This doesn't suit me and it doesn't suit a lot of people I've worked with.

Where does local storage fit in? Any test you write will probably need data. You don't want to mock out your data storage. You just want to use the same API and have it be backed by a hash map (or whatever) and have it easy to populate that with data.

Once you have that, local data for something interactive like a website becomes a natural extension.

[andai]

I find it irritating when a program's compile time is perceptible. In compiled languages, TCC (Tiny C Compiler) was the only one that came close, though it doesn't seem to be great for production use.

This made me switch back to JS and Python. The frictionlessness of "I made this change and I see the result in the same breath" is very compelling to me. Fortunately there are fast TypeScript compilers now, which make the process more or less tolerable (in watch mode).

I seem to be in the minority here, preferring instant responsiveness. When I run Windows XP in a VM, and press Win+E, an explorer window is presented to me in the next frame, fully rendered. When I do this on the host OS (Win10), it takes several hundred MS for the OS to draw a window, and then I watch with sadness for several moments as the UI elements are drawn one by one. If they had done nothing for twenty years, it would still be perfect.

I'm also reminded of Casey Muratori doing the Visual Studio questionnaire. They asked how long do you think it should take to launch. The lowest option was "ten seconds", and he found this comical and depressing. VS used to be much faster, too.

[cletus]

I view JS as necessary because of the Web but honestly I don't like doing Python for anything serious because it's a dynamic language and I don't want to write unit tests for spelling mistakes. I realize it's the tool of choice for AI/ML/DS (for good reasons).

But I'm with you on fast compilation and at Google this was the case, even with C++. There was a ton of infrastructure made around this that wouldn't be easy to replicate but I could certainly compile and run a C++ unit test in <20 seconds most of the time.

[andai]

Someone asked me today what's my favorite programming language, and I said Python.

I don't use it very often, but even with minimal experience, (and despite my love for static typing,) it's significantly more pleasant and productive than everything else.

It's unfortunately not a great fit for my main niches (small fast binaries with minimal dependencies, and browser games), but in the areas where it shines, it shines.

[patrakov]

You don't need to write Python unit tests for spelling mistakes. A good IDE will highlight them on the fly, and static analysis tools such as pyflakes or pylint will flag them on demand.

[tgsovlerkhgsel]

Not even "I made this change".

With JS and Python, I can iterate on code in a REPL. Iteration time is measured in milliseconds.

The somewhat-tested code then goes into the code file to be actually tested as part of the product.

[viraptor]

How long it should take to launch VS or the app through VS? I start it once an update, so any time to start is basically amortised to 0. If anything can be sped up later by doing more processing at startup, I'd totally agree to that.

[andai]

VS itself, but now you mention it, VS's build system is also very slow (8 seconds last I checked) compared with just running the same compiler on the command line (about 1 second iirc).

I once turned on verbose build output and just started laughing hysterically at all the useless bullshit it was wasting my time doing dozens of times a day.

So I just use a build.bat now.

[Washuu]

> That means writing a test should be easy and running it should be fast (including any compilation steps). As soon as something takes more than 30 seconds, you've lost a lot of people. They've switched tabs. They're on HN or reddit or they've pulled out their phone.

ADHD can make this worse since a time delay means getting distracted for much longer.

I have been working on testing a single issue for months. I wrote the fix the first day, but because it can only be tested in the remote development environment. An environment that I have zero insight into how it works and also requires coordinator cross-team members to work together for several hours together to test the fix! ...Because if we need to make a change pushing takes twenty minutes to test and build the new environment.

[johnchristopher]

> I live by this principle: If it takes you more than 30 seconds to test a change, you're going to have a huge productivity drain.

> That means writing a test should be easy and running it should be fast (including any compilation steps). As soon as something takes more than 30 seconds, you've lost a lot of people. They've switched tabs. They're on HN or reddit or they've pulled out their phone.

And here I am, compiling tailwind CSS on a blade based template consisting of hundreds of partials. ~30 seconds then refresh. FML.

[PaulKeeble]

My preference is for test feedback to be subsecond, I quite like the auto runners for automated tests. I want to be able to deploy and run the application in less than 30 seconds ideally a lot faster. I also tend to want things like UIs to be auto load as well so I can do small incremental tweaks and have it auto refresh and show the change so you can rapidly iterate them, UIs especially really benefit from very rapid turn around to build them quickly.