never mind, as long as it works

I'm sure many of us would have encountered scenarios resulting in such a statement as above. A colleague was trying to figure out why his nested SQL select didn't work. Frankly, I'm also as clueless as he is. I suggested using table joins instead. It worked. Doesn't matter why it didn't work with nested select, as long as we've gotten something that worked. It didn't matter because the SQL statement is only for data analysis.

A more senior colleague was commenting that designers and developers tend to choose the easier way out when implementing new functionalities for the website. The mindset is as long as it eventually gets the new functionality working, who cares if one have to re-create a similar UI feature all over again in different pages. He is trying to have such a mindset changed, but admits that it's not going to be easy; I concur.


Actually, it doesn't matter in which context the "never mind, as long as it works" mindset appears in, it is a dangerous mindset. Dangerous to maintaining the quality of work one delivers. And it is something everyone is guilty of, myself inclusive.

Of course there are scenarios like the former, where lapsing into such laziness would not cause any further "harm". But situations like that latter involves a much more complex problem domain. In such cases, if the improvement towards the better method is certainly desireable and to be pursued, the question to ask is how much would one tolerate more bugs and design mistakes than if one were to stick to the current one-for-one implementation technique?

to upgrade?

My little framework need a upgrade, to Spring perhaps, so that it can be more easily configurable and flexible. But as always, time is not on my side to upgrade it in time to hand in some work. Shall I just make do with what I have now? I think I'll just do that.

Upgrading yourself constantly is necessary to keep your mind fresh and challenged, so that it does not forget the methods with which it learns new things. And frankly, I always get a boost of motivation and confidence during an upgrade. Opportunities to upgrade oneself doesn't just present itself at your feet. One have to seek them out, grab them and then make sure it is made full use of. The headache comes when more than one such opportunities have come and there is only room for one.

pointers

A very powerful feature in C and C++. I have sometimes missed the days which I have hours and hours of headache and fun figuring out how to use or read those *******... hahahaaa... *smiles*

But pointers can be misused. Pointing to memory addresses outside of your array can allow your program to access data that you did not initialise. If you know the address of sensitive data, who knows what you can do to them.

Pointing to data outside of your jurisdiction is a no-no. Similarly, pointing fingers at someone else can be hurting as well. No prizes for guessing correctly at which end of the pointing I was at, but it just reminds me of this:

One have to trust others to do the work one is unable to do. This trust is tested when something fails. If the responsibility is unison, the trust is strengthened. Thus with trust, the work fulfilled.

e=mc^2

Einstein. An article in today's papers reminded me of the strong relationship between believing in simpler methods to visualising a truth.

E=mc^2. The formula for Kinetic Energy is KE=0.5m(v^2). I don't know which came first, but I suspect the KE's is earlier. If indeed so, I'm just pleasantly surprised by the similarity between the two formulae. Einstein did not prove that the mc^2 formula is indeed true when published, but merely derived the formula from a parallel observed from everyday lives. This is the make-up of a ingenious mind.

Unified Theory. I religiously believe that Einstein is right, when he attempts (alas, in vain) for a simpler but unified one theory for everything, including mass, time and space. His theory for general relativity has put us one big step forward in that direction. His belief is that this theory has to be simpler than anything that is present, but not too simple. An paradox? Not quite. The achievemet of the former requires of the mind to see past the obvious and derive simplicity from it while the latter requires the mind to merely accept the obvious even if there is anything to be derived from it.

I may seem not be making any sense here, but it is clear in my mind I'm not babbling nonsense.

log_category=blog (part 2)

The software is about to go-live, thus it's about time to close the logger's handler. The most painful part of the problem has been solved in part 1. Part 2 just requires some time to fix.

Part 2 requires the logging to be "cleaned" up so that the appropriate logs get channelled to the correct log files. There is still some confusion to the logging mechanism, but at least the logs appear, just perhaps to all the log files.

logHandler.close();