A Person, Artist, Software Engineer, Geologist.

I'm only human.  I make plenty of mistakes. Early in my career I thought that mistakes where to be avoided.  I rock climbed and mistakes could be at best scary.  In software development the mistakes I made were to be quickly forgotten as I was learning so fast I needed to focus on what I was doing.  Many of my mistakes were because of the fast pace of learning systems, languages, libraries and the like.  The software world was so large and I wanted to learn as much as possible. I no longer try to know everything.  I just need to know just enough. Now days I cherish watching and understanding how mistakes are made (including my own).  Many of my mistakes now days are still due to incomplete understanding of an issue., but it's far less than it used to be.  I now take time to think before deciding if I have enough information to provide valuable input.  I've also adopted the fortunate habit of asking what I call stupid questions.  Th...

I was reading a post on SlashDot.org this week about a developer asking what language they should learn next to further their professional career.  The poster then stated the languages they would not learn because of personal stances dealing with the languages parent company, political stance or whatever. What an interesting but self limiting point of view. For me, I can't really care or direct which language I develop with, other than to work for a company that generally uses the languages I'm interested in.   If the job and problems are interesting then the language is maybe not as important as what I'm learning.  I'm excluding the choices of using Perl for client side applications or XUL for business logic type of decisions.  I'm talking about sound business decisions by the company for selecting a toolset for a specific project. My job is providing a product for the company with the toolset I have.  If I can do this and a fellow developer is always arg...

I have found that I'm am getting picky on what I take time to learn these days.  I have only so many hours in a day that I can devote to learning that I've gotten real choosy on what to focus on. When I decide to learn something new I need to create a "real" product out of it to completely understand what I'm learning.  I tend to focus on products or technology that, for me, I view as having a long term impact on my knowledge, career or interest.  A couple of these technologies have been JSF (Java Server Faces) iPad iOS development.  Very different technologies but the method of my learning is about the same.  It kinda of goes like this: Get excited. Try to develop a product with this technology. Fail (because of my lack of understanding). Stop and learn why I failed. Try again and Succeed. I did this with both JSF and iOS (iPad).  I (falsely) believe that just because I have a zillion years of experience that I can just pick up new technology and...

It's the topic that stirs much emotion in the software development field. Being in the field for 30+ years I've had the opportunity to be involved with many different types of development methodologies with Agile only being the latest among them. Each of them have aspects that are shared but may be implemented differently in different phases of the development lifecycle and Agile is no different. The need to gather and understand the customers requirements, the need to track progress during coding and to verify the operational aspects of the work thus far. All of these aspects exist in different methodologies to different degrees. My personal perspectives on Agile are: It’s not the holy grail of development methodologies.  It tries to instill from a process what good concerned developers should already contain and just using a different process will not over come developers ill suited for a project.  It tries to instill a mantra that could be perceived as “somewhat” of ...

QA, you gotta love them.  The have the job of finding issues with the code that engineers write.  This should be a very good thing, but there are times where developers view QA as something akin to goblins that live in a haunted forest and should be avoided.  This view is totally without merit. This may be related to thinking that it's a Development -vs- QA world with and "end sum" view where for every winner there must be a loser.  This thinking is very harmful as developers and QA have the same goal, to deliver great software. Staff that works in QA is the last line of defense between what we code (and test?) before the end user (expecting a fault free experience) uses it.   QA's only fault is that they point out our faults, that deep down we already know we have.  Developers could preview if we did our own QA screening, but our minds and ego prevent us from doing so.   We like to think that when we finish code, it's finished, done, ready, compl...

I've been thinking about coupling for a while now.  It's more than just one class or process knowing about another class or process, that happens all the time.  It's about using the minimum amount of coupling in a program for it's operation.   Coupling is not a 'one size fits all' issue where there is a right and a wrong way to use it.  It's more of understanding when to use it, when it happens by accident and in general, being aware of the repercussions when too much coupling exists. In my mind, coupling exists when there is a specific relationship between two classes or processes.  This relationship must be explicit where one class must be coupled by another into for some operation to be viable.  This is not the same as just passing data from one object to another where the data couple be in the form of a third data object (a model, strings, streams, etc) where the two objects are not really bound together but there data is.  This is about object...

I've been learning iPad development lately.  At first I was intimidated with : - The Objective-C language. - No garbage collection (retain / release stuff). - The whole X-Code / Interface Builder. - Their implementation of MVC and the libraries. Whew, it sure seemed like a lot but there are some resources that helped a ton.  The iTunes Standford classes are wonderful.  They tell you all of the things you need to know in perfect chunks, along with the little bits of information of "why". I was very glad to see their implementation of the MVC pattern.  Their implementation was the very close to what I have been doing for years (13+ years). The over all philosophy is one that sync's with mine. - Keeping focused on the task. - Provide only what is needed. - Use strict patterns for the UI (Views, Controllers, Models). - Decouple different problem domains. Having fun....