A Person, Artist, Software Engineer, Geologist.

I'm only human.  I make plenty of mistakes. Early in my career I thought that mistakes where to be avoided.  I rock climbed and mistakes could be at best scary.  In software development the mistakes I made were to be quickly forgotten as I was learning so fast I needed to focus on what I was doing.  Many of my mistakes were because of the fast pace of learning systems, languages, libraries and the like.  The software world was so large and I wanted to learn as much as possible. I no longer try to know everything.  I just need to know just enough. Now days I cherish watching and understanding how mistakes are made (including my own).  Many of my mistakes now days are still due to incomplete understanding of an issue., but it's far less than it used to be.  I now take time to think before deciding if I have enough information to provide valuable input.  I've also adopted the fortunate habit of asking what I call stupid questions.  These questions are to verify basic inf

I was reading a post on SlashDot.org this week about a developer asking what language they should learn next to further their professional career.  The poster then stated the languages they would not learn because of personal stances dealing with the languages parent company, political stance or whatever. What an interesting but self limiting point of view. For me, I can't really care or direct which language I develop with, other than to work for a company that generally uses the languages I'm interested in.   If the job and problems are interesting then the language is maybe not as important as what I'm learning.  I'm excluding the choices of using Perl for client side applications or XUL for business logic type of decisions.  I'm talking about sound business decisions by the company for selecting a toolset for a specific project. My job is providing a product for the company with the toolset I have.  If I can do this and a fellow developer is always arguing

I have found that I'm am getting picky on what I take time to learn these days.  I have only so many hours in a day that I can devote to learning that I've gotten real choosy on what to focus on. When I decide to learn something new I need to create a "real" product out of it to completely understand what I'm learning.  I tend to focus on products or technology that, for me, I view as having a long term impact on my knowledge, career or interest.  A couple of these technologies have been JSF (Java Server Faces) iPad iOS development.  Very different technologies but the method of my learning is about the same.  It kinda of goes like this: Get excited. Try to develop a product with this technology. Fail (because of my lack of understanding). Stop and learn why I failed. Try again and Succeed. I did this with both JSF and iOS (iPad).  I (falsely) believe that just because I have a zillion years of experience that I can just pick up new technology and plow a

It's the topic that stirs much emotion in the software development field. Being in the field for 30+ years I've had the opportunity to be involved with many different types of development methodologies with Agile only being the latest among them. Each of them have aspects that are shared but may be implemented differently in different phases of the development lifecycle and Agile is no different. The need to gather and understand the customers requirements, the need to track progress during coding and to verify the operational aspects of the work thus far. All of these aspects exist in different methodologies to different degrees. My personal perspectives on Agile are: It’s not the holy grail of development methodologies.  It tries to instill from a process what good concerned developers should already contain and just using a different process will not over come developers ill suited for a project.  It tries to instill a mantra that could be perceived as “somewhat” of a

QA, you gotta love them.  The have the job of finding issues with the code that engineers write.  This should be a very good thing, but there are times where developers view QA as something akin to goblins that live in a haunted forest and should be avoided.  This view is totally without merit. This may be related to thinking that it's a Development -vs- QA world with and "end sum" view where for every winner there must be a loser.  This thinking is very harmful as developers and QA have the same goal, to deliver great software. Staff that works in QA is the last line of defense between what we code (and test?) before the end user (expecting a fault free experience) uses it.   QA's only fault is that they point out our faults, that deep down we already know we have.  Developers could preview if we did our own QA screening, but our minds and ego prevent us from doing so.   We like to think that when we finish code, it's finished, done, ready, complete, but it&

I've been thinking about coupling for a while now.  It's more than just one class or process knowing about another class or process, that happens all the time.  It's about using the minimum amount of coupling in a program for it's operation.   Coupling is not a 'one size fits all' issue where there is a right and a wrong way to use it.  It's more of understanding when to use it, when it happens by accident and in general, being aware of the repercussions when too much coupling exists. In my mind, coupling exists when there is a specific relationship between two classes or processes.  This relationship must be explicit where one class must be coupled by another into for some operation to be viable.  This is not the same as just passing data from one object to another where the data couple be in the form of a third data object (a model, strings, streams, etc) where the two objects are not really bound together but there data is.  This is about objects like

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 takes place on a

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 problem. Make the product

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.  Design trumps la

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 about theory of develo

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 maintaining a sites content also must b