A Person, Artist, Software Engineer, Geologist.

Yup, we all do it.  I know when I do it.  I feel bad about it because I'm tring to fool myself and that only makes me the fool. This came out of reading an article in New Scientist (Oct 8th 2011 issue, page 32 if you still use print) about biologist Robert Trivers.  Great interview that was right on (for me at least).  He was not talking about programming, but you know how it applies.  We are debugging a very difficult issue and we try to convince ourselves of what the cause is.  Yeah, right.  Facts are facts but that does not stop use from deceiving ourselves in so many ways.  Convincing ourselves that a bug is really a cool feature.  That we really know how the users will use the product.  On and on and on it goes. One of the most interesting points in the interview is even knowing that we are deceiving ourselves, we still go ahead and do it!  Robert knows it and still does it!  Life hard enough and then we do this to ourselves?  Yuck. The positive side to all of this is be

Been wanting to post about my perspectives on Android development.  This is not a Android -vs- iOS blog but just what I see as my perspective of Android development. Android feels easy.  Java feels like a well broken in shoe that slip on in the morning and can wear all day, so Android development feels easy for me.  I understand the attraction of the Intents and Activities for the providing of multiple filters for handling common features (select you email, photo editors, etc), but I view this as more of a benefit for geeks rather than most consumers.   What kind of support is there for uses that download apps only to be presented with selecting providers for comment activities, only to want to revert to the built in provider (yeah you can clear the selection but they need to know where). The destruction of the activity on rotation and on config changes feels like it's un-needed but exists because of legacy issues.  The save/restore of activities values are simple but feel like

Saw a posting on Slashdot today about a programmer being bored at work and asking what to do about it. Well, Slashdot readers being as they are, mostly responded with some not helpful suggestions (but some where).  Seeing as I've been in the development field or such a long time and had my share of periods of boredom (and almost every other emotion) I thought that I add my response.  Here goes. The first thing to find out is what you are bored with.  It may not be so easy to tell.  Is it the same coding, no designing, no attention, lack of social interaction, gotten into a rut?  It basically comes down to needing some kind of change.  New job always comes to mind, but is that the easiest and riskiest method of forcing change on yourself, never mind that jobs may not be easy to come by.  Change is needed but what and how? For myself, I find I get bored if : I'm not doing anything new I'm not keeping myself busy (I love getting things completed). I've run out of

Words, they can be hard to come by, misleading (on purpose or mistake) and costly.   The word "Done" means many things to different people during the software development process, with most of them not-really correct or helpful. Software Engineer says "it's Done" - The code may have been written but not tested.  Or written but not working, or done "except for some details", or if they told the client it's done, then what does that mean? Project manager says "it's Done" - This depends on whom they are saying this to.  Saying this to a client means that they should expect it in their hands NOW.  If it's the CEO then it means, to appease, to inform, to CYA, etc.? QA says it's "Done" - Then it means it's clear of bugs, ready to ship? Done only means "Done" when the client has it in their hands, installed it and it works as promised.  We have all seen or heard to people using the work "Done"

There are tons of blogs that provide sample code on the web and I've found them so helpful to providing insight to answers I've been looking for.  I would like to thank every one. But my blog does not provide code.  I've been tackling a different side of software development.  The side that is filled not with code, but how we think about code, think about why we do what we do. About source code.  Sooooooo subjective.  It's lifespan is limited to the development process and is soon turned into byte code by a compiler, never to be seen by anyone outside of development.  Source code is like shared painting where everyone has a vision.  The locations of brackets, spaces, names of functions, variable, etc. may instill heated debates from almost any group of developers. My guidelines (only) for myself are: Stay close to what ever standard your company uses.  It's not that big of a deal. Don't reformat others code.  You would not want them to reformat yours an