The other side
March 05, 2010 | ProgrammingAs a developer it is an unique experience when you interact with things like an ATM or DVR. Questions often arise concerning how an ATM or other device that operates using a predetermined set of instructions and a processor. A normal person would think nothing of what's going on in the back, unless an error or unexpected behavior occurs. In that case, they would think or say something such as, stupid ATM, give me my money! Two completely difference responses.
It can take a good number of people to design and build devices like an ATM. There's the person who brings up the problem and an initial solution. There are the engineers that build and verify the system will operate in a method that will solve the problem in an efficient manner. There are the user interface designers who design and test the front facing displays that users interact with. And the customer support people who help out when the inevitable disagreement between computer and human gets out of hand. Just to name a few.
Being a developer, I live the experience everyday of being part of building those systems. There are reasons some things are the way they are, odd as they may be. If I experience an error, I tend to problem solve first, seeing what the problem could be. If I wasn't trained to problem solve first, as in debugging when something doesn't work, I would be among the normal user blaming the company making the faulty product. I guess I don't because I would be blaming my own kind, which would just be awkward?
It could be that I have the curiosity to look closely at things I use so I can learn more about how they work. If I can learn a little more about how a human thinks or interacts with a device, when I build something similar, I can avoid the same mistakes. I can use the knowledge of something that is proven to work in a product that pushes the boundaries of what we see today.
There are always two sides to things.