A Person, Artist, Software Engineer, Geologist.

I just watched a PBS documentary on the  Spartans.   Interesting at time and always informative.  But it wasn't till right at the end where the narrator Bettany Hughes wrapped up the reason for the downfall of the Spartens.   In a nutshell " The Spartens fatal flaw was that in the pursuit of perfection, they made a enemy of change itself ". What a powerful statement! Looking at current events in the software industry I can see instances of this with the the resent staffing changes at Apple and Microsoft.  High level staff, that was thought to be core to the company, have been let go.  Their dogma that used to be OK for the times, now appears to be so harmful that they needed to go.  Times change, change is powerful can not be denied. This can be seen on the smaller more personal scale in the form of language and process dogma that can be held so tightly.  Statements like "your not doing it right if you are not using X". ...

I'm an old timer in Rock climbing.  Not the Faux climbing in the gym but on real rock with whatever surface erosion has provided for it.  I remember a boulder problem on Mt. Woodson that was called Television Screen (aka, Super Edge).  It was a big rectangular block that was tilted just off vertical with an irregular surface and this wonder edge that also had variations in it.  There was just enough of both to provide light hand and food holds to lie back off of while edging with your feet on the face.  It was rated 5.10 and just on the edge of what I could do with my new (then) EB climbing shoes. I was so proud of finally being able to climb it with my new EB shoes.  Then a friend of mine just scurried up in the running shoes!  I could not believe it, regular shoes and much less effort! The difference between the two of us was the context, me -vs- him.  I could do it but I needed better shoes and it was still hard.  He just needed ...

Life is not static so you have to mix it up a bit to keep it interesting.  Well that is what I've done (at least I try to do) with publishing an iBook using iTunes and the iBookAuthor software.  Nothing better than using a new tool and learning about a new field.  My wife is a writer so I wanted to get a little taste of publishing my self, but I'll never be in her league. A lay persons guide into the messy world of software creation. This provides a basic foundation of what software is and the basic forces in it development.  This should provide the reader with the general development process and the complexities that can arise in the phases of development. Free download of iBook here I wanted to lay a foundation of the messy (dare I say wacky) world of software development.  It sounds so high-tech and science like, but for the most part it's the interaction between people, each with there own issues, desires and feelings that are the primary factors in ...

Lately there have been a number of posts on Slashdot.org  about older (40+) software developers or the half life of software developers. I don't use the term software engineers because the majority of younger workers in the software field have not yet gain enough experience and wisdom to be able to consistently and predictable design, plan and implement complex software project without a lot of re-design and refactoring along the way.   Being a bridge engineer does not afford the re-building of a bridge 2 or more times before getting it right.  The same principal also applies to software engineers. Back to the Slashdot articles.  My though on the comments of the half life of software developers only be 15 years is what the company is using their staff for.  If you are interesting in keeping wages down, have only simple to moderately complex projects, use 100's of staff (in this case 4,500) and expect them to not have a life outside of work, then yes, the h...

I'm Lazy. I don't want to write more code than I need to. I don't want to create a design that is too complex. I don't want to write "the next big thing", I just want to get the project done and make it a success. More code = more complexity = more debugging = more testing Even though I'll create bugs, I want them to be easy to fix, so I architect the design for each correction.  I don't want to be asked questions from other engineers on how things work so I make sure the class names, object hierarchy is clean and the operational processes are simple to understand. I don't want to have to hunt all over the code for related behavior so I group them by name or packages. I don't want to have to work late so I under promise and over deliver. I don't want to be confused so I ask stupid questions so that even I can understand what I need to do. I don't get too involved with shiny new objects because 1) too shiny and they distra...

I've been revisiting HTML5 developing of late.  What I've found is three broad categories (I group by nature and habit), of current HTML5 development methods. They are: The tried and true, create your HTML page, add JavaScript and sprinkle with CSS.   Use "heavy weight" framework like Sencha's Ext-JS.  Heavy weight in sense of complexity and understanding.  Even for me it's a bit over whelming. Find a middle ground method that is in between the "build everything from the ground up" approach and the "kitchen sink" toolkits and libraries. I think I have found my "porridge that's just right" development method in the form of Enyo.js.  This is the framework that was born out of WebOS and is now in it's 2.0 release.  It's refreshing not to work in an all too common 0.999 release of a project and with the simplicity and clarity of design and implementation that eludes a project like Sencha EXT-JS. The Enyo.js co...

Just read the book "Team Geek"  (amazon)  today and I would highly suggest reading it.  It's short, to the point and covers almost all aspects of development teams and the issues therein. It's a great book.  It does not mince words on problem staff, management (good and bad) and the multitude of issues that we have all been exposed to in our careers.   The good and the bad. Where Buddhism is about understanding oneself and making changes based on this understanding, this book covers the other side of the coin, working with others, problem staff, management anti-patterns and culture.  I can't say enough good about this book. The only comment I do have is the section on the physical working environment.  There are workgroups on one end and offices on the other.  I understand the flow of communication with workgroups but the interruption and lack of a personal workspace can effect a number of people.  This is somewhat covered by the comm...