For six years I worked in a SaaS startup that built an applicant tracking system (a tool to manage recruitment efforts in big/mid-sized companies) tailored for the local market of the country we lived in. My experience tells me that our main value was in forcing them to rethink their recruitment processes, not adapting to their existing ones that were usually all over the place.
As much as I want to believe the opposite to be true as a “power user”, good tools often force you to adopt better practices, not the other way around.
> good tools often force you to adopt better practices
Just wanted to highlight this excellent statement. It's like having a strict type system that enforces certain rules are always met. It provides consistency and predictability.
> rethink their recruitment processes
This context is relevant to the kind of software system that was needed. To improve their processes, it was necessary to impose an explicit top-down order to the existing mess.
Malleable software, on the other hand, feels more suited for personal computing, greenfield projects, or small teams with members working independently as well as collaboratively. Particularly in the early stages of product R&D, strict rules can be a source of friction in the creative process.
Strict better practices and well-designed tools are discovered and developed through open and flexible explorations, as a kind of distillation of knowledge and experience.
I worked for a company that provided a mobile friendly job application form that integrated with major applicant tracking systems (back when they didn’t provide mobile friendly forms).
Our biggest value was getting customers to remove all the extra questions on their applications that had built up over years of management changes that no one had any idea why they were even asking.
Absolutely. When we started growing (I was employee #3, we were about 20 people when I left), we didn't use our own product for our own needs. It wasn't designed for a tiny startup, it would be like building a sand castle with a bulldozer.
But we started as a "boutique" company that implemented everything requested by our then small number of clients (mainly out of desperation, we were self-funded and we didn't have much leeway, we needed those clients). It was as flexible as it gets before the LLM times.
But after a while, you start noticing patterns, an understanding of what works and what doesn't in a given context. Our later customers rarely requested a feature that we didn't already have or we didn't have a better alternative of. It's not like we had a one-size-fits-all solution that we forced on everyone. We offered a few alternative ways of working that fit different contexts (hiring an airline pilot is a very different context than hiring a flight attendant). And in time, this know-how started to become our most important value proposition.
At some point we even started joking about leaving the software business and offering recruitment consulting services instead.
In fewer words: It was already a fairly flexible and customizable tool. But then came a time when a client requested faster horses we could show them our car instead and they recognized the value. (And occasionally, when _they_ requested a car instead of our faster horses, _we_ recognized the value and implemented it).
I write some of my thoughts on this sone years ago. The library described at the end is now fairly out of date but the ideas and suggestions are still good, I think.
The original argument was that neanderthals didn't have good language skills because "their anatomy didn't allow for making complex sounds". Pointing out that deaf or mute humans still have complex language skills seems like an adequate counterargument to me.
That ignores the co-evolution between throat anatomy and brain structures related to language. There's no reason to select for language ability in the brain over evolutionary time if the throat can't use it. If mere ability to use sign language was enough to push language development, chimps would do much better with human-invented sign languages. Deaf and/or mute humans are, I presume, co-opting language skill "meant" (selected) for vocal language.
It also had the best “swipe” text typing mode for Turkish. iPhone got it very recently and it’s close to useless and Android one was meh last I checked.
Another way to induce memory corruption glitches on old computers was to quickly turn off and on again. I never managed to get anything useful like your unlimited lives hack out of it but I did see lots of interesting graphical glitches on my Atari 800XL back in the day.
I believe at least the Vitest project considered using node:module hooks for live reloading but rejected it in the past. The reason given to me was that, there is no way to garbage-collect a real EcmaScript module since they're always reachable by the module ID string as per the specification.
This kind of leak was deemed acceptable in a browser tab (which we tend to close or reload often) but unacceptable for a long-running server process.
Pseudo-modules based on node:vm, on the other hand, will be collected normally when they become unreachable.
