DEV Community

Nitya Narasimhan, Ph.D for DevFestNYC

Posted on • Originally published at Medium on

#1 Coding Fearlessly: Origin Story

This is the first of a series of posts where I will explore the Firebase platform in all its splendor, touching upon the good, the bad, and the “OMG what happened! aspects that make it, in my opinion, a worthwhile tool to add to your dev toolbelt.

Background

Let’s start at the very beginning. Actually let’s not. Let’s just jump in.

This is the first of a series of planned and unplanned-but-serendipitously-interesting posts that I want to write, to cover the full scope of Firebase , the platform that started off as a real-time database but has since evolved into a one-stop-shop catering to all the serverless computing needs of mobile & web developers. And that is both a blessing and a curse.

The Blessing is that, as tech advances rapidly, we as developers need these kind of turnkey solutions and delegation-of-management patterns that can help us focus more attention on crafting unique, fulfilling user experiences instead of spinning our cycles writing, rewriting or managing a lot of the complexity that is required on the server side – but which is often unseen or unappreciated by the consumer.

And because much of this complexity stems from common underlying needs – like authentication, storage, databases, hosting, analytics, payments, performance monitoring, testing, scalability etc. – it actually lends itself well to the backend-as-a-service (BaaS) model. The commonality can be abstracted away into API-based services that can be invoked easily from client-side code – and the process further simplified by standard client-side libraries that are maintained by the BaaS provider, ensuring they are reliable & up-to-date with changing or evolving service features.

The Curse is that these platforms provide a non-trivial set of services but it is not always clear when, how, or why, you need them. Are they really necessary or are we falling for the old-fashioned upsell? What if, using a pharmaceutical analogy, we wanted the brand name service for some feature – instead of the bundled-in generic that is provided by the BaaS? Is that viable? Does that add complexity – and if so, what are the tradeoffs? And finally, will I be making an irreversible decision? In other words, does committing to this platform put me on the path of increased dependency on a technology – such that if, or when, it is deprecated (or worse, sunset-ed), I am not effectively left up the creek without a paddle. Let’s be clear. There is no such thing as risk-free technology – rather the discussion here is more about timeframes for obsoleteness, and pathways for migration or mitigation as the ecosystem evolves.

Goals

First, was my motivation to write a series of articles that explored this space. The target audience was, in fact, me. I’ve found that writing things down helps me see the gaps in my own understanding – and that teaching others helps me see the gaps in the relevance or applicability of those ideas to diverse contexts. But I could never find time to do this just because life!

Second , I am passionate about teaching others, and it occurred to me that having this be a series of articles could effectively come in handy if I were to want to create trails or pathways for students in my “FirebaseCamp events to explore on their own later. In that context, I specifically wanted to highlight the term “ fearless coding_._ Too often I have found that adults, perhaps some more than others, underestimate their abilities and overanalyze their failures because of self-image issues that are often a product of popular culture and not reality. I happen to have been one of them.

I was afraid to admit I didn’t know many things – after 20+ years in tech, it was hard to say “I am not a CS major, I have an ECE background – and most of what I know was self-taught so I have gaps in my knowledge or understanding of foundational things”. It was easier to say “Sure, I know that.” and then pay the price in late nights of studying & innumerable hours of painful debugging to figure it out on my own – rather than just ask for help. Here’s the awesome truth though – once you accept that you don’t know something, you find that an incredible load is off your shoulders and you feel freer to ask questions and actually learn more productively than before. Yes, just saying “I don’t know so TELL me is incredibly empowering and liberating at the same time!!

Hence the focus on Fearless Coding. In this series I am going to say, do and share whatever I know. And when I am wrong – and I will be, many times over – I hope people will correct me, educate me, and help me refine those sections so our collective understanding improves. The important thing is that I now have incredible belief in my ability to learn, understand & apply ideas and I want to help everyone else get to that point of positive self-esteem without fear.

Third , tech moves so fast that sometimes ideas, APIs or tools become obsolete in a matter of months, as new revisions or competitive alternatives emerge. And so this is also meant to be a living document – a place where I can come back and update sections as things change, to reflect current best practices. And also have it serve as a repository of code snippets that describe frequently-used code patterns or quick-lookup method invocation examples, that I can repurpose in my personal and professional projects built with Firebase.

Outcomes

Alright, great. So where do I go from here? I want to write articles and have goals for doing this – but how do I incentivize myself? And what is the endgame?

Glad you asked.

November is National Novel Writing Month (NaNoWriMo). And if there is one thing my recent #30Days foray into habit-forming behaviors showed me, it is that setting goals/routines can get you further towards a desired outcome – even if you might fall short or have to revise estimates along the way.

And so here goes. I am committing to writing my series of articles with the intent of putting them together into a single “novel by December 1.

The focus in November will be to just start getting content in there as articles. I can come back later and finesse the content, update it to be more visual, rearrange or otherwise group things together to form sub-topics etc. It will be raw content but it will be a a start.

Wish Me Luck!


Top comments (0)