Hey .... not that anybody reads my blog... but who cares...
I thought I would mention that there has been something bothering me for a while now. People tend to hand pick reasons in a biased fashion from their basket of reasoning to facilitate their personal causes during a debate.
Being able to stand back and provide totally neutral advice or feedback is one of those gifts that only truly great thinkers amongst us are able to do. Being able to accept and more importantly REALIZE ones mistakes is an even greater gift, and is a true sign of intelligence.
EXAMPLE
The age old debate of stored procs against inline SQL. I prefer stored procs because they extract the SQL from application and provide an abstracted type of database interface along with integrated security. You will get some programmers that will give you the reason that they use stored procs because they can be compiled on the DB level to improve performance. Although this is true the amount of performance gained by a well designed SQL statement RELATIVE to the performance gained by the compilation of the stored proc is not EVEN RELEVANT. i.e. the time the SQL takes to execute against the DB outweighs compilation of the execution plan by 10 to 1 time in 99% of all cases.
As you can see from the above analogy there are always reasons to do the wrong thing but they are outweighed heavily against the reasons to do the right thing. It just takes common sense to weigh then up properly, and make the right decisions.
It's about time for another blog entry...
I find that the two most coveted attributes in a programmer is the appreciation for simple elegant solutions and plain common sense.
It seems as though there are too many of us that enjoy making life unnecessarily complicated within the systems we write/design.
It’s easy to complicate things nowadays with the wide array of abstraction mechanisms we have at our disposal. I always respect programmers/architects that can come up with a simple and scalable solutions. This inevitably pushes the system's complexity into the business rules where it belongs.
Unfortunately, I still find that a lot of programmers/architects make life unnecessarily complicated for the sake of job security. I feel that the one of the most overlooked issues by non-technical/technical management is the responsibility of the programmer (on top of getting the work done on time and within budget) to write self documenting and maintainable code.
Common sense is the one attribute all great programmers have.