Finding the motivation to complete.

It happens to all of us. We get a awesome idea, a world changer, an industry changer even. We plan it out, using some fancy or not so fancy tech; months go by, we make good progress, we near the end; we can see the light at the end of the tunnel…then, nothing. Knowing we could do it was enough, the project never reachs release.

Over the years I personally have gotten better about completing projects I start. One of the best ways was to clearly, and strongly define what ‘done’ means. Then pick half of that to be the target ‘done’. Applying the Scotty Principle but in reverse we can work backwards and figure out how much time and effort would be needed. Gauge that against how much time and effort you’re willing to devote, then divide in 1/2. What can you accomplish in that time frame? That is your ‘done’.

Using this process I have been able to release a number of small projects. None of them were meant to be big, granted, but they got finished and I am happy with the state they are in.

How do you keep motivation to complete projects? Let me know in the comments.

Package release announcement. Auto-Gourcer (Repository visualizer)

I’ve always had a soft spot for visualizations. Info-graphics, animations, the the like. One specific tool I came across years back is Gource. Finally got around to writing a wrapper for it. Introducing AutoGourcer! It is a very early release so the functionality is limited but it does work; and that’s progress.

Input, mutate, output…pretty much explains everything.

As a person with many hobbies I often find myself trying to take a situation I am not familiar with and compare it to something I do know. Analogizing the unknown to something that is known seems to make the unknown more palattable.

This came into practice heavily over the weekend as I spent 6 hours with friends deconstructing the front end of my track car. I have indeed done work to it before; but, this is the most major thing I have ever done. Anyway, as we worked along removing part and pieces, and disconnected, and removed, tagged and bagged pieces after piece I realized automotive is not dissimilar to software systems. Then a couple days later having a conversation with the same friend (while somewhat intoxicated) the topic that everything, when boiled down, is input, mutate, output.

 

Software:

input: data of W format w/ X points

mulate: application code changes date

output: data of Y format w/ Z points

Automotive

input: fuel, oxygen, spark

mutate: atomization of the mixture

output linear force upon the piston head creating motion

 

I endeavour to find situations / activities / systems that do not conform to the input/mutate/output process w/o ~really~ stretching the concept or loose the spirit of the application.

 

Bonus: Picture time