A Person, Artist, Software Engineer, Geologist.

The other day, I had one of my team members come to me on how to handle talk with a specific person.  The issues was that this team member felt that they felt pressured into agreeing to something they did not fully understand.  The root issue was in the conversation they had with a different engineer. I'll call this issue, the Fast -vs- Slow thinking syndrome.  This is where one person speak fast, thinks fast where the other person processes information at a different pace. This type of conversation leads the "Fast" engineer to drive the conversions, without giving the "Slow" engineer time to think about all the facets of the topic at hand.  This can lead to the feeling where a decision has been fully vetted when it has not. A possible solution to this is to slow the conversion down but using email, documents, etc. Look around and see if you can spot this in your meetings. * By Slow, I do not mean dumb or simple.  By Slow I'm referring to the pro

As I've been in the software / UI field forever, I've been able to observe changes and how they effect others around me and then, view the results. Sometimes we are so busy, we don't take time to step back and notice the rest of the system we are intwined with and understand what is transpiring.  It's a funny thing.  I always say, it's not what you see, its what you don't see that matters  Statements like "Joe has always made the UI design choices" may instill confidence in Joe, or it could point to the question "is Joe the best person to make these decisions?". It's not often that events appear that actually answer that question (no, Joe is not the best person).    What comes next is what is important.  How does Joe react?  How do others react this news?  This will tell you a lot about the makeup of Joe and the team.  Acceptance and relief will assure you that you have a thoughtful and understanding people to work with and great pr

I've done UI architecture and implementation for-ever, that I've picked up UX along the way.  Now I'm moving more and more in the UX side of things.  Today UX has made the big time, mostly out of necessity.  Prior to about 5 years ago, your company only needed to product an application for a specific need.  But with the advent of mobile (first) and now cloud based apps, the competition is so great to 1) stand out and 2) be better (great even), the focus on UX has become the deciding factor. This of course is great news, but the field is still all over the map.  Personal tastes varies wildly that end results still can miss the mark.  Never mind that businesses are hesitant to actually paid for UX help. As Apple has shown the world, it's all about the design.  A better design can go a long way in making life a little better.  It does not have to save the world, just a little better.

I know how I work.  How a think about, visualize a problem and go about mentally design a solution and implement it in code.  My thought pattern works pretty well for me on most occasions, but not always. There are times when I have a force myself to change my thought pattern because of the problem I'm solving requires a different mindset.  Anyway, this posting is about how I work most of the time.  Here is goes. I quickly break down a feature into operations that are required to exists and tackle that code first.  My thinking is that, if I can solve the primary issues first, then secondary features will fall into "known knowns" and I can address those at anytime (and sometimes at my leisure) and this allows me to meet my internal timeline. If I addressed features and operations that are not primary first, then I feel I risk my (and the projects) timeline without addressing issues that allow the feature to operate.  You may have seen this occur where small features