A Person, Artist, Software Engineer, Geologist.

Every day I fight complexity.  When I look at code and when I write code, I am always questioning myself about the complexity of the code.  I look at the reasons that I find code difficult to work with our understand. Are there hidden dependancies, multiple configurations that must be dealt with for proper operation of the code, is the layout and naming confusing.  All of these factors (and many many more) are what I deal with on a daily basis.  If I find something difficult then how will others find it months or years later? My goal is to reduce the complexity of any code that I design or write so that it's design and implementation are as transparent as possible to the  operational logic that is the main purpose of the code.  This is the end goal, to provide code that does what it's supposed to do with as little impact on the development process as possible. It's not about being smart.  It's not about being super-duper fast.  It's not abo...

Long ago I understood that my skill set was finite and no matter how I wanted to learn other skills, I had a limited amount of time for each skill and other engineers may be a better choice for some tasks.  It's this acceptance that it requires a mix of skills and knowledge that makes a project successful. Many times I moderate my self in discussions when I feel that I do have the expertise and knowledge of a topic to provide help in moving a subject forward.  The difficult part for some people is knowing when their comments are moving a process forward -vs- toward their own agenda or just to be heard.  Expertise is not just about the mastery of a topic but the looking at a topic from multiple directions.  An example of this could be the design of a website.  A graphic artist can make a site that is stunning but not usable.  In this case the graphic artist needs input from an operational expert on the usability of a design.  The factor of maintaini...

When do I know it's time to refactor code? Refactoring is different for every person but for me I follow these guidelines: - If I don't know / understand the code, I don't refactor.  Period! - Is the code broken?  If not then I generally don't refactor - Can the code be made much simpler?  If the amount of code can be reduced by 2x and made cleaner / simpler then I may refactor. - Can the existing code handle the new feature / bug fix?  If not then I may refactor. - I will not refactor the code if I think I have a better way.  Better my be for me but not other developers.  I leave working code working. Tests: I never assume that tests for existing code: -  Has complete code coverage (I've never seen this yet).  I've seen 100% coverage but not all combinations of logic or possible side effects of API changes, etc. - That the tests are even correct.  The tests only test what the developer wanted to test, not what could / should hap...

My thinking toolbox consists of the thoughts that I have when designing and coding.  At a base level what I am concerned about is basically: Will this solve the issue? With others understand this? Can it be maintained and modified? Does this suit the issue? How can this effect other code or other developers? No matter what one does, whether one's deeds serve virtue or vice, nothing lacks importance. All actions bear a kind of fruit. - Buddha  Nothing that we do is without side effects and development is no different.  When a piece of code is designed or written, does it belong to the engineer that wrote it?  Will it ever effect anyone else?  How and why code is written can have far reaching effects down stream of it's creation. One of my concerns for any code that I write is if others can understand it.  My test for this is: Is the code the right complexity for the issue at hand.   Are there any hidden levels of indirection (think refl...

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