I recently ordered a custom tailored set of shirt, trousers, and belt. Their site was bragging about their great AI technology, but sadly I didn't notice that red flag early enough.
The results were nothing short of disastrous. I sent in my measurements and they sent me a trouser with wrong measurements and a postcard that said that they adjusted my measurements with AI for a better fit. The belt they included was a completely different size than the trouser and I'm still waiting for the shirt to arrive. And now I'm fighting the usual uphill battle to talk to a human and get this mess fixed or get a refund.
The core of Stitchfix is personalization, as they say. But that means an individual solution for each individual customer, and not AI for memorizing generic trends in a huge dataset.
That is nothing short of hilarious. The machine knows best! Who are you, human, to pretend you are able to measure yourself?!
> AI for memorizing generic trends
It's possible "AI" may be just a pretext to sell mass-made junk and pretend it is adjusted to each individual.
It's also an internal distraction. They'd achieve something much closer to what they promise if they just threw some old-school regression analysis at the problem. But that's not cool these days, plus it's hard to relabel as AI even for the marketroids these days, and would involve actual work :).
This applies to many "AI companies" - so many want to either have easy process (throw data at some random Kaggle model and hope it sticks) or just a buzzword to bullshit investors with. Sometimes both.
Maybe it could be considered class of fallacy, a kind that one would say the most popular choice of integers between 1 and 2 is 1.5000001.
A lot of people do not in fact know how to measure themselves properly for clothes (many people measure the wrong part of their body for the "waist"). Perhaps even more people think they're a certain size, but have never actually measured themselves, they just go by the measurements on clothes they already own, which are frequently "vanity sized" to make people feel better. I don't envy solving this problem between two sets of users: people who actually have the correct measurements and people who believe strongly that they do, but are quite wrong. Imagine how far off you would be if you went by your Old Navy pants: https://flowingdata.com/2010/09/30/advertised-vs-actual-wais...
"I, For One, Welcome Our Robot Overlords"
into the comments field when ordering :)
> It's possible "AI" may be just a pretext to sell mass-made junk and pretend it is adjusted to each individual.
Actually, I wouldn't mind that too much. It is difficult for me to find well-fitting trousers, so if they can supply those for me, I'm happy as long as the quality is acceptable. Plus their price is roughly half of what a proper tailor would cost me, so I kind of expected them to cut some corners.
This brings a whole new meaning to "over fitting"
It may very well be to my own detriment (there is a lot of promise in either) but fortunately there are lots of interesting problems outside these areas and I can just treat the mention of either of those topics as red flags.
That said, I want to note that I have had good results with Stitchfix but that was due to entering professionally-taken measurements. I got even better results however, from a local to-order suit maker and bought the full suit there, but basic shirt(s) from Stitchfix
And yes, my measurements were also from a professional tailor. But the resulting trouser has (among other issues) been "corrected" to a 15cm shorter outside leg length, so I wonder if a professional vs. an amateur measuring it would have made much of a difference.
Whoa.
customer: Please, I need a trouser size 34"
AI: Thank you sir, but according to my data, a 33" will better suit you
It's WFH time now though, I'm wearing 2/3XL shirts (good cut though, they don't look baggy) and pajama pants and have done so for over a year now. I am here for the comfort.
I'm trying to think of a way this makes sense. Do they have access to some big database about you that they can use to predict how you'll screw up your measurements?
I kind of get where they are coming from, though. I myself also love over-engineering solutions ^_^
Cool, what they mean is they probably have some (barely) linear fits of people to some dimension, but of course that breaks down quick as the USAF found out in the 40s https://www.thestar.com/news/insight/2016/01/16/when-us-air-...
I switched to Bombfell and I had been very happy until my cancellation.(canceled cause I wanted to explore fashion myself)
- Bill Vaughan (https://quoteinvestigator.com/2010/12/07/foul-computer)
Artisans make beautiful things and software artisans make beautiful software, but it’s hard to do it and still be a viable business.
And artisans moving slowly isn’t arbitrary. They move slow on the things that matter. The things that shine when attention was paid to the details.
I have started making this sort of software, and I thoroughly enjoy it. I target the platform I use, I solve the problems I have, and my only metric is pleasure.
I wish we all had more of such projects.
I wouldn't have been able to put so much work in maintaining ArchMac for so long without going completely bonkers had I not taken it this way either.
So it’s entirely possible to build large scale projects this way, and I’m wondering how we could make companies work that way too. At the very least it should be part of any employee sustainability plan.
“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
Obviously, this is totally incompatible with how most software is made in the industry, so I just do it as a hobby instead.
I chose to take this April’s fool that way.
I "move slow and make things" in some sense. I will endeavor to use this as a jumping off point for something constructive rather than leaving a pointless whiney comment about how the world will never understand or appreciate me.
I would love to see “small batch data science” where people actually understand the results. Black box recommendations never feel really right.
In general, if your DS's can't explain the model then something has gone horribly wrong.
I've been calling it my "curiosity killed the cat" spreadsheet. Small batch data science sounds so much more respectable while meaning basically the same thing, I think.
At some point, we started expecting civil and mechanical engineers to stop "moving fast and breaking things." If software engineers were similar licensed and on the hook for signing off on garbage, we'd see a dramatic slowdown of the pace of development, but likely an uptick in quality.
I could imagine it one day even being a bifurcation of the industry. You want to work on cat videos, you can be a non-licensed programmer. You want to work on medical devices or core financial-backbone things? Better be a full-certified Software Engineer.
It's not that hard actually, but you must limit growth. You can easily be profitable and make an amazing product if your goal is not $1B in revenue, but just to be profitable at a small scale, which allows you to run things at your own pace.
And then making things. To me this means no paper prototyping. Not selling people on your idea without having anything tangible. Some may call it smart. To me it feels like gambling with your believability / integrity. There are only so many times you can do this before people get tired of you and your stories / dreams / business ideas. Just make something, show it to people when it’s actually useful. And feel good about actually having made something people liked. Instead of selling something people liked and then suffer the feeling of non-stop pressure, constantly _not_ being where you’ve told others you are.
Happy april fools :)
> There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure."
~~The Tao of Programming
For example, I have https://www.invisible-computers.com up as a website. You can read about the product and you can sign up to be notified. But I won't take a cent until I have a product ready to ship.
But when someone does agree to pay (meaning you've somewhat validated your idea) then you're left empty handed and have to backtrack with your first customer. Not a great start. But that's just me :) YMMV
1. Why "Invisible"?
2. Why such a thick frame? I hope you expand frame choices, or offer a minimal version that customer can frame.
3. I guess you are building a custom UI layout for the calendar data, but please allow any URL to be loaded in the frame, so the community can build custom data views.
I “move slow,” taking the time to test carefully, and leave clean, concise, well-documented code, but I’m told that I actually move at a blistering pace.
I have found there is absolutely no substitute for having an operational, full-feature implementation (I hesitate to call it a “prototype,” because it needs to be fully functional, not just eye candy). I am not a fan of lash-up prototypes, because they invariably become ship code, and starting on a foundation of sand is a very, very bad idea. I short-circuit that, by writing everything as ship code; even my A/B experiments. I can often recycle the rejected code for other projects. It also saves a lot of testing time, as the code is being constantly tested from the start, and being tested while still in scaffolding (meaning more complete testing, overall).
For example, in the app I’m developing now, I’m working on a dropdown screen that allows the user to define search criteria for a database lookup. It’s a complex and fraught operation, and I’ve already had to make a number of changes, based on actually using the facility, as opposed to thinking about using it. If I had simply solidified my original design, it would have been a mess.
I will also be making sure that the facility works for different regions and languages, despite the first implementation being only for the US. It has been my experience that this kind of thing should be built in from the start, as retrofitting it is a nightmare (and bug farm).
My approach does mean that I often need to rewrite a lot of finished, tested code, or throw out big chunks (which is one reason I have a bunch of small, polished, standalone package projects). It’s taught me to design and implement very flexible code (which is actually dangerous, so I often go back, and remove flexibility, once I have settled on an implementation). Nevertheless, I have found it’s the best way to end up with a usable, relevant, high-quality, finished product, that meets the customer’s needs, in a remarkably short time.
DISCLAIMER: This is a viable way to design UX (the kind of code I usually write), but may not be the best approach for “engine” or algorithm code.
The mistake people often make with such things is building it thoroughly enough that it can be shipped.
If you hit that problem, you didn't build a proof of concept - you built sloppy production code.
Their watch, and next the car - will be the next arguably iconic products.
The 'move slow an make things' movement is a much-needed niche to be explored, and a place where I'd love to be.
"slow is smooth and smooth is fast" is something that I'm working to internalize.
This is why I believe, at core, in 100% test coverage.
For a tech business, "move slow and make things" can only be a joke. But for a developer collective, it can be real.
This is GHC / Haskell philosophy. Golang tries too.
I'd _highly_ recommend M-Tailor however as an alternative. It's not a subscription box, but the clothes are extremely well made and the "body scanning" technology actually works (especially for someone of an odd body size like myself: 6'5", 205lbs, athletic build).
Another good company, but I don't know much about other than they're based in Southeast Asia is iTailor. They'll build you -exactly- what you want, to a fault in my experience. Get measured professionally by someone with experience if you're going this route.
As others have mused here and I'll join them: we can use a lot more hand-crafted and "slow" approach. We're chasing our own tails -- ESPECIALLY in programming! -- and progress is nearly non-existent.
I mean, in 2021, people are still debugging multithreaded shared state problems. These should belong to the past -- make it impossible on a hardware level as a start, then the programming languages will adapt in a matter of a few months at the maximum.
It should also be hardware-assisted (if it's impossible to stop it at the hardware level). Stuff like atomic counters were a good first step but the state of the art there hasn't moved in a long time (we don't have atomic 512-bit update operations, do we? if we did, a lot of kernel data structures could be atomically updated; this alone would fix a lot of contention problems).
The hardware can also just work in a CRDT/OT-like manner, namely accumulate update requests for a memory location in small queues (that get flushed after 10 nanoseconds or after the mini queue fills up). This could help with a good chunk of the buggy scenarios as well.
Not saying we can make it perfect tomorrow -- of course we can't. What I am saying is that nobody [who can truly make a difference] is even trying.
It gets a bit disappointing and grim after you have been in the profession for a while, you know?
The article itself is excellent. But the best part is the title is a so much better real credo than the "real" one it parodies.
Every log structure is analyzed by hand. Every log structure data behaviour is verified with statistics by hand. Every log data is normalized by hand. Every parser is done by hand. Every log is documented and gets unit tests.
What has not gone through this process ends up in the "automatic extraction" bucket waiting to get human love.
April's fool or not, you may laugh at me. My L3 security analysts don't.
The slogan is pure gold.
"move slow and make things."
Geninuosly asking. If it becomes a thing, it would only be because the developers push it further... and HN is full of devs. I doubt such a perspective would ever come from "lean" managers and the like.
I move slow and make things because my livelihood doesn't depend on it. I have practically unlimited free time and sufficient income, so I can build things that don't matter.
This isn't the case for more people. Time is money, and being slow means you're not earning much for your time.
It's just that the current way of doing things is financially incentivized.
This part is about when i started dying laughing at every sentence, before i was a bit confused. But only after checking the comments did i realize it was on 1 april.
