“Don’t trust other objects. After all, they were written by other
people, or even by you last month when you weren’t as smart.
Get the information you need from others, and then do your
own calculations and make your own decisions. Don’t give up
control to others!”
Learn a new programming language. But, don’t go from Java to C# or from C to C++. Learn a new language that makes you think in a new way. If you’re a Java or C# programmer, try learning a language like Smalltalk or Ruby that doesn’t employ strong, static typing. Or, if you’ve been doing object-oriented programming for a long time, try a functional language like Haskell or Scheme. You don’t have to become an expert. Work through enough code that you truly feel the difference in the new programming envi-ronment. If it doesn’t feel strange enough, either you’ve picked the wrong language or you’re applying your old way of thinking to the new language. Go out of your way to learn the idioms of the new language. Ask old-timers to review your code and make suggestions that would make it more idiomatically correct.
Legendary jazz guitarist Pat Metheny has a stock piece of advice for young musicians, which is “Always be the worst guy in every band you’re in.”
Before starting my career in information technology, I was a professional jazz and blues saxophonist. As a musician, I had the good fortune of learning this lesson early on and sticking to it. Being the worst guy in the band means always playing with people who are better than you.
Unfortunately, usability often depends on minor interface details, which is why systematic usability engineering work is necessary to ferrer out those details. For example, Simonelli reports on the development of instructions for a frozen-dinner microwave indicator that would gradually change from being white to being blue. User testing showed that the phrase "turns blue" was much poorer than "white disappears" for describing this change, even though the two phrases are logically equivalent relative to this process. The blue color was not uniform - it was dark blue in some places and light blue in others - so users were uncertain "how blue is blue?" when the first wording was used.
Conozco un planeta en el que vive un señor muy colorado. Nunca ha olido una flor. Nunca ha contemplado una estrella. Nunca ha amado a nadie. Nunca ha hecho otra cosa que sumas. Se pasa el día diciendo, como tú: “¡Soy un hombre serio! ¡Soy un hombre serio!”, lo que le hace hincharse de orgullo. Pero eso no es un hombre, ¡es un hongo!.
" The gold at the heart of MVC is the separation between the user interface code (the view, these days often called the presentation) and the domain logic (the model). The presentation classes contain only the logic needed to deal with the user interface. Domain objects contain no visual code but all the business logic. This separates two complicated parts of the program into pieces that are easier to modify. It also allows multiple presentations of the same business logic. Those experienced in working with objects use this separation instinctively, and it has proved its worth. "