A Person, Artist, Software Engineer, Geologist.

I've been learning iPad development lately.  At first I was intimidated with : - The Objective-C language. - No garbage collection (retain / release stuff). - The whole X-Code / Interface Builder. - Their implementation of MVC and the libraries. Whew, it sure seemed like a lot but there are some resources that helped a ton.  The iTunes Standford classes are wonderful.  They tell you all of the things you need to know in perfect chunks, along with the little bits of information of "why". I was very glad to see their implementation of the MVC pattern.  Their implementation was the very close to what I have been doing for years (13+ years). The over all philosophy is one that sync's with mine. - Keeping focused on the task. - Provide only what is needed. - Use strict patterns for the UI (Views, Controllers, Models). - Decouple different problem domains. Having fun....

Us software engineers are told we are smart, earn lots of money and are so important to the company.  We also allow this to go to our heads, forget that we have just as many issues as anybody else (maybe more) and are the root of many of the problems with software development. We want to use language X because we think it's cool. We interpet requirements for our benefit, not the clients. We work to convince others that our logic is better when issues arise. We create the bugs for QA to find. We make the software hard to understand, modify or install. We are the problem. This is a part of being human and something that we all face to some extent.  Being a Buddhist means to know what our issues are and confront them every day. The sad part is that you can see this problem behavior with many developers.  When things go wrong (as they often do), you can see the pattern of denial and defending of actions that caused the problem in the first place.   This all ta...

Think about the role you play in development.  do you write new code or do you fix bugs? It's a trick question!  Every developer's role should including fixing bugs.  We created them and we should take responsibility in fixing them too.  The notion that a developer is so important creating new code that they don't have time to fix their own error is ... well... to say the least, problematic on so many levels.  It's a problem with the company, project and the code that is written. The notion that developers that fix code are not at the same level of those assigned to new features is backwards.  Those that fix bugs have a very difficult job.  They: Do not have as much knowledge about the code as the original author. Work in a wide variety of code written by multiple developers and styles. Should not break any other code.   Do not get to refactor code but have to fix the code in place with the current design.  Even if that design is the...

Our field is a young one.  Young in terms of the average age of engineers in the field doing work.  This has the unfortunate side effect of the same failures to repeat with each generation of developers.  I've been in the field to see a few generations go by and the same mistakes re-appear. Every few years there is talk (hype really) of how a new language or tool is going to revolutionize software development.  The IDE's Languages, development methodologies, etc. are the "hot new thing" in the field. But I've never found that true.  I can still code and produce the same code with the same quality as I did 20 years ago.  The basics are the same, edit, build, run, test.  Yup the tools and computers are much faster today so the cycle time is quicker but it's not 10-100x faster.  More like 2-3 times faster than decades ago.  So what makes one type of development or a project much better than another? From my perspective it's the design. ...

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