The Long Easy Way Versus the Short Hard Way

Today I had a small discussion with a good technical friend of mine ;) The discussion started with trying to handle an SQL Query with one shot.

The SQL Query got a bit too complicated to handle and needed some extra research, reading and thinking to figure out the correct way to do it. It took two technical brains, good MySQL experience, about forty minutes of work, and at the end some testing. It resulted with a long SQL statement.

Through our work we had another solution, its a very easy solution, get the data you need through multiple SQL statements. Thus, a long but easier way to do it.

We felt so proud that we were able to tackle the short difficult path, but at the end, considering the long easy path we missed, I felt a bit unrelaxed, but as soon as that happened, I was reminded with an important wisdom (by my amigo):

"If you keep choosing the easy and long path, you'll hardly learn anything. It's the difficult short path that provides you with extra skill and power."

Now imagine the amount of skill and power you can gain by choosing the long difficult path. Hmmmm, cool as long as no fatal mistakes takes place.

There's always alternate wisdom supplements when twisting different stories around.

Build space ship 'One' before space ship 'Two'

Whenever you have an idea for a library, product, class or anything else, always remember to build space ship one first, stop collecting extrabonanzic features and ideal design methodologies to reach directly to your dream space ship, start with space ship 'one' always.

This means, if its a product, this would be the minimal set of features that will make it usable.

If its a library, this means exposing the minimal set of functions that are sufficient to achieve the main objective of the library.

If its a class, then allow the smallest simplest possible code that'll make it work.

Ofcourse, before you even think of starting to work on Spache Ship 'Two', remember to launch spache ship 'One', or else, you're skipping the advice.

In a product's sense, space ship one is usually your own design, thoughts and implementation. After launching space ship one, people will start giving you feedback on certain conveniences, improvements, enhancements which you should take into account in space ship two.

The important thing to remember is: "DONT TAKE MUCH FEEDBACK FROM PEOPLE ON SPACESHIP ONE, DONT ADD FEATURES PEOPLE WANT ON SPACESHIP ONE, JUST IMPLEMENT SPACE SHIP ONE AND LAUNCH IT."

Nothing more, nothing less, if you cant launch space ship one, dont even think of building a space ship.

The Idea, The Money and The Environment

I like this analogy and I think it puts an ends to the world wide debate of whats more important, the idea or the money?

The analogy simply states that an idea is the 'seed', the money is the 'water' and the environment the idea gets implemented in is the 'soil'.

Now, all you have to do to understand the effects of the lack or availability of these elements is by substitution and elimination...

If you have a good idea without enough money or without a suitable environment, then it stays in it's passive form, with no yield.

If you have lots of money without a (good) idea and a suitable environment then your money is in its passive form, with no yield.

If you have a wonderful environment without a (good) idea or enough money, then you're environment is in its passive form, with no yield.

When three of them match, you'll get a wonderful tree. However, without sufficient money, it might take longer to grow, without a matching culture or environment then it will take a lot more time to be accepted, but at the end, without the seed, there's absolutely no tree.