A Person, Artist, Software Engineer, Geologist.

From "Buddhist thought of the day" comes this quote: When you give a shilling to a beggar - do you realize that you are giving it to yourself? When you help a lame dog over a stile - do you realize that you yourself are being helped? When you kick a man when he is down - do you realize that you are kicking yourself? Give him another kick - if you deserve it! - Why Lazurus Laughed by Wei Wu Wei... My variation of this theme (because I'm a simple person) is this: Code spends most of it's life being enhanced and maintained by developers other that the original creator.  It should be clear. If it's hard to understand by the next programmer, they are more likely to re-design / re-write it and create new and different bugs. Don't try to show others how smart you are, just make their (and your) life easier.  You will gain new friends and like yourself better. Try to separate the what needs to be done from how it's being done.  This is a defining pillar

I got a new camera recently and am enjoying it.  Yeah it's cool (a Nikon D3000) but that is not the reason I enjoy it.  I enjoy it because it shows things for what they are.  Let me explain. First of all, I'm not that great of photographer but I enjoy looking at pretty things and the camera forces me to take time to do so.  The other thing that camera's do is not being subjective.  When a picture is taken, it is what it is.  It does not place a narrative overtone of what you are seeing, it just shows you the facts. Which brings us to how this is related to software engineering. In any meeting or discussion that occurs with software engineers about technology, design or technique, it's can be difficult to determine what are "facts" about an issue from the different versions of "truth" from engineers.  Truth is not the same as facts, facts don't change.  The sun rises every morning but the truth of why the sun rises may change with culture an

I can't say what code makes you happy but I can tell what code makes me happy. My greatest satisfaction is from : Getting things done (documents, features, working with people, etc). Understanding / learning how a specific framework, library or tool ready works. Visualizing how and why a design works or does not work. A while back I had a couple of very pleasurable moments working with some code.  One moment was working with the Java Swing GUI Library and the other was in a design pattern that was a variation of MVC (Model View Controller), or so I thought. I was working with the Java Swing library trying to get a panel contained in a JScrollPane to set the scroll bar at the top of the viewport.  For a normal panel this is a piece of cake but not when the panels components are dynamically added to the panel after it's made visible.  What made me happy about this task was that it forced me to think of not what I wanted to do but what was really happening inside the lib

It's not that your way is not the right way, it's that everyone has their own right way.  So which is the right way?  Is there a right way? Software development is full of discussions that revolve about the "right" way of doing something. The terms used in discussing software design, tools and implementation are so undefined as to make them meaningless.  Code is not designed and written in a vacuum, it's designed by real people in real companies, each with their own constraints and issues.  Code that may look like a hack could have been the result of an employee dragged out of bed at 2am by a company shirt that only cared that they they did not lose their personal client the next morning.  Everything must be looked at in context.  A project written to "Best Practices" may never be finished before development funding dries up.   Goals, vision, constraints and thoughts should be somewhat aligned for project to be successful (or at least enjoyable in deve