Faceted Classification
From Wikipedia, emphasis mine:
A faceted classification system allows the assignment of an object to multiple characteristics (attributes), enabling the classification to be ordered in multiple ways, rather than in a single, predetermined, taxonomic order. A facet comprises "clearly defined, mutually exclusive, and collectively exhaustive aspects, properties or characteristics of a class or specific subject". For example, a collection of books might be classified using an author facet, a subject facet, a date facet, etc.
Faceted classification is used in faceted search systems that enable a user to navigate information along multiple paths corresponding to different orderings of the facets. This contrasts with traditional taxonomies in which the hierarchy of categories is fixed and unchanging.
Back in the Napster days, I spent a not insignificant amount of time renaming song files and placing them in a hierarchical file system. Each track was named in the following format:
"#{artist_name} - #{album_name} - #{track_number} - #{track_name}.mp3"
And my directory structure looked like this:
- Music
- #{artist_name_1}
- #{album_name_1}
- #{album_name_2}
- #{artist_name_2}
- #{album_name_1}
- #{artist_name_3}
- #{album_name_1}
- #{album_name_2}
- #{album_name_3}
- etc.
With individual track files living inside each album directory.
At the time, I was running Linux on my home PC and spent a lot of time navigating file structures in a shell. Having my music organized hierarchically was useful there, and I spent a bit of effort maintaining the system, even going so far as to write a shell script that would automate the creation of file structures for unclassified files.
Today, my habits have held over even while technology has changed. I still think of my media collection in terms of files (so old fashioned, I know) , and I keep iTunes in the "column browser" view. It works, but it's antiquated; were I more modern, I'd stream media exclusively and would search a cloud library for tags (created through folksonomy), not browse by static, predetermined layers of organization. When I was running Linux that wasn't an option, and my hierarchical organization was my easiest and most effective way of sorting songs. Now, that advantage is slipping away in the music industry, as social and cloud-based streaming services become more and more intelligent about how they thing about the qualities of a song or artist.
In other facets of my life, hierarchical organization gets closer and closer to obsolescence. When managing 3D assembly models, I find it tricky to establish naming sequences that will make sense across projects and phases of development. I tend towards part names that begin with two letters and end with four numbers. In a given filename, I follow the part name with a short verbal description. The end result looks like this:
"BK1008 Rack End.ipt"
Here, the file extension is .ipt, which is the Autodesk Inventor extension for part files. This particular part is one I designed for custom bike racks, and the prefix "BK" refers to bikes. The part lives in a directory called "BK Bike Parts", along with a bunch of other - related and unrelated - parts. Parts are categorized in directories according to the purpose they're originally designed for, but they're often repurposed or discarded. Their part numbers are just placeholders, and the descriptive titles I give them are often mostly meaningless. Often times, one designs a part with a particular form in mind and names it accordingly. Over time, that form changes, and in the end the name is nothing but a vestige. It's a kind of a Theseus' Paradox, and one that conventional naming schemes - or mine, anyway - don't account for well.
I'm happy to say that I have no idea what my files naming sequences will look like in five years. Jordan Brandt, Technology Futurist at Autodesk, predicts the death of files in a way that strikes me as totally prescient here. I'm not totally clear on the implications, but he describes a world in which part metadata is stored at attribute tags, much like Facebook photo tagging. Such a system would, I presume, at least initially require the user to set up searchable tags in order to enable reliable part retrieval. Eventually I'd hope that attributes could be generated predictively, much like Facebook scans photos for faces and auto-suggests likely matches for who to tag.
At this point, my file naming conventions would become irrelevant. Brandt puts it very well - I *never* need to look in a particular folder, or for a particular filename, when I want to find a photo on Facebook. It's tagged with all the relevant data, and with adequate search tools it'll never be hard to find. Eventually I expect the same to be the case for the little gadgets I'm designing: their identities becomes more and more tied to their actual attributes, rather than some arbitrary and cumbersome naming sequence.
Miyamoto
From The New Yorker's great profile of Nintendo's Shigeru Miyamoto. Emphasis mine.
What he hasn’t created is a company in his own name, or a vast fortune to go along with it. He is a salaryman. Miyamoto’s business card says that he is the senior managing director and the general manager of the entertainment-analysis and -development division at Nintendo Company Ltd., the video-game giant. What it does not say is that he is Nintendo’s guiding spirit, its meal ticket, and its playful public face. Miyamoto has said that his main job at Nintendo is ningen kougaku—human engineering. He has been at the company since 1977 and has worked for no other. (He prizes Nintendo’s financial and creative support for his work: “There’s a big difference between the money you receive personally from the company and the money you can use in your job.”) He has never been the company’s (or his own) boss, but it is not unreasonable to imagine that Nintendo might not exist without him. He designed the games and invented the franchises that caused people to buy the consoles. He also helped design the consoles.
This is fascinating to me. I am unclear, in many ways, about the extent of my own desire for ownership of the products I create. Specifically, I can say this: I wish for the experience of providing value more than I do for ownership of what I'm working on. It's totally possible for that to come through individual endeavors, but my experiences working alone have in many ways been lacking in this area, and my natural inclination now is to look for value in collaboration, not solitude. Ownership is secondary, as the benefits it has provided me have been limited by the ultimate value of the work I've done - which value is, I suspect, greater in collaborative settings than not.
Objects in Mirror
Via Hot Wheels.
More Kahneman
A disturbing demonstration of depletion effects in judgment was recently reported in the Proceedings of the National Academy of Sciences. The unwitting participants in the study were eight parole judges in Israel. They spend entire days reviewing applications for parole. The cases are presented in random order, and the judges spend little time on each one, an average of 6 minutes. (The default decision is denial of parole; only 35% of requests are approved. The exact time of each decision is recorded, and the times of the judges’ three food breaks – morning break, lunch, and afternoon break – during the day are recorded as well.) The authors of the study plotted the proportion of approved requests against the time since the last food break. The proportion spikes after each meal, when about 65% of request are granted. During the two hours or so until the judges’ next feeding, the approval rate drops steadily, to about zero just before the meal. As you might expect, this is an unwelcome result and the authors carefully checked many alternative explanations. The best possible account of the data provides bad news: tired and hungry judges tend to fall back on the easier default position of denying requests for parole. Both fatigue and hunger probably play a role.
Daniel Kahneman, Thinking, Fast and Slow; emphasis mine.
Kahneman
Intelligence is not only the ability to reason; it is also the ability to find relevant material in memory and to deploy attention when needed.
-Daniel Kahneman, Thinking, Fast and Slow.
Logo
I remember wanting my logo *so* *much.*
Throughout its development, I worked with Grady Klein, who was a great collaborator and communicator.
When I was younger
I built this frame in 2008. It was the first belt drive bike I built, and hence it was an experiment that I financed on my nonexistent R&D budget. I probably spent $2500 on it, plus something like 40 hours of build time. But that paled in comparison to the time I spent *thinking* about it, which was likely in the 80 hour range. I also developed the graphic design myself, teaching myself Illustrator in the process - add another 20-30 hours there.
I like the bike. It was a pain in the ass, a challenge. I tested out a bunch of new things on it - the S&S seatstay coupling, a new waterjet head tube badge, a new (fancy) paint job with painted-on graphics. I think it came out great, though paint isn't exactly notable for its durability, and now the frame - despite being woefully underused - is chipped and scratched in all manner of places.
Regardless, I love it. I don't know what I thought I was doing, but I fucking took this bike on, and I'm proud of myself that the project being a bit over my head - and over my budget - didn't stop me.
Sloane
Mia Sara blew my mind.
Innovators Patent Agreement
From Twitter's Blog (emphasis mine):
The IPA is a new way to do patent assignment that keeps control in the hands of engineers and designers. It is a commitment from Twitter to our employees that patents can only be used for defensive purposes. We will not use the patents from employees’ inventions in offensive litigation without their permission. What’s more, this control flows with the patents, so if we sold them to others, they could only use them as the inventor intended.
This is a significant departure from the current state of affairs in the industry. Typically, engineers and designers sign an agreement with their company that irrevocably gives that company any patents filed related to the employee’s work. The company then has control over the patents and can use them however they want, which may include selling them to others who can also use them however they want. With the IPA, employees can be assured that their patents will be used only as a shield rather than as a weapon.
Bezos
From the Amazon Shareholder Letter, 1998:
During our hiring meetings, we ask people to consider three questions before making a decision:
Will you admire this person?
If you think about the people you’ve admired in your life, they are probably people you’ve been able to learn from or take an example from. For myself, I’ve always tried hard to work only with people I admire, and I encourage folks here to be just as demanding. Life is definitely too short to do otherwise.
Will this person raise the average level of effectiveness of the group they’re entering?
We want to fight entropy. The bar has to continuously go up. I ask people to visualize the company 5 years from now. At that point, each of us should look around and say, “The standards are so high now -- boy, I’m glad I got in when I did!”
Along what dimension might this person be a superstar?
Many people have unique skills, interests, and perspectives that enrich the work environment for all of us. It’s often something that’s not even related to their jobs. One person here is a National Spelling Bee champion (1978, I believe). I suspect it doesn’t help her in her everyday work, but it does make working here more fun if you can occasionally snag her in the hall with a quick challenge: “onomatopoeia!”
The damage done by tornadoes
4D Printing & Self Assembly
Skylar Tibbits is awesome.
From the video notes:
This project investigates chiral self-assembly with many parts in order to explore the aggregate behavior of simultaneous assembly and self-selection. 240 pieces are agitated to self-assemble closed molecular structures. The continual process shows the various stages of assembly from independent parts to fully assembled structures.
This work points towards a future of both tangible educational tools for scientific phenomena as well as new possibilities for industrial-scale assembly.
Skylar Tibbits has some pretty awesome stuff on Vimeo. This one is beautiful:
Here he explains his work at the MIT Self Assembly lab, and shows a few other cool projects:
Awesome robots
These things self-assemble into different shapes. Pretty awesome.
Chris
I know it's hard to tell, but this is Chris, engraving some parts on my old pantograph in early 2010.
I like dark photos :)
The Character of Prediction Errors
Nassim Nicholas Taleb, The Black Swan, pp.159-160.
Like many biological variables, life expectancy is from Mediocristan, that is, it is subjected to mild randomness. It is not scalable, since the older we get, the less likely we are to live. In a developed country a newborn female is expected to die at around 79, according to insurance tables. When she reaches her 79th birthday, her life expectancy, assuming that she is in typical health, is another 10 years. At the age of 90, she should have another 4.7 years to go. At the age of 100, 2.5 years. At the age of 119, if she miraculously lives that long, she should have about nine months left. As she lives beyond the expected date of death, the number of additional years to go decreases. This illustrates the major property of random variables related to the bell curve. The conditional expectation of additional life drops as a person gets older.
With human projects and ventures we have another story. These are often scalable...With scalable variables, the ones from Extremistan, you will witness the exact opposite effect. Let's say a project is expected to terminate in 79 days, the same expectation in days as the newborn female has in years. On the 79th day, if the project is not finished, it will be expected to take another 25 days to complete. But on the 90th day, if the project is still not completed, it should have about 58 days to go. On the 100th, it should have 89 days to go. On the 119th, it should have an extra 149 days. On day 600, if the project is not done, you will be expected to need an extra 1,590 days. As you see, the longer you wait, the longer you will be expected to wait.
Let's say you are a refugee waiting for the return to your homeland. Each day that passes you are getting farther from, not closer to, the day of triumphal return. The same applies to the completion date of your next opera house. If it was expected to take two years, and three years later you are asking questions, do not expect the project to be completed any time soon. If wars last on average six months, and your conflict has been going on for two years, expect another few years of problems.
I enjoy Taleb's writing, but I often find his citations opaque. AFAICT, this is the only citation for the passage above:
If anyone can explain exactly what he's saying here, I hope they chime in - but, again, AFAICT, Taleb hasn't actually taken a survey of late projects to determine the numbers he quotes above. Again, I'd love to know if I'm mistaken here, and regardless I find his argument fascinating and compelling.
Aaron Dignan on The worst game ever.
Aaron Dignan, quoted by smartplanet earlier this year:
Imagine playing a game where you only get feedback once a year in an annual review? It would be the worst game ever. And yet, that’s the game we play at work.
My last job prioritized production over team feedback. It was, of course, not by design, and nobody would have actually articulated anything to that point, but looking back I regret not speaking up. But the nature of the company was that projects were sold before the infrastructure to deliver them was in place, and the result was that we were - at least during my time there - always behind schedule. Efforts were made to emphasize team building and open communication, but when projects are late by as much time as they were originally projected to be completed in, it's difficult to put much energy into anything but hurrying the hell up.
In the end, I was complicit in these tendencies as well. I can distinctly recall the spacey way in which I would listen to my reports talk about their families; I absorbed as much as I needed in order to ask a question from time to time, but I wouldn't say I put a ton of effort into *really* hearing them. I was careful to provide positive feedback when warranted (and negative feedback when necessary), but our product's long term prospects were too hazy - and my own feelings about the company were too conflicted - for me to really engage in the discussions that I'm sure mattered most.
Parts
I took these photos in 2009, and meant to do something with them for a long time.
The seat lug remains unused, though I'd like to change that. The stem went on Ian's bike. The hand vise is actually very handy, though career shifts mean that I don't use it often anymore.
A good afternoon's work
This. Was fun.
Happy Friday, everyone.
What "honey" means
;)