Work Log - Deleting sound assets
Value rigidity - an inability to revalue what one sees because of commitment to previous values.
In motorcycle maintenance, you must rediscover what you do as you go. Rigid values make this impossible.
The typical situation is that the motorcycle doesn't work. The facts are there, but you don't see them. You're looking right at them, but they don't yet have enough value. This often shows up in premature diagnosis when you're sure you know what the trouble is, and then when it isn't, you're stuck. Then you've got to find some new clues, but before you can find them you have to clear your head of old opinions.
If you're plagued with value rigidity, you can fail to see the real answer even when it's staring you right in the face because you can't see the new answer's importance.
-Zen and the Art of Motorcycle Maintenance
My company creates an application called GameSalad, which enables users to create games. Games typically have sounds, either sound effects or music. GameSalad has a feature where users can load sounds into their games. However, users did not have a way to delete sounds from their game, if those sounds were not being used. Therefore, my job was to enable users to delete sounds they weren't using.
This task required me to hook up dialog boxes and buttons to functionality in code. A trivial task - the program needed to know if a sound icon was selected, and if the sound icon was selected, the program needed to know when the user pressed the delete button. If a sound is selected, and the user pressed the delete button, the sound asset would be deleted.
Challenges lay in knowing relationships between different objects. What represented a sound asset? How were sound assets created? Where were they stored? This required me to learn how dialog boxes and buttons tied into code, on the Mac. On Macs, forms and dialogs understand implicitly what functions are available to their views. Their base classes have "selection" features built-in. However, my assumptions on how things worked, based on my experience creating forms in Windows, blocked understanding.
I eventually figured out a solution, but wound up reinventing a lot of code that was already built-in to different Mac forms. I also burned a lot of energy being angry and raging against the backward-philosophy behind Mac development. Mac development is what it is, and accepting that would have made the job much easier.
What you have to do, if you get caught in this trap of value rigidity, is slow down - you're going to have to slow down anyway whether you want to or not - but slow down deliberately and go over ground that you've been over before to see if the things you thought were important were really important. Just stare at the machine. There's nothing wrong with that. Just live with it for a while. Watch it the way you watch a line when fishing and before long, you'll get a little nibble, a little fact asking if you're interested in it. That's the way the world keeps on happening. Be interested in it.
In motorcycle maintenance, you must rediscover what you do as you go. Rigid values make this impossible.
The typical situation is that the motorcycle doesn't work. The facts are there, but you don't see them. You're looking right at them, but they don't yet have enough value. This often shows up in premature diagnosis when you're sure you know what the trouble is, and then when it isn't, you're stuck. Then you've got to find some new clues, but before you can find them you have to clear your head of old opinions.
If you're plagued with value rigidity, you can fail to see the real answer even when it's staring you right in the face because you can't see the new answer's importance.
-Zen and the Art of Motorcycle Maintenance
My company creates an application called GameSalad, which enables users to create games. Games typically have sounds, either sound effects or music. GameSalad has a feature where users can load sounds into their games. However, users did not have a way to delete sounds from their game, if those sounds were not being used. Therefore, my job was to enable users to delete sounds they weren't using.
This task required me to hook up dialog boxes and buttons to functionality in code. A trivial task - the program needed to know if a sound icon was selected, and if the sound icon was selected, the program needed to know when the user pressed the delete button. If a sound is selected, and the user pressed the delete button, the sound asset would be deleted.
Challenges lay in knowing relationships between different objects. What represented a sound asset? How were sound assets created? Where were they stored? This required me to learn how dialog boxes and buttons tied into code, on the Mac. On Macs, forms and dialogs understand implicitly what functions are available to their views. Their base classes have "selection" features built-in. However, my assumptions on how things worked, based on my experience creating forms in Windows, blocked understanding.
I eventually figured out a solution, but wound up reinventing a lot of code that was already built-in to different Mac forms. I also burned a lot of energy being angry and raging against the backward-philosophy behind Mac development. Mac development is what it is, and accepting that would have made the job much easier.
What you have to do, if you get caught in this trap of value rigidity, is slow down - you're going to have to slow down anyway whether you want to or not - but slow down deliberately and go over ground that you've been over before to see if the things you thought were important were really important. Just stare at the machine. There's nothing wrong with that. Just live with it for a while. Watch it the way you watch a line when fishing and before long, you'll get a little nibble, a little fact asking if you're interested in it. That's the way the world keeps on happening. Be interested in it.