This post was originally published at meluski.com
Meta work is fun, but it is the empty calorie of programming.
Having spent a lifetime (i.e. six years) focusing on Javascript in my career roles, I was alarmed to realize that my already slippery knowledge of backend architecture was escaping my grasp at an ever-increasing rate. In the early days, out of necessity, I worked the entire stack of the website and subsequently managed to sleep through the dev-ops revolution. Scaling? When focusing on the client work, so many scaling issues are assignable to the nebulous backend team, regardless of whether they belong to a third party or your own company.
But that's not how a GOOD engineer rolls. A good engineer understands things they depend upon but they don't contribute to daily. So this probably made me a somewhat bad engineer. A bad, bad, ignorant engineer.
This realization led me to the brash, panicky deep dive which I tend to do when a gap in my armor is exposed. It's a dumb response when I think about it - impulsive and grasping. I do enjoy learning things, so that is the upside. Still, I think I need to be more comfortable about just not knowing things, I can't spend all my life buried in books... can I?
This led me to a couple tomes, one called Building Evolutionary Architectures and another named Building Microservices. Nice, high-level books which focus on the concepts behind the technologies which tend to go whizzing past us so fast that if you take any time out, you're likely to be awash in nonsensical technology jargon.
When I take the time to step back and properly think through things, I find myself desirous of understanding the technology in total - not just how to make it work, but the theory that makes it work. In retrospect, searching out these books is more aligned with the person I want to be instead of flop-sweating and bumbling my way through rickety implementations that fall apart at the first changeset.
Both books cite Conway's Law in some places, and honestly, this is probably the driver which moves us away from the monoliths to which we had become accustomed in the previous decade. Monolithic command and control dynamics will always have a place in architecture design, but much like the HTML <table> they are evolving away from the accepted standard into a consciously chosen use case. As Neal Ford warns in Building Evolutionary Architectures "Make sure your architecture matches the problem domain."
So now we have gained a greater degree of the flexibility and dynamism that we see in our daily lives and workplaces. To meet that challenge as technologists, it seems, is the key. For myself, that means turning theory into action, which is why I turned up an EC2 instance at the first opportunity I saw for practical application. Web servers are the hamburger of the service-oriented architecture menu - steadfast and well known, if not always understood. Everyone offers a server or hosting package, right?
It had been a while, and I hope to do something more than turn a server on and off (at the time of this writing, I had already gotten Nginx set up, so expect more on that). As someone who had worked with clients for a long time, this was a rare opportunity to do some damage in the AWS playground. I had some rare dalliances with Lambda a few years back, but as my company grew I found myself more siloed from basic functions which would require prowess with their services.
As a side note, there was a recent time when I managed to create enormous data transfer charges by treating an S3 bucket as a mounted drive on my laptop. Let's just say that I check in on the Billing part of my AWS dashboard far more often these days.
Top comments (0)