Good article if you are getting into container services.
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.
You know, I might as well just add dev.to into my RSS feed. Really really great articles over there these last few weeks.
Blaine Osepchuk over on dev.to has an interesting counterpoint to Uncle Bob’s rip on the Atlantic’s article concerning software in safety critical usages. It is a good read and makes valid points (as does Uncle Bob typically, check him out as well).
If you are so inclined to be a vim uber like James LaChance ;).
Sometime we take the most basic of things for granted. Stable dependable internet, phone system, traffic control, having more than 50cents a day for food. Even with a mountain of obstacles Alvaro Videla persevered.
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.
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.
input: data of W format w/ X points
mulate: application code changes date
output: data of Y format w/ Z points
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