A Person, Artist, Software Engineer, Geologist.

I've been busy doing things for a while.  It can seem that being busy and being productive are the same things.  But my definition of "productive" has changed of late.  Productive in what sense? I fight my mind for which direction I should be going, want to go or am going.  All do not lead to happiness.  As of late, programming / designing as not been my happiness trail.  I'm sure it will be later, but my needs now are on a different path. It being spring may be the motivator for this, but doing little jobs around the house, painting, performing fixes on my neglected car "rattles" and getting the garden ready has brought me pleasant rewards. Sometimes you just need a break from all the media in our lives.  The quick sound bites, images and headlines that never truly satisfy.  In no field is this more true than in the software field.  So much information, ideas and products that are just out of reach, for now.  Time and energy can...

Being a software engineer of a certain age, I get to see the same patterns repeat themselves in this field. One of the patterns is companies repeating statements that sound like they are true, want to believe they are true and try to convince others they are true, when they are not. - Visual Basic is object orientated. - Aspect Orientated Programing is the next big thing. - C (or C++) is dead. - Ruby on Rails is the best for web development. - HTML can handle your mobile app needs. Each has it's strength and segment of truth but have reached beyond their domain.  There is a natural desire the share ones enthusiasm with others but this can be taken to extremes where one starts believing in aspects that are not true and believe their own hype. I've been commenting on the Linkedin forums and have found great benefit in helping others and commenting on questions and issues.  It's nice place.  I use Linkedin web site but not their mobile app.  The web site ask...

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...