As a developer, I am constantly building stuff. I compose elements, wire the cables, configure stuff, not mentioning the endless trail and error.

But I got to confess, unlike what other people thought, I have no ideas what I am building and have no ideas how did I constantly march from point A to point B, again and again.

It’s like sculpturing. Initially it’s just this square stone, cold face and emotionless. And Michelangelo had this very rough idea regarding what this gone-to-born statue “looks like”, then he went on working on it. Staring with big, rough, hard strikes, then moving on to gentle, small and careful brushes.

Then here comes the David. Simple as that, impossible to explain how he did it. He just did it.

People think software could change, and in indeed it could change. But could change doesn’t mean it’s always easy to change. It could become hard, very very hard. It could become so hard that no single person knows exactly what’s going on. I bet anyone knows exactly what happened when anyone types something in the Google search box in fine details.

I had been using Meteor seriously and intensively for a few months this year, and went on seriously doing Rails in my current company, a Rails shop, for a few weeks.

There are some thoughts in my mind hovering, and I just don’t know what those thoughts are. And today in shower, I suddenly realized what those thoughts are about.

It’s about changeability.

Meteor uses MongoDB by default, and I have been using that pretty much like a JSON dump, in other words, like a normal KV database; and Rails come with relational database as default. I mean you could use all kinds databases as your major databases, but Rails still come with sql as default and ActiveRecord works well with relational databases for years, and it won’t change over night.

I could do all those kinds of nice validation and relation macros, structuring my routes like codes in textbooks, and adding crazy amount of functionalities in one monolithic application in an idiomatic way, or splitting them into micro-services as the current fashion.

But it feels so hard. So hard that I got to do migrations whenever I change something in models. An as a man who has no ideas what I am building, I just couldn’t stand it.

And the back-end and front-end is actually separated. That’s really good, but for god’s sake, I don’t really want that good when building a toy. Writing JavaScripts for everything in a highly integrated environment is really easy, as easy as using an App in iPhone.

Some people could write novels with rough skeletons, as they know the plot already, and just finish the book by adding those meat, and make it alive.

I don’t find myself particularly enjoying that(A hard confess, I feel the shame but I got to confess it). And software changes so fast today that I don’t really want to bother with that. Particularly when most of stuff I am building is so small scale, so nothing really matters.

I wrote novels (actually, codes) more like listening to what codes are telling me. Slowly and gradually, codes talk to me and I just follow the orders. I do do some planning/thinking in my head, but it feels more like codes (or this gone-to-born-haven’t-born-ghost-app) are telling a story and I am just writing it out.

But when building big systems, ironically I found myself to the one with perfectionism and like mentioning the buzz word “craftsmanship” three times a day.

When doing Rails I feel I need some kind of proper planning, but when doing Meteor, I feel I am just hacking and making toys.

I think building toys is actually good. When building products, maybe it is even better to just start with toys, rebuild the same toy a few times, get a feeling regarding what’s going on, then move on to serious craftsmanship.

With your final pick of the language, final pick of the framework, or your final creation of your own DIY framework, your final pick of modeling approaches and your final pick of accompanying beer.

I guess writing the same thing three times will make your codes highly specialized and insanely good at the problems in your domains, and I guess the final version will be completely different from the first version.

And I believed that’s the natural evolution. Nothing could be perfect from the very beginning, and usually they did start as shit.

It is good that the codes solve specialized problems are different from generic ones, as they should be different. And it’s also a fact that specialized tools usually don’t solve generic problems well enough.

I guess when I am learning new stuff, I will learn all kinds of tools, take a look at all kinds of frameworks.

And when I am building toys, I will just Meteor. Life is too short to write the perfect codes at one shot. Even though I don’t like everything in Meteor, it’s really good enough for 90% of cases, if not 99%.

And when I need to deal the rest 1%, I will pick the most suitable choice by following the golden principle, “it depends”.