Developmental plasticity

 Back in the days, while in college, all I used to care about was getting it done. Had you shown a white textual output on a completely black screen, you would have done buttery smooth in your academics. I must admit this went on till the final year of my college, until it hit me.

I still remember how one of the deciding rounds during my placement was supposed to be something called a "pairing round", one where you'd just bounce off ideas with the mentors and build stuff programatically. What on Earth does 'designing' have to do with programming I thought, until it hit me again!

This time, harder! Months long rigorous training around making us understand how the wheels of a car should have nothing to do with the odometer by design. No, we weren't learning automobile engineering, but engineering an automobile in the software ecosystem. It made sense, making sure responsibilities of objects stay right, don't get mixed up and build up a system as self descriptive units.

I still had to realise its importance though. Things are different when you're performing in a simulation versus the real world. And as expected, I screwed up! Big time. In a race between time and delivery, I missed a small part of the design which would have let me scale it up easily days down the line. Lesson learnt - design rules delivery (*cough* most of the time). I rewrote it, got it reviewed n times, and ended up building a robust module I'm still proud of till date. My intention here is not to brag, I screwed up at the first place!

As the journey went by I found a deep inclination towards infrastructure, or devops. Having done application development all the while I was still trying to map the relationship between design and infrastructure. It exists, definitely, but not distinctly visible. It might probably be because of the tools, terraform some may say, but even the right use of modules in terraform brings a beautiful infrastructural pattern that it seems as if the resources were speaking for themselves. Sounds cheesy! But I found this to be true while playing around ACMs and ACLs. Moreover, CDK is too inclined towards design. There's practically no difference between the design we're used to using in JAVA, versus the one we can use in CDK. Smart move Amazon! Smart move!

And now after realising how integral design is, I'm still astonished by the same thing I've been seeing repeatedly. It's not déjà vu. It's just that I'm discovering bigger, newer chunks where design is practically the same, but it's much more evolutionary than I had seen before. Domains, contexts, bounded contexts, traditional monolith enterprises, modern contextual enterprises, it's a cloud of knowledge that's here to rain for long! And I'm enjoying the rain. I'm still at the initial steps of what it takes to be 'just okay' at design. Then why am I blabbering about it too much? Nothing in particular, just that I remembered that 5 year old self, who after completing a weeks assignment in a day felt as if the task was "done", whereas, if you ask me now, it had never even started.

Cheers!