This is my review of my first couple of weeks with Ally Bank, and why I ultimately decided to stay with stodgy, old Chase.
When I was 16 years old, I went with my Mom to a local Bank One branch to open my own personal checking account. Bank One eventually got acquired by Chase, and so I’ve effectively been a Chase customer for more than half my life!
But it’s been a love-hate relationship. On the positive side, it seems that no matter where in the United States I am, I’m always less than 3 miles from a Chase branch, so it’s definitely convenient. I also don’t worry about Chase failing so it seems like a safe place to keep my family’s money. Their iPhone app is actually pretty good, especially the ability to remotely deposit checks.
But on the downside, I often get a “big bank” feel from them, mostly owing to the fact that I don’t really have a personal relationship with anyone there. I find I’m usually just engaging the “Chase Infrastructure” rather than contacting a specific person I know.
Earlier today, I met a friend for breakfast who’s an outstanding professional UX designer. I was curious about something:
“How do you balance the need to give people a user interface they’re familiar with and can do something with right away, against the opportunity to innovate and do new things that may take more time to learn?”
He gave a beautiful analogy in response.
“Consider the violin. It has one of the most difficult user interfaces in the world to use. But if you’re willing to put in the thousands of hours of practice, you can make such beautiful music with it. There has to be that trade off. If we demand of our users a steep learning curve, they had better be able to produce some beautiful music.”
I like that idea because I’ve met many designers who get so mesmerized by the idea of doing something new and amazing that they lose sight of the fact that “the tradeoff” has to make sense.
I gave this talk at Desert Code Camp earlier today as part of the DevOps track. It gives an introduction to Chef with a special emphasis on getting you to Hello World and beyond.
They say Chef has a steep learning curve, but I think that’s only because there are a lot of concepts you need to know before you can do the most basic things. I tried to cover most of those concepts here. I also included some best practices I discovered such as how to handle secrets like passwords and certificates using Chef.
Recently, I worked on a sprint as part of our company’s scrum process. This sprint was somewhat unusual in that I was the sole developer. Not only that but I knew most of the specs in my head, so our product manager and I agreed it wasn’t necessary to write acceptance criteria for the user stories I would be working on. Since I wrote the acceptance criteria, it made sense that I would be the one who ultimately signed off on the user stories.
I hate bureaucracy so I was excited about how “lightweight” this process for the sprint was. But I found something kind of interesting.
When I was wearing my developer hat, I realized how much I enjoyed taking time to learn about other technologies. I had made a commitment to my teammates to get a certain amount of work done by a certain date, and we came up with estimates to make sure that the work was achievable.
But once I was doing it, my human nature started subconsciously looking for ways to “cheat”. I still wanted to get the work done, and done well. I wanted to be acknowledged by my colleagues for having delivered what was expected with high quality. But I also wanted to sneak in extra time so I could do more tech learning on the side.