The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I'm way too lazy to do Test Driven Dev. I like immediate satisfaction.
But I'm a fan of dogfooding. For those outside microsoft land that means using the stuff you make for your own real world things before release.
It's a royal pain though, precisely because it is good at driving bugs out of hiding.
Unfortunately, because of the complexity of Slang, any real world project with it is the total house that jack built - there's a half dozen steps to go through before reproducing anything, and sometimes bugs only crop up when i use a slang powered tool as a pre-build step which means no debugger.
I can't tell you how many times now I've had to copy the file contents of my Slang Tokenizer from github because my tool keeps breaking it. meh
Still, better now than later.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
But don't overestimate it. It easily ends up as an echo chamber. "It works well for myself, then it must be perfect for the world!" I worked in one company where we hired students on short-term contracts to do both robustness and usability tests: After six months or so, they had learned to think along the same paths as the developers. They did "the right things", and reported fewer problems. We had to bring in new ones twice a year to test and evaluate the products the way users would do it, not the way developers do it.
I consider dogfooding to be the major reason for the failure of many open software projects attempting to compete against commercial end user applications: They tend to do dogfooding only. The products work fine if you are a competent software developer, but you simply can't tell an everyday secretary or dog breeder or truck driver to specify a regex for the search. Not even to use a command shell limited to 7-bit ASCII and you have to escape a lot of characters (escape characters in particular). And so on. The dogfood that pleases the developer dosen't necessarily please the customer.
One story, from the early 1980s: This office automation software, NOTIS[^], was based on an OS where users had a flat set of files - not uncommon in those days. Unix ideas were spreading, and developers were eager to offer a hierarchical file system. So they created an archive system were documents were put in folders, in drawers, in cabinets. From one of the major customers, the University of Oslo Publishing house, we heard that one of editors had found a solution to a problem: She "lost" so many documents, she spent significant resources on searching through all the folders in all the drawers in all the cabinets to find that letter she wrote yesterday. But now she had created a single cabinet, named "Cabinet", with a single drawer, named "Drawer", and a single folder, named "Folder", and moved all her documents into that folder. She no longer spent time on endless searches! All her co-workers rejoiced: That's a great idea! So within a few weeks they all had adopted the same solution, to overcome the problem of "lost" documents.
Today, it may be hard to understand that people couldn't use hierarchical systems properly, but that's how it was. While you could tell a developer to just do a "man find", the "find" syntax is completely incomprehensible to anynone without software background. Dogfooding proves that files can easily be found in a hierarchy. The developer don't see it as a problem. The customer does.